On 6/25/19 4:37 PM, Jakub Kicinski wrote:

On Thu, 20 Jun 2019 13:24:16 -0700, Shannon Nelson wrote:

quoted

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

quoted

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

quoted

+	}