linux-kernel - Re: [spi-devel-general] [PATCH] atmel

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:	Fri, 22 Feb 2008 14:52:06 -0500
From:	Ned Forrester <nforrester@...i.edu>
To:	David Brownell <david-b@...bell.net>
Cc:	anemo@....ocn.ne.jp, spi-devel-general@...ts.sourceforge.net,
	marc.pignat@...s.ch, linux-kernel@...r.kernel.org
Subject: Re: [spi-devel-general] [PATCH] atmel_spi: support zero length	 transfer

David Brownell wrote:
>> This would be OK.  It would not be hard to fix pxa2xx_spi, for example,
>> to reject zero-length transfers in DMA mode, as long as it is acceptable
>> to reject the message in mid-message.
> 
> Such "illegal message" rejection is best done early; "fail-fast".
> Mid-message rejection isn't wrong, but it's a rude policy.
> 
> It'd be best to fix pxa2xx_spi to not start zero-length DMAs.

So again, same as my last reply, it would be best to handle a zero
length transfer silently, as if it were non-zero, but just skipping over
any invalid hardware operations due to the zero length.

>> 	If it were necessary to scan a
>> whole message for zero-length transfers and refuse to queue an offending
>> message, then that adds burden to all messages.
> 
> Sanity checking messages as they're submitted is easy; and it's
> also the natural point for setting up DMA mappings (and making
> those cachelines available for better use).

Hmmm.... Obviously I have much to learn about modern computers.  It had
not occurred to me, even after reading "Linux Device Drivers", Corbet,
et.al, that by DMA mapping, one frees the cache for other uses.  It
makes sense.  In my application I pass many large buffers to the master
driver, and I map them in the protocol driver.  I did that without good
reason, but now I see it was the proper choice.

Unfortunately, pxa2xx_spi does any DMA mapping not done by the protocol
driver in pump_transfers, as each transfer is submitted to the hardware.
 There is not currently any message checking done in transfer(), the
only error return from that is if the master driver is shutdown (queue
stopped).  The current scheme is to return the message with non-zero
spi_message.status if it has failed *after* execution has been
attempted.  I don't look forward to making major changes, if we really
want all DMA mapping and error checking to be in transfer(), though I
see no reason why it could not be done.

-- 
Ned Forrester                                       nforrester@...i.edu
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079

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