| Submitter | gregkh@linuxfoundation.org |
|---|---|
| Date | Jan. 15, 2013, 10:54 p.m. |
| Message ID | <20130115225343.033036403@linuxfoundation.org> |
| Download | mbox | patch |
| Permalink | /patch/1983981/ |
| State | New, archived |
| Headers | show |
Comments
On Tue, Jan 15, 2013 at 02:54:33PM -0800, Greg Kroah-Hartman wrote: > 3.0-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Theodore Ts'o <tytso@mit.edu> > > commit 721e3eba21e43532e438652dd8f1fcdfce3187e7 upstream. > > Commit c278531d39 added a warning when ext4_flush_unwritten_io() is > called without i_mutex being taken. It had previously not been taken > during orphan cleanup since races weren't possible at that point in > the mount process, but as a result of this c278531d39, we will now see > a kernel WARN_ON in this case. Take the i_mutex in > ext4_orphan_cleanup() to suppress this warning. > > Reported-by: Alexander Beregalov <a.beregalov@gmail.com> > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> > Reviewed-by: Zheng Liu <wenqing.lz@taobao.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> By the description and looking at commit c278531d39, this change isn't needed for 3.0 or 3.4 kernels (anything <= 3.6), they don't contain commit c278531d39. > > --- > fs/ext4/super.c | 2 ++ > 1 file changed, 2 insertions(+) > > --- a/fs/ext4/super.c > +++ b/fs/ext4/super.c > @@ -2204,7 +2204,9 @@ static void ext4_orphan_cleanup(struct s > __func__, inode->i_ino, inode->i_size); > jbd_debug(2, "truncating inode %lu to %lld bytes\n", > inode->i_ino, inode->i_size); > + mutex_lock(&inode->i_mutex); > ext4_truncate(inode); > + mutex_unlock(&inode->i_mutex); > nr_truncates++; > } else { > ext4_msg(sb, KERN_DEBUG, > >
On Thu, Jan 17, 2013 at 06:07:11PM -0200, Herton Ronaldo Krzesinski wrote: > On Tue, Jan 15, 2013 at 02:54:33PM -0800, Greg Kroah-Hartman wrote: > > 3.0-stable review patch. If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Theodore Ts'o <tytso@mit.edu> > > > > commit 721e3eba21e43532e438652dd8f1fcdfce3187e7 upstream. > > > > Commit c278531d39 added a warning when ext4_flush_unwritten_io() is > > called without i_mutex being taken. It had previously not been taken > > during orphan cleanup since races weren't possible at that point in > > the mount process, but as a result of this c278531d39, we will now see > > a kernel WARN_ON in this case. Take the i_mutex in > > ext4_orphan_cleanup() to suppress this warning. > > > > Reported-by: Alexander Beregalov <a.beregalov@gmail.com> > > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> > > Reviewed-by: Zheng Liu <wenqing.lz@taobao.com> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > By the description and looking at commit c278531d39, this change isn't > needed for 3.0 or 3.4 kernels (anything <= 3.6), they don't contain > commit c278531d39. Ah, good catch. Should this be reverted from 3.0 and 3.4? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, Jan 17, 2013 at 04:46:16PM -0800, Greg Kroah-Hartman wrote: > On Thu, Jan 17, 2013 at 06:07:11PM -0200, Herton Ronaldo Krzesinski wrote: > > On Tue, Jan 15, 2013 at 02:54:33PM -0800, Greg Kroah-Hartman wrote: > > > 3.0-stable review patch. If anyone has any objections, please let me know. > > > > > > ------------------ > > > > > > From: Theodore Ts'o <tytso@mit.edu> > > > > > > commit 721e3eba21e43532e438652dd8f1fcdfce3187e7 upstream. > > > > > > Commit c278531d39 added a warning when ext4_flush_unwritten_io() is > > > called without i_mutex being taken. It had previously not been taken > > > during orphan cleanup since races weren't possible at that point in > > > the mount process, but as a result of this c278531d39, we will now see > > > a kernel WARN_ON in this case. Take the i_mutex in > > > ext4_orphan_cleanup() to suppress this warning. > > > > > > Reported-by: Alexander Beregalov <a.beregalov@gmail.com> > > > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> > > > Reviewed-by: Zheng Liu <wenqing.lz@taobao.com> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > By the description and looking at commit c278531d39, this change isn't > > needed for 3.0 or 3.4 kernels (anything <= 3.6), they don't contain > > commit c278531d39. > > Ah, good catch. Should this be reverted from 3.0 and 3.4? I judge it as unecessary from what I saw so far, can ext4 developers and/or people in Cc confirm? It should be harmless, only consequence is an uneeded lock being taken now in 3.0/3.4 > > thanks, > > greg k-h >
On Fri, Jan 18, 2013 at 01:47:48AM -0200, Herton Ronaldo Krzesinski wrote: > > > By the description and looking at commit c278531d39, this change isn't > > > needed for 3.0 or 3.4 kernels (anything <= 3.6), they don't contain > > > commit c278531d39. > > > > Ah, good catch. Should this be reverted from 3.0 and 3.4? > > I judge it as unecessary from what I saw so far, can ext4 developers > and/or people in Cc confirm? It should be harmless, only consequence is > an uneeded lock being taken now in 3.0/3.4 It's not worth it to revert it. The lock is being taken in a completely non-fastpath, as well as guaranteed-to-be non-contended code path. We're not requiring that the lock be taken in 3.0 and 3.4, but arguably it's still a good idea to take it from a consistency point of view. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, Jan 17, 2013 at 10:56:50PM -0500, Theodore Ts'o wrote: > On Fri, Jan 18, 2013 at 01:47:48AM -0200, Herton Ronaldo Krzesinski wrote: > > > > By the description and looking at commit c278531d39, this change isn't > > > > needed for 3.0 or 3.4 kernels (anything <= 3.6), they don't contain > > > > commit c278531d39. > > > > > > Ah, good catch. Should this be reverted from 3.0 and 3.4? > > > > I judge it as unecessary from what I saw so far, can ext4 developers > > and/or people in Cc confirm? It should be harmless, only consequence is > > an uneeded lock being taken now in 3.0/3.4 > > It's not worth it to revert it. The lock is being taken in a > completely non-fastpath, as well as guaranteed-to-be non-contended > code path. > > We're not requiring that the lock be taken in 3.0 and 3.4, but > arguably it's still a good idea to take it from a consistency point of > view. Thanks for letting me know, I'll just leave it for now. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch
--- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2204,7 +2204,9 @@ static void ext4_orphan_cleanup(struct s __func__, inode->i_ino, inode->i_size); jbd_debug(2, "truncating inode %lu to %lld bytes\n", inode->i_ino, inode->i_size); + mutex_lock(&inode->i_mutex); ext4_truncate(inode); + mutex_unlock(&inode->i_mutex); nr_truncates++; } else { ext4_msg(sb, KERN_DEBUG,