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
Signed-off-by: Pranay Kr. Srivastava <[email protected]>
---
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
On Thu, Jun 30, 2016 at 4:42 PM, Pranay Kr. Srivastava
<[email protected]> wrote:
> Signed-off-by: Pranay Kr. Srivastava <[email protected]>
> ---
> 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
On Thu, Jun 30, 2016 at 02:12:30PM +0300, Pranay Kr. Srivastava wrote:
> Signed-off-by: Pranay Kr. Srivastava <[email protected]>
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 <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
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
On Mon, Jul 4, 2016 at 7:59 PM, Theodore Ts'o <[email protected]> wrote:
> On Thu, Jun 30, 2016 at 02:12:30PM +0300, Pranay Kr. Srivastava wrote:
>> Signed-off-by: Pranay Kr. Srivastava <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Theodore Ts'o <[email protected]>
>
> 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