linux-kernel - Re: floppy driver assumes INITIAL

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1006031515030.8175@i5.linux-foundation.org>
Date:	Thu, 3 Jun 2010 15:33:23 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stephen Hemminger <shemminger@...tta.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: floppy driver assumes INITIAL_JIFFIES == 0

On Thu, 3 Jun 2010, Linus Torvalds wrote:
>
> > So still a race that shows up with KVM (fast floppy?) and manifests
> > as floppy_ready or reset_interrupt OOPS.
> 
> Yes, it's quite possible that the Linux floppy driver is simply broken by 
> any floppy device that basically responds immediately to a command with an 
> interrupt. And considering how few people use floppies, I do expect that 
> driver to get _worse_ rather than better in the future.

Having looked at that driver some more, I can inf act pretty much 
guarantee it. The locking is rather baroque. It has a "floppy_lock", but 
that only protects certain small parts. In particular, it looks like the 
irq handler and the timers do _not_ take it, and that's where most of the 
real work is done.

And in fact, that does look broken. The interrupt handler really does a 
"schedule_work()" to schedule the actual handler outside of irq context, 
and I don't see any serialization between the timers that file and the 
handler running.

That driver used to be this state machine that ran entirely from interrupt 
context, where one interrupt handler would set the state for the next one 
(that's what the "do_floppy" thing is for). But then it became bottom 
halves, and now it's using schedule_work() instead - and at the same time, 
the _timers_ haven't really changed. Those run in timer context, and can 
thus interrupt the work thing.

It always was a disgusting driver. Now it's just even more so. And yes, 
I'm sure it's full of races that are largely hidden by the fact that real 
floppy hardware is so slow that you can never hit them.

Looking too much at that driver will cause PTSD.  I have to look away.

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