+ Sabrina Dubroca (takes care of team driver which has the same issue)
On 13/03/2020 10.56, Oleksij Rempel wrote:
On Mon, Mar 09, 2020 at 11:25:50AM +0100, Marc Kleine-Budde wrote:
On 3/7/20 6:13 AM, David Miller wrote:
Like this:
if (netdev->ops != &can_netdev_ops)
return;
There is no single can_netdev_ops. The netdev_ops are per CAN-network
driver. But the ml_priv is used in the generic CAN code.
ping,
are there any other ways or ideas how to solve this issue?
Well, IMO the patch from
https://marc.info/?l=linux-can&m=158039108004683
is still valid.
Although the attribution that commit 8df9ffb888c ("can: make use of
preallocated can_ml_priv for per device struct can_dev_rcv_lists")
introduced the problem could be removed.
Even before this commit dev->ml_priv of CAN interfaces has been used to
store the filter lists. And either the bonding and the team driver do
not take care of ml_priv.
They pretend to be CAN interfaces by faking dev->type to be ARPHRD_CAN -
but they are not. When we dereference dev->ml_priv in (badly) faked CAN
devices we run into the reported issue.
So the approach is to tell bonding and team driver to keep the fingers
away from CAN interfaces like we do with some ARPHRD_INFINIBAND setups
in bond_enslave() too.
Regards,
Oliver
