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=2566a89b9e163b2fcd104d6005e0149f197b8a48
> >
> > 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, [email protected] 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=2566a89b9e163b2fcd104d6005e0149f197b8a48
> > >
> > > 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: [email protected] # 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, [email protected] wrote:
> On Mon, Mar 14, 2022 at 07:38:50AM +0100, [email protected] 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=2566a89b9e163b2fcd104d6005e0149f197b8a48
> > > >
> > > > 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: [email protected] # 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, [email protected] wrote:
> > On Mon, Mar 14, 2022 at 07:38:50AM +0100, [email protected] 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=2566a89b9e163b2fcd104d6005e0149f197b8a48
> > > > >
> > > > > 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: [email protected] # 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