[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190904142202.GA20391@lenoir>
Date: Wed, 4 Sep 2019 16:22:03 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
Russell King - ARM Linux admin <linux@...linux.org.uk>,
Peter Zijlstra <peterz@...radead.org>,
Chris Metcalf <cmetcalf@...hip.com>,
Christoph Lameter <cl@...ux.com>,
Kirill Tkhai <tkhai@...dex.ru>, Mike Galbraith <efault@....de>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Davidlohr Bueso <dave@...olabs.net>
Subject: Re: [PATCH 2/3] task: RCU protect tasks on the runqueue
On Mon, Sep 02, 2019 at 11:52:01PM -0500, Eric W. Biederman wrote:
>
> In the ordinary case today the rcu grace period of a task comes when a
> task is reaped, well after the task has left the runqueue. This
> change guarantees that the rcu grace period always happens after a
> task has left the runqueue. As this is something that usaually happens
> today I do not expect any code correctness problems with this change.
> At most I anticipate timing challenges.
What do you consider as the reaping point here? If this is the call to
release_task(), it can happen way before the task forever leaves the runqueue.
Let alone the RCU call to delayed_put_task_struct() can happen way before
the target leaves the runqueue, either after autoreap or normal reaping.
Powered by blists - more mailing lists