Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp5316460rwp; Mon, 17 Jul 2023 01:40:36 -0700 (PDT) X-Google-Smtp-Source: APBJJlFMP95dOIxfvslV2krjkTKeTIc827Ie79HPxk7lweohUqHbqCU87v6PEwIUsVfoR2Vt70Cg X-Received: by 2002:aa7:c3c9:0:b0:51d:8a55:6c11 with SMTP id l9-20020aa7c3c9000000b0051d8a556c11mr12503915edr.8.1689583236055; Mon, 17 Jul 2023 01:40:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689583236; cv=none; d=google.com; s=arc-20160816; b=nmY505zfZRClDE09EM5xSzTOosq83ic+OzT9Jn6v2PRuaN4MKC7ZJcil2P0zvlZH/8 5PcHFYIoSlUHmpukL5tZGKytHFdtG2y39INQaVCZeaHKHLH2roYU10fDiChdFBQIJlOI 3APbg/m8T+55mfJM0L+xoRTpSMM1wi0I6LCb5uFdf1I2YHKPnJhDqbn7RA1vStfMJsq3 HomfpjbzPTxgEd8AqNf/gQ9lZuTXjoY2VYiFEr1cCgIWX4/qmPPl9m2aT0qmMl/VMMS1 6YlM9FdMd4NVlpJNAdneIDmTVSKptvW+AVPfCma49x7mmznKxJBfxPIEG6UtXn7VIHm5 v+XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=gTEqmAASkHZHNE4oMuHvY6RYvvJvsYbcuMrYWqfl3p4=; fh=dCDQazI1Z4ePjNfIkBK53loLrbIABDe64reaCyzziN8=; b=FHrCwrMWj/sks5LnWW00ob+eaEX7C551k1SGGLQxGbM8wAq3HYU+d56B+55N9rZDqZ +QdW4Ll/G+qgLb/aU9nkLNpFXMRwP6dnXJgW8b8yi3Hx39Gy344ZfvmQEO9brZgjBpF6 wqVoblHbHDsb71ppBu+6bkx+L9wKgkefx9uGiADOXwLLLnFZE+w2GdV4ylvVt2KKDl6u PT8oy1QOg87iqpwc88d6JH4YaBagNKwTf0qwobbpjGTeK8CmU0wuQtAZqPwRwpUpthkn J7AAVwLmEnbEDJes5TdN3cTgPhltkeyZ8qUrlmdfpq/PrqbfWzftHDzsici4cEayEWcR 90wA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r4-20020aa7cb84000000b0051df7c90301si4990579edt.684.2023.07.17.01.40.11; Mon, 17 Jul 2023 01:40:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230178AbjGQHuF (ORCPT + 99 others); Mon, 17 Jul 2023 03:50:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231139AbjGQHtz (ORCPT ); Mon, 17 Jul 2023 03:49:55 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CFE00E4E for ; Mon, 17 Jul 2023 00:49:51 -0700 (PDT) Received: from moin.white.stw.pengutronix.de ([2a0a:edc0:0:b01:1d::7b] helo=bjornoya.blackshift.org) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qLIzA-0006dj-I5; Mon, 17 Jul 2023 09:49:36 +0200 Received: from pengutronix.de (unknown [172.20.34.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mkl-all@blackshift.org) by smtp.blackshift.org (Postfix) with ESMTPSA id 7CB481F310E; Mon, 17 Jul 2023 07:49:30 +0000 (UTC) Date: Mon, 17 Jul 2023 09:49:29 +0200 From: Marc Kleine-Budde To: Michal Sojka Cc: Maxime Jayat , Oliver Hartkopp , linux-can@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Dae R. Jeong" , Hillf Danton Subject: Re: can: isotp: epoll breaks isotp_sendmsg Message-ID: <20230717-disbelief-catalyst-bcff471e0433-mkl@pengutronix.de> References: <11328958-453f-447f-9af8-3b5824dfb041@munic.io> <87cz1czihl.fsf@steelpick.2x.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mfssbwpjvgohqem3" Content-Disposition: inline In-Reply-To: <87cz1czihl.fsf@steelpick.2x.cz> X-SA-Exim-Connect-IP: 2a0a:edc0:0:b01:1d::7b X-SA-Exim-Mail-From: mkl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --mfssbwpjvgohqem3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 01.07.2023 00:35:18, Michal Sojka wrote: > Hi Maxime, >=20 > 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=20 > > 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. >=20 > That's definitely not expected behavior. I tested the patch only with > poll, hoping that epoll would behave the same. >=20 > [...] >=20 > > > > By reverting 79e19fa79c, I get better results but still incorrect: >=20 > [...] >=20 > > 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. >=20 > Yes, incorrect behavior was why we made the commit in question, however > we saw write() returning -EAGAIN when it shouldn't. >=20 > > I don't know how to solve the problem. To me, using wq_has_sleeper seem= s=20 > > weird. >=20 > Agreed. I've never tried to understand how synchronization works here. > Hopefully, Oliver knows more. >=20 > > The implementation of isotp_poll feels weird too (calling both=20 > > datagram_poll and > > poll_wait?). But I am not sure what would be the correct > > implementation. >=20 > 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. >=20 > > My actual use-case is in Async Rust using tokio. >=20 > 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. >=20 > I'll try to look at this in more detail during the weekend. It's too > late for me today. Any progress on this issue? Marc --=20 Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung N=C3=BCrnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 | --mfssbwpjvgohqem3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEDs2BvajyNKlf9TJQvlAcSiqKBOgFAmS08oYACgkQvlAcSiqK BOhHswf/SZj4m2DVNOkl8OLWL+ZJXTBoXd/S2pg2MLr7/+pO98wd8wbmGN5Kn6T9 cToBbnCaa6TEHzCROw0uQDM8BwoWxwPlcfaKpEFKdze1grV+lMYcSVI1nlaM19xR es+jWh45mQnxhPjjDDNHowucfA7z+ivXYo46yf3LJsYVSfznf+/LIwlvKU4PMz0d Vzwxar8/aStqGF1+i3vLNDnP99JwG2U3EqmjLGer80tP+n0qetxbuHkdShq05GpJ 4e5KS8/yXxvXgEJM1LNlhNh4W5oig+qivhE1pPIDAOt6fv4iptWjF3FEEMHsHdzC x6fxKMIscbIL+6KmBwSt+7kz9iMoTA== =uF3O -----END PGP SIGNATURE----- --mfssbwpjvgohqem3--