[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200714200616.GA20137@pc636>
Date: Tue, 14 Jul 2020 22:06:16 +0200
From: Uladzislau Rezki <urezki@...il.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: "Paul E. McKenney" <paulmck@...nel.org>, mingo@...nel.org,
linux-kernel@...r.kernel.org, rcu@...r.kernel.org, arnd@...db.de,
elver@...gle.com, ethp@...com, frederic@...nel.org,
jbi.octave@...il.com, joel@...lfernandes.org,
lihaoliang@...gle.com, madhuparnabhowmik10@...il.com,
mchehab+huawei@...nel.org, peter.enderborg@...y.com,
rdunlap@...radead.org, richard.weiyang@...ux.alibaba.com,
urezki@...il.com, zou_wei@...wei.com, tglx@...utronix.de
Subject: Re: [GIT PULL tip/core/rcu] RCU commits for v5.9
On Tue, Jul 14, 2020 at 09:02:53PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-07-14 11:27:32 [-0700], Paul E. McKenney wrote:
> > I believe that Ulad and Joel are working on an update.
>
> I expressed multiple times that I am unhappy with the raw_spinlock_t
> which both want to keep. It is important to be future proof but at the
> same time I am not sure if they know how many in-hardirq kmalloc() or
> kfree() invocation we have as of today in PREEMPT_RT.
>
It is not about counting how many times kfree_rcu() gets called from
the hard IRQ context for RT kernel. In fact it is about breaking of
such possibility if a conversion to spinlock_t is done. Is not it?
As a result the revert would change a behavior of the API function,
that is used to accept such usage. That is a motivation.
--
Vlad Rezki
Powered by blists - more mailing lists