linux-kernel - Re: [PATCH kvm-next V11 4/7] KVM: guest_memfd: Use guest mem inodes instead of anonymous inodes

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aNXMDgeFqhWJPArm@google.com>
Date: Thu, 25 Sep 2025 16:11:10 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Shivank Garg <shivankg@....com>, Ackerley Tng <ackerleytng@...gle.com>, pbonzini@...hat.com, 
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH kvm-next V11 4/7] KVM: guest_memfd: Use guest mem inodes
 instead of anonymous inodes

Trimmed the Cc substantially.

On Thu, Sep 25, 2025, Sean Christopherson wrote:
> On Thu, Sep 25, 2025, David Hildenbrand wrote:
> > On 25.09.25 15:41, Sean Christopherson wrote:
> > > Regarding timing, how much do people care about getting this into 6.18 in
> > > particular?
> > 
> > I think it will be beneficial if we start getting stuff upstream. But
> > waiting a bit longer probably doesn't hurt.
> > 
> > > AFAICT, this hasn't gotten any coverage in -next, which makes me a
> > > little nervous.
> > 
> > Right.
> > 
> > If we agree, then Shivank can just respin a new version after the merge
> > window.
> 
> Actually, if Shivank is ok with it, I'd be happy to post the next version(s).
> I'll be focusing on the in-place conversion support for the next 1-2 weeks, and
> have some (half-baked) refactoring changes to better leverage the inode support
> from this series.

Shivank, unless you really, really, _really_ want to post the next version, I'll
post v12.  I've accumulated a bunch of changes (almost entirely just code movement,
naming tweaks, and adding comments) to better prepare for reusing the inode support
for in-place conversion.  The in-place conversion stuff is much further out, but
I'm hoping to get a refreshed RFC out (with Ackerley's help) in the near future,
and shuffling things around in this series should help avoid too much churn.

P.S. Thanks a ton for hammering this out!  I'm especially grateful y'all took
on the inode stuff.  It took me several hours to wrap my head around things, and
that was with your code to look at. :-)