Re: [PATCH 1/10] Add generic helpers for arch IPI function calls

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Jens Axboe <jens.axboe@...>
Cc: <linux-kernel@...>, <peterz@...>, <npiggin@...>, <linux-arch@...>, <jeremy@...>, <mingo@...>
Date: Tuesday, April 29, 2008 - 9:59 am

On Tue, Apr 29, 2008 at 09:26:21AM +0200, Jens Axboe wrote:

Looks much better, but there still appears to be a potential deadlock
with a CPU spinning waiting (indirectly) for a grace period to complete.
Such spinning can prevent the grace period from ever completing.

See "!!!".

							Thanx, Paul


!!! What if this CPU recently did a smp_call_function_mask() in no-wait mode,
and this CPU's fallback element is still waiting for a grace period
to elapse?  Wouldn't we end up with a deadlock, with this CPU spinning
preventing the grace period from completing, thus preventing the element
from ever being freed?


Good, now there is no need to worry about readers seeing a recycling
event on the fallback element.  I just need to go check to see what
readers do if there is no memory available and the fallback element
is in use...


Much improved over the earlier list_for_each_entry()!!!


Here is is OK not to wait for a grace period -- this CPU owns the element,
so no one ease should be accessing it.


Ah -- per-CPU fallback element, and we are presumably not permitted
to block during the course of the call.  But then someone might be
using it after we exit this function!!!   More on this elsewhere...

Hmmm...  What about the no-wait case?

Ah, not a problem, because we always use the "d" element that is allocated
on our stack.  But aren't we then passing a reference to an on-stack
variable out of scope?  Don't we need to allocate "d" at the top level
of the function?  Isn't gcc within its rights to get rid of this local
(perhaps re-using it for a compiler temporary or some such) as soon as
its scope ends?


If we are using the on-stack variable, generic_exec_single() is
guaranteed to wait until all other CPUs are done with it.


!!! We are passing "d" out of its scope -- need to move the declaration
to the top level.


And there are no references to "d" past here.  Preemption appears to be
disabled by all callers.  So good.

Still might have the fallback element waiting for a grace period
past this point, which would interfere with a subsequent call to this
function!!!

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 1/10] Add generic helpers for arch IPI function c..., Jeremy Fitzhardinge, (Wed Apr 30, 6:56 pm)
Re: [PATCH 1/10] Add generic helpers for arch IPI function c..., Paul E. McKenney, (Tue Apr 29, 9:59 am)
Re: [PATCH 1/10] Add generic helpers for arch IPI function c..., Paul E. McKenney, (Wed Apr 30, 10:44 pm)
Re: [PATCH 2/10] x86: convert to generic helpers for IPI fun..., Jeremy Fitzhardinge, (Wed Apr 30, 5:39 pm)
Re: [PATCH 2/10] x86: convert to generic helpers for IPI fun..., Jeremy Fitzhardinge, (Tue Apr 29, 4:35 pm)
Re: [PATCH 2/10] x86: convert to generic helpers for IPI fun..., Jeremy Fitzhardinge, (Wed Apr 30, 10:51 am)