On 3/19/19 11:17 AM, Florian Fainelli wrote:
On 3/19/19 11:14 AM, Christian Lamparter wrote:
Cc: Florian. I hope you don't mind.
On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:
Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
on an IPQ4019-based device, I can get basic connectivity either manually,
or with a "standard" UCI definition of the "lan" bridge[2].
(I'm aware that this is not "production" code and expect "challenges".)
[...]
This unfortunately results in a kernel panic when trying to add to the
bridge.
Bridge br-lan initially set up with "default" UCI config[2]
Full serial log available[4]
ip link add link wan0 name wan0.100 type vlan id 100
ip link set wan0 up
ip link set wan0.100 up
ip link set wan0.100 master br-lan
(kernel panics)
I've traced this to passing of a null pointer to br_vlan_enabled()
with the diagnostic patch shown in [5]
Yes, this shouldn't crash. I think Florian has already a patch for this
upstream [6].
Right, this specific commit omitted two key details which were that:
- not all drivers support port_vlan_{add,del}
- not all drivers support programming VID 0
This is fixed upstream with d6af21a4fb5fff2f6640feb011902212e658414d
("net: dsa: Use prepare/commit phase in dsa_slave_vlan_rx_add_vid()")
commit 061f6a505ac33659eab007731c0f6374df39ab55
Author: Florian Fainelli <f.faine...@gmail.com>
Date: Wed Feb 20 14:35:39 2019 -0800
net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
That should help with the NPEs since it now checks whenever the
bridge_dev is valid or not.
[3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
[6] <https://patchwork.ozlabs.org/patch/1026172/>
Thanks all for the quick and insightful responses!
It looks like the critical line to avoid the NPE
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
was provided by in recent mainline by the referenced commit 061f6a505ac3
The structure of the DSA code changed significantly on the way to 5.1,
so I'm looking through the 46 or so commits in mainline net/dsa/ that
aren't in 4.19 and trying to make sense of which need to be backported
to have a reasonably complete and functional 4.19 implementation.
Jeff
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
