Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[David Brownell]

> > > Interrupts are disabled during usb_hcd_giveback_urb because that's how 
> > > it was done originally and nobody has made an effort to remove this 
> > > assumption from the USB device drivers.

Also Host Controller Drivers (HCDs).  You do sort of have to
remember who's calling this routine.  It's normally an HCD in
the middle of its IRQ processing, tending hardware.

I'd actually say the reason that has IRQs disabled is because
of the amount of work that would have been involved in changing
that assumption ...  I actually did look at what it'd take to
let IRQs be enabled during USB completion callbacks a while back,
and concluded it'd be a lot of work for hardly any return.


> > > 			There's no real reason for it 
> > > other than historical inertia.  It's not done for serialization -- 
> > > there's no need for serialization since an URB can't be resubmitted 
> > > before the previous callback occurs (unless a driver is badly broken).  
> > > The "detached" method is used simply to avoid an extra pair of 
> > > enable/disable instructions.
> > 
> > so we can remove it altogether, via the patch below?

Sounds dangerous to me.


> > 					(If there's any 
> > unsafe driver, it should already be unsafe on SMP, and with the 
> > proliferation of HT and dual-core CPUs, SMP will be the norm within a 
> > year or so - so the sooner we trigger any breakages, the better i 
> > guess.)
> > 
> > i'll give it a whirl in the -RT tree.
>
> In general yes, the patch should be okay.  But there are a few things to
> check for.  Perhaps most of the USB drivers don't care whether interrupts
> are enabled or not in their completion routines.

And in general, all drivers have been _allowed_ to know that IRQs are
disabled in completion handlers ever since the earliest 2.2 kernels
that included USB support.

Changes like that -- interactions between at least three obvious
subsystems (usbcore, usb drivers, hcds) and lots of unobvious ones
(whoever the drivers talk to) -- sound rather error prone to me.
Worth taking very cautiously, with lots of regression testing of
stress loads on some of the funkier hardware.


Not that I'm deeply opposed to such changes, you understand, but
there seem to be three choices here:

  1 ALWAYS complete() with IRQs disabled

  2 NEVER complete() with them disabled

  3 SOMETIMEs complete() with them disabled.

Right now we're with #1 which is simple, consistent and guaranteed.

We couldn't switch to #2 with patches that simple.  They'd in fact
be rather involved, because there is logic like "If the endpoint's
queue is empty when the completion handler returns, then deschedule
that queueue" inside IRQ handlers.  Basic things, like correctness,
for periodic scheduling depend on such logic.

And I don't see much point to #3.  It's got all the DIS-advantages
of #1 and #2 and the advantages of neither ...

- Dave

-
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/