On Fri, Jul 29, 2016 at 03:35:29PM +0200, Michal Hocko wrote: > On Fri 29-07-16 16:14:10, Michael S. Tsirkin wrote: > > On Fri, Jul 29, 2016 at 08:04:22AM +0200, Michal Hocko wrote: > > > On Thu 28-07-16 23:41:53, Michael S. Tsirkin wrote: > > > > On Thu, Jul 28, 2016 at 09:42:33PM +0200, Michal Hocko wrote: > [...] > > > > > and the reader would hit a page fault > > > > > + * if it stumbled over a reaped memory. > > > > > > > > This last point I don't get. flag read could bypass data read > > > > if that happens data read could happen after unmap > > > > yes it might get a PF but you handle that, correct? > > > > > > The point I've tried to make is that if the reader really page faults > > > then get_user will imply the full barrier already. If get_user didn't > > > page fault then the state of the flag is not really important because > > > the reaper shouldn't have touched it. Does it make more sense now or > > > I've missed your question? > > > > Can task flag read happen before the get_user pagefault? > > Do you mean? > > get_user_mm() > temp = false <- test_bit(MMF_UNSTABLE, &mm->flags) > ret = __get_user(x, ptr) > #PF > if (!ret && temp) # misses the flag > > The code is basically doing > > if (!__get_user() && test_bit(MMF_UNSTABLE, &mm->flags)) > > so test_bit part of the conditional cannot be evaluated before > __get_user() part is done. Compiler cannot reorder two depending > subconditions AFAIK. But maybe the CPU can. > -- > Michal Hocko > SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>