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] [day] [month] [year] [list]

Date:   Thu, 27 Jun 2019 08:59:59 -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/26/19 8:52 AM, Shannon Nelson wrote:
> 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.

... except, of course, in this error case.  Yes, I'll add a free here.

sln