Messages in this thread | | | Date | Fri, 27 Mar 2009 19:56:41 +0900 | Subject | Re: Question about PRIVATE_FUTEX | From | Minchan Kim <> |
| |
Hi, Perter. Thanks for joining this thread.
My concern is page reclaimer can reclaim the user page which have futex between get_fuex_key and get_futex_value_locked.
On Fri, Mar 27, 2009 at 5:49 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Fri, 2009-03-27 at 11:12 +0900, Minchan Kim wrote: >> Hi, Peter and Eric. >> >> I am not expert about futex. >> I am sorry if this is dumb question. >> >> If we use private futex, get_futex_key don't call get_user_pages_fast >> which pins page at page table. > > But also drops that page ref at the end of get_futex_key(). The whole > and only purpose of using get_user_pages_fast() is to get at the mapping > data without having to obtain the mmap_sem.
Thanks. I understand. It's not only private futex.
> >> Then, get_futex_value_locked calls __cpy_from_user_inatomic with >> pagefault_disable. >> >> Who make sure the user page is mapped at app's page table ? > > Nobody, all uses of get_futex_value_locked() have to deal with it > returning -EFAULT.
Does It mean that __copy_from_user_inatomic in get_futex_value_locked would be failed rather than sleep? In fact, I don't make sure _copy_from_user_inatomic function's meaning. As far as I understand, It never sleep. It just can be failed in case of user page isn't mapped. Is right ? Otherwise, it can be scheduled with pagefault_disable which increments preempt_count. It is a atomic bug. If my assume is right, it can be failed rather than sleep. At this case, other architecture implements __copy_from_user_inatomic with __copy_from_user which can be scheduled. It also can be bug.
Hmm, Now I am confusing.
> Most of this is legacy btw, from when futex ops were done under the > mmap_sem. Back then we couldn't fault because that would cause mmap_sem > recursion. Howver, now that we don't hold mmap_sem anymore we could use > a faulting user access like get_user(). > Darren has been working on patches to clean that up, some of those are > already merged in the -tip tree.
Thanks for good information. It will be very desirable way to enhance kernel performance.
> HTH >
-- Kinds regards, Minchan Kim
| |