Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH] powerpc: Select HAVE_FUTEX_CMPXCHG | Date | Sat, 19 Sep 2020 13:50:41 +0000 |
| |
From: Samuel Holland > Sent: 19 September 2020 04:20 > > On powerpc, access_ok() succeeds for the NULL pointer. This breaks the > dynamic check in futex_detect_cmpxchg(), which expects -EFAULT. As a > result, robust futex operations are not functional on powerpc.
access_ok(NULL, sane_count) will succeed on all (maybe most) architectures. All access_ok() does is check that kernel addresses aren't referenced. (access_ok(kernel_adress, 0) is also likely to succeed.)
It is the access to user-address 0 that is expected to fault. If this isn't faulting something else is wrong.
Historically (at least pre-elf, if not before) user programs were linked to address zero - so the page was mapped. (Linux may be too new to actually require it.) Not sure what 'wine' requires for win-32 execuatbles.
ISTR there are also some 'crazy' ARM? cpu that read the interrupt vectors from address 0 in user-space.
So assuming:
static void __init futex_detect_cmpxchg(void) { #ifndef CONFIG_HAVE_FUTEX_CMPXCHG u32 curval;
/* * 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. */ if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT) futex_cmpxchg_enabled = 1; #endif }
will fail -EFAULT because user address 0 is invalid seems hopeful.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |