linux-kernel - Re: [regression] CD-DA delay needed after insertion (http://bugzilla.kernel.org/show

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 for Android: free password hash cracker in your pocket

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

Message-ID: <806dafc20809301110h2817e9e8g42ba031220763e9d@mail.gmail.com>
Date:	Tue, 30 Sep 2008 14:10:56 -0400
From:	"Monty Montgomery" <monty@...h.org>
To:	"Geert Uytterhoeven" <Geert.Uytterhoeven@...ycom.com>
Cc:	"James Bottomley" <James.Bottomley@...senpartnership.com>,
	linux-scsi@...r.kernel.org,
	"Linux Kernel Development" <linux-kernel@...r.kernel.org>
Subject: Re: [regression] CD-DA delay needed after insertion (http://bugzilla.kernel.org/show_bug.cgi?id=10974)

> It happens on anything after 2.6.24 (cfr.
> http://bugzilla.kernel.org/show_bug.cgi?id=10974).
> E.g. mainline 2.6.27-rc8.

Ah.

Geert, I'm sorry this has come up and thanks for bringing it to my attention.

I'm relying on 15 year old behavior.  It has always been the case that
the packet pass-through interfaces treat O_NONBLOCK as 'don't wait for
commands' (ie, classic async communication or, in the case of SGIO,
don't block on mandatory locks) not 'change how you mediate the
communication'.  The whole point of the passthrough interface is
'please don't fuck with the packet stream.  My userspace application
knows better than the kernel in this case'.  If the kernel has
suddenly changed that, it is responsible for the loss of
functionality, not cdparanoia.

It is also the case that the kernel randomly interspersing its own
packets, commands and setup would be yanking setup state out from
under cdparanoia.  What am I supposed to do if I set density and
completely change the data mode of a cdrom drive (persistent across
disc changes), or change the block descriptor caching extents, only to
have the kernel decide to change them back without warning? If you
eject media with one of these new kernels, do I still get any
meaningful sense state, or is the sense key and all subsequent
commands merely intercepted and refused?  What happens on a timeout?
A media error?  A bus reset?  Does any 'CHECK CONDITION' status
completely yank the rug out from under the passthrough?

The kernel must not interfere with the pass-through or cdparanoia is
castrated. Or... I'm back to the era of enacting workarounds based on
kernel dot-version.  Regardless, this is a change to a longstanding
behavior.  Is it on purpose, unintentional or 'intentional but without
realizing it was actually important'?  Would be interesting to know.

> In this case, sg means scatter/gather, and it's a purely internal
> interface.  It does not start/stop the drive, nor the scsi interface.

Ah, I confused it with a much older utility that would up/down an SG
device entirely.

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