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: <4729209A.50809@gmail.com>
Date:	Thu, 01 Nov 2007 09:40:58 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	Jens Axboe <jens.axboe@...cle.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Daniel Drake <dsd@...too.org>,
	linux list <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org
Subject: Re: "Fix ATAPI transfer lengths" causes CD writing regression

Hello, Jeff.

Jeff Garzik wrote:
> That's easy for the PIO case.  But CD writing is normally DMA, which
> means you will get a DMA engine exception if the device wants to give
> you more data than the scatter/gather entries permit.

For sense data and mode pages, the standard-sanctioned way to know the
transfer size is to issue command with short buffer size just enough to
contain the fixed size header part, determine actual transfer size from
it and issue the command again with the correct buffer size.  This
doesn't happen for READ/WRITE commands.  Transfer sizes are
pre-determined for those commands and WRITE's to optical devices often
can't be retried w/o side effect.

I've just went through the ATA spec and this basically means we can't
use DMA for these variable-transfer-length commands.  Some DMA engines
have "throw away what's left over bit" in its command structure or SG
entry but not all do and none of drivers we currently has such feature
enabled.

Hmmm.... reading ide-cd.c::cdrom_pc_intr().  OIC, ide-cd is dealing with
this problem by draining PIO after BMDMA engine is done.  This is
possible for BMDMA engines as they simply step out when the SG entries
are exhausted; then, the interrupt handler kicks in and drains the
left-over using PIO.  This just isn't possible with more modern DMA engines.

This really makes me think libata should do these commands via PIO
unless we're gonna enable leftover draining for each DMA engine
implementation or blacklist the ones which can't drain individually.
Then again, nobody really knows how well those features would work as
probably none has actually used them.

Thanks.

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