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:   Sat, 7 Sep 2019 17:25:10 -0400
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, f.fainelli@...il.com
Subject: Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: add RXNFC support

Hi Andrew,

On Sat, 7 Sep 2019 22:32:56 +0200, Andrew Lunn <andrew@...n.ch> wrote:
> > +	policy = devm_kzalloc(chip->dev, sizeof(*policy), GFP_KERNEL);
> > +	if (!policy)
> > +		return -ENOMEM;
> 
> I think this might be the first time we have done dynamic memory
> allocation in the mv88e6xxx driver. It might even be a first for a DSA
> driver?
> 
> I'm not saying it is wrong, but maybe we should discuss it. 
> 
> I assume you are doing this because the ATU entry itself is not
> sufficient?
> 
> How much memory is involved here, worst case? I assume one struct
> mv88e6xxx_policy per ATU entry? Which you think is too much to
> allocate as part of chip? I guess most users will never use this
> feature, so for most users it would be wasted memory. So i do see the
> point for dynamically allocating it.

A layer 2 policy is not limited to the ATU. It can also be based on a VTU
entry, on the port's Etype, or frame's Etype. We can have 0, 1 or literally
thousands of policies programmed by the user. The ethtool API does not
store the entries and requires the driver to dump them on get operations,
hence the allocation for simplicity. But we may accomodate the DSA layer in
the future if there are more RXNFC users than just bcm_sf2 and mv88e6xxx.


Thanks,

	Vivien

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ