Hi Kurt,
On 21/01/2020 20.22, Kurt Van Dijck wrote:
I decreased the CC list a bit, as I'm more like thinking in the wild
now:
Good choice!
Since the problems happens only rarely, and with vxcan, I assume not
vcan, I started to think to locking issues.
1. What surprised me a bit is 'rtnl_dereference()' calls, without
rcu_read_lock() around it? is that supposed to be ok?
Don't know. This code was just copied from veth.c
But veth doesn't fiddle with ml_priv like us.
2. is it possible to call vxcan_dellink in between the 2
rcu_assign_pointer() calls in vxcan_newlink(), resulting in a dead end,
i.e. one end is referenced, but already deleted?
I'd expect a kind of rcu_write_lock around the cross-linking at least.
Will look into this too. When there's a comment this might be a
justification for doing "hacky" things ;-)
It still puzzles me how this bisected to CAN_REQUIRED_SIZE() macro
commit.
Yes. That's really weird as is just has an impact on the socket API. But
it should not have any impact on the CAN_RAW socket they are using.
Hm - in fact is has an impact on the socket API.
Before the patch the user space was able to send 16 bytes to the CAN_RAW
socket. Now it's only 8 byte as you reduced the required size.
Regards,
Oliver
