Michel Dänzer wrote: > On Wed, 2009-08-05 at 10:50 +0200, Thomas Hellström wrote: > >> Michel Dänzer wrote: >> >>> From: Michel Dänzer <[email protected]> >>> >>> Make sure bo->vm_node is valid, to prevent crashes in the fault handler, and >>> adjust vma->vm_pgoff according to it, so userspace attempts to access >>> /dev/fb* >>> mappings don't always result in SIGBUS. >>> >>> Signed-off-by: Michel Dänzer <[email protected]> >>> --- >>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 ++++++ >>> 1 files changed, 6 insertions(+), 0 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c >>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c >>> index 27b146c..57d0c94 100644 >>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c >>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c >>> @@ -282,7 +282,13 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct >>> ttm_buffer_object *bo) >>> if (vma->vm_pgoff != 0) >>> return -EACCES; >>> >>> + if (!bo->vm_node) { >>> + printk(KERN_ERR TTM_PFX "bo->vm_node == NULL\n"); >>> + return -EACCES; >>> + } >>> >>> >> Michel, >> Did you actually hit a bo with an invalid vm_node? >> > > See patch 3 - the radeon driver used to create the fbcon BO as > kernel-only, so when I tried passing that to ttm_fbdev_mmap() > all /dev/fb* userspace mappings mysteriously caught SIGBUS on access. It > took me a while to track that down, this is basically a debugging aid > for bugs like that. >
Ah, OK. But since that is really a kernel bug, we should trap it with BUG_ON(). /Thomas ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
