From: Greg KH <greg@kroah.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
linux-kernel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@lst.de>
Subject: Re: Naughty ramdrives
Date: Thu, 7 Sep 2006 15:05:59 -0700 [thread overview]
Message-ID: <20060907220559.GA29771@kroah.com> (raw)
In-Reply-To: <20060907145412.db920bb5.akpm@osdl.org>
On Thu, Sep 07, 2006 at 02:54:12PM -0700, Andrew Morton wrote:
> On Fri, 8 Sep 2006 00:59:27 +0400
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> > You'd laugh, but...
> >
> > Summary:
> >
> > After loading and unloading rd.ko many times "ls -l /dev/ram*"
> > results are not persistent.
> >
> > Steps to reproduce:
> >
> > # while true; do modprobe rd && rmmod rd; done
> > [wait ~10 seconds]
> > ^C
> > # modprobe rd
> >
> > # ls -l /dev/ram*
> > lrwxrwxrwx 1 root root 5 Sep 8 00:35 /dev/ram12 -> rd/12
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram6 -> rd/6
> > # ls -l /dev/ram*
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram0 -> rd/0
> > lrwxrwxrwx 1 root root 5 Sep 8 00:35 /dev/ram13 -> rd/13
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram6 -> rd/6
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram7 -> rd/7
> > # ls -l /dev/ram*
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram0 -> rd/0
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram1 -> rd/1
> > lrwxrwxrwx 1 root root 5 Sep 8 00:35 /dev/ram11 -> rd/11
> > lrwxrwxrwx 1 root root 5 Sep 8 00:35 /dev/ram12 -> rd/12
> > lrwxrwxrwx 1 root root 5 Sep 8 00:35 /dev/ram14 -> rd/14
> > lrwxrwxrwx 1 root root 5 Sep 8 00:35 /dev/ram15 -> rd/15
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram3 -> rd/3
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram7 -> rd/7
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram8 -> rd/8
> > lrwxrwxrwx 1 root root 4 Sep 8 00:35 /dev/ram9 -> rd/9
> >
> > Versions:
> >
> > Linux 2.6.18-rc5
> > udev 087
>
> So I assume udev is still madly crunching on its message backlog while
> this is happening?
It shouldn't be, this should not take that long. Run 'udevmonitor' to
see what udev is doing at the moment to verify this or not.
> If so, ug.
I agree. What distro is this?
I just tested this on my box running Gentoo and a newer version of udev
(099), and it worked just fine. It took a while for udev to catch back
up with the flood of events, but it did and everything was fine. No
harm done in the end.
thanks,
greg k-h
next prev parent reply other threads:[~2006-09-07 22:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-07 20:59 Naughty ramdrives Alexey Dobriyan
2006-09-07 21:54 ` Andrew Morton
2006-09-07 22:05 ` Greg KH [this message]
2006-09-07 22:08 ` Alexey Dobriyan
2006-09-07 22:20 ` Andrew Morton
2006-09-07 23:01 ` Greg KH
2006-09-07 23:28 ` Andrew Morton
2006-09-07 23:49 ` Greg KH
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=20060907220559.GA29771@kroah.com \
--to=greg@kroah.com \
--cc=adobriyan@gmail.com \
--cc=akpm@osdl.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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