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.
+ }
