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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 14, 2025 at 07:54:48AM -0800, Suren Baghdasaryan wrote:
> On Tue, Jan 14, 2025 at 6:59 AM 'Liam R. Howlett' via kernel-team
> <kernel-team@xxxxxxxxxxx> wrote:
> >
> > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> [250113 23:09]:
> > > 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?
> > >
> >
> > I think it's in good shape, but more time for this change is probably
> > the right approach.
> >
> > I don't think it's had enough testing time with the changes since v7.
> > The series has had significant changes, with the side effect of
> > invalidating some of the test time.
> >
> > I really like what it does, but if Suren doesn't need it upstream for
> > some reason then I'd say we leave it to soak longer.
> >
> > If he does need it upstream, we can deal with any fallout and fixes - it
> > will have minimum long term effects as it's not an LTS.
>
> Thanks for voicing your opinion, folks! There is no real urgency and
> no objections from me to wait until the next cycle.
> I'll be posting v10 shortly purely for reviews while this is fresh on
> people's mind, and with the understanding that it won't be picked up
> by Andrew.
> Thanks,
> Suren.

(From my side :) Thanks, and definitely no reflection on quality and your
responsiveness has been amazing, just a reflection of the complexity of
this change.

>
> >
> > Thanks,
> > Liam
> >
> > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@xxxxxxxxxxx.
> >




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux