Hi Daniel,
On Sun, Mar 13, 2022 at 03:03:07PM +0100, Daniel Suchy wrote:
Hello,
I noticed boot problems on my Turris Omnia (with Marvell 88E6176 switch chip) after "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Within logs I catched hung kernel tasks (see below), at least first is related to DSA subsystem.
When I revert this patch, everything works as expected and without any issues.
In my setup, I have few vlans on affected switch (i'm using ifupdown2 v3.0 with iproute2 5.16 for configuration).
It seems your this patch introduces some new problem (at least for 5.15 kernels). I suggest revert this patch.
- Daniel
Oh wow, I'm terribly sorry. Yes, this patch shouldn't have been backported to kernel 5.15 and below, but I guess I missed the backport notification email and forgot to tell Greg about this. Patch "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" needs to be immediately reverted from these trees.
Greg, to avoid this from happening in the future, would something like this work? Is this parsed in some way?
Depends-on: 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work") # which first appeared in v5.16
On Sun, Mar 13, 2022 at 04:10:30PM +0200, Vladimir Oltean wrote:
Hi Daniel,
On Sun, Mar 13, 2022 at 03:03:07PM +0100, Daniel Suchy wrote:
Hello,
I noticed boot problems on my Turris Omnia (with Marvell 88E6176 switch chip) after "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Within logs I catched hung kernel tasks (see below), at least first is related to DSA subsystem.
When I revert this patch, everything works as expected and without any issues.
In my setup, I have few vlans on affected switch (i'm using ifupdown2 v3.0 with iproute2 5.16 for configuration).
It seems your this patch introduces some new problem (at least for 5.15 kernels). I suggest revert this patch.
- Daniel
Oh wow, I'm terribly sorry. Yes, this patch shouldn't have been backported to kernel 5.15 and below, but I guess I missed the backport notification email and forgot to tell Greg about this. Patch "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" needs to be immediately reverted from these trees.
Greg, to avoid this from happening in the future, would something like this work? Is this parsed in some way?
Depends-on: 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work") # which first appeared in v5.16
Looks like only 5.15 is affected. I re-checked the backport notification emails, and the patch failed to apply on 5.10, 5.4, 4.19 and 4.14, as intended.
On Sun, Mar 13, 2022 at 02:10:31PM +0000, Vladimir Oltean wrote:
Hi Daniel,
On Sun, Mar 13, 2022 at 03:03:07PM +0100, Daniel Suchy wrote:
Hello,
I noticed boot problems on my Turris Omnia (with Marvell 88E6176 switch chip) after "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Within logs I catched hung kernel tasks (see below), at least first is related to DSA subsystem.
When I revert this patch, everything works as expected and without any issues.
In my setup, I have few vlans on affected switch (i'm using ifupdown2 v3.0 with iproute2 5.16 for configuration).
It seems your this patch introduces some new problem (at least for 5.15 kernels). I suggest revert this patch.
- Daniel
Oh wow, I'm terribly sorry. Yes, this patch shouldn't have been backported to kernel 5.15 and below, but I guess I missed the backport notification email and forgot to tell Greg about this. Patch "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" needs to be immediately reverted from these trees.
Greg, to avoid this from happening in the future, would something like this work? Is this parsed in some way?
Depends-on: 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work") # which first appeared in v5.16
The "Fixes:" tag will solve this, please just use that in the future.
I'll go revert this, thanks.
greg k-h
On Mon, Mar 14, 2022 at 07:38:50AM +0100, gregkh@linuxfoundation.org wrote:
On Sun, Mar 13, 2022 at 02:10:31PM +0000, Vladimir Oltean wrote:
Hi Daniel,
On Sun, Mar 13, 2022 at 03:03:07PM +0100, Daniel Suchy wrote:
Hello,
I noticed boot problems on my Turris Omnia (with Marvell 88E6176 switch chip) after "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Within logs I catched hung kernel tasks (see below), at least first is related to DSA subsystem.
When I revert this patch, everything works as expected and without any issues.
In my setup, I have few vlans on affected switch (i'm using ifupdown2 v3.0 with iproute2 5.16 for configuration).
It seems your this patch introduces some new problem (at least for 5.15 kernels). I suggest revert this patch.
- Daniel
Oh wow, I'm terribly sorry. Yes, this patch shouldn't have been backported to kernel 5.15 and below, but I guess I missed the backport notification email and forgot to tell Greg about this. Patch "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" needs to be immediately reverted from these trees.
Greg, to avoid this from happening in the future, would something like this work? Is this parsed in some way?
Depends-on: 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work") # which first appeared in v5.16
The "Fixes:" tag will solve this, please just use that in the future.
Ah, you did have a fixes tag here, so then use the way to say "you also need to add another patch here" by adding the sha to the line for the stable tree: cc: stable@vger.kernel.org # 0faf890fc519
So, should I just backport that commit instead? The "Fixes:" line says this needs to be backported to 4.14, which is why I added it to these trees.
thanks,
greg k-h
On Mon, Mar 14, 2022 at 08:21:30AM +0100, gregkh@linuxfoundation.org wrote:
On Mon, Mar 14, 2022 at 07:38:50AM +0100, gregkh@linuxfoundation.org wrote:
On Sun, Mar 13, 2022 at 02:10:31PM +0000, Vladimir Oltean wrote:
Hi Daniel,
On Sun, Mar 13, 2022 at 03:03:07PM +0100, Daniel Suchy wrote:
Hello,
I noticed boot problems on my Turris Omnia (with Marvell 88E6176 switch chip) after "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Within logs I catched hung kernel tasks (see below), at least first is related to DSA subsystem.
When I revert this patch, everything works as expected and without any issues.
In my setup, I have few vlans on affected switch (i'm using ifupdown2 v3.0 with iproute2 5.16 for configuration).
It seems your this patch introduces some new problem (at least for 5.15 kernels). I suggest revert this patch.
- Daniel
Oh wow, I'm terribly sorry. Yes, this patch shouldn't have been backported to kernel 5.15 and below, but I guess I missed the backport notification email and forgot to tell Greg about this. Patch "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" needs to be immediately reverted from these trees.
Greg, to avoid this from happening in the future, would something like this work? Is this parsed in some way?
Depends-on: 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work") # which first appeared in v5.16
The "Fixes:" tag will solve this, please just use that in the future.
Ah, you did have a fixes tag here, so then use the way to say "you also need to add another patch here" by adding the sha to the line for the stable tree: cc: stable@vger.kernel.org # 0faf890fc519
So, should I just backport that commit instead? The "Fixes:" line says this needs to be backported to 4.14, which is why I added it to these trees.
thanks,
No, don't backport the dependency, just revert the patch (hence my question: how can I describe "don't backport beyond commit X"?).
Here, you can apply the revert attached.
On Mon, Mar 14, 2022 at 11:17:50AM +0000, Vladimir Oltean wrote:
On Mon, Mar 14, 2022 at 08:21:30AM +0100, gregkh@linuxfoundation.org wrote:
On Mon, Mar 14, 2022 at 07:38:50AM +0100, gregkh@linuxfoundation.org wrote:
On Sun, Mar 13, 2022 at 02:10:31PM +0000, Vladimir Oltean wrote:
Hi Daniel,
On Sun, Mar 13, 2022 at 03:03:07PM +0100, Daniel Suchy wrote:
Hello,
I noticed boot problems on my Turris Omnia (with Marvell 88E6176 switch chip) after "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Within logs I catched hung kernel tasks (see below), at least first is related to DSA subsystem.
When I revert this patch, everything works as expected and without any issues.
In my setup, I have few vlans on affected switch (i'm using ifupdown2 v3.0 with iproute2 5.16 for configuration).
It seems your this patch introduces some new problem (at least for 5.15 kernels). I suggest revert this patch.
- Daniel
Oh wow, I'm terribly sorry. Yes, this patch shouldn't have been backported to kernel 5.15 and below, but I guess I missed the backport notification email and forgot to tell Greg about this. Patch "net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN" needs to be immediately reverted from these trees.
Greg, to avoid this from happening in the future, would something like this work? Is this parsed in some way?
Depends-on: 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work") # which first appeared in v5.16
The "Fixes:" tag will solve this, please just use that in the future.
Ah, you did have a fixes tag here, so then use the way to say "you also need to add another patch here" by adding the sha to the line for the stable tree: cc: stable@vger.kernel.org # 0faf890fc519
So, should I just backport that commit instead? The "Fixes:" line says this needs to be backported to 4.14, which is why I added it to these trees.
thanks,
No, don't backport the dependency, just revert the patch (hence my question: how can I describe "don't backport beyond commit X"?).
Here, you can apply the revert attached.
Thanks, now queued up.
greg k-h
linux-stable-mirror@lists.linaro.org
-
gregkh＠linuxfoundation.org -
Vladimir Oltean