linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 005 of 5] md: Allow mddevs to live a bit longer to avoid a loop with udev.
Date: Fri, 8 Dec 2006 12:05:52 +1100	[thread overview]
Message-ID: <1061208010552.21344@suse.de> (raw)
In-Reply-To: 20061208120132.21203.patches@notabene


As md devices a automatically created on first open, and automatically
destroyed on last close if they have no significant state, a loop can
be caused with udev.

If you open/close an md device that will generate add and remove
events to udev.  udev will open the device, notice nothing is there
and close it again ... which generates another pair of add/remove events. 
Ad infinitum.

So: Change md to only destroy a device if an explicity MD_STOP was
requested.  This means that md devices might hang around longer than
you would like, but it is easy to get rid of them, and that could even
be automated in user-space (e.g. by mdadm --monitor).


Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./drivers/md/md.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c	2006-12-07 21:01:11.000000000 +1100
+++ ./drivers/md/md.c	2006-12-08 10:22:46.000000000 +1100
@@ -292,7 +292,7 @@ static mddev_t * mddev_find(dev_t unit)
 	atomic_set(&new->active, 1);
 	spin_lock_init(&new->write_lock);
 	init_waitqueue_head(&new->sb_wait);
-	new->dead = 1;
+	new->dead = 0;
 
 	new->queue = blk_alloc_queue(GFP_KERNEL);
 	if (!new->queue) {

  parent reply	other threads:[~2006-12-08  1:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08  1:05 [PATCH 000 of 5] md: Assorted minor fixes for mainline NeilBrown
2006-12-08  1:05 ` [PATCH 001 of 5] md: Remove some old ifdefed-out code from raid5.c NeilBrown
2006-12-08  1:05 ` [PATCH 002 of 5] md: Return a non-zero error to bi_end_io as appropriate in raid5 NeilBrown
2006-12-08  1:05 ` [PATCH 003 of 5] md: Assorted md and raid1 one-liners NeilBrown
2006-12-08  1:05 ` [PATCH 004 of 5] md: Close a race between destroying and recreating an md device NeilBrown
2006-12-08  1:05 ` NeilBrown [this message]
2006-12-09  0:04 ` [PATCH 000 of 5] md: Assorted minor fixes for mainline Andrew Morton
2006-12-09  8:51   ` Neil Brown

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=1061208010552.21344@suse.de \
    --to=neilb@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    /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 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).