Thread (18 messages) 18 messages, 3 authors, 2022-07-17

Re: [PATCH net-next v1 1/1] net: bridge: ensure that link-local traffic cannot unlock a locked port

From: Hans S <hidden>
Date: 2022-07-04 14:36:32
Also in: bridge, linux-kselftest, lkml

Possibly related (same subject, not in this thread)

On Mon, Jul 4, 2022 at 1:00 PM Ido Schimmel [off-list ref] wrote:
On Mon, Jul 04, 2022 at 09:54:31AM +0200, Hans S wrote:
quoted
quoted
IIUC, with mv88e6xxx, when the port is locked and learning is disabled:

1. You do not get miss violation interrupts. Meaning, you can't report
'locked' entries to the bridge driver.

2. You do not get aged-out interrupts. Meaning, you can't tell the
bridge driver to remove aged-out entries.

My point is that this should happen regardless if learning is enabled on
the bridge driver or not. Just make sure it is always enabled in
mv88e6xxx when the port is locked. Learning in the bridge driver itself
can be off, thereby eliminating the need to disable learning from
link-local packets.
So you suggest that we enable learning in the driver when locking the
port and document that learning should be turned off from user space
before locking the port?
Yes. Ideally, the bridge driver would reject configurations where
learning is enabled and the port is locked, but it might be too late for
that. It would be good to add a note in the man page that learning
should be disabled when the port is locked to avoid "unlocking" the port
by accident.
Well you cannot unlock the port by either enabling or disabling
learning after the port is locked, but Mac-Auth and refreshing might
not work. I clarify just so that no-one gets confused.

I can do so that the driver returns -EINVAL if learning is on when
locking the port, but that would of course only be for mv88e6xxx...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help