[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230307171913.GA4387@maniforge>
Date: Tue, 7 Mar 2023 11:19:13 -0600
From: David Vernet <void@...ifault.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, rostedt@...dmis.org,
bsegall@...gle.com, mgorman@...e.de, bristot@...hat.com,
vschneid@...hat.com, kernel-team@...a.com,
torvalds@...ux-foundation.org, ebiederm@...ssion.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tasks: Extract rcu_users out of union
On Mon, Feb 27, 2023 at 10:11:42AM -0600, David Vernet wrote:
> On Fri, Feb 17, 2023 at 11:25:21AM +0100, Oleg Nesterov wrote:
> > On 02/16, David Vernet wrote:
> > >
> > > On Thu, Feb 16, 2023 at 09:04:59AM +0100, Oleg Nesterov wrote:
> > > >
> > > > > a task that's successfully looked
> > > > > up in e.g. the pid_list with find_task_by_pid_ns(), can always have a
> > > > > 'usage' reference acquired on them, as it's guaranteed to be >
> > > > > 0 until after the next gp.
> > > >
> > > > Yes. So it seems you need another key-to-task_struct map with rcu-safe
> > > > lookup/get and thus the add() method needs inc_not_zero(task->rcu_users) ?
> > >
> > > Yes, exactly.
> >
> > OK, in this case I agree, inc_not_zero(rcu_users) makes sense and thus we need
> > this patch.
>
> Thanks again for taking a look.
>
> >
> > Just I was confused by the previous part of the changelog due to my bad English.
>
> No worries at all -- the commit summary definitely could have been more
> clear.
>
> Does anyone else have any thoughts? Is there anything else we need to do
> for this patch to land?
Sending a friendly ping on this now that the merge window has closed and
things have settled down a bit.
Thanks,
David
Powered by blists - more mailing lists