Re: [PATCH v9 00/17] reimplement per-vma lock as a refcount

[Lorenzo Stoakes]

On Mon, Jan 13, 2025 at 08:09:08PM -0800, Andrew Morton wrote:
> On Mon, 13 Jan 2025 18:53:11 -0800 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
>
> > On Mon, Jan 13, 2025 at 5:49 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > >
> > > Yes, we're at -rc7 and this series is rather in panic mode and it seems
> > > unnecessarily risky so I'm inclined to set it aside for this cycle.
> > >
> > > If the series is considered super desirable and if people are confident
> > > that we can address any remaining glitches during two months of -rc
> > > then sure, we could push the envelope a bit.  But I don't believe this
> > > is the case so I'm thinking let's give ourselves another cycle to get
> > > this all sorted out?
> >
> > I didn't think this series was in panic mode with one real issue that
> > is not hard to address (memory ordering in
> > __refcount_inc_not_zero_limited()) but I'm obviously biased and might
> > be missing the big picture. In any case, if it makes people nervous I
> > have no objections to your plan.
>
> Well, I'm soliciting opinions here.  What do others think?
>
> And do you see much urgency with these changes?

With apologies to Suren (genuinely!) who is doing great work and is
super-responsive here, this really needs another cycle in my opinion.

As Vlastimil points out there's some non-trivial bits to go, but I am also
firmly of the opinion we need to have as much testing as is practical here.

I don't think this is urgent on any timeline so I'd like to join Vlastimil
to firmly but politely push for this to land in 6.15 rather than 6.14.

Just to reiterate - this is absolutely no reflection on Suren who has been
really great here - it is purely a product of the complexity and scope of
this change.