On Wed, Mar 01 2023, Oliver Hartkopp wrote: > I added the sockopt CAN_ISOTP_WAIT_TX_DONE in isotp-poll-test.c which > fixes the problem: I saw CAN_ISOTP_WAIT_TX_DONE but didn't want to use it, because the whole point of (e)poll/select is to wait only in poll() and have write() execute without any blocking. In a sense, CAN_ISOTP_WAIT_TX_DONE is incompatible with O_NONBLOCK sockets. > The sockopt uses a wait queue and returns from the write() syscall when > tx.state becomes ISOTP_IDLE. That should be the point of poll() too: Waiting until the socket is ready for the next write(). As I understand it, the poll() implementation is "connected" to all relevant wait queues and whenever a wait queue is woken up, protocol's poll method is called. It checks if the wake really made the socket writable (or readable) and if so, the poll() syscall returns. When thinking about that, I guess I know where is the problem. Currently, we call datagram_poll(), which checks only sock->wq.wait queue and not the isotp wait queue so->wait. Tomorrow, I'll try to look at how to wait also for so->wait. > Using the isotp socket without CAN_ISOTP_WAIT_TX_DONE turned out to be > not such good idea. But this results from the original API which had > some kind of "fire-and-forget" mode. > > Today the tx.state is set back to ISOTP_IDLE in isotp_rcv_echo() - and > with this short 9 byte PDU the interaction with the receiving entity is > really fast on vcan's. Maybe faster than the the write syscall > returns. If it is faster, then we wouldn't see write() returning EAGAIN in our poll() tests (without CAN_ISOTP_WAIT_TX_DONE). Best regards, -Michal
