netdev - Re: [PATCH] Fix SJA1000 command register writes on SMP systems

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] [day] [month] [year] [list]

Message-ID: <4BF1A165.1040704@grandegger.com>
Date:	Mon, 17 May 2010 22:04:53 +0200
From:	Wolfgang Grandegger <wg@...ndegger.com>
To:	Oliver Hartkopp <socketcan@...tkopp.net>
CC:	SocketCAN Core Mailing List <socketcan-core@...ts.berlios.de>,
	Linux Netdev List <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>, stable@...nel.org
Subject: Re: [PATCH] Fix SJA1000 command register writes on SMP systems

On 05/17/2010 09:47 PM, Oliver Hartkopp wrote:
> On 17.05.2010 16:29, Wolfgang Grandegger wrote:
>> Hi Oliver,
>>
>> On 05/17/2010 01:06 PM, Oliver Hartkopp wrote:
>>> The SJA1000 command register is concurrently written in the rx-path to free
>>> the receive buffer _and_ in the tx-path to start the transmission.
>>> On SMP systems this leads to a write stall in the tx-path, which can be
>>> solved by adding some locking for the command register in the SMP case.
>>
>> We should explain why a write stall can happen. Here is the relavant
>> part from the SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR):
>>
>> "Between two commands at least one internal clock cycle is needed in
>> order to proceed. The internal clock is half of the external oscillator
>> frequency."
> 
> The delay directly after the register access can only be guaranteed when there
> is some locking around the command register write access.

Of course.

> In the end it boils down to a SMP issue again as this is (from all known
> environments) the only case, where the problem appears in reality.
> This was also what i've taken from the discussion on the SocketCAN ML.

I know.

> I don't stick on the patch description. Would you like to produce a different
> one? My Acked-by for the code remains sure :-)

I just suggested to mention the hardware requirements in the patch
description so people can understand why we need it. Feel free to add
what I wrote above.

Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html