public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Frank Hofmann <fhofmann@cloudflare.com>,
	Sasha Levin <sashal@kernel.org>,
	"Darrick J . Wong" <djwong@kernel.org>,
	Leah Rumancik <leah.rumancik@gmail.com>,
	Chandan Babu R <chandan.babu@oracle.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Adam Manzanares <a.manzanares@samsung.com>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Dave Chinner <dchinner@redhat.com>,
	"Darrick J . Wong" <darrick.wong@oracle.com>,
	Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 5.10 v2 6/7] xfs: reorder iunlink remove operation in xfs_ifree
Date: Thu, 1 Sep 2022 15:07:33 +0200	[thread overview]
Message-ID: <YxCulVd4dESBjCUM@kroah.com> (raw)
In-Reply-To: <CAOQ4uxh0We9+56EJUSw_NAqd_TLLV1v0yvyY=dj645H_4M_AyQ@mail.gmail.com>

On Thu, Sep 01, 2022 at 03:37:59PM +0300, Amir Goldstein wrote:
> On Thu, Sep 1, 2022 at 1:26 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Sep 01, 2022 at 01:16:33PM +0300, Amir Goldstein wrote:
> > > On Thu, Sep 1, 2022 at 12:41 PM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Thu, Sep 01, 2022 at 12:30:13PM +0300, Amir Goldstein wrote:
> > > > > On Thu, Sep 1, 2022 at 12:04 PM Frank Hofmann <fhofmann@cloudflare.com> wrote:
> > > > > >
> > > > > > On Thu, Sep 1, 2022 at 6:49 AM Amir Goldstein <amir73il@gmail.com> wrote:
> > > > > > >
> > > > > > > From: Dave Chinner <dchinner@redhat.com>
> > > > > > >
> > > > > > > commit 9a5280b312e2e7898b6397b2ca3cfd03f67d7be1 upstream.
> > > > > > >
> > > > > > > [backport for 5.10.y]
> > > > > >
> > > > > > Hi Amir, hi Dave,
> > > > > >
> > > > > > I've got no objections to backporting this change at all. We've been
> > > > > > using the patch on our internal 5.15 tracker branch happily for
> > > > > > several months now.
> > > > > >
> > > > > > Would like to highlight though that it's currently not yet merged in
> > > > > > linux-stable 5.15 branch either (it's in 5.19 and mainline alright).
> > > > > > If this gets queued for 5.10 then maybe it also should be for 5.15 ?
> > > > > >
> > > > >
> > > > > Hi Frank,
> > > > >
> > > > > Quoting from my cover letter:
> > > > >
> > > > > Patches 6-7 in this 5.10.y update have not been applied to 5.15.y yet.
> > > > > I pointed Leah's attention to these patches and she said she will
> > > > > include them in a following 5.15.y update.
> > > >
> > > > And as you know, this means I can't take this series at all until that
> > > > series is ready, so to help us out, in the future, just don't even send
> > > > them until they are all ready together.
> > > >
> > >
> > > What?
> > >
> > > You cannot take backports to 5.10.y before they are applied to 5.15.y?
> > > Since when?
> >
> > Since always.
> >
> > Why would you ever want someone to upgrade from an older tree (like
> > 5.10.y) to a newer one (5.15.y) and have a regression?
> >
> 
> That is certainly not a goal when backporting fixes to 5.10.y, but it
> can happen as a by-product of the decentralized nature of testing
> backports.
> 
> But it did not bother you when xfs patches were applied to 5.4.y and
> no xfs patches at all applied to 5.10.y for two years?

I've been bothered by xfs patches for so long that really, I didn't care
as the maintainers didn't seem bothered either :)

But now that everything is working properly, let's do it correctly
please.

> > So we always try to make sure patches are always applied to newer trees
> > first.  Yes, sometimes we miss this and make mistakes, but it's always
> > been this way and we fix that whenever it happens accidentally.
> >
> 
> That is my intention.
> I will try to keep to that rule in the future.
> I would have waited for the patches to land in 5.15.y, but
> Leah got distracted by another task so I decided to not wait,
> knowing that the patches are already in her queue.
> 
> > I'll drop this series from my review queue for now until the 5.15.y
> > series shows up.
> 
> Please don't drop the series.
> Please drop patches 6-7 if you must
> Or if you insist I can re-post patches 1-5.

Please resend as just the correct ones that you want so I know what to
pick exactly.

thanks,

greg k-h

  reply	other threads:[~2022-09-01 13:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01  5:48 [PATCH 5.10 v2 0/7] xfs stable patches for 5.10.y (from v5.18+) Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 1/7] xfs: remove infinite loop when reserving free block pool Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 2/7] xfs: always succeed at setting the reserve pool size Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 3/7] xfs: fix overfilling of reserve pool Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 4/7] xfs: fix soft lockup via spinning in filestream ag selection loop Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 5/7] xfs: revert "xfs: actually bump warning counts when we send warnings" Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 6/7] xfs: reorder iunlink remove operation in xfs_ifree Amir Goldstein
2022-09-01  9:04   ` Frank Hofmann
2022-09-01  9:30     ` Amir Goldstein
2022-09-01  9:41       ` Greg Kroah-Hartman
2022-09-01 10:16         ` Amir Goldstein
2022-09-01 10:26           ` Greg Kroah-Hartman
2022-09-01 12:37             ` Amir Goldstein
2022-09-01 13:07               ` Greg Kroah-Hartman [this message]
2022-09-01 15:19                 ` Amir Goldstein
2022-09-01 11:43       ` Frank Hofmann
2022-09-01  5:48 ` [PATCH 5.10 v2 7/7] xfs: validate inode fork size against fork format Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YxCulVd4dESBjCUM@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=a.manzanares@samsung.com \
    --cc=amir73il@gmail.com \
    --cc=chandan.babu@oracle.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=fhofmann@cloudflare.com \
    --cc=leah.rumancik@gmail.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox