Re: kernel BUG at mm/truncate.c:475!
From: Miklos Szeredi
Date: Mon Dec 06 2010 - 07:36:46 EST
On Fri, 3 Dec 2010, Michael Leun wrote:
> On Thu, 2 Dec 2010 11:57:22 +0100
> Michael Leun <lkml20101129@xxxxxxxxxxxxxxx> wrote:
>
> > > Can you please describe in detail the workload that's causing this
> > > to happen?
> >
> > Thats rather complicated, but I'll try. Basically it boils down to:
> >
> > unshare -n -m /bin/bash
> > unionfs -o
> > cow,suid,allow_other,max_files=65536 /home/netenv/user1-union=RW:/=RO /home/netenv/user1
> > mount -n -t proc none /home/netenv/user1/proc mount -n -t sysfs
> > none /home/netenv/user1/sys mount -n -t devtmpfs
> > devtmpfs /home/netenv/user1/dev mount -n -t devpts
> > devpts /home/netenv/user1/dev/pts chroot /home/netenv/user1 /bin/su -
> > user1
> [...]
> > In some of this setups two or more environments share the same
> > writable branch, so the files in this environments changed against
> > real root of the machine are the same, e.g.:
> >
> > [...]
> > unionfs -o
> > cow,suid,allow_other,max_files=65536 /home/netenv/commondir=RW:/=RO /home/netenv/user1
> > [...]
> >
> > and another one
> >
> > [...]
> > unionfs -o
> > cow,suid,allow_other,max_files=65536 /home/netenv/commondir=RW:/=RO /home/netenv/user2
> > [...]
>
> Additional note: Happens also WITHOUT that "two unionfs mounts use the
> same branch dir" stuff.
Thanks.
For you the workaround would be to use the "kernel_cache" option which
disables cache invalidation on open.
I'll try to reproduce the BUG on my machine, and if I don't succeed
I'll need som more help from you.
Also could you please send me your kernel .config
>
> Really seems to happen much more often in 2.6.36.1 than in 2.6.36.
Probably just coincidence. Sometimes the frequency a bug shows up
depends on code layout (and hence cache layout) differences, which can
vary from compile to compile and even from one boot to the next.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/