diff options
| author | Paolo Abeni <pabeni@redhat.com> | 2026-09-22 13:31:23 +0200 |
|---|---|---|
| committer | Paolo Abeni <pabeni@redhat.com> | 2026-09-22 13:31:24 +0200 |
| commit | eabc76156e86f20f2b2c43f6ed7b0769dd26391c (patch) | |
| tree | bc4ac37212e83ebd24a02c4e6e02ca36e61af704 /include/linux | |
| parent | 2d7341a020a57b30c1826db38f81bbc257ae3bbc (diff) | |
| parent | 242ebf4c51148d5202b9c57841082c44c4284082 (diff) | |
Merge branch 'net-dsa-mv88e6xxx-ethtool-n-tuple-follow-ups'
Jakub Kicinski says:
====================
net: dsa: mv88e6xxx: ethtool n-tuple follow ups
Here are two small tweaks to the mv88e6xxx n-tuple filter handling
suggested by Sashiko when reviewing commit b1fffc273112 ("net: dsa:
mv88e6xxx: bound the policy rule dump by the caller's buffer size")
At the high level the problem is that the driver has shared rule
table but for some ops it doesn't check whether the rule operated
on belongs to the port on which the ethtool request was sent.
I initially thought that this could be intentional, but on closer
look I don't think it really works..
Sending for net-next, because this is AI-induced, build-tested-only
slop-code. The outcome is unlikely and results in mis-configuration,
no crashes.
====================
Link: https://patch.msgid.link/20260918185326.3940857-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions
