Date: Fri, 28 Nov 2014 10:29:02 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Message-ID: <bug-193367-16-TK0OZVNda5@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-193367-16@https.bugs.freebsd.org/bugzilla/> References: <bug-193367-16@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #10 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to Eygene Ryabinkin from comment #8) > Looks like there is at least off-by-one access to the driver-specific ioctl > array, http://codelabs.ru/fbsd/patches/drm2/fix-drm_drv-off-by-one.diff, > since max_ioctl is not a number of a highest supported ioctl number, but > rather a size of driver's ioctl array. I think that the patch is wrong, and there is no off-by-one bug. At least in i915 case, max_ioctl is initialized as nitems(i915_ioctls), which is the number of array elements. Applying your patch, the last ioctl in the driver-specific array becomes inaccessible. As an easier test, consider what would happen after your change if array consists of single element. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193367-16-TK0OZVNda5>