Re: [PATCH 6.7 438/641] md: bypass block throttle for superblock update

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

 



On Tue, Jan 23, 2024 at 2:20 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Jan 23, 2024 at 02:35:15PM -0700, Dan Moulding wrote:
> > > Or is the regression also in Linus's tree and both of these should be
> > > reverted/dropped in order to keep systems ok until the bug is fixed in
> > > Linus's tree?
> >
> > The regression is in Linus' tree and appeared with commit
> > bed9e27baf52. I was operating under the assumption that the two
> > commits (bed9e27baf52 and d6e035aad6c0) are intended to exist as a
> > pair that should go together (the commit messages led me to believe
> > so).
> >
> > The commit that caused the regression has already appeared in the
> > 6.7.1 release (but without the second commit). Since I thought the two
> > commits are a pair and the regression needs to be reverted, that the
> > second commit should not be backported for 6.7.2 until the issue is
> > properly resolved in Linus' tree.
> >
> > But it sounds like Song Liu is saying that the second commit
> > (d6e035aad6c0) should actually be fine to accept on its own even
> > though the other one needs to be reverted, and is not really dependent
> > on the one that caused the regression [1]. So maybe it's fine to pick
> > it up for 6.7.2.
> >
> > I can say that I have tested 6.7.1 plus just commit d6e035aad6c0 and I
> > cannot reproduce the regression with it. But 6.7.1 plus both commits,
> > I can still reproduce the regression. So bed9e27baf52 definitely needs
> > to be reverted to eliminate the regression.
> >
> > I hope that clears things up some.
>
> Nope, not at all :)
>
> For now, I'm going to keep both commits in the stable trees, as that
> matches what is in Linus's tree as this seems to be hard to reproduce
> and I haven't seen any other reports of issues.  Being in sync with what
> is in Linus's tree is almost always good, that way if a fix happens
> there, we can easily backport it to the stable trees too.
>
> So unless the maintainer(s) say otherwise, I'll just let this be.

Thanks Greg!

Yes, let's keep the tree as-is while we look into this issue. I tried to
reproduce the issue from my side, but haven't hit it yet.

Song





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux