linux-kernel - Re: [patch 3/4] sdio: extend sdio_readsb() and friends to handle any length of buffer

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]

Date:	Wed, 08 Aug 2007 14:22:20 +0100
From:	David Vrabel <david.vrabel@....com>
To:	Pierre Ossman <drzeus-list@...eus.cx>
CC:	linux-kernel@...r.kernel.org, David Vrabel <david.vrabel@....com>
Subject: Re: [patch 3/4] sdio: extend sdio_readsb() and friends to handle
 any length of buffer

Pierre Ossman wrote:
> On Wed, 08 Aug 2007 11:19:33 +0100
> David Vrabel <david.vrabel@....com> wrote:
> 
>> We need to know the block size in use /before/ the start of the
>> transfer as we would like drivers to be able to perform transfers
>> with single commands as this can result in significantly better
>> performance[1].  The drivers for our (CSR's) WiFi chips should do
>> this.  This isn't some (as you suggested in a previous post) 'rare'
>> requirement.
>>
> 
> Well, there are more ways that can be achieved.
> 
> First, the driver could lock down the block size using
> sdio_force_block_size(). Then it knows what it gets.
> 
> Second, we could try to make it possible for the driver to indicate
> "feel free to pad this transfer". Then we could also remove the need
> for drivers to mess with buffers and keep such stuff in the core. We
> could even magically remove a memcpy() by setting up two sg entries,
> one for the data and one for the padding.

Setting the block size in io_rw_ext_helper() has several drawbacks, namely:

1. Reduces the flexibility of drivers to manage what commands are performed.
2. A performance penalty on the first transfer.
3. Greater code complexity.
4. Non-intuitive location for card initialization code.

Sure we could just through hoops and add (much) extra complexity to the
core, to improve item 1 but 2, 3 and 4 are insoluble. Given that setting
block size before the first command has /zero/ benefits[1], why bother?

Your insistence on this stupid idea baffles me, particularly in the
light of your other useful comments.

I would also like to advise that until a larger number of function
drivers become available that the core is kept as simple and as flexible
as possible.  Without knowing how different cards operate it is
difficult to know what's common behaviour and what's card specific.

My latest (and hopefully final) patch set follows.

David

[1] dynamic block sizing was (potentially) a useful benefit but I have
comprehensibly shown it's not beneficial.  The idea that is somehow
necessary to permit the core to change it's block size selection
algorithm is bogus.
-- 
David Vrabel, Software Engineer, Drivers group  Tel: +44 (0)1223 692562
CSR plc, Churchill House, Cambridge Business Park, Cowley Road, CB4 0WZ

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