linux-kernel - Re: kernel BUG at lib/radix-tree.c:473!

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

Date:	Thu, 14 Aug 2008 18:42:33 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Ian Campbell <ijc@...lion.org.uk>
cc:	linux-kernel@...r.kernel.org,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Kel Modderman <kel@...ku42.de>,
	Markus Armbruster <armbru@...hat.com>
Subject: Re: kernel BUG at lib/radix-tree.c:473!

On Thu, 14 Aug 2008, Ian Campbell wrote:
> On Thu, 2008-08-14 at 14:06 +0100, Hugh Dickins wrote:
> > On Thu, 14 Aug 2008, Ian Campbell wrote:
> > > Jeremy first noticed this
> > > http://marc.info/?l=linux-kernel&m=121783008503477&w=2
> > > 
> > > I've bisected it down to:
> > > commit 14fcc23fdc78e9d32372553ccf21758a9bd56fa1
> > > Author: Hugh Dickins <hugh@...itas.com>
> > > Date:   Mon Jul 28 15:46:19 2008 -0700
> > > 
> > >     tmpfs: fix kernel BUG in shmem_delete_inode
> 
> > In both cases it's handling a page fault: I'm curious as to what kind
> > of vma this fault is occurring on.  Could you devise a way of getting
> > us /proc/<pid>/maps output, together with the faulting address, when
> > it hits one of these BUGs?  Or should I try to put together a patch
> > for that?
> 
> I'll have a go but I'm just about to go away for a long weekend so it
> might be next week unless I get to it tonight. Any pointers on how to go
> about it would be appreciated though...

No, have a good break and come back to it next week.  Whatever I suggest
in a rush will at first give you more oopses than you started out with,
back and forth, then it'll give us some info but not enough, back and
forth... no.  I'd rather spend the time trying to work out a hypothesis
from my end: it's always easier to devise an info patch once you have
a hypothesis to test, right now it makes no sense to me at all.

My starting point will be, prior to my tmpfs patch the faulting page
had a .set_page_dirty that kept it out of trouble, with that change
of ops now it hasn't; but what kind of page it actually is, a shmem
page (because the ops change affected it) that isn't a shmem page
(because it doesn't have the ops), I don't grasp yet.

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