Re: INFO: suspicious rcu_dereference_check() usage -kernel/pid.c:419 invoked rcu_dereference_check() without protection!

[Oleg Nesterov]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/