netdev - Re: [PATCH 08/15] devlink: add devres managed devlinkm_alloc and devlinkm

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: <20200131100723.0d6893fa@cakuba.hsd1.ca.comcast.net>
Date:   Fri, 31 Jan 2020 10:07:23 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     netdev@...r.kernel.org, jiri@...nulli.us, valex@...lanox.com,
        linyunsheng@...wei.com, lihong.yang@...el.com
Subject: Re: [PATCH 08/15] devlink: add devres managed devlinkm_alloc and
 devlinkm_free

On Thu, 30 Jan 2020 14:59:03 -0800, Jacob Keller wrote:
> Add devres managed allocation functions for allocating a devlink
> instance. These can be used by device drivers based on the devres
> framework which want to allocate a devlink instance.
> 
> For simplicity and to reduce churn in the devlink core code, the devres
> management works by creating a node with a double-pointer. The devlink
> instance is allocated using the normal devlink_alloc and released using
> the normal devlink_free.
> 
> An alternative solution where the raw memory for devlink is allocated
> directly via devres_alloc could be done. Such an implementation would
> either significantly increase code duplication or code churn in order to
> refactor the setup from the allocation.
> 
> The new devres managed allocation function will be used by the ice
> driver in a following change to implement initial devlink support.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>

Ugh. The devlink instance sharing/aliasing is something that needs to
be solved at some point. But the problem likely exists elsewhere
already. Do you have global ASIC resources?