On Tue, Jan 07, 2014 at 07:12:58PM +0100, Oleg Nesterov wrote:
> Hello.
>
> I tried to audit the users of thread_group_empty() (we need
> to change it) and found rcu_my_thread_group_empty() which
> looks wrong.
>
> The patches look simple, but I am not sure it is fine to use
> rcu_lock_acquire() directly. Perhaps it makes sense to add a
> new helper? Note that we have more users which take rcu lock
> only to shut up lockdep. Please review.
>
> And I am a bit confused. Perhaps rcu_lock_acquire() should
> depend on CONFIG_PROVE_RCU, not on CONFIG_DEBUG_LOCK_ALLOC?
> We only need rcu_lock_map/etc for rcu_lockdep_assert().
I am not all that excited about invoking rcu_lock_acquire() outside
of RCU...
Another approach would be to add an argument to files_fdtable()
that is zero normally and one for "we know we don't need RCU
protection." Then rcu_dereference_check() could be something
like the following:
#define files_fdtable(files, c) \
(rcu_dereference_check_fdtable((files), (files)->fdt) || c)
Would that work?
Thanx, Paul
> Oleg.
>
> fs/file.c | 24 +++++++++++-------------
> include/linux/fdtable.h | 19 +++++++++++++------
> include/linux/rcupdate.h | 2 --
> kernel/rcu/update.c | 11 -----------
> 4 files changed, 24 insertions(+), 32 deletions(-)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
