netdev - Re: [PATCH net] net/smc: use the correct ndev to find pnetid by pnetid table

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]

Message-ID: <20250109040429.350fdd60.pasic@linux.ibm.com>
Date: Thu, 9 Jan 2025 04:04:29 +0100
From: Halil Pasic <pasic@...ux.ibm.com>
To: Guangguan Wang <guangguan.wang@...ux.alibaba.com>
Cc: Paolo Abeni <pabeni@...hat.com>, wenjia@...ux.ibm.com, jaka@...ux.ibm.com,
        alibuda@...ux.alibaba.com, tonylu@...ux.alibaba.com,
        guwen@...ux.alibaba.com, davem@...emloft.net, edumazet@...gle.com,
        kuba@...nel.org, horms@...nel.org, linux-rdma@...r.kernel.org,
        linux-s390@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Alexandra Winter <wintera@...ux.ibm.com>,
        Halil Pasic <pasic@...ux.ibm.com>
Subject: Re: [PATCH net] net/smc: use the correct ndev to find pnetid by
 pnetid table

On Wed, 8 Jan 2025 12:57:00 +0800
Guangguan Wang <guangguan.wang@...ux.alibaba.com> wrote:

> > sorry for chiming in late. Wenjia is on vacation and Jan is out sick!
> > After some reading and thinking I could not figure out how 890a2cb4a966
> > ("net/smc: rework pnet table") is broken.  
> 
> Before commit 890a2cb4a966:
> smc_pnet_find_roce_resource
>     smc_pnet_find_roce_by_pnetid(ndev, ...) /* lookup via hardware-defined pnetid */
>         smc_pnetid_by_dev_port(base_ndev, ...)
>     smc_pnet_find_roce_by_table(ndev, ...) /* lookup via SMC PNET table */
>     {
>         ...
>         list_for_each_entry(pnetelem, &smc_pnettable.pnetlist, list) {
>                 if (ndev == pnetelem->ndev) { /* notice here, it was ndev to matching pnetid element in pnet table */
>         ...
>     }
> 
> After commit 890a2cb4a966:
> smc_pnet_find_roce_resource
>     smc_pnet_find_roce_by_pnetid
>     {
>         ...
>         base_ndev = pnet_find_base_ndev(ndev); /* rename the variable name to base_ndev for better understanding */
>         smc_pnetid_by_dev_port(base_ndev, ...)
>         smc_pnet_find_ndev_pnetid_by_table(base_ndev, ...)
>         {
>                 ...
>                 list_for_each_entry(pnetelem, &smc_pnettable.pnetlist, list) {
>                 if (base_ndev == pnetelem->ndev) { /* notice here, it is base_ndev to matching pnetid element in pnet table */
>                 ...
>         }
> 
>     }
> 
> The commit 890a2cb4a966 has changed ndev to base_ndev when matching pnetid element in pnet table.
> But in the function smc_pnet_add_eth, the pnetid is attached to the ndev itself, not the base_ndev.
> smc_pnet_add_eth(...)
> {
>     ...
>     ndev = dev_get_by_name(net, eth_name);
>     ...
>         if (new_netdev) {
>             if (ndev) {
>                 new_pe->ndev = ndev;
>                 netdev_tracker_alloc(ndev, &new_pe->dev_tracker,
>                     GFP_ATOMIC);
>             }
>             list_add_tail(&new_pe->list, &pnettable->pnetlist);
>             mutex_unlock(&pnettable->lock);
>         } else {
>     ...
> }

I still not understand why do you think that 890a2cb4a966~1 is better
than 890a2cb4a966 even if things changed with 890a2cb4a966 which
I did not verify for myself but am willing to assume.

Is there some particular setup that you think would benefit from
you patch? I.e. going back to the 890a2cb4a966~1 behavior I suppose.

I think I showed a valid and practical setup that would break with your
patch as is. Do you agree with that statement?

Regards,
Halil