Web lists-archives.com

Re: [linux-usb-devel] RT-friendly IRQ management in USB

Jiri Kosina wrote:
> On Tue, 3 Jul 2007, Steven Rostedt wrote:
>> Unfortunately that would not work in the RT case either. Because in RT, 
>> that spin_lock can schedule, and we are not allowed to schedule with 
>> interrupts disabled.
> So how do you handle in RT all the current code everywhere in the tree, 
> which does precisely this? (i.e. calls spin_lock() with interrupts 
> disabled). 
> Do you convert all such code to something different as a part of the RT 
> work?

Yep!  You can read my OLS RT paper here:


And my slides are here:


The main thing is that a spin_lock is a macro that determines by type 
what type of spin_lock it is.  A few places declare the spin_lock as 
"raw" which that spin lock will stay as the current busy looping lock, 
but all others "magically" become mutexes under PREEMPT_RT.  In all 
other processing modes (CONFIG_PREEMPT and others), all spin_locks are 
the same.

The RT patch does not need to touch any of the USB code to make those 
spin_locks into mutexes, that's done by the headers. Even out of tree 
modules that are compiled against the RT tree will act the same.

The problem that we are facing in this thread is that the RT patch 
doesn't touch local_irq_save and restore. These still turn off 
interrupts, and can be a problem with the RT patch.  We need a tight 
coupling between spin_lock and irq disable. This is done by 
spin_lock_irqsave, so in the RT patch we don't need to disable 
interrupts here.  But calling local_irq_save() followed by spin_lock() 
it will cause bugs in RT.

I'm liking the idea of having a local_irq_restore_from_spinlock(flags) 
which documents that the irqs were disabled by a spin_lock_irqsave.

-- Steve

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
To unsubscribe, use the last form field at: