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]
Message-ID: <4d812a88-90d8-4376-a0bb-7faa6d0491d4@CMEXHTCAS1.ad.emulex.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ