* [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode @ 2018-01-26 7:44 Amir Goldstein 2018-01-26 7:44 ` Christoph Hellwig 2018-01-26 21:44 ` Darrick J. Wong 0 siblings, 2 replies; 26+ messages in thread From: Amir Goldstein @ 2018-01-26 7:44 UTC (permalink / raw) To: Darrick J . Wong Cc: Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel 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@gmail.com> --- Darrick, You may want to rush this last minute v4.15 regression fix. Thanks, Amir. fs/xfs/xfs_icache.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index 3861d61fb265..3ce946063ffe 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -295,6 +295,7 @@ xfs_reinit_inode( uint32_t generation = inode->i_generation; uint64_t version = inode->i_version; umode_t mode = inode->i_mode; + dev_t dev = inode->i_rdev; error = inode_init_always(mp->m_super, inode); @@ -302,6 +303,7 @@ xfs_reinit_inode( inode->i_generation = generation; inode->i_version = version; inode->i_mode = mode; + inode->i_rdev = dev; return error; } -- 2.7.4 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-01-26 7:44 [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode Amir Goldstein @ 2018-01-26 7:44 ` Christoph Hellwig 2018-01-26 21:44 ` Darrick J. Wong 1 sibling, 0 replies; 26+ messages in thread From: Christoph Hellwig @ 2018-01-26 7:44 UTC (permalink / raw) To: Amir Goldstein Cc: Darrick J . Wong, Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel Looks good, Reviewed-by: Christoph Hellwig <hch@lst.de> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-01-26 7:44 [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode Amir Goldstein 2018-01-26 7:44 ` Christoph Hellwig @ 2018-01-26 21:44 ` Darrick J. Wong 2018-01-29 11:07 ` Amir Goldstein 1 sibling, 1 reply; 26+ messages in thread From: Darrick J. Wong @ 2018-01-26 21:44 UTC (permalink / raw) To: Amir Goldstein Cc: Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel 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@gmail.com> Looks ok, Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> > --- > > Darrick, > > You may want to rush this last minute v4.15 regression fix. > > Thanks, > Amir. > > fs/xfs/xfs_icache.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c > index 3861d61fb265..3ce946063ffe 100644 > --- a/fs/xfs/xfs_icache.c > +++ b/fs/xfs/xfs_icache.c > @@ -295,6 +295,7 @@ xfs_reinit_inode( > uint32_t generation = inode->i_generation; > uint64_t version = inode->i_version; > umode_t mode = inode->i_mode; > + dev_t dev = inode->i_rdev; > > error = inode_init_always(mp->m_super, inode); > > @@ -302,6 +303,7 @@ xfs_reinit_inode( > inode->i_generation = generation; > inode->i_version = version; > inode->i_mode = mode; > + inode->i_rdev = dev; > return error; > } > > -- > 2.7.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-01-26 21:44 ` Darrick J. Wong @ 2018-01-29 11:07 ` Amir Goldstein 2018-01-29 15:50 ` Darrick J. Wong 0 siblings, 1 reply; 26+ messages in thread From: Amir Goldstein @ 2018-01-29 11:07 UTC (permalink / raw) To: Darrick J. Wong Cc: Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel On Fri, Jan 26, 2018 at 11:44 PM, Darrick J. Wong <darrick.wong@oracle.com> 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@gmail.com> > > Looks ok, > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> > I recon that now we should now also strap: Cc: <stable@vger.kernel.org> #v4.15 Can I assume, you'll add it on apply? Thanks, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-01-29 11:07 ` Amir Goldstein @ 2018-01-29 15:50 ` Darrick J. Wong 2018-02-01 0:27 ` Amir Goldstein 0 siblings, 1 reply; 26+ messages in thread From: Darrick J. Wong @ 2018-01-29 15:50 UTC (permalink / raw) To: Amir Goldstein Cc: Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel 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@oracle.com> 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@gmail.com> > > > > Looks ok, > > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> > > > > I recon that now we should now also strap: > Cc: <stable@vger.kernel.org> #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. --D > Thanks, > Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-01-29 15:50 ` Darrick J. Wong @ 2018-02-01 0:27 ` Amir Goldstein 2018-02-01 0:29 ` Amir Goldstein 2018-02-01 0:35 ` Darrick J. Wong 0 siblings, 2 replies; 26+ messages in thread From: Amir Goldstein @ 2018-02-01 0:27 UTC (permalink / raw) To: Darrick J. Wong Cc: Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel, Greg KH, stable On Mon, Jan 29, 2018 at 5:50 PM, Darrick J. Wong <darrick.wong@oracle.com> 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@oracle.com> 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@gmail.com> >> > >> > Looks ok, >> > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> >> > >> >> I recon that now we should now also strap: >> Cc: <stable@vger.kernel.org> #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. CC'ing stable for attention. This patch is now in master, but due to its timing it did not get the CC: stable tag. Thanks, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-02-01 0:27 ` Amir Goldstein @ 2018-02-01 0:29 ` Amir Goldstein 2018-02-01 0:35 ` Darrick J. Wong 1 sibling, 0 replies; 26+ messages in thread From: Amir Goldstein @ 2018-02-01 0:29 UTC (permalink / raw) To: Darrick J. Wong Cc: Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel, Greg KH, stable On Thu, Feb 1, 2018 at 2:27 AM, Amir Goldstein <amir73il@gmail.com> wrote: > On Mon, Jan 29, 2018 at 5:50 PM, Darrick J. Wong > <darrick.wong@oracle.com> 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@oracle.com> 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@gmail.com> >>> > >>> > Looks ok, >>> > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> >>> > >>> >>> I recon that now we should now also strap: >>> Cc: <stable@vger.kernel.org> #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. > > CC'ing stable for attention. > > This patch is now in master, but due to its timing it did not > get the CC: stable tag. > Now really CC stable. Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-02-01 0:27 ` Amir Goldstein 2018-02-01 0:29 ` Amir Goldstein @ 2018-02-01 0:35 ` Darrick J. Wong 2018-03-11 16:08 ` Amir Goldstein 1 sibling, 1 reply; 26+ messages in thread From: Darrick J. Wong @ 2018-02-01 0:35 UTC (permalink / raw) To: Amir Goldstein Cc: Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel, Greg KH, stable 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@oracle.com> 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@oracle.com> 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@gmail.com> > >> > > >> > Looks ok, > >> > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> > >> > > >> > >> I recon that now we should now also strap: > >> Cc: <stable@vger.kernel.org> #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. --D > CC'ing stable for attention. > > This patch is now in master, but due to its timing it did not > get the CC: stable tag. > > Thanks, > Amir. > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-02-01 0:35 ` Darrick J. Wong @ 2018-03-11 16:08 ` Amir Goldstein 2018-03-11 16:24 ` Greg KH 0 siblings, 1 reply; 26+ messages in thread From: Amir Goldstein @ 2018-03-11 16:08 UTC (permalink / raw) To: Darrick J. Wong Cc: Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel, Greg KH, stable On Thu, Feb 1, 2018 at 2:35 AM, Darrick J. Wong <darrick.wong@oracle.com> 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@oracle.com> 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@oracle.com> 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@gmail.com> >> >> > >> >> > Looks ok, >> >> > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> >> >> > >> >> >> >> I recon that now we should now also strap: >> >> Cc: <stable@vger.kernel.org> #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? As I wrote above, the reason this patch is missing the Cc: stable tag is because it landed just after v4.15 was released, but I was aiming for it to get merged to v4.15 and avoid the regression in a release kernel. Thanks, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-11 16:08 ` Amir Goldstein @ 2018-03-11 16:24 ` Greg KH 2018-03-12 16:27 ` Darrick J. Wong 0 siblings, 1 reply; 26+ messages in thread From: Greg KH @ 2018-03-11 16:24 UTC (permalink / raw) To: Amir Goldstein Cc: Darrick J. Wong, Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel, stable 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@oracle.com> 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@oracle.com> 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@oracle.com> 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@gmail.com> > >> >> > > >> >> > Looks ok, > >> >> > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> > >> >> > > >> >> > >> >> I recon that now we should now also strap: > >> >> Cc: <stable@vger.kernel.org> #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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-11 16:24 ` Greg KH @ 2018-03-12 16:27 ` Darrick J. Wong 2018-03-12 20:16 ` Amir Goldstein 0 siblings, 1 reply; 26+ messages in thread From: Darrick J. Wong @ 2018-03-12 16:27 UTC (permalink / raw) To: Greg KH, Amir Goldstein Cc: Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel, stable On Sun, Mar 11, 2018 at 05:24:42PM +0100, Greg KH wrote: > 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@oracle.com> 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@oracle.com> 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@oracle.com> 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@gmail.com> > > >> >> > > > >> >> > Looks ok, > > >> >> > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> > > >> >> > > > >> >> > > >> >> I recon that now we should now also strap: > > >> >> Cc: <stable@vger.kernel.org> #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. ^^^^^^^^^^^^ Hi Amir, could you do this step ? As far as the code patch goes it's probably fine for stable, but I don't want patches going to stable that have not been run through xfstests to look for regressions. If the patch doesn't increase the number of xfstests failures then it's ready to go to 4.15.y. --D > > > > > > > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-12 16:27 ` Darrick J. Wong @ 2018-03-12 20:16 ` Amir Goldstein 2018-03-13 6:48 ` Amir Goldstein 0 siblings, 1 reply; 26+ messages in thread From: Amir Goldstein @ 2018-03-12 20:16 UTC (permalink / raw) To: Darrick J. Wong Cc: Greg KH, Christoph Hellwig, Eryu Guan, Miklos Szeredi, linux-xfs, linux-fsdevel, stable On Mon, Mar 12, 2018 at 6:27 PM, Darrick J. Wong <darrick.wong@oracle.com> wrote: > On Sun, Mar 11, 2018 at 05:24:42PM +0100, Greg KH wrote: >> 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@oracle.com> 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@oracle.com> 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@oracle.com> 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@gmail.com> >> > >> >> > >> > >> >> > Looks ok, >> > >> >> > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> >> > >> >> > >> > >> >> >> > >> >> I recon that now we should now also strap: >> > >> >> Cc: <stable@vger.kernel.org> #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. > ^^^^^^^^^^^^ > Hi Amir, could you do this step ? > Will do. > As far as the code patch goes it's probably fine for stable, but I don't > want patches going to stable that have not been run through xfstests to > look for regressions. If the patch doesn't increase the number of > xfstests failures then it's ready to go to 4.15.y. > Thanks, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-12 20:16 ` Amir Goldstein @ 2018-03-13 6:48 ` Amir Goldstein 2018-03-13 12:46 ` Amir Goldstein 0 siblings, 1 reply; 26+ messages in thread From: Amir Goldstein @ 2018-03-13 6:48 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Christoph Hellwig, Eryu Guan, linux-xfs On Mon, Mar 12, 2018 at 10:16 PM, Amir Goldstein <amir73il@gmail.com> wrote: > On Mon, Mar 12, 2018 at 6:27 PM, Darrick J. Wong [...] >>> > > 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. >> ^^^^^^^^^^^^ >> Hi Amir, could you do this step ? >> > > Will do. > Quick question. I don't run -g auto regularly and now when running -g auto on v4.15.9 I get a bunch of soft lockups on: [37036.050685] xfs_bmapi_write+0x61a/0xed1 [37036.051794] xfs_reflink_convert_cow+0x9d/0xbf [37036.052761] ? xfs_vm_writepages+0x42/0x99 [37036.053617] xfs_submit_ioend+0x3b/0xf8 [37036.054459] xfs_vm_writepages+0x79/0x99 Can anyone share a good expunge list for running latest xfs/xfstest/xfsprogs with -g auto and reflink support? Thanks, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-13 6:48 ` Amir Goldstein @ 2018-03-13 12:46 ` Amir Goldstein 2018-03-13 13:11 ` Christoph Hellwig 0 siblings, 1 reply; 26+ messages in thread From: Amir Goldstein @ 2018-03-13 12:46 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Christoph Hellwig, Eryu Guan, linux-xfs On Tue, Mar 13, 2018 at 8:48 AM, Amir Goldstein <amir73il@gmail.com> wrote: > On Mon, Mar 12, 2018 at 10:16 PM, Amir Goldstein <amir73il@gmail.com> wrote: >> On Mon, Mar 12, 2018 at 6:27 PM, Darrick J. Wong > [...] > >>>> > > 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. >>> ^^^^^^^^^^^^ >>> Hi Amir, could you do this step ? >>> >> >> Will do. >> > > Quick question. > > I don't run -g auto regularly and now when running -g auto on > v4.15.9 I get a bunch of soft lockups on: > > [37036.050685] xfs_bmapi_write+0x61a/0xed1 > [37036.051794] xfs_reflink_convert_cow+0x9d/0xbf > [37036.052761] ? xfs_vm_writepages+0x42/0x99 > [37036.053617] xfs_submit_ioend+0x3b/0xf8 > [37036.054459] xfs_vm_writepages+0x79/0x99 > > Can anyone share a good expunge list for running latest xfs/xfstest/xfsprogs > with -g auto and reflink support? > OK, found the patches the fix soft lockups in generic/269 and assertion in generic/232, so expunging those 2 tests from v4.15.y test runs. Thanks, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-13 12:46 ` Amir Goldstein @ 2018-03-13 13:11 ` Christoph Hellwig 2018-03-13 14:33 ` Amir Goldstein 0 siblings, 1 reply; 26+ messages in thread From: Christoph Hellwig @ 2018-03-13 13:11 UTC (permalink / raw) To: Amir Goldstein; +Cc: Darrick J. Wong, Christoph Hellwig, Eryu Guan, linux-xfs On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote: > OK, found the patches the fix soft lockups in generic/269 and > assertion in generic/232, so expunging those 2 tests from v4.15.y > test runs. Which patches are those? We should probably backport them to 4.15-stable. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-13 13:11 ` Christoph Hellwig @ 2018-03-13 14:33 ` Amir Goldstein 2018-03-13 21:50 ` Dave Chinner 0 siblings, 1 reply; 26+ messages in thread From: Amir Goldstein @ 2018-03-13 14:33 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Darrick J. Wong, Eryu Guan, linux-xfs On Tue, Mar 13, 2018 at 3:11 PM, Christoph Hellwig <hch@lst.de> wrote: > On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote: >> OK, found the patches the fix soft lockups in generic/269 and >> assertion in generic/232, so expunging those 2 tests from v4.15.y >> test runs. > > Which patches are those? We should probably backport them to 4.15-stable. Probably, but I guess Darrick has those in his TODO. There is this series that refers to failure in generic/232: https://marc.info/?l=linux-xfs&m=151701545720824&w=2 These 2 commits refer to generic/269 specifically in commit message: 70c57dcd606f xfs: skip CoW writes past EOF when writeback races with truncate be78ff0e7277 xfs: recheck reflink / dirty page status before freeing CoW reservations and the thread on the second commit also mentions generic/270 (I found out the hard way that it also soft locks). But there are surely more patches for stable in master. I recon CC: stable and/or Fixes: tags could have been helpful, but I don't see any of those in v4.16-rcX from the core xfs developers. Cheers, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-13 14:33 ` Amir Goldstein @ 2018-03-13 21:50 ` Dave Chinner 2018-03-14 6:24 ` Amir Goldstein 0 siblings, 1 reply; 26+ messages in thread From: Dave Chinner @ 2018-03-13 21:50 UTC (permalink / raw) To: Amir Goldstein; +Cc: Christoph Hellwig, Darrick J. Wong, Eryu Guan, linux-xfs On Tue, Mar 13, 2018 at 04:33:15PM +0200, Amir Goldstein wrote: > On Tue, Mar 13, 2018 at 3:11 PM, Christoph Hellwig <hch@lst.de> wrote: > > On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote: > >> OK, found the patches the fix soft lockups in generic/269 and > >> assertion in generic/232, so expunging those 2 tests from v4.15.y > >> test runs. > > > > Which patches are those? We should probably backport them to 4.15-stable. > > Probably, but I guess Darrick has those in his TODO. > > There is this series that refers to failure in generic/232: > https://marc.info/?l=linux-xfs&m=151701545720824&w=2 > > These 2 commits refer to generic/269 specifically in commit message: > 70c57dcd606f xfs: skip CoW writes past EOF when writeback races with truncate > be78ff0e7277 xfs: recheck reflink / dirty page status before freeing > CoW reservations > and the thread on the second commit also mentions generic/270 > (I found out the hard way that it also soft locks). > > But there are surely more patches for stable in master. > I recon CC: stable and/or Fixes: tags could have been helpful, > but I don't see any of those in v4.16-rcX from the core xfs developers. AS I always say: if you want to maintain a stable backport kernel with all the fixes that go into the bleeding edge, you're more than welcome to do it. Everyone else is flat out just keeping up with on going development and fixing bugs in the kernel as it's moving forward. So if you have the need for stable backports, please keep backporting patches you need, testing them and asking the stable maintainers to include them. Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-13 21:50 ` Dave Chinner @ 2018-03-14 6:24 ` Amir Goldstein 2018-03-14 12:33 ` Dave Chinner 2018-03-19 13:40 ` Greg KH 0 siblings, 2 replies; 26+ messages in thread From: Amir Goldstein @ 2018-03-14 6:24 UTC (permalink / raw) To: Dave Chinner Cc: Christoph Hellwig, Darrick J. Wong, Eryu Guan, linux-xfs, Greg KH, stable On Tue, Mar 13, 2018 at 11:50 PM, Dave Chinner <david@fromorbit.com> wrote: > On Tue, Mar 13, 2018 at 04:33:15PM +0200, Amir Goldstein wrote: >> On Tue, Mar 13, 2018 at 3:11 PM, Christoph Hellwig <hch@lst.de> wrote: >> > On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote: >> >> OK, found the patches the fix soft lockups in generic/269 and >> >> assertion in generic/232, so expunging those 2 tests from v4.15.y >> >> test runs. >> > >> > Which patches are those? We should probably backport them to 4.15-stable. >> >> Probably, but I guess Darrick has those in his TODO. >> >> There is this series that refers to failure in generic/232: >> https://marc.info/?l=linux-xfs&m=151701545720824&w=2 >> >> These 2 commits refer to generic/269 specifically in commit message: >> 70c57dcd606f xfs: skip CoW writes past EOF when writeback races with truncate >> be78ff0e7277 xfs: recheck reflink / dirty page status before freeing >> CoW reservations >> and the thread on the second commit also mentions generic/270 >> (I found out the hard way that it also soft locks). >> >> But there are surely more patches for stable in master. >> I recon CC: stable and/or Fixes: tags could have been helpful, >> but I don't see any of those in v4.16-rcX from the core xfs developers. > > AS I always say: if you want to maintain a stable backport kernel > with all the fixes that go into the bleeding edge, you're more than > welcome to do it. > > Everyone else is flat out just keeping up with on going development > and fixing bugs in the kernel as it's moving forward. So if you have > the need for stable backports, please keep backporting patches you > need, testing them and asking the stable maintainers to include > them. > Greg, I tested the patch in question per Darrick's request. I found no regressions with full "auto" run on xfs with reflinks enabled. Please include this patch in stable 4.15. Dave, It is often the case, though maybe not always, that the author of a patch has the knowledge of the 'Fixes' commit and/or the stable kernel version patch is relevant to or would easily apply to. It is therefore a relatively low effort for a developer to include this information as courtesy to stable maintainers, whether they are maintaining kernel.org stable kernels or distro stable kernels. That's just my opinion. Christoph/Darrick, FYI, with stable kernel 4.15.y, I found the following failures with -g auto: Assert (mostly on quota related): generic/232 xfs/222 xfs/305 xfs/440 xfs/442 Soft lockup (likely fixed by be78ff0e7277): generic/269 generic/270 xfs/442 Failures (output mismatch): xfs/170 xfs/191-input-validation xfs/348 Thanks, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-14 6:24 ` Amir Goldstein @ 2018-03-14 12:33 ` Dave Chinner 2018-03-14 12:49 ` Christoph Hellwig 2018-03-19 13:40 ` Greg KH 1 sibling, 1 reply; 26+ messages in thread From: Dave Chinner @ 2018-03-14 12:33 UTC (permalink / raw) To: Amir Goldstein Cc: Christoph Hellwig, Darrick J. Wong, Eryu Guan, linux-xfs, Greg KH, stable On Wed, Mar 14, 2018 at 08:24:30AM +0200, Amir Goldstein wrote: > On Tue, Mar 13, 2018 at 11:50 PM, Dave Chinner <david@fromorbit.com> wrote: > > AS I always say: if you want to maintain a stable backport kernel > > with all the fixes that go into the bleeding edge, you're more than > > welcome to do it. > > > > Everyone else is flat out just keeping up with on going development > > and fixing bugs in the kernel as it's moving forward. So if you have > > the need for stable backports, please keep backporting patches you > > need, testing them and asking the stable maintainers to include > > them. [....] > Dave, > > It is often the case, though maybe not always, that the author of a patch > has the knowledge of the 'Fixes' commit and/or the stable kernel version > patch is relevant to or would easily apply to. In my experience (especially from my time as the maintainer) working out where a bug was introduced usually takes more time than it does to notice the bug, fix, test, post and review the patch. > It is therefore a relatively low effort for a developer to include > this information If it were easy, then everyone would just do it and everything would be magically backported and it would all just work and everyone would be happy. Back in reality, however, it takes a *lot* of time and knowledge to isolate where a bug was introduced and whether the fix is even something we want to backport to older kernels . If you don't know the code, a git bisect is the only resort and even then there's a chance it doesn't isolate the cause because of some other bug or change. And a bisect is even more time and resource intensive than examining code history, especially for bugs introduced a long time ago. Hence asking developers to do this for every bug the fix .... > as courtesy to stable maintainers, .... is an unreasonable burden to place on developers and reviewers, especially those that don't really know the code they are fixing in any significant detail. > whether they are maintaining kernel.org > stable kernels or distro stable kernels. I've done my fair share of distro kernel maintenance and 500+ patch backports in the past. Doing backports requires looking at every patch that isn't in the older kernel, working out if the change is necessary and then working out all the dependencies that set of necessary patches requires. It's time consuming, complex, and easy to screw up, especially if you just blindly rely on "fixes" or "stable" comments in commits. 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. And that's ignoring the elephant in the room. The big difference between distro backports and upstream stable kernels is the months of QA and bug fixing spent on the distro backports before any user gets near them. "stable" kernels might only get a couple of days of high level integration testing - it's really only enough to smoke test everything. We have never had the time and resources to do properly maintained stable backports for upstream kernels because they move so fast and there are so many of them. It's a full time job in itself, and it's substantially wasted effort because the upstream process throws most of that work away every 3 months. IOWs, if you want to maintain a long term stable upstream kernel backport for XFS, then go and put the effort into doing it properly. Don't demand that upstream developers do extra work on every change they make just so you're not inconvenienced in the future by having to do a little extra work when a one-off fix needs to be backported to a stable kernel.org kernel. > That's just my opinion. Yup, everyone has one. Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-14 12:33 ` Dave Chinner @ 2018-03-14 12:49 ` Christoph Hellwig 2018-03-14 15:45 ` Amir Goldstein 0 siblings, 1 reply; 26+ messages in thread From: Christoph Hellwig @ 2018-03-14 12:49 UTC (permalink / raw) To: Dave Chinner Cc: Amir Goldstein, Christoph Hellwig, Darrick J. Wong, Eryu Guan, linux-xfs, Greg KH, stable 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-14 12:49 ` Christoph Hellwig @ 2018-03-14 15:45 ` Amir Goldstein 2018-03-14 15:46 ` Christoph Hellwig 2018-03-14 16:01 ` Darrick J. Wong 0 siblings, 2 replies; 26+ messages in thread From: Amir Goldstein @ 2018-03-14 15:45 UTC (permalink / raw) To: Christoph Hellwig Cc: Dave Chinner, Darrick J. Wong, Eryu Guan, linux-xfs, Greg KH, stable 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. 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. Thanks, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-14 15:45 ` Amir Goldstein @ 2018-03-14 15:46 ` Christoph Hellwig 2018-03-14 16:01 ` Darrick J. Wong 1 sibling, 0 replies; 26+ messages in thread From: Christoph Hellwig @ 2018-03-14 15:46 UTC (permalink / raw) To: Amir Goldstein Cc: Christoph Hellwig, Dave Chinner, Darrick J. Wong, Eryu Guan, linux-xfs, Greg KH, stable On Wed, Mar 14, 2018 at 05:45:40PM +0200, Amir Goldstein wrote: > 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. I have no idea if anyone is taking care of the stable tree at the moment, maybe we'll need a volunteer.. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-14 15:45 ` Amir Goldstein 2018-03-14 15:46 ` Christoph Hellwig @ 2018-03-14 16:01 ` Darrick J. Wong 1 sibling, 0 replies; 26+ messages in thread From: Darrick J. Wong @ 2018-03-14 16:01 UTC (permalink / raw) To: Amir Goldstein Cc: Christoph Hellwig, Dave Chinner, Eryu Guan, linux-xfs, Greg KH, stable 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-14 6:24 ` Amir Goldstein 2018-03-14 12:33 ` Dave Chinner @ 2018-03-19 13:40 ` Greg KH 2018-03-19 14:59 ` Amir Goldstein 1 sibling, 1 reply; 26+ messages in thread From: Greg KH @ 2018-03-19 13:40 UTC (permalink / raw) To: Amir Goldstein Cc: Dave Chinner, Christoph Hellwig, Darrick J. Wong, Eryu Guan, linux-xfs, stable On Wed, Mar 14, 2018 at 08:24:30AM +0200, Amir Goldstein wrote: > On Tue, Mar 13, 2018 at 11:50 PM, Dave Chinner <david@fromorbit.com> wrote: > > On Tue, Mar 13, 2018 at 04:33:15PM +0200, Amir Goldstein wrote: > >> On Tue, Mar 13, 2018 at 3:11 PM, Christoph Hellwig <hch@lst.de> wrote: > >> > On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote: > >> >> OK, found the patches the fix soft lockups in generic/269 and > >> >> assertion in generic/232, so expunging those 2 tests from v4.15.y > >> >> test runs. > >> > > >> > Which patches are those? We should probably backport them to 4.15-stable. > >> > >> Probably, but I guess Darrick has those in his TODO. > >> > >> There is this series that refers to failure in generic/232: > >> https://marc.info/?l=linux-xfs&m=151701545720824&w=2 > >> > >> These 2 commits refer to generic/269 specifically in commit message: > >> 70c57dcd606f xfs: skip CoW writes past EOF when writeback races with truncate > >> be78ff0e7277 xfs: recheck reflink / dirty page status before freeing > >> CoW reservations > >> and the thread on the second commit also mentions generic/270 > >> (I found out the hard way that it also soft locks). > >> > >> But there are surely more patches for stable in master. > >> I recon CC: stable and/or Fixes: tags could have been helpful, > >> but I don't see any of those in v4.16-rcX from the core xfs developers. > > > > AS I always say: if you want to maintain a stable backport kernel > > with all the fixes that go into the bleeding edge, you're more than > > welcome to do it. > > > > Everyone else is flat out just keeping up with on going development > > and fixing bugs in the kernel as it's moving forward. So if you have > > the need for stable backports, please keep backporting patches you > > need, testing them and asking the stable maintainers to include > > them. > > > > Greg, > > I tested the patch in question per Darrick's request. > I found no regressions with full "auto" run on xfs with reflinks enabled. > Please include this patch in stable 4.15. I have no idea anymore what "this patch" means here :( Please resend the git commit id of what I need to apply to where. thanks, greg k-h ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-19 13:40 ` Greg KH @ 2018-03-19 14:59 ` Amir Goldstein 2018-03-19 15:19 ` Greg KH 0 siblings, 1 reply; 26+ messages in thread From: Amir Goldstein @ 2018-03-19 14:59 UTC (permalink / raw) To: Greg KH Cc: Dave Chinner, Christoph Hellwig, Darrick J. Wong, Eryu Guan, linux-xfs, stable On Mon, Mar 19, 2018 at 3:40 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > On Wed, Mar 14, 2018 at 08:24:30AM +0200, Amir Goldstein wrote: >> On Tue, Mar 13, 2018 at 11:50 PM, Dave Chinner <david@fromorbit.com> wrote: >> > On Tue, Mar 13, 2018 at 04:33:15PM +0200, Amir Goldstein wrote: >> >> On Tue, Mar 13, 2018 at 3:11 PM, Christoph Hellwig <hch@lst.de> wrote: >> >> > On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote: >> >> >> OK, found the patches the fix soft lockups in generic/269 and >> >> >> assertion in generic/232, so expunging those 2 tests from v4.15.y >> >> >> test runs. >> >> > >> >> > Which patches are those? We should probably backport them to 4.15-stable. >> >> >> >> Probably, but I guess Darrick has those in his TODO. >> >> >> >> There is this series that refers to failure in generic/232: >> >> https://marc.info/?l=linux-xfs&m=151701545720824&w=2 >> >> >> >> These 2 commits refer to generic/269 specifically in commit message: >> >> 70c57dcd606f xfs: skip CoW writes past EOF when writeback races with truncate >> >> be78ff0e7277 xfs: recheck reflink / dirty page status before freeing >> >> CoW reservations >> >> and the thread on the second commit also mentions generic/270 >> >> (I found out the hard way that it also soft locks). >> >> >> >> But there are surely more patches for stable in master. >> >> I recon CC: stable and/or Fixes: tags could have been helpful, >> >> but I don't see any of those in v4.16-rcX from the core xfs developers. >> > >> > AS I always say: if you want to maintain a stable backport kernel >> > with all the fixes that go into the bleeding edge, you're more than >> > welcome to do it. >> > >> > Everyone else is flat out just keeping up with on going development >> > and fixing bugs in the kernel as it's moving forward. So if you have >> > the need for stable backports, please keep backporting patches you >> > need, testing them and asking the stable maintainers to include >> > them. >> > >> >> Greg, >> >> I tested the patch in question per Darrick's request. >> I found no regressions with full "auto" run on xfs with reflinks enabled. >> Please include this patch in stable 4.15. > > I have no idea anymore what "this patch" means here :( > > Please resend the git commit id of what I need to apply to where. > Please apply commit acd1d71598f7 xfs: preserve i_rdev when recycling a reclaimable inode to stable kernel v4.15 Thanks, Amir. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode 2018-03-19 14:59 ` Amir Goldstein @ 2018-03-19 15:19 ` Greg KH 0 siblings, 0 replies; 26+ messages in thread From: Greg KH @ 2018-03-19 15:19 UTC (permalink / raw) To: Amir Goldstein Cc: Dave Chinner, Christoph Hellwig, Darrick J. Wong, Eryu Guan, linux-xfs, stable On Mon, Mar 19, 2018 at 04:59:00PM +0200, Amir Goldstein wrote: > On Mon, Mar 19, 2018 at 3:40 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Wed, Mar 14, 2018 at 08:24:30AM +0200, Amir Goldstein wrote: > >> On Tue, Mar 13, 2018 at 11:50 PM, Dave Chinner <david@fromorbit.com> wrote: > >> > On Tue, Mar 13, 2018 at 04:33:15PM +0200, Amir Goldstein wrote: > >> >> On Tue, Mar 13, 2018 at 3:11 PM, Christoph Hellwig <hch@lst.de> wrote: > >> >> > On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote: > >> >> >> OK, found the patches the fix soft lockups in generic/269 and > >> >> >> assertion in generic/232, so expunging those 2 tests from v4.15.y > >> >> >> test runs. > >> >> > > >> >> > Which patches are those? We should probably backport them to 4.15-stable. > >> >> > >> >> Probably, but I guess Darrick has those in his TODO. > >> >> > >> >> There is this series that refers to failure in generic/232: > >> >> https://marc.info/?l=linux-xfs&m=151701545720824&w=2 > >> >> > >> >> These 2 commits refer to generic/269 specifically in commit message: > >> >> 70c57dcd606f xfs: skip CoW writes past EOF when writeback races with truncate > >> >> be78ff0e7277 xfs: recheck reflink / dirty page status before freeing > >> >> CoW reservations > >> >> and the thread on the second commit also mentions generic/270 > >> >> (I found out the hard way that it also soft locks). > >> >> > >> >> But there are surely more patches for stable in master. > >> >> I recon CC: stable and/or Fixes: tags could have been helpful, > >> >> but I don't see any of those in v4.16-rcX from the core xfs developers. > >> > > >> > AS I always say: if you want to maintain a stable backport kernel > >> > with all the fixes that go into the bleeding edge, you're more than > >> > welcome to do it. > >> > > >> > Everyone else is flat out just keeping up with on going development > >> > and fixing bugs in the kernel as it's moving forward. So if you have > >> > the need for stable backports, please keep backporting patches you > >> > need, testing them and asking the stable maintainers to include > >> > them. > >> > > >> > >> Greg, > >> > >> I tested the patch in question per Darrick's request. > >> I found no regressions with full "auto" run on xfs with reflinks enabled. > >> Please include this patch in stable 4.15. > > > > I have no idea anymore what "this patch" means here :( > > > > Please resend the git commit id of what I need to apply to where. > > > > Please apply commit > acd1d71598f7 xfs: preserve i_rdev when recycling a reclaimable inode > > to stable kernel v4.15 Now applied, thanks. greg k-h ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2018-03-19 15:19 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-26 7:44 [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode Amir Goldstein 2018-01-26 7:44 ` Christoph Hellwig 2018-01-26 21:44 ` Darrick J. Wong 2018-01-29 11:07 ` Amir Goldstein 2018-01-29 15:50 ` Darrick J. Wong 2018-02-01 0:27 ` Amir Goldstein 2018-02-01 0:29 ` Amir Goldstein 2018-02-01 0:35 ` Darrick J. Wong 2018-03-11 16:08 ` Amir Goldstein 2018-03-11 16:24 ` Greg KH 2018-03-12 16:27 ` Darrick J. Wong 2018-03-12 20:16 ` Amir Goldstein 2018-03-13 6:48 ` Amir Goldstein 2018-03-13 12:46 ` Amir Goldstein 2018-03-13 13:11 ` Christoph Hellwig 2018-03-13 14:33 ` Amir Goldstein 2018-03-13 21:50 ` Dave Chinner 2018-03-14 6:24 ` Amir Goldstein 2018-03-14 12:33 ` Dave Chinner 2018-03-14 12:49 ` Christoph Hellwig 2018-03-14 15:45 ` Amir Goldstein 2018-03-14 15:46 ` Christoph Hellwig 2018-03-14 16:01 ` Darrick J. Wong 2018-03-19 13:40 ` Greg KH 2018-03-19 14:59 ` Amir Goldstein 2018-03-19 15:19 ` Greg KH
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.