[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YZzqX0PjxNmhJSvm@casper.infradead.org>
Date: Tue, 23 Nov 2021 13:19:27 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: akpm@...ux-foundation.org, mhocko@...nel.org, mhocko@...e.com,
rientjes@...gle.com, hannes@...xchg.org, guro@...com,
riel@...riel.com, minchan@...nel.org, kirill@...temov.name,
aarcange@...hat.com, christian@...uner.io, hch@...radead.org,
oleg@...hat.com, david@...hat.com, jannh@...gle.com,
shakeelb@...gle.com, luto@...nel.org, christian.brauner@...ntu.com,
fweimer@...hat.com, jengelh@...i.de, timmurray@...gle.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
kernel-team@...roid.com
Subject: Re: [PATCH 1/2] mm: protect free_pgtables with mmap_lock write lock
in exit_mmap
On Tue, Nov 16, 2021 at 01:57:14PM -0800, Suren Baghdasaryan wrote:
> @@ -3170,6 +3172,7 @@ void exit_mmap(struct mm_struct *mm)
> unmap_vmas(&tlb, vma, 0, -1);
> free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
> tlb_finish_mmu(&tlb);
> + mmap_write_unlock(mm);
>
> /*
> * Walk the list again, actually closing and freeing it,
Is there a reason to unlock here instead of after the remove_vma loop?
We'll need the mmap sem held during that loop when VMAs are stored in
the maple tree.
Powered by blists - more mailing lists