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]
Message-Id: <20120306164916.171429c5.akpm@linux-foundation.org>
Date:	Tue, 6 Mar 2012 16:49:16 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Eric Paris <eparis@...isplace.org>
Cc:	gaowanlong@...fujitsu.com, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, James Morris <jmorris@...ei.org>,
	sds@...ho.nsa.gov
Subject: Re: [PATCH] selinux: init target class when add avc callback

On Tue, 06 Mar 2012 19:41:33 -0500
Eric Paris <eparis@...isplace.org> wrote:

> __initcall() functions aren't serialized?  I guess that would be bad and
> we would need a lock.  I wonder if there are other places I assumed
> __initcall() would be serialized (note that all of these call sites are
> built in and not modules if that makes a difference)

There's plenty of code in the kernel which assumes that initcalls
are singly-threaded.  And init/main.c:do_initcalls() is very
singly-threaded!  It's less clear when the initcall is executed by
modprobe, but presumably there's something in the module code which
prevents concurrent execution of module_init() functions.

So I think the list management code is acceptable, as long as we ensure
that the function is only ever called from initcall functions.  We can
add a comment, but a neat way of ensuring this is to mark the function
__init.  This saves memory and will cause a build-time warning if we
screw up.

My point was that given that this function is only ever called from
initcalls, that weak GFP_ATOMIC could/should be replaced with
GFP_KERNEL.

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