[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjT6LG6sDaZtfeT80B9RaMP-y7RNRM4F5CX2v2Z=o8e=A@mail.gmail.com>
Date: Sun, 15 Sep 2019 10:07:24 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Peter Zijlstra <peterz@...radead.org>,
Oleg Nesterov <oleg@...hat.com>,
Russell King - ARM Linux admin <linux@...linux.org.uk>,
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 v2 3/4] task: With a grace period after
finish_task_switch, remove unnecessary code
On Sun, Sep 15, 2019 at 7:32 AM Paul E. McKenney <paulmck@...nel.org> wrote:
>
> First, what am I looking for?
>
> I am looking for something that prevents the following:
>
> o Task A acquires a reference to Task B's task_struct while
> protected only by RCU, and is just about to increment ->rcu_users
> when it is delayed. Maybe its vCPU is preempted or something.
Where exactly do you see "increment ->rcu_users"
There are _no_ users that can increment rcu_users. The thing is
initialized to '2' when the process is created, and nobody ever
increments it. EVER.
It's only ever decremented, and when it hits zero we know that both
users are gone, and we start the rcu-delayed free.
Linus
Powered by blists - more mailing lists