On Mon, Jul 10, 2006 at 09:09:35PM +0100, Esben Nielsen wrote:
> 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 :-(
;-)
One possibility would be a file in the Documentation directory.
Another would be something on the web, but a file in the Documentation
directory would have the advantage of being synched with the -rt version.
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
