From: Neil Brown <neilb@suse•de>
To: Andrew Morton <akpm@linux-foundation•org>
Cc: kay.sievers@vrfy•org, sfr@canb•auug.org.au,
linux-next@vger•kernel.org, linux-kernel@vger•kernel.org,
adobriyan@gmail•com, greg@kroah•com
Subject: Re: linux-next: Tree for December 9
Date: Thu, 11 Dec 2008 09:15:45 +1100 [thread overview]
Message-ID: <18752.16273.604044.142078@notabene.brown> (raw)
In-Reply-To: message from Andrew Morton on Wednesday December 10
On Wednesday December 10, akpm@linux-foundation•org wrote:
> On Wed, 10 Dec 2008 12:42:58 +1100 (EST)
> "NeilBrown" <neilb@suse•de> wrote:
>
> > On Wed, December 10, 2008 12:30 pm, Andrew Morton wrote:
> > > On Wed, 10 Dec 2008 01:31:13 +0100 "Kay Sievers" <kay.sievers@vrfy•org>
> > > wrote:
> > >
> > >> > akpm2:/home/akpm# udevmonitor
> > >> > udevmonitor prints the received event from the kernel [UEVENT]
> > >> > and the event which udev sends out after rule processing [UDEV]
> > >> >
> > >> > UDEV [1228867146.103334] add@/class/bdi/9:0
> > >> > UDEV [1228867146.107566] remove@/block/md0
> > >> > UDEV [1228867146.111969] remove@/class/bdi/9:0
> > >> > UEVENT[1228867146.119889] add@/block/md0
> > >> > UEVENT[1228867146.119964] add@/class/bdi/9:0
> > >> > UEVENT[1228867146.120162] remove@/class/bdi/9:0
> > >> > UEVENT[1228867146.120205] remove@/block/md0
> > >> > UDEV [1228867146.122839] add@/block/md0
> > >> > UDEV [1228867146.129125] add@/class/bdi/9:0
> > >> > UDEV [1228867146.133459] remove@/block/md0
> > >> > UDEV [1228867146.137813] remove@/class/bdi/9:0
> > >> > UEVENT[1228867146.145652] add@/block/md0
> > >>
> > >> Weird loop, something is accessing /dev/md0, i guess, which creates
> > >> the kernel device, and the event, which accesses /dev/md0 again and it
> > >> goes crazy. Maybe caused by changes Neil did.
> > >
> > > I knew an Australian was to blame - it's just a matter of determining
> > > which one.
> >
> > Let's not count our chickens .... :-)
> >
> > Can you get me
> > tar czvf - /lib/udev /etc/udev | mail neilb
> >
> > so I can see exactly what FC6 is likely to try to do when an
> > md device appears or disappears?
>
> Is at http://userweb.kernel.org/~akpm/udev.tar.gz, thanks.
Thanks.
That udev code does no special handling of md device, and runs vol-id
on every device that appears to see what it contains.
So if an md device is ever opened and closed immediately - as
typically happens at boot to sent the AUTO_RUN ioctl to do in-kernel
autodetection - then it will start a loop:
loop:
The open causes an ADD event to udev.
By the time udev handles it the device is closed, so when
udev opens the device (via vol-id), the device is re-created
triggering another ADD event.
vol-id then closes the device and it disappears.
Goto loop
So it isn't safe to destroy the md device as soon as it is closed.
Next best option is to destroy it after close providing at least one
ioctl has been made (or similar change via writing to sysfs).
This means that in most cases the device will disappear when not
needed, but in the particular case of some code which doesn't really
understand 'md' opening the device, it will hang around to avoid
causing confusion.
I have just pushed out an updated for-next branch.
The incremental patch is below.
Thanks,
NeilBrown
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 89700b5..bef91b8 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -262,7 +262,7 @@ static mddev_t * mddev_find(dev_t unit)
if (new) {
list_add(&new->all_mddevs, &all_mddevs);
spin_unlock(&all_mddevs_lock);
- new->hold_active = UNTIL_CLOSE;
+ new->hold_active = UNTIL_IOCTL;
return new;
}
} else if (new) {
@@ -3487,6 +3487,8 @@ md_attr_store(struct kobject *kobj, struct attribute *attr,
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
rv = mddev_lock(mddev);
+ if (mddev->hold_active == UNTIL_IOCTL)
+ mddev->hold_active = 0;
if (!rv) {
rv = entry->store(mddev, page, length);
mddev_unlock(mddev);
@@ -5160,6 +5162,9 @@ static int md_ioctl(struct block_device *bdev, fmode_t mode,
done_unlock:
abort_unlock:
+ if (mddev->hold_active == UNTIL_IOCTL &&
+ err != -EINVAL)
+ mddev->hold_active = 0;
mddev_unlock(mddev);
return err;
@@ -5209,8 +5214,6 @@ static int md_release(struct gendisk *disk, fmode_t mode)
BUG_ON(!mddev);
atomic_dec(&mddev->openers);
- if (mddev->hold_active == UNTIL_CLOSE)
- mddev->hold_active = 0;
mddev_put(mddev);
return 0;
diff --git a/include/linux/raid/md_k.h b/include/linux/raid/md_k.h
index 19756d7..dac4217 100644
--- a/include/linux/raid/md_k.h
+++ b/include/linux/raid/md_k.h
@@ -138,7 +138,7 @@ struct mddev_s
struct kobject kobj;
int hold_active;
-#define UNTIL_CLOSE 1
+#define UNTIL_IOCTL 1
#define UNTIL_STOP 2
/* Superblock information */
next prev parent reply other threads:[~2008-12-10 22:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-09 7:52 linux-next: Tree for December 9 Stephen Rothwell
2008-12-09 8:53 ` Al Viro
2008-12-09 13:57 ` byteorder headers on parisc Alexey Dobriyan
2008-12-09 23:12 ` Harvey Harrison
2008-12-09 23:34 ` linux-next: Tree for December 9 Andrew Morton
2008-12-10 0:06 ` Kay Sievers
2008-12-10 0:15 ` Andrew Morton
2008-12-10 0:31 ` Kay Sievers
2008-12-10 1:30 ` Andrew Morton
2008-12-10 1:36 ` Kay Sievers
2008-12-10 1:42 ` NeilBrown
2008-12-10 1:58 ` Andrew Morton
2008-12-10 19:16 ` Andrew Morton
2008-12-10 22:15 ` Neil Brown [this message]
2008-12-10 11:57 ` [BUG] linux-next: 20081209 - kernel bug at __rcu_process_callbacks, while booting up Kamalesh Babulal
2008-12-10 14:54 ` Paul E. McKenney
2008-12-10 16:30 ` Kamalesh Babulal
2008-12-10 17:53 ` Paul E. McKenney
2008-12-10 18:09 ` Kamalesh Babulal
2008-12-10 18:33 ` Paul E. McKenney
2008-12-12 19:40 ` Kamalesh Babulal
2008-12-12 22:16 ` Paul E. McKenney
2008-12-16 14:30 ` Kamalesh Babulal
2008-12-16 14:37 ` Jens Axboe
2008-12-17 11:12 ` Kamalesh Babulal
2008-12-17 11:18 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2009-12-09 6:47 linux-next: Tree for December 9 Stephen Rothwell
2010-12-09 4:41 Stephen Rothwell
2010-12-09 11:46 ` Zimny Lech
2010-12-09 15:49 ` Greg KH
2010-12-09 16:42 ` Zimny Lech
2010-12-09 19:35 ` Jing Huang
2010-12-09 20:29 ` Zimny Lech
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=18752.16273.604044.142078@notabene.brown \
--to=neilb@suse$(echo .)de \
--cc=adobriyan@gmail$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=greg@kroah$(echo .)com \
--cc=kay.sievers@vrfy$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=sfr@canb$(echo .)auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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