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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 31 Jan 2020 16:51:10 -0800
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
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 1/31/2020 10:07 AM, Jakub Kicinski wrote:
> On Thu, 30 Jan 2020 14:59:03 -0800, Jacob Keller wrote:
> 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?
> 

We do have some global resources on the device. This is somewhat managed
by firmware, but not everything is managed, and there's often little to
no visibility even at the driver layer let alone a system administrator.

Things like flash_update and flash regions also only make sense device
wide, and it's a little silly to expose them for multiple functions.

Unfortunately, we *do* have separate PCIe functions, and I wasn't able
to come up with a good (safe) method for managing something like this
that crosses the function boundary.

I noticed that the mlx4 and mlx5 drivers appear to create one devlink
per PF as well, but the mlxsw driver appears to have a single function
for the whole device.

I'm not sure about other drivers, but I do think this is a common
problem, and would benefit from some core code.

One possibility that I've tossed around in my head is some sort of
subordinate PCI bus driver that loads once for the device before the
function drivers load... But I really am not sure where to begin with
that. This also represents a fairly significant device driver model change.

Beyond just having the devlink is some capability to add per-port
configuration as well.

TL;DR; Yes, I'd like to have a single devlink for the device, but no, I
don't have a good answer for how to do it sanely.

Thanks,
Jake

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ