[robust-futex-4] futex: robust futex support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Ulrich,
I've incorporated your suggestions, wih the exception of passing the pthreaad mutex attribute into the kernel for futex_register. I'd like to be able to 
pass the attributes associated with the pthread_mutex into the kernel
so the kernel can support whatever attributes are on the mutex without
having to change the interface between glibc and the kernel.

	If we pass the attributes in for robustness we don't have to change
the interface if/when the kernel supports other attributes, like
priority inheritance.

	Let me know what you think of the implementation, and thanks
for the suggestions, they made the patch much less intrusive.


David

The original code for this patch was supplied by Todd Kneisel.

 Incorporated changes suggested by Urich Drepper.

 fs/dcache.c           |    2
 include/linux/fs.h    |    2
 include/linux/futex.h |   33 ++++
 init/Kconfig          |    9 +
 kernel/exit.c         |    2
kernel/futex.c | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++ 
 6 files changed, 443 insertions(+)

Attachment: robust-futex-4
Description: Binary data



On Jan 17, 2006, at 9:50 AM, Ulrich Drepper wrote:


And another thing: semaphores are on their way out.  So, in
futex_deregister and in futex_head, shouldn't you use mutexes?  I
don't see that you realy need semaphores.

In futex_register, you define mm and initialize it with current->mm.
That's OK.  But why then are you using

+       down_read(&current->mm->mmap_sem);

just a few lines below?

And finally (for now): in get_futex_key the VMA containing the futex
is determined.  And yet, in futex_register you have an identical
find_extend_vma call.  I don't know how expensive this function is.
But I would assume that at least the error handling in futex_register
can go away since the VMA cannot be torn down while mmap_sem is taken,
right?  But perhaps this just points to more inconsistencies.  Why is
the list/sem lookup in get_futex_key?  Only to share the code with
futex_deregister.  But is that really worth it?  The majority of calls
to get_futex_key come from all the other call sites so the code you
added is only a cost without any gain.  Especially since you could in
futex_register do the whole thing without any additional cost and
because most of the new tests in get_futex_key are again tested in
futex_register (to determined shared vs non-shared) and do not have to
be tested in futex_deregister (we know the futex is in shared memory).

I suggest that if find_extend_vma is sufficiently expensive, pass a
pointer to a variable of that type to get_futex_key.  If it is cheap,
don't do anything.  Pull the new code in get_futex_key into
futex_register and futex_deregister, optimize out unnecessary code,
and merge with the rest of the functions.  It'll be much less
invasive.
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux