linux-kernel - Re: [BUG, linux-next] spawn PID 1 without CLONE

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

Message-ID: <20141217145446.GA3895@newt.localdomain>
Date:	Wed, 17 Dec 2014 06:54:46 -0800
From:	Jeremiah Mahler <jmmahler@...il.com>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [BUG, linux-next] spawn PID 1 without CLONE_FS, wireless inop

Takashi,

On Wed, Dec 17, 2014 at 02:17:57PM +0100, Takashi Iwai wrote:
> At Tue, 16 Dec 2014 12:03:51 -0800,
> Jeremiah Mahler wrote:
> > 
> > Al Viro,
[...]
> > > 
> > > OK, so the root is on sda6, it's been mounted before those attempts to
> > > load firmware and init has been chrooted into it, while init_fs got left
> > > behind.  And that "chrooted into" has happened without pivot_root(2) (or
> > > it would've been caught by chroot_fs_refs() in sys_pivot_root()) and
> > > not from the "no /init on initramfs" codepath (you do have it there).
> > > 
> > > OK, it's probably unsalvagable, then.  Pity, since it means that PID 1 and
> > > kernel threads _must_ share ->fs, for the sake of usable ->fs->root, which
> > > is asking for trouble.  And it means that we still need a sane solution for
> > > nfsd folks...
> > > 
> > > Anyway, dropped that stuff from for-next (and for-linus, obviously), with
> > > apologies all around.
> > 
> > On a totally different machine, an Acer C720, the sound quit working.
> > I bisected that one and it pointed to this same commit.  However this
> > one doesn't involve loading firmware or any of that stuff.  Attached
> > are the good/bad dmesg logs.
> 
> Did you mean HD-audio stuff?  The bad case shows the error
> 
> [    2.122849] hda-i915: get_power symbol get fail
> [    2.122856] snd_hda_intel 0000:00:03.0: Error request power-well from i915
> 
> This is the place calling request_symbol(), where i915 module should
> have been loaded dynamically but it failed, likely because of the same
> reason as the firmware loading failure.
> 

Ah, perhaps it does load firmware.  Then I am mistaken on that point.

> 
> Takashi

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