netdev - Re: [PATCH net-next 10/18] ionic: Add management of rx filters

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: <5ea141a1-37e1-a33f-105f-16f5a976bdb8@pensando.io>
Date:   Wed, 26 Jun 2019 08:52:24 -0700
From:   Shannon Nelson <snelson@...sando.io>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 10/18] ionic: Add management of rx filters

On 6/25/19 4:37 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:16 -0700, Shannon Nelson wrote:
>> +int ionic_rx_filter_save(struct lif *lif, u32 flow_id, u16 rxq_index,
>> +			 u32 hash, struct ionic_admin_ctx *ctx)
>> +{
>> +	struct device *dev = lif->ionic->dev;
>> +	struct hlist_head *head;
>> +	struct rx_filter *f;
>> +	unsigned int key;
>> +
>> +	f = devm_kzalloc(dev, sizeof(*f), GFP_KERNEL);
>> +	if (!f)
>> +		return -ENOMEM;
>> +
>> +	f->flow_id = flow_id;
>> +	f->filter_id = le32_to_cpu(ctx->comp.rx_filter_add.filter_id);
>> +	f->rxq_index = rxq_index;
>> +	memcpy(&f->cmd, &ctx->cmd, sizeof(f->cmd));
>> +
>> +	INIT_HLIST_NODE(&f->by_hash);
>> +	INIT_HLIST_NODE(&f->by_id);
>> +
>> +	switch (le16_to_cpu(f->cmd.match)) {
>> +	case RX_FILTER_MATCH_VLAN:
>> +		key = le16_to_cpu(f->cmd.vlan.vlan) & RX_FILTER_HLISTS_MASK;
>> +		break;
>> +	case RX_FILTER_MATCH_MAC:
>> +		key = *(u32 *)f->cmd.mac.addr & RX_FILTER_HLISTS_MASK;
>> +		break;
>> +	case RX_FILTER_MATCH_MAC_VLAN:
>> +		key = le16_to_cpu(f->cmd.mac_vlan.vlan) & RX_FILTER_HLISTS_MASK;
>> +		break;
>> +	default:
> I know you use devm_kzalloc() but can't this potentially keep arbitrary
> amounts of memory held until the device is removed (and it's the entire
> device not just a LIF)?

Yes, but we're freeing this memory when objects are deleted.  We're 
trying to be tidy with our allocations, but used devm_kzalloc to be more 
sure that things went away when the device did.

>
>> +		return -ENOTSUPP;
> EOPNOTSUPP, please do not use ENOTSUPP in the drivers.  It's a high
> error code, unknown to libc.  We should use EOPNOTSUPP or EINVAL.

Sure.

>
>> +	}