Messages in this thread |  | | Date | Sat, 16 Feb 2008 14:41:55 +0100 | From | Heiko Carstens <> | Subject | Re: + futex-runtime-enable-pi-and-robust-functionality.patch added to -mm tree |
| |
On Sat, Feb 16, 2008 at 02:05:13PM +0100, Thomas Gleixner wrote: > On Sat, 16 Feb 2008, Heiko Carstens wrote: > > > + /* > > > + * This will fail and we want it. Some arch implementations do > > > + * runtime detection of the futex_atomic_cmpxchg_inatomic() > > > + * functionality. We want to know that before we call in any > > > + * of the complex code paths. Also we want to prevent > > > + * registration of robust lists in that case. NULL is > > > + * guaranteed to fault and we get -EFAULT on functional > > > + * implementation, the non functional ones will return > > > + * -ENOSYS. > > > + */ > > > + curval = cmpxchg_futex_value_locked(NULL, 0, 0); > > > + if (curval == -EFAULT) > > > + futex_cmpxchg_enabled = 1; > > > + > > > > Why should that fail? You're accessing a kernel space address here and no > > user space address. > > Well, NULL pointer dereferencing is supposed to fail, isn't it ?
I wasn't sure that this is true for all architectures, but...
> > Indeed it does fail with an Oops on s390 since we enable low address > > protection in the kernel so we get an exception if something within the > > kernel writes to the first 512 bytes of the kernel address space. > > Otherwise it would have silently passed the test... > > NULL pointer dereferencing faults on all architectures, at least it > should, but we explicitely disable pagefaults and recover via the > extable fixup, which is in S390 as well. That returns -EFAULT and > signals that there is a working implementation, while those which have > no support return -ENOSYS, which keeps the robust/pi stuff disabled.
...one of our exception table entries has an off-by-one bug. Never mind, I'll go and fix our own stuff instead ;)
|  |