Messages in this thread | | | Subject | Re: One (possible) x86 get_user_pages bug | From | Peter Zijlstra <> | Date | Fri, 28 Jan 2011 11:51:31 +0100 |
| |
On Thu, 2011-01-27 at 14:30 +0000, Jan Beulich wrote: > >>> On 27.01.11 at 14:56, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > On Thu, 2011-01-27 at 21:05 +0800, Xiaowei Yang wrote: > >> > >> However, from the comments embedded in gup.c, it seems deliberate to > >> avoid the lock in the fast path. The question is: if so, how to avoid > >> the above scenario? > > > > Something like the below comes to mind... but I must say I haven't fully > > considered the problem yet.. > > That doesn't seem to account for the possible case of the page > even managing to get allocated again to something else. > > And I think you would need to drop out of gup_pte_range() in > that case. > > I would think this needs to be get_page_unless_zero() > followed by re-checking of the page table entry (probably > not even requiring a second gup_get_pte()); I'm not sure > yet what the correct action would be for change in only the > accessed/dirty bits.
Nah, if its racy against unmap its racy and the caller needs to be able to deal with whatever page comes it way. You either get the old, the new, or no page.
The get_page_unless_zero() + RCU-freed page-tables should make Xen work again, look at the powerpc gup_fast implementation.
| |