netdev - RE: [PATCH net 2/2] be2net: Need a delay before processing CQE after 2nd mbox register write

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 14 Jan 2014 06:33:56 +0000
From:	Somnath Kotur <Somnath.Kotur@...lex.Com>
To:	David Laight <David.Laight@...LAB.COM>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	Kalesh Purayil <Kalesh.Purayil@...lex.Com>
Subject: RE: [PATCH net 2/2] be2net: Need a delay before processing CQE
 after 2nd mbox register write



> -----Original Message-----
> From: David Laight [mailto:David.Laight@...LAB.COM]
> Sent: Wednesday, January 08, 2014 3:02 PM
> To: Somnath Kotur; netdev@...r.kernel.org
> Cc: davem@...emloft.net; Kalesh Purayil
> Subject: RE: [PATCH net 2/2] be2net: Need a delay before processing CQE
> after 2nd mbox register write
> 
> > From: Somnath Kotur
> > Due to Host platform synchronization issues between the mbox RDY bit
> > polled status and the completion of the DMA for the CQE, it is
> > preferable that the Host always wait for the RDY bit to transition to
> > 1 after the 2nd mbox register write and always follow that with a
> > short wait for the valid bit in the CQE, before processing the CQE.
> 
> While I don't doubt that a delay(1) fixes the problem it doesn't seem an ideal
> solution.
> I've not looked at what the code is doing (or how often it does it) but either
> delay(1) is far, far longer than is necessary or it might not be long enough and
> some kind of retry loop is required.
> 
> It might even be that the driver is just missing a memory barrier.

David,
	The memory barrier by itself did not work, however like you said polling on the valid 
Bit to be set seems like the right solution as the time for the mbox-completion DMA to finish/reach the host
may not be deterministic.

Thanks
Som
--
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