Messages in this thread | | | Subject | Re: [PATCH 2/2] CRED: Fix __task_cred()'s lockdep check and banner comment | From | Tetsuo Handa <> | Date | Wed, 04 Aug 2010 09:38:42 +0900 |
| |
David Howells wrote: > Tetsuo Handa wrote: > > > I got below warning. Is this related to this patch? > > > > [ 140.173556] =================================================== > > [ 140.215379] [ INFO: suspicious rcu_dereference_check() usage. ] > > [ 140.216461] --------------------------------------------------- > > [ 140.217530] kernel/signal.c:660 invoked rcu_dereference_check() without protection! > > Yes. The patch has uncovered a case of where we should be holding a lock, but > aren't. > > Can you try the attached patch? > > David > --- > From: David Howells <dhowells@redhat.com> > Subject: [PATCH] CRED: Fix RCU warning due to previous patch fixing __task_cred()'s checks > > A previous patch: > > commit 8f92054e7ca1d3a3ae50fb42d2253ac8730d9b2a > Author: David Howells <dhowells@redhat.com> > Date: Thu Jul 29 12:45:55 2010 +0100 > Subject: CRED: Fix __task_cred()'s lockdep check and banner comment > > fixed the lockdep checks on __task_cred(). This has shown up a place in the > signalling code where a lock should be held - namely that > check_kill_permission() requires its callers to hold the RCU lock. > > It's may be that it would be better to add RCU read lock calls in > group_send_sig_info() only, around the call to check_kill_permission(). On the > other hand, some of the callers are either holding the RCU read lock already, > or have disabled interrupts, in which case, it's just extra overhead to do it > in g_s_s_i().
That patch solved the warning. Thank you.
| |