[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210616091035.qcb5nhwfvtyhrwqe@vireshk-i7>
Date: Wed, 16 Jun 2021 14:40:35 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Rafael Wysocki <rjw@...ysocki.net>,
Ionela Voinescu <ionela.voinescu@....com>,
Sudeep Holla <sudeep.holla@....com>,
"Rafael J. Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
Qian Cai <quic_qiancai@...cinc.com>,
"Paul E . McKenney" <paulmck@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 2/3] arch_topology: Avoid use-after-free for
scale_freq_data
On 16-06-21, 10:31, Greg Kroah-Hartman wrote:
> On Wed, Jun 16, 2021 at 01:48:59PM +0530, Viresh Kumar wrote:
> > On 16-06-21, 09:57, Greg Kroah-Hartman wrote:
> > > On Wed, Jun 16, 2021 at 12:18:08PM +0530, Viresh Kumar wrote:
> > > > Currently topology_scale_freq_tick() may end up using a pointer to
> > > > struct scale_freq_data, which was previously cleared by
> > > > topology_clear_scale_freq_source(), as there is no protection in place
> > > > here. The users of topology_clear_scale_freq_source() though needs a
> > > > guarantee that the previous scale_freq_data isn't used anymore.
> > > >
> > > > Since topology_scale_freq_tick() is called from scheduler tick, we don't
> > > > want to add locking in there. Use the RCU update mechanism instead
> > > > (which is already used by the scheduler's utilization update path) to
> > > > guarantee race free updates here.
> > > >
> > > > Cc: Paul E. McKenney <paulmck@...nel.org>
> > > > Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> > >
> > > So this is a bugfix for problems in the current codebase? What commit
> > > does this fix? Should it go to the stable kernels?
> >
> > There is only one user of topology_clear_scale_freq_source()
> > (cppc-cpufreq driver, which is already reverted in pm/linux-next). So
> > in the upcoming 5.13 kernel release, there will be no one using this
> > API and so no one will break.
> >
> > And so I skipped the fixes tag, I can add it though.
>
> It would be nice to have to answer this type of question, otherwise you
> will have automated scripts trying to backport this to kernels where it
> does not belong :)
Sure, I will add these to the next version.
--
viresh
Powered by blists - more mailing lists