Messages in this thread | | | Subject | RE: [RFC/PATCH] FUSYN Realtime & Robust mutexes for Linux try 2 | Date | Sat, 6 Dec 2003 17:15:16 -0800 | From | "Perez-Gonzalez, Inaky" <> |
| |
> From: Jamie Lokier [mailto:jamie@shareable.org]
I had one question for you I forgot to ask wrt to fulocks.
In the vlocator code I ripped your stuff for get_futex_key() to generate the unique ID. Now, in ufulocks I need to access the user space page where the vfulock is to modify it when we fiddle with the ownership of fulock state to keep it in sync; in every case we need to pull it up from swap if it is there because we'll read and potentially write.
As I do it now is the lazy way. I just pin the page and keep it in fulock->page. This is kind of ugly because it reverts back to the old futex behavior of 'page pinned while waiting'.
Now, I'd love to be able to have a key that can be used to pull the 'struct page' from, so I don't need to pin the page while waiting.
This would be easy to do if we only had the lock and unlock cases, as both have direct and easy access to the location of the vfulock in current's address space.
However, the problem is in __ufulock_exit(); in this case, we don't necessarily have access to the address space of the exiting thread. I am thinking of just adding the user space address an an ownership property so __ufulock_exit() can use it, but I am kind of concerned on what would happen if a shared area were unmapped while owning a lock that is supposed to be on it.
Do you have any ideas on what would be a good way to do this?
Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |