[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2bohfxnbthvf3w4kz5u72wj5uxh5sb5s3mbhdk5eg2ingkpkqg@ylykphugpydy>
Date: Mon, 7 Apr 2025 10:24:53 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Nikita Kalyazin <kalyazin@...zon.com>
Cc: Ackerley Tng <ackerleytng@...gle.com>,
Vishal Annapurve <vannapurve@...gle.com>,
Fuad Tabba <tabba@...gle.com>, akpm@...ux-foundation.org,
pbonzini@...hat.com, shuah@...nel.org, viro@...iv.linux.org.uk,
brauner@...nel.org, muchun.song@...ux.dev, hughd@...gle.com,
kvm@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, jack@...e.cz,
lorenzo.stoakes@...cle.com, jannh@...gle.com, ryan.roberts@....com,
david@...hat.com, jthoughton@...gle.com, peterx@...hat.com,
graf@...zon.de, jgowans@...zon.com, roypat@...zon.co.uk,
derekmn@...zon.com, nsaenz@...zon.es, xmarcalx@...zon.com
Subject: Re: [PATCH v3 0/6] KVM: guest_memfd: support for uffd minor
* Nikita Kalyazin <kalyazin@...zon.com> [250407 10:05]:
>
...
> >
> > All of this is extremely confusing because the onus of figuring out what
> > the final code will look like is put on the reviewer. As it is, we have
> > issues with people not doing enough review of the code (due to limited
> > time). One way to get reviews is to make the barrier of entry as low as
> > possible.
> >
> > I spent Friday going down a rabbit hole of patches referring to each
> > other as dependencies and I gave up. It looks like I mistook one set of
> > patches as required vs them requiring the same in-flight ones as your
> > patches.
> >
> > I am struggling to see how we can adequately support all of you given
> > the way the patches are sent out in batches with dependencies - it is
> > just too time consuming to sort out.
>
> I'm happy to do whatever I can to make the review easier. I suppose the
> extreme case is to wait for the dependencies to get accepted, effectively
> serialising submissions, but that slows the process down significantly. For
> example, I received very good feedback on v1 and v2 of this series and was
> able to address it instead of waiting for the dependency. Would including
> the required patches directly in the series help? My only concern is in
> that case the same patch will be submitted multiple times (as a part of
> every depending series), but if it's better, I'll be doing that instead.
Don't resend patches that someone else is upstreaming, that'll cause
other problems.
Three methods come to mind:
1. As you stated, wait for the dependencies to land. This is will mean
what you are working against is well tested and won't change (and you
won't have to re-spin due to an unstable base).
2. Combine them into a bigger patch set. I can then pull one patch set
and look at the parts of interest to the mm side.
3. Provide a git repo with the necessary changes together.
I think 2 and 3 together should be used for the guest_memfd patches.
Someone needs to be managing these to send upstream. See the discussion
in another patch set on guest_memfd here [1].
As this is not based on fully upstream patches, this should be marked as
RFC, imo.
Thanks,
Liam
[1]. https://lore.kernel.org/all/aizia2elwspxcmfrjote5h7k5wdw2stp42slytkl5visrjvzwi@jj3lwuudiyjk/
Powered by blists - more mailing lists