Messages in this thread | | | Date | Wed, 11 Dec 2013 18:18:07 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: process 'stuck' at exit. |
| |
On Wed, 11 Dec 2013, Oleg Nesterov wrote: > On 12/10, Linus Torvalds wrote: > > > > I think what happens is: > > - get_user_pages_fast(address, 1, 1, &page) fails (because it's read-only) > > - get_user_pages_fast(address, 1, 0, &page) succeeds and gets a large-page > > - __get_user_pages_fast(address, 1, 1, &page) fails (because it's read-only). > > > > so what triggers this is likely that Dave now does large-pages, and > > one of them is a read-only mapping. > > > > So I would suggest replacing the second "1" in the > > __get_user_pages_fast() call with a "!ro" instead. So how about this > > second patch instead (the access_ok() move remains). > > I know almost nothing about THP, but why we may need write == true in > this case? > > IOW, > > > - if (likely(__get_user_pages_fast(address, 1, 1, &page) == 1)) { > > + if (likely(__get_user_pages_fast(address, 1, !ro, &page) == 1)) { > > can't > if (likely(__get_user_pages_fast(address, 1, 0, &page) == 1)) { > > work?
If the futex call needs to write to that address, we need a writeable mapping, right? And get_user_pages_fast() will verify that for us.
> I have to admit, I do not understand why we can't avoid this altogether. > > __get_page_tail() can find the stable ->first_page, why get_futex_key() > can't ?
Because it can be split under us.
Thanks,
tglx
| |