[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170725191952.GR29716@redhat.com>
Date: Tue, 25 Jul 2017 21:19:52 +0200
From: Andrea Arcangeli <aarcange@...hat.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>,
Andrew Morton <akpm@...ux-foundation.org>,
David Rientjes <rientjes@...gle.com>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Oleg Nesterov <oleg@...hat.com>,
Hugh Dickins <hughd@...gle.com>, linux-mm@...ck.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm, oom: allow oom reaper to race with exit_mmap
On Tue, Jul 25, 2017 at 06:04:00PM +0200, Michal Hocko wrote:
> - down_write(&mm->mmap_sem);
> + if (tsk_is_oom_victim(current))
> + down_write(&mm->mmap_sem);
> free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
> tlb_finish_mmu(&tlb, 0, -1);
>
> @@ -3012,7 +3014,8 @@ void exit_mmap(struct mm_struct *mm)
> }
> mm->mmap = NULL;
> vm_unacct_memory(nr_accounted);
> - up_write(&mm->mmap_sem);
> + if (tsk_is_oom_victim(current))
> + up_write(&mm->mmap_sem);
How is this possibly safe? mark_oom_victim can run while exit_mmap is
running. Even if you cache the first read in the local stack, failure
to notice you marked it, could lead to use after free. Or at least
there's no comment on which lock should prevent the use after free
with the above.
Powered by blists - more mailing lists