[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTikSFUqtvw8VZa2oXWOZL3tUnt+UEg@mail.gmail.com>
Date: Tue, 7 Jun 2011 20:05:07 -0500
From: Will Drewry <wad@...omium.org>
To: paulmck@...ux.vnet.ibm.com
Cc: linux-kernel@...r.kernel.org, kees.cook@...onical.com,
torvalds@...ux-foundation.org, tglx@...utronix.de, mingo@...e.hu,
rostedt@...dmis.org, jmorris@...ei.org
Subject: Re: [PATCH v4 04/13] seccomp_filter: add process state reporting
On Tue, Jun 7, 2011 at 6:56 PM, Paul E. McKenney
<paulmck@...ux.vnet.ibm.com> wrote:
> On Fri, Jun 03, 2011 at 03:34:03PM -0500, Will Drewry wrote:
>> Adds seccomp and seccomp_filter status reporting to proc.
>> /proc/<pid>/seccomp_filter provides the current seccomp mode
>> and the list of allowed or dynamically filtered system calls.
>>
>> v4: move from rcu guard to mutex guard
>
> Just in case the mutex guard turns into a bottleneck... Replacing
> your earlier racy rcu_assign_pointer() with xchg() would allow
> the "winner" to free up the "loser"'s structure.
>
> Of course, if the mutex guard works well for you, why bother?
In my tests so far, the overhead has been quite low (since the fast
path is usually taken). If it turns into a pain point for any reason
(increased contention, arch-specific pain, whatever), I'll certainly
look at replacing it with an xchg(). I opted for the simplest
approach for now in hopes I wouldn't do it wrong yet-again.
Thanks!
will
--
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