linux-kernel - Re: kernel BUG at mm/truncate.c:475!

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101202115722.1c00afd5@xenia.leun.net>
Date:	Thu, 2 Dec 2010 11:57:22 +0100
From:	Michael Leun <lkml20101129@...ton.leun.net>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	hughd@...gle.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: kernel BUG at mm/truncate.c:475!

On Thu, 02 Dec 2010 10:42:51 +0100
Miklos Szeredi <miklos@...redi.hu> wrote:

> On Thu, 2 Dec 2010, Michael Leun wrote:
> > > Kernel compile 2.6.36.1 with that .page_mkwrite commented out
> > > running now, will reboot really soon now (TM).
> > 
> > OK - that happened very fast again in 2.6.36.1.
> > 
> > Sorry for that tainted kernel, but cannot afford to additionally
> > have graphics lockups all the time - I've shown that it happens with
> > untainted kernel also (long run without fault yesterday also was
> > with nvidia.ko driver).
> > 
> > Until I've another suggestion what to try I'll swich back to 2.6.36
> > to see if it really happens less frequent there.
> 
> 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

Then run some shell-scripts in this shell running as user1.

Of course there is some more stuff as getting network connectivity in
this new namespace and so on, but I guess thats not important for the
fuse problem.

Then there are some (up to 6 at the moment) more setups like the above
one with different users (user2, user3 and so on) running concurrent.

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
[...]

I observed that unionfs process takes much more cpu power than usual
before fault happens.

 elektra:~ # unionfs --version
unionfs-fuse version: 0.24
FUSE library version: 2.8.5
fusermount version: 2.8.5
using FUSE kernel interface version 7.12

-- 
MfG,

Michael Leun

--
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/