lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 6 Mar 2020 13:52:07 +0100 From: Vlastimil Babka <vbabka@...e.cz> To: Minchan Kim <minchan@...nel.org>, Andrew Morton <akpm@...ux-foundation.org> Cc: LKML <linux-kernel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>, linux-api@...r.kernel.org, oleksandr@...hat.com, Suren Baghdasaryan <surenb@...gle.com>, Tim Murray <timmurray@...gle.com>, Daniel Colascione <dancol@...gle.com>, Sandeep Patil <sspatil@...gle.com>, Sonny Rao <sonnyrao@...gle.com>, Brian Geffon <bgeffon@...gle.com>, Michal Hocko <mhocko@...e.com>, Johannes Weiner <hannes@...xchg.org>, Shakeel Butt <shakeelb@...gle.com>, John Dias <joaodias@...gle.com>, Joel Fernandes <joel@...lfernandes.org>, Jann Horn <jannh@...gle.com>, alexander.h.duyck@...ux.intel.com, sj38.park@...il.com Subject: Re: [PATCH v7 6/7] mm/madvise: employ mmget_still_valid for write lock On 3/2/20 8:36 PM, Minchan Kim wrote: > From: Oleksandr Natalenko <oleksandr@...hat.com> > > Do the very same trick as we already do since 04f5866e41fb. KSM hints > will require locking mmap_sem for write since they modify vm_flags, so > for remote KSM hinting this additional check is needed. > > Reviewed-by: Suren Baghdasaryan <surenb@...gle.com> > Signed-off-by: Oleksandr Natalenko <oleksandr@...hat.com> > Signed-off-by: Minchan Kim <minchan@...nel.org> > --- > mm/madvise.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/madvise.c b/mm/madvise.c > index e794367f681e..e77c6c1fad34 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -1118,6 +1118,8 @@ int do_madvise(struct task_struct *target_task, struct mm_struct *mm, > if (write) { > if (down_write_killable(&mm->mmap_sem)) > return -EINTR; > + if (current->mm != mm && !mmget_still_valid(mm)) > + goto skip_mm; This will return 0, is that correct? Shoudln't there be a similar error e.g. as when finding the task by pid fails (-ESRCH ?), because IIUC the task here is going away and dumping the core? > } else { > down_read(&mm->mmap_sem); > } > @@ -1169,6 +1171,7 @@ int do_madvise(struct task_struct *target_task, struct mm_struct *mm, > } > out: > blk_finish_plug(&plug); > +skip_mm: > if (write) > up_write(&mm->mmap_sem); > else >
Powered by blists - more mailing lists