From: Michal Sojka <michal.sojka@cvut.cz>
To: Maxime Jayat <maxime.jayat@mobile-devices.fr>,
Oliver Hartkopp <socketcan@hartkopp.net>,
Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Dae R. Jeong" <threeearcat@gmail.com>,
Hillf Danton <hdanton@sina.com>
Subject: Re: can: isotp: epoll breaks isotp_sendmsg
Date: Sat, 01 Jul 2023 00:35:18 +0200 [thread overview]
Message-ID: <87cz1czihl.fsf@steelpick.2x.cz> (raw)
In-Reply-To: <11328958-453f-447f-9af8-3b5824dfb041@munic.io>
Hi Maxime,
On Fri, Jun 30 2023, Maxime Jayat wrote:
> Hi,
>
> There is something not clear happening with the non-blocking behavior
> of ISO-TP sockets in the TX path, but more importantly, using epoll now
> completely breaks isotp_sendmsg.
> I believe it is related to
> 79e19fa79c ("can: isotp: isotp_ops: fix poll() to not report false
> EPOLLOUT events"),
> but actually is probably deeper than that.
>
> I don't completely understand what is exactly going on, so I am sharing
> the problem I face:
>
> With an ISO-TP socket in non-blocking mode, using epoll seems to make
> isotp_sendmsg always return -EAGAIN.
That's definitely not expected behavior. I tested the patch only with
poll, hoping that epoll would behave the same.
[...]
>
> By reverting 79e19fa79c, I get better results but still incorrect:
[...]
> It is then possible to write on the socket but the write is blocking,
> which is not the expected behavior for a non-blocking socket.
Yes, incorrect behavior was why we made the commit in question, however
we saw write() returning -EAGAIN when it shouldn't.
> I don't know how to solve the problem. To me, using wq_has_sleeper seems
> weird.
Agreed. I've never tried to understand how synchronization works here.
Hopefully, Oliver knows more.
> The implementation of isotp_poll feels weird too (calling both
> datagram_poll and
> poll_wait?). But I am not sure what would be the correct
> implementation.
I understand it as follows (which might be wrong - someone, please
correct me), isotp_poll() should register the file with all waitqueues
it can wait on. so->wait is one and sock->sq.wait (used by
datagram_poll) is another. The former is definitely used for TX, the
latter is probably used because skb_recv_datagram() is called for RX.
But so->wait is also used for RX and there might proabbly be be some
inconsistency between those.
> My actual use-case is in Async Rust using tokio.
Our initial motivation was also Rust and tokio however than I did
testing only with simple C programs. I'm definitely interested in having
this working.
I'll try to look at this in more detail during the weekend. It's too
late for me today.
Best regards,
-Michal
next prev parent reply other threads:[~2023-06-30 22:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-30 16:44 can: isotp: epoll breaks isotp_sendmsg Maxime Jayat
2023-06-30 22:35 ` Michal Sojka [this message]
2023-07-17 7:49 ` Marc Kleine-Budde
2023-07-17 13:05 ` Michal Sojka
2023-08-13 11:23 ` Lukas Magel
2023-08-18 11:53 ` Lukas Magel
2023-08-20 19:51 ` Oliver Hartkopp
2023-08-22 6:51 ` Lukas Magel
2023-08-22 16:37 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cz1czihl.fsf@steelpick.2x.cz \
--to=michal.sojka@cvut.cz \
--cc=hdanton@sina.com \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.jayat@mobile-devices.fr \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=socketcan@hartkopp.net \
--cc=threeearcat@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox