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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2b2a8734-62c5-4983-a353-a79f0ed96466@CMEXHTCAS1.ad.emulex.com>
Date:	Tue, 14 Jan 2014 06:30:38 +0000
From:	Somnath Kotur <Somnath.Kotur@...lex.Com>
To:	David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	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 Miller [mailto:davem@...emloft.net]
> Sent: Saturday, January 11, 2014 1:41 AM
> To: Somnath Kotur
> Cc: netdev@...r.kernel.org; Kalesh Purayil
> Subject: Re: [PATCH net 2/2] be2net: Need a delay before processing CQE
> after 2nd mbox register write
> 
> From: Somnath Kotur <somnath.kotur@...lex.com>
> Date: Wed, 8 Jan 2014 14:52:02 +0530
> 
> > 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.
> >
> > Signed-off-by: Kalesh AP <kalesh.purayil@...lex.com>
> > Signed-off-by: Somnath Kotur <somnath.kotur@...lex.com>
> > ---
> >  drivers/net/ethernet/emulex/benet/be_cmds.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
> > b/drivers/net/ethernet/emulex/benet/be_cmds.c
> > index 94c35c8..78560f2 100644
> > --- a/drivers/net/ethernet/emulex/benet/be_cmds.c
> > +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
> > @@ -502,6 +502,9 @@ static int be_mbox_notify_wait(struct be_adapter
> *adapter)
> >  	if (status != 0)
> >  		return status;
> >
> > +	/* Need a delay before processing CQE after 2nd mbox register write
> */
> > +	udelay(1);
> > +
> 
> Like others, I find his delay being used to fix the stated problem as
> questionable, at best.
> 
> Either find a more appropriate way to fix this problem, or elaborate (in the
> commit message), why this is really a suitable way to handle this.
Dave,
   	It indeed looks like an *arbitrary* delay between the mbox RDY read and CQ-entry read was not the right solution.
The correct fix would be for the driver to poll on the CQ-entry valid bit to become 1, as the time taken for the mbox-compl DMA
to finish may not be deterministic.
--
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