netdev - Re: [PATCH net-next v2 5/6] bnxt_fwctl: Add bnxt fwctl device

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: <74540a81-a7af-4a50-b832-679e7873cfe0@intel.com>
Date: Thu, 25 Sep 2025 08:46:32 -0700
From: Dave Jiang <dave.jiang@...el.com>
To: Pavan Chebbi <pavan.chebbi@...adcom.com>
Cc: jgg@...pe.ca, michael.chan@...adcom.com, saeedm@...dia.com,
 Jonathan.Cameron@...wei.com, davem@...emloft.net, corbet@....net,
 edumazet@...gle.com, gospo@...adcom.com, kuba@...nel.org,
 netdev@...r.kernel.org, pabeni@...hat.com, andrew+netdev@...n.ch,
 selvin.xavier@...adcom.com, leon@...nel.org,
 kalesh-anakkur.purayil@...adcom.com
Subject: Re: [PATCH net-next v2 5/6] bnxt_fwctl: Add bnxt fwctl device



On 9/24/25 9:31 PM, Pavan Chebbi wrote:
> On Thu, Sep 25, 2025 at 4:02 AM Dave Jiang <dave.jiang@...el.com> wrote:
>>
> 
>>> +static void *bnxtctl_fw_rpc(struct fwctl_uctx *uctx,
>>> +                         enum fwctl_rpc_scope scope,
>>> +                         void *in, size_t in_len, size_t *out_len)
>>> +{
>>> +     struct bnxtctl_dev *bnxtctl =
>>> +             container_of(uctx->fwctl, struct bnxtctl_dev, fwctl);
>>> +     struct bnxt_aux_priv *bnxt_aux_priv = bnxtctl->aux_priv;
>>> +     struct fwctl_dma_info_bnxt *dma_buf = NULL;
>>> +     struct device *dev = &uctx->fwctl->dev;
>>> +     struct fwctl_rpc_bnxt *msg = in;
>>> +     struct bnxt_fw_msg rpc_in;
>>> +     int i, rc, err = 0;
>>> +     int dma_buf_size;
>>> +
>>> +     rpc_in.msg = kzalloc(msg->req_len, GFP_KERNEL);
>>
>> I think if you use __free(kfree) for all the allocations in the function, you can be rid of the gotos.
>>
> Thanks Dave for the review. Would you be fine if I defer using scope
> based cleanup for later?
> I need some time to understand the mechanism better and correctly
> define the macros as some
> pointers holding the memory are members within a stack variable. I
> will fix the goto/free issues
> you highlighted in the next revision. I hope that is going to be OK?

Sure that is fine. The way things are done in this function makes things a bit tricky to do cleanup properly via the scope based cleanup. I might play with it a bit and see if I can come up with something. It looks like it needs a bit of refactoring to split some things out. Probably not a bad thing in the long run.