Hello Oliver, On Wed, Nov 6, 2019 at 12:12 PM Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote: > > Hello Jaroslav, > > On 05/11/2019 22.46, Jaroslav Beran wrote: > > > So far I've learned this issue is most probably caused by upper (net > > and can) layers (so this is not specific for certain controller > > driver). When a driver calls can_bus_off, it sets carrier-off and > > triggers linkwatch_* actions that deactivate net queues and substitute > > a struct qdisc with `noop_qdisc`. Upon sending a frame, it's enqueue > > function - noop_enqueue - just returns NET_XMIT_CN, which is > > transformed by net_xmit_errno macro to zero, that's passed by > > net/can/af_can.c:can_send up to a userspace caller of write as > > success. > > Hm. > > > According to description for qdisc return codes in > > include/linux/netdevice.h, NET_XMIT_CN stands for `congestion > > notification` and further > > > > /* NET_XMIT_CN is special. It does not guarantee that this packet is lost. It > > * indicates that the device will soon be dropping packets, or already drops > > * some packets of the same priority; prompting us to send less aggressively. */ > > > > > > Is this behavior appropriate for a node in BUS-OFF state? I'd rather > > expect such controller would be always dropping all frames (not just > > soon and some) until reset. > > The common use of the net_xmit_errno macro probably really does not fit > to the CAN specialties ... > > > In current situation a caller of write gets success even if his frame > > is lost for sure. Is there any specific reason for this? Of course he > > can be notified by receiving error frame, but why don't just return > > error in can_send? > > Yes. It makes sense to forward the carrier-off state that is thankfully > provided by the linkwatch triggers to the user space. > > Looking to man(2) send we should provide -ENOBUFS in the case of > carrier-off state, right? Maybe -ENETDOWN is more suitable? > > Would you like to provide a patch? Sure. Best regards, Jaroslav
