linux-kernel - Re: "Fix ATAPI transfer lengths" causes CD writing regression

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: <20071030190153.373c9347@the-village.bc.nu>
Date:	Tue, 30 Oct 2007 19:01:53 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Daniel Drake <dsd@...too.org>
Cc:	linux list <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org
Subject: Re: "Fix ATAPI transfer lengths" causes CD writing regression

> The nutty app I was using for burning is Brasero, a GNOME app which does 
> some SG_IO directly with the drive. (I guess it has some bad error 
> handling and doesn't realise when some I/O path has failed)

I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
"Umm wtf is this data left over for ?", with the new code the drive is
likely to change state as it knows the transfer size and that will
*correctly* cause an HSM error and what follows.

Now the question is who gets the length wrong - Brasero or the ata
translation code in libata

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