[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e9235b88-e2be-4358-a6fb-507c5cad6fd9@lucifer.local>
Date: Thu, 3 Jul 2025 17:01:54 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Peter Xu <peterx@...hat.com>
Cc: Suren Baghdasaryan <surenb@...gle.com>, Mike Rapoport <rppt@...nel.org>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Vlastimil Babka <vbabka@...e.cz>, Muchun Song <muchun.song@...ux.dev>,
Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
James Houghton <jthoughton@...gle.com>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Nikita Kalyazin <kalyazin@...zon.com>, Michal Hocko <mhocko@...e.com>,
David Hildenbrand <david@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Oscar Salvador <osalvador@...e.de>,
Axel Rasmussen <axelrasmussen@...gle.com>,
Ujwal Kundur <ujwal.kundur@...il.com>
Subject: Re: [PATCH v2 1/4] mm: Introduce vm_uffd_ops API
On Thu, Jul 03, 2025 at 11:45:40AM -0400, Peter Xu wrote:
> I still feel like we're over-worried on this. For OOT drivers I never
> cared breaking anything. For in-tree ones, this discussion can really
> happen when there's a need to. And at that time we can also have a look at
> the impl using uffd_copy(), maybe it'll not be that bad either. It seems
> to me we don't necessarily need to figure this out right now. IMHO we can
> do it two-steps in worst case.
This kind of approach in relation to f_op->mmap() is precisely how I ended
up being cc'd on an embargoed report of a critical zero-day security flaw.
So I think if anything there is under-worrying going on here.
Powered by blists - more mailing lists