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

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

Post by david sing » Fri, 20 Jan 2006 11:30:09



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
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(+)
 
 
 

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

Post by Andrew Mor » Fri, 20 Jan 2006 14:30:16

avid singleton < XXXX@XXXXX.COM > wrote:


It's worth putting this field inside CONFIG_ROBUST_FUTEX


Indenting went wonky.


Nice comment!


Is this test needed?

This function is called when a dentry's refcount falls to zero. But there
could be other refs to this inode which might get upset at having their
robust futexes thrown away. Shouldn't this be based on inode destruction
rather than dentry?


inodes never have a null ->i_mapping


If we're throwing away the entire contents of the list, there's no need to
detach items as we go.


What locking guarantees that vma->vm_file->f_mapping continues to exist?
Bear in mind that another thread which shares this thread's files can close
fds, unlink files, munmap files, etc.


That's a bit unconventional - normally we'd perform the other-task-visible
write and _then_ wake up the other task. What prevents the woken task from
waking then seeing the not-yet-written-to value?


The name "find_owned_mutex" is a bit misleading - it implies that it is
some lookup function which has no side-effects. But find_owned_futex()
actually makes significant state changes.


The patch in general does an awful lot of these lengthy pointer chases.
It's more readable to create temporaries to avoid this. Sometimes it
generates better code, too.

The kmem_cache_free above is a bit sad. It means that in the common case
we'll allocate a file_futex and then free it again. It's legal to do
GFP_KERNEL allocations within mmap_sem, so I suggest you switch this to
allocate-only-if-needed.


Again, we could have checked whether we needed to allocate these before
allocating them.


Pointer chasing, again...

^
A stray space got in there.


A bit of 80-column wrapping needed there please.

Are futex_heads likely to be allocated in sufficient volume to justify
their own slab cache, rather than using kmalloc()? The speed is the same -
if anything, kmalloc() will be faster because its text and data are more
likely to be in CPU cache.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

 
 
 

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

Post by Ingo Oese » Sun, 22 Jan 2006 06:00:23

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/



Couldn't even detach the list elements first by

list_splice_init(&mapping->robust_head->robust_list, head);

and free the list from "head" after releasing the mutex?
This would reduce lock contention, no?


The goal here was to do cheap futex accounting, as described in the
documentation to this patch.


Regards

Ingo Oeser


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBD0SDEU56oYWuOrkARAtXcAKC3W5b84Lv/Z0V9T15gDskilWb57gCgsjw4
GlemIowOqSCDn80g5XKbsMA=
=mE5B
-----END PGP SIGNATURE-----
 
 
 

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

Post by Andrew Mor » Sun, 22 Jan 2006 07:20:20


Yes, it would reduce lock contention nicely.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

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

Post by david sing » Sun, 22 Jan 2006 11:40:15


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/





Incorporated changes suggested by Andrew Morton and Ingo Oeser.

fs/inode.c | 2
include/linux/fs.h | 4
include/linux/futex.h | 33 ++++
init/Kconfig | 9 +
kernel/exit.c | 2
kernel/futex.c | 399
++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 449 insertions(+)



David
 
 
 

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

Post by Todd Kneis » Wed, 25 Jan 2006 03:30:58


In an early version, it was based on inode destruction. But inodes are
not destroyed
at process termination. If I understand the code, they're cached so that another
process that opens the same file will not have to build the inode from scratch.

So I based it on the dentry's refcount falling to zero, which occurs at process
termination. I did consider the problem of other references to the
inode. The only
scenario I could come up with was mapping the file using hard links. Then there
would be multiple dentrys referencing the same inode. This could be fixed by
adding a refcount to the futex_robust structure, but I never got around to doing
this.

Todd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/