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: <acf43b57-497c-436e-8c8d-2af50616d9b2@amd.com>
Date: Fri, 26 Sep 2025 11:50:30 +0530
From: "Garg, Shivank" <shivankg@....com>
To: Sean Christopherson <seanjc@...gle.com>,
 David Hildenbrand <david@...hat.com>
Cc: 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



On 9/26/2025 4:41 AM, Sean Christopherson wrote:
> 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. :-)

Thanks for the update, Sean!

Since this is my first feature merge, I would have really liked to get the end-to-end
experience of posting the patch series and seeing it through to completion.
But as you said, it can help reduce iteration and expedite merging, so please feel free
to go ahead and post v12.
I'm happy to assist however I can. Please just let me know if there's anything you'd
like me to review, test, or help coordinate.

Thanks,
Shivank