linux-kernel - Re: bug in 2.6.26-rc9: sleeping function called from invalid context at kernel/rwsem:21

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4875DB38.4000209@cateee.net>
Date:	Thu, 10 Jul 2008 11:49:44 +0200
From:	"Giacomo A. Catenazzi" <cate@...eee.net>
To:	Vegard Nossum <vegard.nossum@...il.com>
CC:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: bug in 2.6.26-rc9: sleeping function called from invalid context
 at kernel/rwsem:21

Vegard Nossum wrote:
> On Thu, Jul 10, 2008 at 10:19 AM, Giacomo A. Catenazzi <cate@...eee.net> wrote:
>> Hello,
>>
>> yesterday at shutdown I had a crash. Unfortunately it seems
>> that there was one (or more) oops missing. The bug appeared
>> at unmounting partition at shutdown, so there are no logs
>> of the previous messages.
> 
> Thanks for the report.
> 
> It would be really useful to know which filesystems you are/were
> using, including virtual filesystems like sysfs. Maybe you are using
> ecryptfs or FUSE?
> 
> (It would also be interesting to see if you could run
> /etc/rc0.d/S40umountfs while the machine is up, to see if you can get
> the segfault but keep the machine usable enough to get the whole log.)

At home, my disks are only ext2.
sysfs, procfs and other system fs and /dev/* mount points are not
umounted in /etc/rc0.d/S40umountfs.

By a quick look (I'm not at home), it seems that on my home computer
only ext2 fs are umounted by /etc/rc0.d/S40umountfs.

As I said, the bug doesn't seems reproducible,
but I'll try harder later.

At subsequent boot, the unclean fs were: / /var and /usr,
Checking was done without error messages, so I think no busy
or opened files at time of crash.

Note: at the boot, one filesystem was checked (after 30+x),
I think it was /home. But I really think it is unrelated
(but it means that some of the other fs have a boot count > 30)

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