Re: [PATCH 1/3] rcu: Use static initializer for krc.lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 16, 2020 at 10:05:57PM +0200, Uladzislau Rezki wrote:
> On Thu, Apr 16, 2020 at 12:53:27PM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 16, 2020 at 03:26:23PM -0400, Steven Rostedt wrote:
> > > On Thu, 16 Apr 2020 14:59:34 -0400
> > > Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote:
> > > 
> > > > But, then will it be safe for kfree_rcu() callers from hard IRQ context to
> > > > call this in PREEMPT_RT? That could would just break then as you cannot sleep
> > > > in hard IRQ context even on PREEMPT_RT.
> > > 
> > > But where in PREEMPT_RT would it be called in hard IRQ context?
> > 
> > I believe that call_rcu() is invoked with raw spinlocks held, so we should
> > allow kfree_rcu() to be invoked from similar contexts.  It obviously
> > cannot allocate memory in such contexts, so perhaps the rule is that
> > single-argument kfree_rcu() cannot be invoked within hard IRQ contexts
> > or with raw spinlocks held.  In those contexts, you would instead need
> > to invoke two-argument kfree_rcu(), which never needs to allocate memory.
> > 
> > Seem reasonable?
> > 
> Paul, just to make it more clear, even invoking two arguments fkree_rcu()
> currently does an allocation. We maintain an array that contains pointers
> for "bulk logic". 

True, but that is an optimization rather than an absolute necessity.
In addition, most two-argument kfree_rcu() callers will take another slot
from the array that has already been allocated.  So one alternative is
to do the allocation only if both interrupts and preemption are enabled.
As long as most kfree_rcu() invocations can allocate, you get good
performance and things work nicely in -rt.

Another alternative is to check to see what currently invokes kfree_rcu()
and work out what to do about any that are invoked from an environment
in which -rt does not allow memory allocation.  And deal with future
additions of kfree_rcu() to such environments.

Given that most people don't test -rt, the second alternative has
the potential of handing Sebastian an endless stream of bugs that are
kfree_rcu() usage bugs only in -rt.  But maybe he is OK with that?
(I wouldn't be, but I will let him speak for himself.)

							Thanx, Paul



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux