linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/1]ext4: Fix for WARN_ON_ONCE when marking buffer dirty
@ 2016-06-30 11:12 Pranay Kr. Srivastava
  2016-06-30 11:12 ` [PATCH 1/1]ext4: Fix " Pranay Kr. Srivastava
  0 siblings, 1 reply; 5+ messages in thread
From: Pranay Kr. Srivastava @ 2016-06-30 11:12 UTC (permalink / raw)
  To: tytso, adilger.kernel, linux-ext4, linux-kernel; +Cc: Pranay Kr. Srivastava


1) Fix WARN_ON_ONCE when marking buffer dirty
   it's possible that a writeback for the super block
   buffer head is triggered after setting the buffer
   uptodate on a buffer write_io_error.

   If however there's an error while writing the buffer
   head then the buffer is cleared from being uptodate.

   If the buffer uptodate is not set while calling
   mark_buffer_dirty, it throws a WARN_ON_ONCE.
   This patch fixes it by locking the buffer while marking
   the buffer uptodate and then marking it dirty while holding
   the buffer head lock.


Pranay Kr. Srivastava (5):
   Fix WARN_ON_ONCE when marking buffer dirty

 fs/ext4/super.c     |  30 +++++-----
 1 files changed, 16 insertions(+), 14 deletions(-)

-- 
1.9.1

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty
  2016-06-30 11:12 [PATCH 0/1]ext4: Fix for WARN_ON_ONCE when marking buffer dirty Pranay Kr. Srivastava
@ 2016-06-30 11:12 ` Pranay Kr. Srivastava
  2016-07-04  7:09   ` Pranay Srivastava
  2016-07-04 14:29   ` Theodore Ts'o
  0 siblings, 2 replies; 5+ messages in thread
From: Pranay Kr. Srivastava @ 2016-06-30 11:12 UTC (permalink / raw)
  To: tytso, adilger.kernel, linux-ext4, linux-kernel; +Cc: Pranay Kr. Srivastava

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

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty
  2016-06-30 11:12 ` [PATCH 1/1]ext4: Fix " Pranay Kr. Srivastava
@ 2016-07-04  7:09   ` Pranay Srivastava
  2016-07-04 14:29   ` Theodore Ts'o
  1 sibling, 0 replies; 5+ messages in thread
From: Pranay Srivastava @ 2016-07-04  7:09 UTC (permalink / raw)
  To: Theodore Ts'o, adilger.kernel, linux-ext4, linux-kernel
  Cc: Pranay Kr. Srivastava

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty
  2016-06-30 11:12 ` [PATCH 1/1]ext4: Fix " Pranay Kr. Srivastava
  2016-07-04  7:09   ` Pranay Srivastava
@ 2016-07-04 14:29   ` Theodore Ts'o
  2016-07-05  3:27     ` Pranay Srivastava
  1 sibling, 1 reply; 5+ messages in thread
From: Theodore Ts'o @ 2016-07-04 14:29 UTC (permalink / raw)
  To: Pranay Kr. Srivastava; +Cc: adilger.kernel, linux-ext4, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1]ext4: Fix WARN_ON_ONCE when marking buffer dirty
  2016-07-04 14:29   ` Theodore Ts'o
@ 2016-07-05  3:27     ` Pranay Srivastava
  0 siblings, 0 replies; 5+ messages in thread
From: Pranay Srivastava @ 2016-07-05  3:27 UTC (permalink / raw)
  To: Theodore Ts'o, Pranay Kr. Srivastava, adilger.kernel,
	linux-ext4, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-07-05  3:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-06-30 11:12 [PATCH 0/1]ext4: Fix for WARN_ON_ONCE when marking buffer dirty Pranay Kr. Srivastava
2016-06-30 11:12 ` [PATCH 1/1]ext4: Fix " Pranay Kr. Srivastava
2016-07-04  7:09   ` Pranay Srivastava
2016-07-04 14:29   ` Theodore Ts'o
2016-07-05  3:27     ` Pranay Srivastava

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).