Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Wed, Mar 14, 2018 at 05:45:40PM +0200, Amir Goldstein wrote:
> On Wed, Mar 14, 2018 at 2:49 PM, Christoph Hellwig <hch@lst.de> wrote:
> > On Wed, Mar 14, 2018 at 11:33:14PM +1100, Dave Chinner wrote:
> >> IOWs, if all you're doing is relying on "fixes" tags to determine
> >> what /might/ be needed in a stable kernel.org update, then your
> >> stable backport process is fundamentally broken. You're going to
> >> break things and make stable kernels worse for your users, not
> >> better.
> >
> > Agreed.  As someone who has done a fair share of -stable backports
> > for a customer:  The backport to the last stable release is fairly
> > easy, as it means picking everything that is not clearly a feature
> > or cleanup, and you're generally still familiar with the code.  It
> > still needs quite a lot of QA time.  Backports to older long-term
> > stable bases can become much more hairy very quickly.
> >
> > In either case Fixes: tags don't help at all.  What helps is having
> > one person doing the backports continiously so that they are in the
> > loop.  So when I had a paying customer for the backports it was
> > fairly easy for me as I knew where I left off, need to pick up again
> > and remember the pitfalls of the old stable code.  Randomly Ccing
> > stable or someone working from Fixes tags has none of those benefits.
> > And espesically the CC stable is dangerous as there is no QA or
> > detailed review performed.
> 
> Got it.
> 
> I also read between the lines that the responsibility of herding the stable
> patches has shifted from you to Darrick in the last development cycle.

"..from [Christoph] to /dev/null..." would be more accurate. :(

At this point I must give up the fiction that between prepping/reviewing
patches for the next kernel and fixing problems in the current rc I have
any time for stable kernel stuff at all.

So, it's open season for anyone who /does/ have the time to pick out
fixes and their dependencies, massage them into the appropriate stable
kernels, and do at least the minimum xfstests QA (testing a v4, a v5 +
everything, and a v5 + everything + 1k block size would be a good
start).

> Eventually, I got my answer to how I should make sure my patch finds
> its way to stable, so I'm good with that.
> 
> Only wondering out loud if there should not be a process to expedite
> last cycle regression fixes, such as my patch, to the stable tree.
> After all, we are at 4.15.9 and I reported the regression even before
> v4.15 was released.

Aaaanyway, this i_rdev preservation fix is ok for 4.15, since (as Amir
has pointed out) it originated in 4.15-rc1.

--D

> Thanks,
> Amir.