[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aEO6asiCu9oG1z8o@casper.infradead.org>
Date: Sat, 7 Jun 2025 05:04:58 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Barry Song <21cnbao@...il.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Barry Song <v-songbaohua@...o.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
David Hildenbrand <david@...hat.com>,
Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>,
Lokesh Gidra <lokeshgidra@...gle.com>,
Tangquan Zheng <zhengtangquan@...o.com>,
Qi Zheng <zhengqi.arch@...edance.com>
Subject: Re: [PATCH v3] mm: use per_vma lock for MADV_DONTNEED
On Sat, Jun 07, 2025 at 12:46:23PM +1200, Barry Song wrote:
> To simplify handling, the implementation falls back to the standard
> mmap_lock if userfaultfd is enabled on the VMA, avoiding the complexity of
> userfaultfd_remove().
This feels too complex to me. Why do we defer grabbing the vma lock
so late, instead of grabbing it at the start like the fault handler does?
Powered by blists - more mailing lists