From: Oleg Nesterov <oleg@redhat.com>
To: Greg Thelen <gthelen@google.com>
Cc: Jens Axboe <axboe@kernel.dk>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: INFO: suspicious rcu_dereference_check() usage - kernel/pid.c:419 invoked rcu_dereference_check() without protection!
Date: Thu, 11 Nov 2010 23:00:49 +0100 [thread overview]
Message-ID: <20101111220048.GA19979@redhat.com> (raw)
In-Reply-To: <xr93sjz73ar6.fsf@ninji.mtv.corp.google.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Greg Thelen <gthelen@google.com>
Cc: Jens Axboe <axboe@kernel.dk>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: INFO: suspicious rcu_dereference_check() usage - kernel/pid.c:419 invoked rcu_dereference_check() without protection!
Date: Thu, 11 Nov 2010 23:00:49 +0100 [thread overview]
Message-ID: <20101111220048.GA19979@redhat.com> (raw)
In-Reply-To: <xr93sjz73ar6.fsf@ninji.mtv.corp.google.com>
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-11-11 22:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-12 7:08 INFO: suspicious rcu_dereference_check() usage - kernel/pid.c:419 invoked rcu_dereference_check() without protection! Greg Thelen
2010-10-12 7:08 ` Greg Thelen
2010-11-07 18:20 ` Paul E. McKenney
2010-11-07 18:20 ` Paul E. McKenney
2010-11-08 15:15 ` Oleg Nesterov
2010-11-08 15:15 ` Oleg Nesterov
2010-11-09 20:29 ` Paul E. McKenney
2010-11-09 20:29 ` Paul E. McKenney
2010-11-10 15:55 ` Oleg Nesterov
2010-11-10 15:55 ` Oleg Nesterov
2010-11-10 16:02 ` Oleg Nesterov
2010-11-10 16:02 ` Oleg Nesterov
2010-11-11 11:19 ` Jens Axboe
2010-11-11 11:19 ` Jens Axboe
2010-11-11 12:30 ` Oleg Nesterov
2010-11-11 12:30 ` Oleg Nesterov
2010-11-11 12:39 ` Jens Axboe
2010-11-11 12:39 ` Jens Axboe
2010-11-11 19:45 ` Greg Thelen
2010-11-11 19:45 ` Greg Thelen
2010-11-11 22:00 ` Oleg Nesterov [this message]
2010-11-11 22:00 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101111220048.GA19979@redhat.com \
--to=oleg@redhat.com \
--cc=axboe@kernel.dk \
--cc=gthelen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.