* [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).