All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Eric Paris <eparis@parisplace.org>
Cc: gaowanlong@cn.fujitsu.com, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, James Morris <jmorris@namei.org>,
	sds@tycho.nsa.gov
Subject: Re: [PATCH] selinux: init target class when add avc callback
Date: Tue, 6 Mar 2012 16:49:16 -0800	[thread overview]
Message-ID: <20120306164916.171429c5.akpm@linux-foundation.org> (raw)
In-Reply-To: <1331080893.6253.1.camel@localhost>

On Tue, 06 Mar 2012 19:41:33 -0500
Eric Paris <eparis@parisplace.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.


  parent reply	other threads:[~2012-03-07  0:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-05  1:53 [PATCH] selinux: init target class when add avc callback Wanlong Gao
2012-03-06 23:59 ` Wanlong Gao
2012-03-07  0:15   ` Andrew Morton
2012-03-07  0:41     ` Eric Paris
2012-03-07  0:48       ` Wanlong Gao
2012-03-07  0:49       ` Andrew Morton [this message]
2012-03-07 13:27       ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120306164916.171429c5.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=eparis@parisplace.org \
    --cc=gaowanlong@cn.fujitsu.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.