lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4593C051.2020400@redhat.com>
Date:	Thu, 28 Dec 2006 08:02:09 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	Jesper Juhl <jesper.juhl@...il.com>
CC:	linux-kernel@...r.kernel.org, nfs@...ts.sourceforge.net,
	Trond Myklebust <trond.myklebust@....uio.no>
Subject: Re: [NFS] VFS: Busy inodes after unmount. Self-destruct in 5 seconds.
 Have a nice day...

Jesper Juhl wrote:
> I get this message in my webservers (with NFS mounted homedirs) logs once 
> in a while : 
> 
>   kernel: VFS: Busy inodes after unmount. Self-destruct in 5 seconds.  Have a nice day...
> 
> It doesn't seem to have any bad effect on anything, but it would be nice 
> to know if there is any cause for concern.
> 

It is cause for concern. This means that the filesystem was unmounted (and the 
superblock was freed), but the inode structs are still hanging around. The 
"self-destruct" is telling you that eventually, this machine will crash due to 
this. If you see this message you should probably plan a reboot sometime.

What will happen is that eventually the kernel may try to reference these 
inodes, but they now have pointers into a freed superblock. If that superblock 
memory was reused for another purpose, you'll likely crash.

IMO, we should probably consider this to be a BUG(), but that only really is 
helpful if you can capture a coredump and can try to track down why these inodes 
couldn't be flushed correctly. In the very least, it's probably time to change 
this message to be less cryptic.

I've seen some sporadic reports of this problem on earlier kernels in situations 
where a NFS server is unable to be contacted for a while, but have not gotten 
enough info to get a handle on it.

-- Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ