linux-kernel - Re: [PATCH 7/7] sg_ring: convert core ATA code to sg

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: <47721294.7030401@gmail.com>
Date:	Wed, 26 Dec 2007 17:36:36 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	Jens Axboe <jens.axboe@...cle.com>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [PATCH 7/7] sg_ring: convert core ATA code to sg_ring.

Hello, Rusty Russell.

Rusty Russell wrote:
> ATA relies so heavily on scsi that it needs to be converted at the
> same time.
> 
> ATA adds padding to scatterlists in scsi commands, but because there was
> no good way of appending to those scatterlists, it had to use boutique
> iterators to make sure the padding is included.  With sg_ring, ATA can
> simply append an sg_ring entry with the padding, and normal iterators
> can be used.
> 
> I renamed qc->cursg to qc->cur_sg to catch all the users: they should
> now be referring to 'qc->cur_sg[qc->cursg_i]' wherever they were using
> 'qc->cursg'.
> 
> Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>

There's pending patchset to make libata use chained sg.  Please search
for "[PATCHSET] libata: improve ATAPI data transfer handling, take #3"
on your favorite mailing archive (I'm writing this message offline so
can't give you the url at the moment).  The 11th patch in the patchset
converts libata to use chained sg and and the following ones extend it
to also chain drain sg entries.

I agree that the current chained sg isn't easy to use and it would be
nice to have some abstraction on top of it but sg_ring seems to
implement duplicate feature which is already available through sg
chaining albeit cumbersome to use.

It would be better to build upon sg chaining as we already have it.  I
think it can be made much easier with a bit more safe guards,
generalization and some helpers.

Thanks.

(PS, I haven't followed the sg chaining discussion.  Why is sg chaining
an optional feature?  Performance overhead on low end machines?)

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