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]
Date:   Thu, 14 Apr 2022 16:35:46 +0200
From:   Clément Léger <clement.leger@...tlin.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Herve Codina <herve.codina@...tlin.com>,
        Miquèl Raynal <miquel.raynal@...tlin.com>,
        Milan Stevanovic <milan.stevanovic@...com>,
        Jimmy Lalande <jimmy.lalande@...com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-renesas-soc@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 02/12] net: dsa: add Renesas RZ/N1 switch tag
 driver

Le Thu, 14 Apr 2022 17:22:42 +0300,
Vladimir Oltean <olteanv@...il.com> a écrit :

> > +
> > +/* To define the outgoing port and to discover the incoming port a TAG is
> > + * inserted after Src MAC :
> > + *
> > + *       Dest MAC       Src MAC           TAG         Type
> > + * ...| 1 2 3 4 5 6 | 1 2 3 4 5 6 | 1 2 3 4 5 6 7 8 | 1 2 |...
> > + *                                |<--------------->|
> > + *
> > + * See struct a5psw_tag for layout
> > + */
> > +
> > +#define A5PSW_TAG_VALUE			0xE001
> > +#define A5PSW_TAG_LEN			8
> > +#define A5PSW_CTRL_DATA_FORCE_FORWARD	BIT(0)
> > +/* This is both used for xmit tag and rcv tagging */
> > +#define A5PSW_CTRL_DATA_PORT		GENMASK(3, 0)
> > +
> > +struct a5psw_tag {  
> 
> This needs to be packed.
> 
> > +	u16 ctrl_tag;
> > +	u16 ctrl_data;  
> 
> These need to be __be16.
> 
> > +	u32 ctrl_data2;  
> 
> This needs to be __be32.

Acked.

> 
> > +};
> > +
> > +static struct sk_buff *a5psw_tag_xmit(struct sk_buff *skb, struct net_device *dev)
> > +{
> > +	struct a5psw_tag *ptag, tag = {0};
> > +	struct dsa_port *dp = dsa_slave_to_port(dev);  
> 
> Please keep variable declarations sorted in decreasing order of line
> length (applies throughout the patch series, I won't repeat this comment).

Acked, both PCS and DSA driver are ok with that rule. Missed that one
though.
> 
> > +	u32 data2_val;
> > +
> > +	/* The Ethernet switch we are interfaced with needs packets to be at
> > +	 * least 64 bytes (including FCS) otherwise they will be discarded when
> > +	 * they enter the switch port logic. When tagging is enabled, we need
> > +	 * to make sure that packets are at least 68 bytes (including FCS and
> > +	 * tag).
> > +	 */
> > +	if (__skb_put_padto(skb, ETH_ZLEN + sizeof(tag), false))
> > +		return NULL;
> > +
> > +	/* provide 'A5PSW_TAG_LEN' bytes additional space */
> > +	skb_push(skb, A5PSW_TAG_LEN);
> > +
> > +	/* make room between MACs and Ether-Type to insert tag */
> > +	dsa_alloc_etype_header(skb, A5PSW_TAG_LEN);
> > +
> > +	ptag = dsa_etype_header_pos_tx(skb);
> > +
> > +	data2_val = FIELD_PREP(A5PSW_CTRL_DATA_PORT, BIT(dp->index));
> > +	tag.ctrl_tag = htons(A5PSW_TAG_VALUE);
> > +	tag.ctrl_data = htons(A5PSW_CTRL_DATA_FORCE_FORWARD);
> > +	tag.ctrl_data2 = htonl(data2_val);
> > +
> > +	memcpy(ptag, &tag, sizeof(struct a5psw_tag));  
> 
> sizeof(tag), to be consistent with the other use of sizeof() above?
> Although, hmm, I think you could get away with editing "ptag" in place.

I was not sure of the alignment guarantee I would have here. If the
VLAN header is guaranteed to be aligned on 2 bytes, then I guess it's
ok to do that in-place.


-- 
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ