[PATCH 4.14 56/61] fs: clear writeback errors in inode_init_always
4.14-stable review patch. If anyone has any objections, please let me know. -- From: "Darrick J. Wong" [ Upstream commit 829bc787c1a0403e4d886296dd4d90c5f9c1744a ] In inode_init_always(), we clear the inode mapping flags, which clears any retained error (AS_EIO, AS_ENOSPC) bits. Unfortunately, we do not also clear wb_err, which means that old mapping errors can leak through to new inodes. This is crucial for the XFS inode allocation path because we recycle old in-core inodes and we do not want error state from an old file to leak into the new file. This bug was discovered by running generic/036 and generic/047 in a loop and noticing that the EIOs generated by the collision of direct and buffered writes in generic/036 would survive the remount between 036 and 047, and get reported to the fsyncs (on different files!) in generic/047. Signed-off-by: Darrick J. Wong Reviewed-by: Jeff Layton Reviewed-by: Brian Foster Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- fs/inode.c |1 + 1 file changed, 1 insertion(+) --- a/fs/inode.c +++ b/fs/inode.c @@ -177,6 +177,7 @@ int inode_init_always(struct super_block mapping->a_ops = _aops; mapping->host = inode; mapping->flags = 0; + mapping->wb_err = 0; atomic_set(>i_mmap_writable, 0); mapping_set_gfp_mask(mapping, GFP_HIGHUSER_MOVABLE); mapping->private_data = NULL;
[PATCH 4.14 56/61] fs: clear writeback errors in inode_init_always
4.14-stable review patch. If anyone has any objections, please let me know. -- From: "Darrick J. Wong" [ Upstream commit 829bc787c1a0403e4d886296dd4d90c5f9c1744a ] In inode_init_always(), we clear the inode mapping flags, which clears any retained error (AS_EIO, AS_ENOSPC) bits. Unfortunately, we do not also clear wb_err, which means that old mapping errors can leak through to new inodes. This is crucial for the XFS inode allocation path because we recycle old in-core inodes and we do not want error state from an old file to leak into the new file. This bug was discovered by running generic/036 and generic/047 in a loop and noticing that the EIOs generated by the collision of direct and buffered writes in generic/036 would survive the remount between 036 and 047, and get reported to the fsyncs (on different files!) in generic/047. Signed-off-by: Darrick J. Wong Reviewed-by: Jeff Layton Reviewed-by: Brian Foster Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- fs/inode.c |1 + 1 file changed, 1 insertion(+) --- a/fs/inode.c +++ b/fs/inode.c @@ -177,6 +177,7 @@ int inode_init_always(struct super_block mapping->a_ops = _aops; mapping->host = inode; mapping->flags = 0; + mapping->wb_err = 0; atomic_set(>i_mmap_writable, 0); mapping_set_gfp_mask(mapping, GFP_HIGHUSER_MOVABLE); mapping->private_data = NULL;
