linux-kernel - Re: Busy-waiting with interrupts disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 13 Dec 2011 00:42:36 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Steven Rostedt <rostedt@...dmis.org>
cc:	Alan Stern <stern@...land.harvard.edu>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Busy-waiting with interrupts disabled

On Mon, 12 Dec 2011, Steven Rostedt wrote:

> On Mon, 2011-12-12 at 17:12 -0500, Alan Stern wrote:
> > How long is it okay to busy-wait with interrupts disabled?  Are there 
> > any clear-cut guidelines?

A few usecs nothing more.

> > My feeling is that for ordinary desktop use, 1-2 ms should be about the
> > limit, but other people may feel differently.  (There's one spot in
> > ehci-hcd where the delay can last up to 250 ms, which does seem rather
> 
> "250 ms", holy freaking OUCH! Batman!
> 
> 
> > excessive.  Fortunately it never takes that long unless the hardware is
> > broken.)
> > 
> > No doubt the RT people would say the upper bound should be on the order
> > of a few microseconds or less.  I'd be happy to change ehci-hcd, which
> > has several delays in the 1-2 ms range -- but they tend to be nested
> > inside routines that are called within the scope of spinlock_irq, which
> > means a fair amount of rewriting would be needed.
> > 
> > Any thoughts or recommendations?
> 
> Note that in -rt, spinlocks are really mutexes (unless they are
> raw_spinlocks, which you shouldn't do). Thus, if your spin is with
> spinlock_irq, it wont affect -rt, as it will not have interrupts
> disabled.
> 
> But I could imagine that such a long latency could manifest itself into
> something nasty (lots of interrupts queued up and such) that normal
> desktop users might see a hiccup or two.

Audio folks would be particularly happy about such crap. Aside of that
you can even starve timekeeping that way depending on the wraparound
time of your clocksource and the interrupt/timekeeping affinities at
that point.

Simply don't do that.

Thanks,

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