netdev - RE: [PATCH net-next 1/4] bnx2x: refactor nvram read procedure

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: <504C9EFCA2D0054393414C9CB605C37F20C03E5D@SJEXCHMB06.corp.ad.broadcom.com>
Date:	Mon, 15 Apr 2013 07:14:26 +0000
From:	"Dmitry Kravkov" <dmitry@...adcom.com>
To:	"Francois Romieu" <romieu@...zoreil.com>
cc:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Eilon Greenstein" <eilong@...adcom.com>
Subject: RE: [PATCH net-next 1/4] bnx2x: refactor nvram read procedure

> -----Original Message-----
> From: Francois Romieu [mailto:romieu@...zoreil.com]
> Sent: Saturday, April 13, 2013 2:09 PM
> To: Dmitry Kravkov
> Cc: davem@...emloft.net; netdev@...r.kernel.org; Eilon Greenstein
> Subject: Re: [PATCH net-next 1/4] bnx2x: refactor nvram read procedure
> 
> Dmitry Kravkov <dmitry@...adcom.com> :
> > introduce a parameter to allow nvram read to return
> > data in BE or cpu order.
> [...]
> > @@ -1295,10 +1296,14 @@ static int bnx2x_nvram_read_dword(struct bnx2x *bp, u32 offset, __be32 *ret_val,
> >  		if (val & MCPR_NVM_COMMAND_DONE) {
> >  			val = REG_RD(bp, MCP_REG_MCPR_NVM_READ);
> >  			/* we read nvram data in cpu order
> > -			 * but ethtool sees it as an array of bytes
> > +			 * but ethtool uses it as an array of bytes
> >  			 * converting to big-endian will do the work
> > +			 * if requested.
> 
> You memcpy a u32 to an array of bytes instead of copying it byte after
> byte with proper shift operators and now you are paving the way for more
> endianess headaches. I'd rather avoid the memcpy when readying data for
> ethtool in the first place.
In case of _be data I don't see any issue with copying _be32 it into byte array.
When internal driver function (not exposed to external usage) requests data in CPU order - it meant to bring u32 data ( or array of u32) and memcpy dword by dword also should be harmless.
 
> Nit: the true/false method parameter style in middle layers is mildly
> readable when compared to usual _{be/le} kernel style (you should be
> able to avoid both almost completely anyway :o) ).
Boolean parameter used to share pre- and post-configuring nvram for read operation.
_be/le is less suitable here, since the usage is BE or cpu order.
I was thinking about separating stream read and u32 read to separate callbacks, but this will add another level and this is less preferable than true/false param.
 
> --
> Ueimor


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