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

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

 



On Sun, Mar 11, 2018 at 06:08:06PM +0200, Amir Goldstein wrote:
> On Thu, Feb 1, 2018 at 2:35 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
> > On Thu, Feb 01, 2018 at 02:27:23AM +0200, Amir Goldstein wrote:
> >> On Mon, Jan 29, 2018 at 5:50 PM, Darrick J. Wong
> >> <darrick.wong@xxxxxxxxxx> wrote:
> >> > On Mon, Jan 29, 2018 at 01:07:36PM +0200, Amir Goldstein wrote:
> >> >> On Fri, Jan 26, 2018 at 11:44 PM, Darrick J. Wong
> >> >> <darrick.wong@xxxxxxxxxx> wrote:
> >> >> > On Fri, Jan 26, 2018 at 09:44:29AM +0200, Amir Goldstein wrote:
> >> >> >> Commit 66f364649d870 ("xfs: remove if_rdev") moved storing of rdev
> >> >> >> value for special inodes to VFS inodes, but forgot to preserve the
> >> >> >> value of i_rdev when recycling a reclaimable xfs_inode.
> >> >> >>
> >> >> >> This was detected by xfstest overlay/017 with inodex=on mount option
> >> >> >> and xfs base fs. The test does a lookup of overlay chardev and blockdev
> >> >> >> right after drop caches.
> >> >> >>
> >> >> >> Overlayfs inodes hold a reference on underlying xfs inodes when mount
> >> >> >> option index=on is configured. If drop caches reclaim xfs inodes, before
> >> >> >> it relclaims overlayfs inodes, that can sometimes leave a reclaimable xfs
> >> >> >> inode and that test hits that case quite often.
> >> >> >>
> >> >> >> When that happens, the xfs inode cache remains broken (zere i_rdev)
> >> >> >> until the next cycle mount or drop caches.
> >> >> >>
> >> >> >> Fixes: 66f364649d870 ("xfs: remove if_rdev")
> >> >> >> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
> >> >> >
> >> >> > Looks ok,
> >> >> > Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> >> >> >
> >> >>
> >> >> I recon that now we should now also strap:
> >> >> Cc: <stable@xxxxxxxxxxxxxxx> #v4.15
> >> >>
> >> >> Can I assume, you'll add it on apply?
> >> >
> >> > I'll do a proper backport of this and a couple other critical cow
> >> > fixes after I get the 4.16 stuff merged.
> >> >
> >>
> >> I am not sure what "proper backport" means in the context of
> >> this patch.
> >> This is a v4.15-rc1 regression fix that is based on v4.15-rc8.
> >> It applied cleanly on v4.15.
> >
> > I meant the other things that went into 4.16, like the reflink quota
> > fixes, the directio corruption problems, etc.  Make a branch, add the
> > necessary fixes, run xfstests to make sure it all still works, etc.
> >
> 
> Darrick,
> 
> I may be missing something in the process of stable kernel
> maintenance, but this patch fixes a reproducible v4.15 regression
> (xfstest overlay/017 fails on stable kernel v4.15).
> 
> Is Greg usually picking those stable patches himself or is he waiting
> for xfs maintainers (or xfs stable maintainers) to stage the
> stable patches?

I'm waiting for the patch to either be tagges with cc: stable, or for
someone to tell me to take the patch.

Sometimes I dig through the tree, but for xfs patches, I do not, as was
told not to :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux