Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 11 Nov 2010 23:00:49 +0100 | From | Oleg Nesterov <> | Subject | Re: INFO: suspicious rcu_dereference_check() usage - kernel/pid.c:419 invoked rcu_dereference_check() without protection! |
| |
On 11/11, Greg Thelen wrote: > > a) my original report added rcu_read_lock() to sys_ioprio_get() and > claims that "something" is needed in sys_ioprio_set(). > > c) http://lkml.org/lkml/2010/10/29/168 added rcu locks to both > sys_ioprio_get() and sys_ioprio_set() thus addressing the issues > raised in a). However, I do not see this patch in -mm.
Well, I do not know what happened with this patch, but
> I can resubmit my patch, but want to know if there is a reason that > http://lkml.org/lkml/2010/10/29/168 did not make it into either -mm > or linux-next?
I am looking at http://lkml.org/lkml/2010/10/29/168 now, and I think it should be dropped or you can submit the patch on top of it.
It only adds rcu_read_lock() around of find_task_by_vpid(), but we can use rcu_read_lock() instead of tasklist_lock.
> d) the sys_ioprio_set() comment indicating that "we can't use > rcu_read_lock()" needs to be updated to be more clear. I'm not sure > what this should be updated to, which leads into the next > sub-topic...
It should be just removed. It doesn't match the reality today.
> e) possibly removing tasklist_lock,
Yes.
> though there seems to be some > concern that this might introduce task->io_context usage race.
No!
I am sorry for confusion, those ->io_context races are completely orthogonal to s/tasklist/rcu/.
Oleg.
| ![\](/images/icornerr.gif) |