summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorPaolo Abeni <pabeni@redhat.com>2026-09-22 13:31:23 +0200
committerPaolo Abeni <pabeni@redhat.com>2026-09-22 13:31:24 +0200
commiteabc76156e86f20f2b2c43f6ed7b0769dd26391c (patch)
treebc4ac37212e83ebd24a02c4e6e02ca36e61af704 /include/linux
parent2d7341a020a57b30c1826db38f81bbc257ae3bbc (diff)
parent242ebf4c51148d5202b9c57841082c44c4284082 (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