linux-stable.git/net/devlink, branch linux-6.7.y

devlink: fix port new reply cmd type

2024-03-26T22:18:58+00:00

[ Upstream commit 78a2f5e6c15d8dcbd6495bb9635c7cb89235dfc5 ]

Due to a c&p error, port new reply fills-up cmd with wrong value,
any other existing port command replies and notifications.

Fix it by filling cmd with value DEVLINK_CMD_PORT_NEW.

Skimmed through devlink userspace implementations, none of them cares
about this cmd value.

Reported-by: Chenyuan Yang 
Closes: https://lore.kernel.org/all/ZfZcDxGV3tSy4qsV@cy-server/
Fixes: cd76dcd68d96 ("devlink: Support add and delete devlink port")
Signed-off-by: Jiri Pirko 
Reviewed-by: Parav Pandit 
Reviewed-by: Kalesh AP 
Link: https://lore.kernel.org/r/20240318091908.2736542-1-jiri@resnulli.us
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

devlink: Fix devlink parallel commands processing

2024-03-26T22:18:54+00:00

[ Upstream commit d7d75124965aee23e5e4421d78376545cf070b0a ]

Commit 870c7ad4a52b ("devlink: protect devlink->dev by the instance
lock") added devlink instance locking inside a loop that iterates over
all the registered devlink instances on the machine in the pre-doit
phase. This can lead to serialization of devlink commands over
different devlink instances.

For example: While the first devlink instance is executing firmware
flash, all commands to other devlink instances on the machine are
forced to wait until the first devlink finishes.

Therefore, in the pre-doit phase, take the devlink instance lock only
for the devlink instance the command is targeting. Devlink layer is
taking a reference on the devlink instance, ensuring the devlink->dev
pointer is valid. This reference taking was introduced by commit
a380687200e0 ("devlink: take device reference for devlink object").
Without this commit, it would not be safe to access devlink->dev
lockless.

Fixes: 870c7ad4a52b ("devlink: protect devlink->dev by the instance lock")
Signed-off-by: Shay Drory 
Reviewed-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

devlink: Allow taking device lock in pre_doit operations

2024-03-26T22:18:54+00:00

[ Upstream commit d32c38256db30a2d55b849e2c77342bc70d58c6e ]

Introduce a new private flag ('DEVLINK_NL_FLAG_NEED_DEV_LOCK') to allow
netlink commands to specify that they need to acquire the device lock in
their pre_doit operation and release it in their post_doit operation.

The reload command will use this flag in the subsequent patch.

No functional changes intended.

Signed-off-by: Ido Schimmel 
Reviewed-by: Jiri Pirko 
Signed-off-by: Petr Machata 
Reviewed-by: Simon Horman 
Signed-off-by: David S. Miller 
Stable-dep-of: d7d75124965a ("devlink: Fix devlink parallel commands processing")
Signed-off-by: Sasha Levin

devlink: Enable the use of private flags in post_doit operations

2024-03-26T22:18:54+00:00

[ Upstream commit c8d0a7d6152bec970552786b77626f4b4c562f4d ]

Currently, private flags (e.g., 'DEVLINK_NL_FLAG_NEED_PORT') are only
used in pre_doit operations, but a subsequent patch will need to
conditionally lock and unlock the device lock in pre and post doit
operations, respectively.

As a preparation, enable the use of private flags in post_doit
operations in a similar fashion to how it is done for pre_doit
operations.

No functional changes intended.

Signed-off-by: Ido Schimmel 
Reviewed-by: Jiri Pirko 
Signed-off-by: Petr Machata 
Reviewed-by: Simon Horman 
Signed-off-by: David S. Miller 
Stable-dep-of: d7d75124965a ("devlink: Fix devlink parallel commands processing")
Signed-off-by: Sasha Levin

devlink: Acquire device lock during netns dismantle

2024-03-26T22:18:53+00:00

[ Upstream commit e21c52d7814f5768f05224e773644629fe124af2 ]

Device drivers register with devlink from their probe routines (under
the device lock) by acquiring the devlink instance lock and calling
devl_register().

Drivers that support a devlink reload usually implement the
reload_{down, up}() operations in a similar fashion to their remove and
probe routines, respectively.

However, while the remove and probe routines are invoked with the device
lock held, the reload operations are only invoked with the devlink
instance lock held. It is therefore impossible for drivers to acquire
the device lock from their reload operations, as this would result in
lock inversion.

The motivating use case for invoking the reload operations with the
device lock held is in mlxsw which needs to trigger a PCI reset as part
of the reload. The driver cannot call pci_reset_function() as this
function acquires the device lock. Instead, it needs to call
__pci_reset_function_locked which expects the device lock to be held.

To that end, adjust devlink to always acquire the device lock before the
devlink instance lock when performing a reload.

For now, only do that when reload is triggered as part of netns
dismantle. Subsequent patches will handle the case where reload is
explicitly triggered by user space.

Signed-off-by: Ido Schimmel 
Reviewed-by: Jiri Pirko 
Signed-off-by: Petr Machata 
Reviewed-by: Simon Horman 
Signed-off-by: David S. Miller 
Stable-dep-of: d7d75124965a ("devlink: Fix devlink parallel commands processing")
Signed-off-by: Sasha Levin

devlink: Move private netlink flags to C file

2024-03-26T22:18:53+00:00

[ Upstream commit 526dd6d7877b80b1f56d87156b65b8227c69d59f ]

The flags are not used outside of the C file so move them there.

Suggested-by: Jiri Pirko 
Signed-off-by: Ido Schimmel 
Reviewed-by: Jiri Pirko 
Signed-off-by: Petr Machata 
Reviewed-by: Simon Horman 
Signed-off-by: David S. Miller 
Stable-dep-of: d7d75124965a ("devlink: Fix devlink parallel commands processing")
Signed-off-by: Sasha Levin

devlink: Fix length of eswitch inline-mode

2024-03-26T22:18:27+00:00

[ Upstream commit 8f4cd89bf10607de08231d6d91a73dd63336808e ]

Set eswitch inline-mode to be u8, not u16. Otherwise, errors below

$ devlink dev eswitch set pci/0000:08:00.0 mode switchdev \
  inline-mode network
    Error: Attribute failed policy validation.
    kernel answers: Numerical result out of rang
    netlink: 'devlink': attribute type 26 has an invalid length.

Fixes: f2f9dd164db0 ("netlink: specs: devlink: add the remaining command to generate complete split_ops")
Signed-off-by: William Tu 
Reviewed-by: Jiri Pirko 
Reviewed-by: Simon Horman 
Link: https://lore.kernel.org/r/20240310164547.35219-1-witu@nvidia.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

devlink: fix port dump cmd type

2024-03-01T12:41:58+00:00

[ Upstream commit 61c43780e9444123410cd48c2483e01d2b8f75e8 ]

Unlike other commands, due to a c&p error, port dump fills-up cmd with
wrong value, different from port-get request cmd, port-get doit reply
and port notification.

Fix it by filling cmd with value DEVLINK_CMD_PORT_NEW.

Skimmed through devlink userspace implementations, none of them cares
about this cmd value. Only ynl, for which, this is actually a fix, as it
expects doit and dumpit ops rsp_value to be the same.

Omit the fixes tag, even thought this is fix, better to target this for
next release.

Fixes: bfcd3a466172 ("Introduce devlink infrastructure")
Signed-off-by: Jiri Pirko 
Reviewed-by: Simon Horman 
Reviewed-by: Jakub Kicinski 
Link: https://lore.kernel.org/r/20240220075245.75416-1-jiri@resnulli.us
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

devlink: fix possible use-after-free and memory leaks in devlink_init()

2024-03-01T12:41:55+00:00

[ Upstream commit def689fc26b9a9622d2e2cb0c4933dd3b1c8071c ]

The pernet operations structure for the subsystem must be registered
before registering the generic netlink family.

Make an unregister in case of unsuccessful registration.

Fixes: 687125b5799c ("devlink: split out core code")
Signed-off-by: Vasiliy Kovalev 
Link: https://lore.kernel.org/r/20240215203400.29976-1-kovalev@altlinux.org
Signed-off-by: Paolo Abeni 
Signed-off-by: Sasha Levin

devlink: avoid potential loop in devlink_rel_nested_in_notify_work()

2024-02-16T18:14:23+00:00

[ Upstream commit 58086721b7781c3e35b19c9b78c8f5a791070ba3 ]

In case devlink_rel_nested_in_notify_work() can not take the devlink
lock mutex. Convert the work to delayed work and in case of reschedule
do it jiffie later and avoid potential looping.

Suggested-by: Paolo Abeni 
Fixes: c137743bce02 ("devlink: introduce object and nested devlink relationship infra")
Signed-off-by: Jiri Pirko 
Link: https://lore.kernel.org/r/20240205171114.338679-1-jiri@resnulli.us
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin