All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Riemer <sebastian.riemer@profitbricks.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Neil Brown <neilb@suse.de>, linux-raid@vger.kernel.org
Subject: Re: fsync() on read-only RAID triggers BUG
Date: Fri, 25 Jan 2013 16:09:15 +0100	[thread overview]
Message-ID: <5102A01B.7000407@profitbricks.com> (raw)
In-Reply-To: <1358707492.24121.210.camel@deadeye.wl.decadent.org.uk>

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On 20.01.2013 19:44, Ben Hutchings wrote:
> # Call fsync()
> python -c "import os; os.fsync(os.open('/dev/md0', os.O_RDWR))"
> --- END ---
> 
> I assume that the sync request should be filtered out at some point
> before this assertion is made, since there can be nothing to sync.
> 

I wrote a test case in C. It gets SIGSEGV upon fsync. When making the
rdevs below also read-only the MD device can't be stopped anymore as it
thinks that there is still active IO.

The attached patch should fix it. Please confirm. We have to return a
completion without incrementing the active IO count. Error code -EROFS
seems to be suited best.

But the libc fsync gets -EIO anyway:
Input/output error

Any objection?

Cheers,
Sebastian

[-- Attachment #2: 0001-md-protect-against-crash-upon-fsync-on-ro-array.txt --]
[-- Type: text/plain, Size: 1066 bytes --]

From fe0357344877c9b9cc623fd582a4e0670e448317 Mon Sep 17 00:00:00 2001
From: Sebastian Riemer <sebastian.riemer@profitbricks.com>
Date: Fri, 25 Jan 2013 12:46:59 +0100
Subject: [PATCH] md: protect against crash upon fsync on ro array

If an fsync occurrs on a read-only array, we need to send a
completion for the IO and may not increment the active IO count.
Otherwise, we hit a bug trace and can't stop the MD array anymore.

As return value -EROFS makes most sense.

Signed-off-by: Sebastian Riemer <sebastian.riemer@profitbricks.com>
---
 drivers/md/md.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3db3d1b..475e0be 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -322,6 +322,11 @@ static void md_make_request(struct request_queue *q, struct bio *bio)
 		}
 		finish_wait(&mddev->sb_wait, &__wait);
 	}
+	if (mddev->ro == 1 && unlikely(rw == WRITE)) {
+		rcu_read_unlock();
+		bio_endio(bio, -EROFS);
+		return;
+	}
 	atomic_inc(&mddev->active_io);
 	rcu_read_unlock();
 
-- 
1.7.1


  reply	other threads:[~2013-01-25 15:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-20 18:44 fsync() on read-only RAID triggers BUG Ben Hutchings
2013-01-25 15:09 ` Sebastian Riemer [this message]
2013-01-26 19:44   ` Ben Hutchings
2013-01-27 16:39     ` Christoph Hellwig
2013-01-28 10:32       ` [PATCH v2] md: protect against crash upon fsync on ro array Sebastian Riemer
2013-01-28 12:39         ` [PATCH v3] " Sebastian Riemer
2013-01-29  5:45           ` Ben Hutchings
2013-01-29 11:19             ` [PATCH v4] " Sebastian Riemer
2013-01-29 12:29               ` [PATCH v5] " Paul Menzel
2013-01-31 19:35                 ` Sebastian Riemer
2013-02-04 22:30                   ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5102A01B.7000407@profitbricks.com \
    --to=sebastian.riemer@profitbricks.com \
    --cc=ben@decadent.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.