Re: [PATCH 0/2] rcu_dereference_check_fdtable fix/cleanups

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

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