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.129.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 9EBDB3C454E for ; Tue, 12 May 2026 07:20:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778570411; cv=none; b=B7djGDaBCmCYfmqE7Y+I2ht/sscDq5jR4qOiCEBQuYmMEiRC8lZS3DbfwDjGsU6mWMfRVOqZ5ZyNLpGWhnvcCMk9PBZYTrmAeG5N5azp1guC2D2rfF9bhrXH6hSfWUNxV5A+5c2bNnOLUqsOGtXjHmDpmib027GO8ZQtyycx1VA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778570411; c=relaxed/simple; bh=C9nOtZphHGvpRbbB1mh095pYAR4HXW7ByitF0l7nAq0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QqoGOPgOHMpegCCLuWuWlfSj+EaiSQ6lWOtuvlLaNOCi5y9TL6lYkWu3lCIa/5CqOhscefUxW3AEPKOzLcTDaOReW2IfxJSfQuzyduyP0sKUtSqxiprZ3NAQoKITq5xdTYpGMrshyGbiWVUws/+ZHEHLrohWqMVIdpLyjuNUEvc= 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=a/qLRcRr; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=cP9wZRSx; arc=none smtp.client-ip=170.10.129.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="a/qLRcRr"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="cP9wZRSx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778570406; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QjTia8hEEWTMEUzJIZRRaWOPCFQqnc9xnPKI05ARaEw=; b=a/qLRcRrpV7bC6S1euMGgPpBYOi/lVZ3WoGPZefAZ5arSzWMlsi/v9pIopdBvpcRqqOsTP TazwQYW0Act/DJuN4vxWi4FXbT/tYIXvZHaha03usQakdu6yE0SPyIhAvEiO/yKfOUeNSy BeL0j7jroPSe/yLV0hVlv6meuGDacrk= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-271-Hp5YI3PEPyyOVjbGfjIeXw-1; Tue, 12 May 2026 03:20:05 -0400 X-MC-Unique: Hp5YI3PEPyyOVjbGfjIeXw-1 X-Mimecast-MFC-AGG-ID: Hp5YI3PEPyyOVjbGfjIeXw_1778570404 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-488bd1ee9e7so56932015e9.1 for ; Tue, 12 May 2026 00:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1778570404; x=1779175204; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=QjTia8hEEWTMEUzJIZRRaWOPCFQqnc9xnPKI05ARaEw=; b=cP9wZRSxRq8qvPmqlHHwVZQSEVFNWuYPiFxG6iNVSMEjb1K27TVa5fm4HpT3pZASoc GLh8Zb3BOB3M7ty4wevx8EJ2pZIfeHEuKy+w+I37/JGJw4hbNmei+W6YmIkJOo8pPKGJ y2M/xhsDhCihHUE7hWw/jqofFw4JrOhl6oPyM5pxDVR7ubSsj4cf7l2eRJniry9k8juT GSIxRBFFmMXFMmnGdMVYQsUltfpo3xLlt8jmQZkv+rtkMboXg2TxwiVLO8TvzpV2EYM6 mWlFOGJ5vyavE1lUAWs20qj4RQnAJPm3Mj/vpswFkuFjsXSCvd4iIvVIS1JT1rlkfeOX Zygw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778570404; x=1779175204; h=in-reply-to:content-transfer-encoding:content-disposition :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; bh=QjTia8hEEWTMEUzJIZRRaWOPCFQqnc9xnPKI05ARaEw=; b=GEPAuHgPYy1fTFTKz/axROuxXuCsy/T0QMD2CBlaTmJ1c+zAKhZh6sXlw3zKgDX7QE RaYOwEyrQheF9KD57F4QLSTV88W6ULLlrRSUDHMYuv/dP/Ms+3gOkl3T/X9FgkZEcuT3 IQo0Ta77plz9WRGs85ChR5FbL0txLuISvf2SIvHzjUqL6G+Fe3U3PDMQd1WqPhkX4APy 0vrJh4sk3npl4l4TCgeFsUg42K5+Rs8XngIRF1t/0Tawa1iXabOxB36NOrUKCwTokc8w b6XuKCvrE7RlOOzoO1LMM478sCRQALovlrfNf/tisdXjWKOmlBHj2fw4kSM/bikm745e vYdw== X-Forwarded-Encrypted: i=1; AFNElJ+BI3GZEZ3EB3cvt1niGx1J8rVx3+RZbUUmHJQqBeUy5o7cvBuyQ+oRRNzKuI01bH9vfrg=@vger.kernel.org X-Gm-Message-State: AOJu0Ywf/RZ421ELpJ2u1x8hbUps/lKrEOjqn4nSTNjtKUbcAbcfXERF /s0mYVK3uvzorKwjIE25yslzxE1q+gdO+FyETslEhaSx3YrO91Li1Ty0LuAugbid+Zp7fZ5Rw1b Vu+PhEYAEfrx1p6SCZUAVqLLejIJHxNecnQ/tNL0/BQGUNh4XtFUWcg== X-Gm-Gg: Acq92OHJtf/bMV5P+tX5Sa8qJQjmFFXoRjEzARSitYn3zjctXO3SjMa5zaWwxE1xr5m 1sSQsngm80fXJjNyOGs11drzig7Mbv743tYRnt6VItY+0YlCI3HZOYr1vedZuGWHv3p4DjrvQVI o+jVdHyc3lfhcoATg2kIKUSFYZlUrCvLAoFm4yNB+mRnky18QE5Mcx5a/Uqo/LfNYBOjJnODHV1 6mSjEox0/0Bzma5sUQAARhlV9S/eorxS0KwL94Y/yn2rHWPEOcZ3t7LHJ+nWWcS4ZK2QEqZZge9 qx9bGkjE11OQmPG4alfx8m9DtGGZdTsEfB80iUkJPmxfNN8qhgJGBbYWoSDP3ySvtCLvWMHKvOP uoRFgls7ZZKb3L1e5gWuQyqzg/99dzYj9VNN0Y6awSEvNALK80pCEUTKnpkEIQixujtnUuQDIuw == X-Received: by 2002:a05:600c:3ba8:b0:48a:97b6:7420 with SMTP id 5b1f17b1804b1-48e707fbac7mr215489035e9.24.1778570403954; Tue, 12 May 2026 00:20:03 -0700 (PDT) X-Received: by 2002:a05:600c:3ba8:b0:48a:97b6:7420 with SMTP id 5b1f17b1804b1-48e707fbac7mr215488205e9.24.1778570403394; Tue, 12 May 2026 00:20:03 -0700 (PDT) Received: from sgarzare-redhat (host-87-16-204-231.retail.telecomitalia.it. [87.16.204.231]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e906ae8b5sm44119615e9.6.2026.05.12.00.20.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 00:20:02 -0700 (PDT) Date: Tue, 12 May 2026 09:19:58 +0200 From: Stefano Garzarella To: Jakub Kicinski Cc: "Michael S. Tsirkin" , netdev@vger.kernel.org, Eric Dumazet , Stefan Hajnoczi , virtualization@lists.linux.dev, "David S. Miller" , Jason Wang , Simon Horman , linux-kernel@vger.kernel.org, Paolo Abeni , Xuan Zhuo , kvm@vger.kernel.org, Eugenio =?utf-8?B?UMOpcmV6?= Subject: Re: [PATCH net] vsock/virtio: fix skb overhead accounting to preserve full buf_alloc Message-ID: References: <20260508092330.69690-1-sgarzare@redhat.com> <20260508055125-mutt-send-email-mst@kernel.org> <20260508063104-mutt-send-email-mst@kernel.org> <20260511084551-mutt-send-email-mst@kernel.org> <20260511164841.7f7ff557@kernel.org> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260511164841.7f7ff557@kernel.org> On Mon, May 11, 2026 at 04:48:41PM -0700, Jakub Kicinski wrote: >On Mon, 11 May 2026 15:17:56 +0200 Stefano Garzarella wrote: >> > > Okay, I thought it over over the weekend, and I agree that this patch >> > > still doesn't solve the problem and would still result in packet loss. >> > > So, until we resolve the issue permanently, and since 059b7dbd20a6 is >> > > coming to stable, I'd like to rework this patch so that we only start >> > > dropping packets when the overhead plus the queued bytes exceeds >> > > `buf_alloc * 2`. >> > > Removing the other changes to reduce the buf_alloc advertised, but >> > > terminating the connection so that both peers are aware that something >> > > went wrong. >> > > >> > > Any objections? >> > > >> > > Stefano >> > >> > Let's try to first fix it upstream properly please. Discuss backporting >> > later. >> >> Commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb >> queue") is already in Linus tree and will land soon on stable. Which >> issue do you see on having a patch on top of that to close the >> connection instead of losing data and breaking our test suite? >> >> IMO we need that change in any case, because the previous code also >> discarded packets without any notification, whereas breaking the >> connection would be better in that case. > >Sorry if I'm speaking out of turn or misunderstanding but, like Michael >says, let's focus on fixing this the way we want it to be fixed? IMHO, these are two separate issues (related but still separated): 1. taking overhead into account and setting a limit (which Eric started doing in 059b7dbd20a6) 2. reducing overhead by also merging SEQPACKET as Michael proposed (we already do this for STREAM). Even with option 2, the overhead won’t disappear, and we should maintain a limit as Eric rightly pointed out, especially since the initial problem was a flood of EOMs with 0 or 1 bytes, which option 2 doesn’t solve, since the overhead will eventually explode. So I agree that we should implement 2 as Michael proposed, but I think we also need to fix 1 by improving it slightly (as I’ve tried here, and would like to do in v2). Since I have v2 ready and tested, I'll send it because I think we should have it in any case, even with option 2 implemented. >IIUC you are trying to minimize the size of the fix, please don't worry >about the LoC in the diff at this stage. > Okay, I'll try to work on it, but this week is a nightmare. I hope to come up with something by building on Michael's idea. Thanks, Stefano