linux-kernel - Re: 2.6.39-rc5-git2 boot crashs

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]

Date:	Sat, 30 Apr 2011 04:27:59 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Joern Engel <joern@...fs.org>, Dave Chinner <dchinner@...hat.com>,
	werner <w.landgraf@...ru>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.39-rc5-git2 boot crashs

On Fri, Apr 29, 2011 at 08:09:16PM -0700, Linus Torvalds wrote:
> On Fri, Apr 29, 2011 at 8:02 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > Wait a bit; _can_ we get there with non-NULL ->s_master_inode et.al.?
> > iput(NULL) is a noop... ?I don't think so, since logfs_init_journal()
> > is not called until after we initialize that list.
> >
> > Not that I'd object against taking that initialization earlier, of course,
> > but there seems to be something else going on... ?Which iput() it is?
> 
> Not something I can guess from the oops, sadly. Gcc has inlined
> everything into logfs_mount, and the "0x44f/0x5cc" offset isn't very
> helpful (with the same compiler version and config options it would be
> possible to figure it out).
> 
> But looking at it, logfs_init_mapping() is currently called before
> "s_freeing_list" is initialized, and it sets up at least
> s_mapping_inode. So if anything fails between that point and the point
> where we initialize s_freeing_list, I think we're toast.
> 
> I didn't check the other inodes, but at least that one does seem to be
> potentially non-NULL. No?

Ho-hum...  Point.  Let's take that initialization up to the beginning of
logfs_read_sb(), see if oops goes away and then try to figure out WTF
we hadn't been seeing it all along.  I don't see anything recent affecting
that area, but then logfs goes through many odd places during mount (including,
IIRC, mtd).  So there might be many sources of the failure where we used to
have none and failure in that spot would, indeed, fuck the things up that
way...

In any case, taking that initialization to the beginning of logfs_read_sb()
(if not up to its only caller where we set ->s_op et.al. anyway) seems to be
the obviously right thing to do.  Unless logfs folks have some subtle
objections?
--
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/