From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A1BE48EBE9 for ; Wed, 29 Jul 2026 13:30:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785331836; cv=none; b=HD2i//I9a6ZUj4oN0u1uf4Jo84fVYcI1RogICKUIeWI01i7RTOhW9k1tDiOpLvk1ABnGDE9tBl7L7iOLqXyx2Xvm6pnOGgIudtsTBcVBcWjPA3DbQ+JcE0UqF7qdnM+1yn/xTaG7Z5nQz8iiMT6hcB743btujj4fPucJiyro+rI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785331836; c=relaxed/simple; bh=x22GjEt7cSW637vYD40FSL+sH3AfZF5w9reTRHSznvM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l3jPQq08yy7BrHzyRpSJgBRdAV98HpSRkmDbnJUjesmVKSH1BInptTHMYs9m9BCCKerZrUu00Iaudzm8AxVm8VtefrgW5ZEifAWBSIxQSgvzSk6p90b3yVVmD2id90Xlu/VTGcSZ29Q1ZkCgUgRDmOZGWvfzGkplmfa8JiyfD/0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=DPV/3Rh2; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Kh7+B2k8; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DPV/3Rh2"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Kh7+B2k8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785331825; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0L1AfMh9DvsxqBN6xA7q5Kc35M/kq0HbrYUCNpZ7Miw=; b=DPV/3Rh2wi3RXzAIqZJSlcsAWeQiOauE/B9oIJNVs7I+3fr0dpIv72s+vNSfTqc0EES+Lp ANZTrHbxPAq8iXryXqFGOVX/78nzUIbYyOm1gEr7n/IhkZte4lfv/aBB5yyueNFFkVP4Y6 lokAeI6IZly/wmfTAes5SetBEWFhsD0= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-316-dAzLY_ZMMZOopABF_WVoiw-1; Wed, 29 Jul 2026 09:30:20 -0400 X-MC-Unique: dAzLY_ZMMZOopABF_WVoiw-1 X-Mimecast-MFC-AGG-ID: dAzLY_ZMMZOopABF_WVoiw_1785331817 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-49561facb1dso6997495e9.3 for ; Wed, 29 Jul 2026 06:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1785331817; x=1785936617; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=0L1AfMh9DvsxqBN6xA7q5Kc35M/kq0HbrYUCNpZ7Miw=; b=Kh7+B2k8ILNzxDBAn5b9z8hl2eX2CUX+tls4p4Hwn4tybEHjcyG7++KPiPoeCOJIBg EdYuIBRpmjKssmEwpbYx3D+qiWtP5hsakHl0otFaEYCttbWY3+b0Ebdir8wpsd6gMCV8 CejvJ56Jv5k6uOxuz9q9lpNesEI/a9QZHpWg5WeT4SkgNue9l7ijg7B9im5P5RNHnZMB ZhIh33VdlJ1ihLgIE9M1GwrvuZPKiFoUshFNkF3HFeMcMxAyz4Z5OYsxYiI5QQCicXaa SGg9Rq0+h4mXTSyTgyzLzrrmA1Qwkp2CKik8p0dpq+Odt2VGhLNMien19bZKLzqPbuj3 D1lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785331817; x=1785936617; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0L1AfMh9DvsxqBN6xA7q5Kc35M/kq0HbrYUCNpZ7Miw=; b=l/gumDYP34hej5ZSoVRGAY188ZQhmMNYlexHmyYuvtLPg07PBsoWrTbnio4L8qkUp/ zDehfxCGyWOxABwhe05MRRVFEvOuhnWTluFe95bKxYNPBZp8PkL2ohZY8btgh3elwFTH OaJXBt13U17VX/VWnCCbZb+DfMedLtFd5ZD5uEW16VDtcSuTJAwEQN2rld0K0ZwOTAt6 Uute3aJhin46ojotrCuTDPfGpxswXnUz99PyUWUaoDex05agtSIww4TWHyZ/XE9qnMYR l7/E+vDg2hW2eAJ9I60loPmfESZwmNA+rEdQErF13ST1sb+94OeV6fF6j7PxUo9Hiy2b uZ4Q== X-Forwarded-Encrypted: i=1; AHgh+Rq9q1J09bZkX5d4mHuX+YLDbENmyttwmoy5F0MdBiO3QXGKkzkhhWQNCGsU54EbQUKP5M+B9Ry/xX05Sfk=@vger.kernel.org X-Gm-Message-State: AOJu0YyVdt/jvgiG3DX9uhc79m3IJIetGUTRtkSslwZsLYlmi5BGz3Jb Fdvm/nLHTBwkPcXGBMRmTKO7dtPxYa3QYosNMpJr5FCh41pZqh6l/zSiY9k0G3oCLOIktmf3/sx w7G49IEQ8lwlUUCmpo4jB5sV/NL77YY/+HEp3Bykpekebc4xMGZmrBvdy3rceyX7A7Q== X-Gm-Gg: AR+sD13EihYdwBBdi9ccwgz2LQzqMuAEyz5Ny5MtvSf/Wtdq0HMudOo+1uVXW6wKU8q DiJA26OYAModkoe/OcSB+3e1U3KaB3J/HCATkBFx3L2Fr72x7jbcoiCvXXzLOKPohXPX9uwhdr3 nM+WWYuNF03NhD7ALQfzWqhb4ItwE2QDKQOu5n66Qz0ODbR4mKK/x8Y+achrRUtqo9JuaKRtJnc ntssGEus2Ab8k086h7wTiZdsbGAPD4ul0DxEuAWJyMScKm//V6tEv5p7LZz9nyoPD9ldgVuUz4i d5UNc1QLBTWRfluuBSvLoSfLcmS7k0MJwoRlpbW5ZAevIeqlLeI53cDH5rdp9wCETNNlD7VvaIT Zk4MzhxrNRXLi9l1UfbWS+f0bapSpw8VibdQO3aUBhS0= X-Received: by 2002:a05:600c:4eca:b0:495:7379:17b1 with SMTP id 5b1f17b1804b1-496c6585036mr74945785e9.30.1785331817208; Wed, 29 Jul 2026 06:30:17 -0700 (PDT) X-Received: by 2002:a05:600c:4eca:b0:495:7379:17b1 with SMTP id 5b1f17b1804b1-496c6585036mr74945125e9.30.1785331816437; Wed, 29 Jul 2026 06:30:16 -0700 (PDT) Received: from sgarzare-redhat (ip139-137-192-82.pool-bba.aruba.it. [82.192.137.139]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fb6b0ef48sm7507460f8f.21.2026.07.29.06.30.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 06:30:15 -0700 (PDT) Date: Wed, 29 Jul 2026 15:29:59 +0200 From: Stefano Garzarella To: Michal Luczaj Cc: "Nguyen Dinh Phi [SG]" , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com, virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] vsock: use sock_error() to consume sk_err after connect timeout Message-ID: References: <95cd0d4e-58c9-44ab-b94f-fcf57b88583b@rbox.co> <27412e44-ab4b-4dd3-9685-481875683860@gmail.com> <6b684c2f-1f98-43ea-84c9-9b6f162d5e9f@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: On Wed, Jul 29, 2026 at 03:20:38PM +0200, Michal Luczaj wrote: >On 7/29/26 15:03, Stefano Garzarella wrote: >> On Wed, Jul 29, 2026 at 05:46:29PM +0800, Nguyen Dinh Phi [SG] wrote: >>> On 28/7/26 16:21, Stefano Garzarella wrote: >>>> On Fri, Jul 24, 2026 at 03:34:23PM +0800, Nguyen Dinh Phi [SG] wrote: >>>>> On 24/7/26 05:43, Michal Luczaj wrote: >>>>>> On 7/23/26 12:26, Nguyen Dinh Phi [SG] wrote: >>>>>>>>>>> ... >>>>>>>>>>> Yeah, we need to handle that part better, I think it's >>>>>>>>>>> a leftover when >>>>>>>>>>> we generalized AF_VSOCK to support more transport than vmci. >>>>>>>>> >>>>>>>>> Speaking of leftovers, I have trouble understanding where >>>>>>>>> does vsock set >>>>>>>>> sk_err on listener sockets anyway. If it doesn't, why vsock_accept() >>>>>>>>> checks for it? >>>>>>>> >>>>>>>> I can't also see where it can be set TBH. Should we remove it ? >>>>>>> >>>>>>> I couldn't find it for listener side too. >>>>>> >>>>>> Removing sk_err handling from vsock_accept() solves the problem, right? >>>>>> >>>>>> thanks, >>>>>> Michal >>>>> >>>>> Yes, confirmed, removing sk_err checks from vsock_accept() does >>>>> solve the problem. >>>> >>>> Okay, so maybe better on going on this direction. WDYT? >>>> >>>> Stefano >>>> >>> >>> I'm still a bit concerned about how connect() and poll() interact >>> here, even with the sk_err checks removed from vsock_accept(). >>> >>> For example: >>> vsock_accept() now lets us reuse a socket whose connect() failed (call >>> it r0) as syzbot reproducer does. After listen(), r0 becomes a >>> listener (sk_state == TCP_LISTEN) and works correctly -- it accepts >>> connections. >>> >>> But poll() on r0 still marks POLLERR, even though there is no error on >>> that socket at that point. >>> >>> As I understand it, sk_err holds an error that has not yet been >>> reported to userspace. In the blocking vsock_connect() case we have >>> already read that error and returned it to the caller, so it is no >>> longer pending >>> Shouldn't sk_err be consumed/cleared when vsock_connect() returns it >>> to userspace? >> >> Yeah, makes sense to me, I'll ack the v2. >> @Michal WDYT? > >I'm worried this patch does not address the non-blocking connect() case. >Could vsock_connect_timeout() set `sk->sk_err = ETIMEDOUT` after connect() >returns? This is a good point! So we still need to remove `sk_err` check in vsock_accept(), or set `sk->sk_err = 0` in vsock_listen() to have a complete fix, right? Thanks, Stefano