lkml.org 
[lkml]   [2009]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [cgroup or VFS ?] WARNING: at fs/namespace.c:636 mntput_no_expire+0xac/0xf2()
    On Fri, Feb 13, 2009 at 02:12:13PM +0800, Li Zefan wrote:
    > Al Viro wrote:
    > > On Fri, Feb 13, 2009 at 01:09:17PM +0800, Li Zefan wrote:
    > >
    > >> I ran following testcase, and triggered the warning in 1 hour:
    > >>
    > >> thread 1:
    > >> for ((; ;))
    > >> {
    > >> mount --bind /cgroup /mnt > /dev/null 2>&1
    > >> umount /mnt > /dev/null 2>&1
    > >> }
    > >>
    > >> tread 2:
    > >> for ((; ;))
    > >> {
    > >> mount -t cgroup -o cpu xxx /cgroup > /dev/null 2>&1
    > >> mkdir /cgroup/0 > /dev/null 2>&1
    > >> rmdir /cgroup/0 > /dev/null 2>&1
    > >> umount -l /cgroup > /dev/null 2>&1
    > >> }
    > >
    > > Wow. You know, at that point these redirects could probably be removed.
    >
    > Ah, yes.
    >
    > > If anything in there ends up producing an output, we very much want to
    > > see that. Actually, I'd even make that
    > > mount --bind /cgroup/mnt || (echo mount1: ; date)
    > > etc., so we'd see when do they fail and which one fails (if any)...
    > >
    > > Which umount has failed in the above, BTW?
    > >
    > >
    >
    > the first one sometimes failed, and the second one hasn't failed:

    > mount: wrong fs type, bad option, bad superblock on /cgroup,
    > missing codepage or helper program, or other error
    > In some cases useful info is found in syslog - try
    > dmesg | tail or so
    >
    > mount1

    Hold on. In your last example the first one was doing mount --bind;
    has _that_ failed? Oh, wait... It can fail, all right, if lookup on
    /cgroup gives you your filesystem with the second thread managing to
    detach it before we get the namespace_sem. Then we'll fail that way -
    and clean up properly.

    Oh, well... The original question still stands: with those two
    scripts, which umount produces that WARN_ON? The trivial way
    to check would be to have a copy of /sbin/umount under a different
    name and use _that_ in one of the threads instead of umount.
    Then reproduce the WARN_ON and look at the process name in dmesg...


    \
     
     \ /
      Last update: 2009-02-13 07:45    [W:2.424 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site