Re: [PATCH -rt] catch put_task_struct RCU handling up to mainline

From: Esben Nielsen
Date: Mon Jul 10 2006 - 15:07:35 EST


On Mon, 10 Jul 2006, Paul E. McKenney wrote:

On Mon, Jul 10, 2006 at 07:10:49PM +0100, Esben Nielsen wrote:
On Mon, 10 Jul 2006, Paul E. McKenney wrote:
On Sat, Jul 08, 2006 at 02:59:37PM +0100, Esben Nielsen wrote:

[ . . . ]

The work should be defered to a low priority task. Using rcu is
probably overkill because it also introduces other delays. A tasklet
or a dedicated task would be better.

Agreed -- if there is in fact a legitimate non-error code path, then
a patch that used some deferral mechanism would be good. But RCU is
overkill, and misleading overkill at that!


I think this is a legitimate situation. lock 1 is owned by B which is
blocked on lock 2 which is owned by C

CPU1: CPU2
RT task A locks lock 1 C runs something
A boosts B to RT
A does get_task_struct B
A enables interrupts C unlocks lock 2
An very long interrupt is running B unlocks lock 2
B unlocks lock 1
B is deboosted
B exits
A gets CPU1 again
A does put_task_struct B

I don't know if the timing is realistic, but theoretically it is possible.
It might also be possible the B exits on another CPU even without the long
interrupt handler. If A has cpu affinity to CPU1 it is enough if a higher
priority task preempts it on CPU1.

For this to happen, either A has to be at a lower priority than the irq
tasks or the interrupt has to be a hard irq (e.g., scheduling clock
interrupt). In the first case, the added cleanup processing seems
inconsequential compared to (say) an interrupt doing network protocol
processing. In the second case, B does not do its put_task_struct()
until after the hard irq returns (because the put_task_struct() is invoked
from a call_rcu() callback), which makes the above scenario unlikely,
though perhaps not impossible.

If the second scenario is in fact possible, would you be willing to
supply the appropriate deferral code? I believe we both agree that RCU
is not really the right deferral mechanism in this situation.


Let your patch go through. I'll stop complaining :-)
Is there anywhere where we can make a list of known issues like this?
I can't promise I will get time to fix this one :-(

Esben


Thanx, Paul

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/