Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1434465 > unrolled thread

[PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty

Started by"Pranay Kr. Srivastava" <pranjas@gmail.com>
First post2016-06-30 13:20 +0200
Last post2016-07-05 05:30 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty "Pranay Kr. Srivastava" <pranjas@gmail.com> - 2016-06-30 13:20 +0200
    Re: [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty Pranay Srivastava <pranjas@gmail.com> - 2016-07-04 09:10 +0200
    Re: [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty Theodore Ts'o <tytso@mit.edu> - 2016-07-04 16:30 +0200
      Re: [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty Pranay Srivastava <pranjas@gmail.com> - 2016-07-05 05:30 +0200

#1434465 — [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty

From"Pranay Kr. Srivastava" <pranjas@gmail.com>
Date2016-06-30 13:20 +0200
Subject[PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty
Message-ID<rPIaJ-to-7@gated-at.bofh.it>
Signed-off-by: Pranay Kr. Srivastava <pranjas@gmail.com>
---
 fs/ext4/super.c | 30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 3822a5a..8f10715 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4327,20 +4327,6 @@ static int ext4_commit_super(struct super_block *sb, int sync)
 
 	if (!sbh || block_device_ejected(sb))
 		return error;
-	if (buffer_write_io_error(sbh)) {
-		/*
-		 * Oh, dear.  A previous attempt to write the
-		 * superblock failed.  This could happen because the
-		 * USB device was yanked out.  Or it could happen to
-		 * be a transient write error and maybe the block will
-		 * be remapped.  Nothing we can do but to retry the
-		 * write and hope for the best.
-		 */
-		ext4_msg(sb, KERN_ERR, "previous I/O error to "
-		       "superblock detected");
-		clear_buffer_write_io_error(sbh);
-		set_buffer_uptodate(sbh);
-	}
 	/*
 	 * If the file system is mounted read-only, don't update the
 	 * superblock write time.  This avoids updating the superblock
@@ -4371,7 +4357,23 @@ static int ext4_commit_super(struct super_block *sb, int sync)
 				&EXT4_SB(sb)->s_freeinodes_counter));
 	BUFFER_TRACE(sbh, "marking dirty");
 	ext4_superblock_csum_set(sb);
+	lock_buffer(sbh);
+	if (buffer_write_io_error(sbh)) {
+		/*
+		 * Oh, dear.  A previous attempt to write the
+		 * superblock failed.  This could happen because the
+		 * USB device was yanked out.  Or it could happen to
+		 * be a transient write error and maybe the block will
+		 * be remapped.  Nothing we can do but to retry the
+		 * write and hope for the best.
+		 */
+		ext4_msg(sb, KERN_ERR, "previous I/O error to "
+		       "superblock detected");
+		clear_buffer_write_io_error(sbh);
+		set_buffer_uptodate(sbh);
+	}
 	mark_buffer_dirty(sbh);
+	unlock_buffer(sbh);
 	if (sync) {
 		error = __sync_dirty_buffer(sbh,
 			test_opt(sb, BARRIER) ? WRITE_FUA : WRITE_SYNC);
-- 
1.9.1

[toc] | [next] | [standalone]


#1436122

FromPranay Srivastava <pranjas@gmail.com>
Date2016-07-04 09:10 +0200
Message-ID<rR6aZ-2Cq-5@gated-at.bofh.it>
In reply to#1434465
On Thu, Jun 30, 2016 at 4:42 PM, Pranay Kr. Srivastava
<pranjas@gmail.com> wrote:
> Signed-off-by: Pranay Kr. Srivastava <pranjas@gmail.com>
> ---
>  fs/ext4/super.c | 30 ++++++++++++++++--------------
>  1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 3822a5a..8f10715 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -4327,20 +4327,6 @@ static int ext4_commit_super(struct super_block *sb, int sync)
>
>         if (!sbh || block_device_ejected(sb))
>                 return error;
> -       if (buffer_write_io_error(sbh)) {
> -               /*
> -                * Oh, dear.  A previous attempt to write the
> -                * superblock failed.  This could happen because the
> -                * USB device was yanked out.  Or it could happen to
> -                * be a transient write error and maybe the block will
> -                * be remapped.  Nothing we can do but to retry the
> -                * write and hope for the best.
> -                */
> -               ext4_msg(sb, KERN_ERR, "previous I/O error to "
> -                      "superblock detected");
> -               clear_buffer_write_io_error(sbh);
> -               set_buffer_uptodate(sbh);
> -       }
>         /*
>          * If the file system is mounted read-only, don't update the
>          * superblock write time.  This avoids updating the superblock
> @@ -4371,7 +4357,23 @@ static int ext4_commit_super(struct super_block *sb, int sync)
>                                 &EXT4_SB(sb)->s_freeinodes_counter));
>         BUFFER_TRACE(sbh, "marking dirty");
>         ext4_superblock_csum_set(sb);
> +       lock_buffer(sbh);
> +       if (buffer_write_io_error(sbh)) {
> +               /*
> +                * Oh, dear.  A previous attempt to write the
> +                * superblock failed.  This could happen because the
> +                * USB device was yanked out.  Or it could happen to
> +                * be a transient write error and maybe the block will
> +                * be remapped.  Nothing we can do but to retry the
> +                * write and hope for the best.
> +                */
> +               ext4_msg(sb, KERN_ERR, "previous I/O error to "
> +                      "superblock detected");
> +               clear_buffer_write_io_error(sbh);
> +               set_buffer_uptodate(sbh);
> +       }
>         mark_buffer_dirty(sbh);
> +       unlock_buffer(sbh);
>         if (sync) {
>                 error = __sync_dirty_buffer(sbh,
>                         test_opt(sb, BARRIER) ? WRITE_FUA : WRITE_SYNC);
> --
> 1.9.1
>

Can this be reviewed as well please.


-- 
        ---P.K.S

[toc] | [prev] | [next] | [standalone]


#1436549

FromTheodore Ts'o <tytso@mit.edu>
Date2016-07-04 16:30 +0200
Message-ID<rRd2N-6Kd-23@gated-at.bofh.it>
In reply to#1434465
On Thu, Jun 30, 2016 at 02:12:30PM +0300, Pranay Kr. Srivastava wrote:
> Signed-off-by: Pranay Kr. Srivastava <pranjas@gmail.com>

The description for why the change is being made should go in the
commit.  (No need to put the description in a separate cover letter.)
I ended up rewriting the commit description as follows, to make it
much more understandable:

    ext4: Fix WARN_ON_ONCE in ext4_commit_super()

    If there are racing calls to ext4_commit_super() it's possible for
    another writeback of the superblock to result in the buffer being
    marked with an error after we check if the buffer is marked as
    having a write error and the buffer up-to-date flag is set again.
    If that happens mark_buffer_dirty() can end up throwing a
    WARN_ON_ONCE.

    Fix this by moving this check to write before we call
    write_buffer_dirty(), and keeping the buffer locked during this
    whole sequence.

    Signed-off-by: Pranay Kr. Srivastava <pranjas@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>

Note that the one-line summary needs to carry as much information as
possible so someone who is scanning the commits using git log
--oneline has a chance of understanding it.  This means the high-level
*why* of the commit, not a summary of what the changes in the C code.
Also note the increased context of when the misbehaviour could occur
in the commit description, which was missing in the cover letter.

When I'm processing patches, if I'm in a hurry, patches that require
extra work or which aren't Obviously Right, sometimes get deferred by
a few days.  This patch fell in that category.

Adding to the commit descrtipion additional context and/or
instructions for how to reproduce the problem you are trying to
remediate will often make life much easier for me, and accelerate how
quickly I'll get to your patch.

Cheers,

							- Ted

[toc] | [prev] | [next] | [standalone]


#1436736

FromPranay Srivastava <pranjas@gmail.com>
Date2016-07-05 05:30 +0200
Message-ID<rRpdD-5Oe-3@gated-at.bofh.it>
In reply to#1436549
On Mon, Jul 4, 2016 at 7:59 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Thu, Jun 30, 2016 at 02:12:30PM +0300, Pranay Kr. Srivastava wrote:
>> Signed-off-by: Pranay Kr. Srivastava <pranjas@gmail.com>
>
> The description for why the change is being made should go in the
> commit.  (No need to put the description in a separate cover letter.)
> I ended up rewriting the commit description as follows, to make it
> much more understandable:
>
>     ext4: Fix WARN_ON_ONCE in ext4_commit_super()
>
>     If there are racing calls to ext4_commit_super() it's possible for
>     another writeback of the superblock to result in the buffer being
>     marked with an error after we check if the buffer is marked as
>     having a write error and the buffer up-to-date flag is set again.
>     If that happens mark_buffer_dirty() can end up throwing a
>     WARN_ON_ONCE.
>
>     Fix this by moving this check to write before we call
>     write_buffer_dirty(), and keeping the buffer locked during this
>     whole sequence.
>
>     Signed-off-by: Pranay Kr. Srivastava <pranjas@gmail.com>
>     Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>
> Note that the one-line summary needs to carry as much information as
> possible so someone who is scanning the commits using git log
> --oneline has a chance of understanding it.  This means the high-level
> *why* of the commit, not a summary of what the changes in the C code.
> Also note the increased context of when the misbehaviour could occur
> in the commit description, which was missing in the cover letter.
>
> When I'm processing patches, if I'm in a hurry, patches that require
> extra work or which aren't Obviously Right, sometimes get deferred by
> a few days.  This patch fell in that category.
>
> Adding to the commit descrtipion additional context and/or
> instructions for how to reproduce the problem you are trying to
> remediate will often make life much easier for me, and accelerate how
> quickly I'll get to your patch.
>
> Cheers,
>
>                                                         - Ted

Thank you Theodore Sir. Points duly noted, I'll take care from now on
while sending
patches.


-- 
        ---P.K.S

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web