On 14/09/2026 10:54, Ido Schimmel wrote:
On Fri, Sep 11, 2026 at 01:06:44PM +0300, Nikolay Aleksandrov wrote:
__vlan_del() stops the software deletion when the switchdev operation
fails which is ok for an explicit VLAN deletion because the VLAN remains
configured but not ok when its VLAN group is being destroyed and everything
is being freed. __vlan_flush() always destroys the VLAN group after walking
it regardless of individual deletion errors, so aborting the software vlan
delete leaks the VLAN object's memory (and potentially its master VLAN, due
to references).
Allow teardown callers to finish the software deletion while preserving
error for reporting. Save the VLAN id before deleting because the VLAN
object can already be freed (queued for freeing by call_rcu).
I think we should only log an error instead of aborting the operation.
It's not really valid for a driver to refuse VLAN deletion and it's
inconsistent with the 8021q deletion path (i.e., __vlan_vid_del() ->
vlan_vid_del()) which doesn't abort the operation.
Also, by the time the switchdev deletion fails, the affected FDB entries
were already flushed and the PVID was already cleared, so the state is
inconsistent.
Ack, sounds good. I'll just report the error instead of failing the delete.
That makes it even easier and drops the need for the second patch. :)
Cheers,
Nik
