[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jLEiB4i1_WCkDz3MDM=LBKKWB_cqhOWcpzEYAon0YZp8w@mail.gmail.com>
Date: Wed, 14 Dec 2011 23:20:20 -0800
From: Kees Cook <keescook@...omium.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] sched: mark parent and real_parent as __rcu
On Wed, Dec 14, 2011 at 11:08 PM, Ingo Molnar <mingo@...e.hu> wrote:
> * Kees Cook <keescook@...omium.org> wrote:
>
>> The parent and real_parent pointers should be considered __rcu, since
>> they should be held under either tasklist_lock or rcu_read_lock.
>>
>> Signed-off-by: Kees Cook <keescook@...omium.org>
>> ---
>> include/linux/sched.h | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> Did you get some warning that alerted you to this problem? If
> yes then please include it in the changelog, so that people
> hitting the message can easily find it.
>
> Same consideration applies the second patch as well.
No, this was via code inspection related to reviews of the Yama LSM's
use of these structures and comparing the RCU and tasklist_lock
behavior/requirements seen in the rest of the kernel. Most attempts at
using sparse after this change were not very successful due to the
high volume of unrelated noise currently seen with "make C=2", but I
was able to confirm that the apparmor and tomoyo patches were flagged
by sparse, at least. When this __rcu marking is in place, if there is
a place that might need rcu_dereference, it would show up as "warning:
dereference of noderef expression".
-Kees
--
Kees Cook
ChromeOS Security
--
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