On 07/01, Michal Hocko wrote: > > From: Michal Hocko <mhocko@xxxxxxxx> > > vhost driver relies on copy_from_user/get_user from a kernel thread. > This makes it impossible to reap the memory of an oom victim which > shares mm with the vhost kernel thread because it could see a zero > page unexpectedly and theoretically make an incorrect decision visible > outside of the killed task context. And I still can't understand how, but let me repeat that I don't understand this code at all. > To quote Michael S. Tsirkin: > : Getting an error from __get_user and friends is handled gracefully. > : Getting zero instead of a real value will cause userspace > : memory corruption. Which userspace memory corruption? We are going to kill the dev->mm owner, the task which did ioctl(VHOST_SET_OWNER) and (at first glance) the task who communicates with the callbacks fired by vhost_worker(). Michael, could you please spell why should we care? > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -492,6 +492,14 @@ static bool __oom_reap_task(struct task_struct *tsk) > goto unlock_oom; > } > > + /* > + * Tell all users of get_user_mm/copy_from_user_mm that the content > + * is no longer stable. No barriers really needed because unmapping > + * should imply barriers already and the reader would hit a page fault > + * if it stumbled over a reaped memory. > + */ > + set_bit(MMF_UNSTABLE, &mm->flags); And this is racy anyway. Oleg. -- 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>