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: <539E6963.6010509@landley.net>
Date:	Sun, 15 Jun 2014 22:49:55 -0500
From:	Rob Landley <rob@...dley.net>
To:	Roman Pen <r.peniaev@...il.com>
CC:	Ming Lei <ming.lei@...onical.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Michael Opdenacker <michael.opdenacker@...e-electrons.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Krzysztof Mazur <krzysiek@...lesie.net>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/1] init: fix race between rootfs mount and firmware
 loading

On 06/15/14 06:06, Roman Pen wrote:
> The thing is that built-in modules are being inited before
> rootfs mount. Some of the modules can request firmware loading
> using async 'request_firmware_nowait' call just while inition,
> so we can catch this kind of race: rootfs does not exist yet,
> but we are going to open and load firmware file requesting from
> the kernel.

Fixing this was on my todo list for initmpfs, along with a kernel
command line parameter to pass in size= (other than the default 50%),
and fixing the stupid "don't show initramfs in /proc/self/mountinfo
becuase rootfs is _magic_ and it's not like anything else ever gets
overmounted because nobody would _ever_ do that, no we need a magic
special case for this one thing..."

Concept seems sound, quick glance at the patch looks ok to me, my only
"can't say whether or not this is ok off the top of my head" is whether
the wakeup's being done from the right place.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ