Lines Matching refs:no

22 state, and there's no in-kernel state associated with it. The kernel
40 the kernel cannot help with the cleanup: if there is no 'futex queue'
42 then the kernel has no information to clean up after the held lock!
43 Userspace has no chance to clean up after the lock either - userspace is
44 the one that crashes, so it has no opportunity to clean up. Catch-22.
71 because the kernel has no knowledge about how many robust futexes there
92 In the common case, at do_exit() time, there is no list registered, so
123  - it's much, much faster: at thread exit time, there's no need to loop
127  - no VM changes are needed - 'struct address_space' is left alone.
129  - no registration of individual locks is needed: robust mutexes dont
135  - no per-lock kernel allocation happens.
137  - no resource limits are needed.
139  - no kernel-space recovery call (FUTEX_RECOVER) is needed.
141  - the implementation and the locking is "obvious", and there are no