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 4C5BF357D19 for ; Tue, 12 May 2026 07:20:08 +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=1778570412; cv=none; b=tLYlP/+MpvMKpj5WdarLgk0vAFl5LjVqjpZN85kV/V7Lf9LWFPNjpo2hH41nrZIrNSSDIZ4rNabLWqZIbNaiockDE0lwYPZvSLu5xkNPawot7dGpN3sU78Qfsv11zPlzJWuZRmTF26uoJBrEUzCjYj2imWobisDbkzt5B/UP3k4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778570412; c=relaxed/simple; bh=C9nOtZphHGvpRbbB1mh095pYAR4HXW7ByitF0l7nAq0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Zu11cTk09ZLA/rSUMDYdUMHjBTEGlEvZCB5M2Xr1Z61qbgBe+vjF1dUtsa2Vto7Wea8r2p1qrezILyvPHmIcWjVbAwU+qq09/xW0zxAv+gwAhl4oZqpLXnn7xjRSIIUWQNpDqvEOOuPCrACaw6ASq13pm0Yt7IKnDpA8H3XjcQI= 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=aw5Nl7+2; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=cP9wZRSx; 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="aw5Nl7+2"; 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=1778570407; 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=aw5Nl7+2P3MXHKR3s7SnqjrL2HCywvqt0M2dYeHvuUkEuIaHIztWnUBu5bhPMcn2j6jYEO tUxE3OKxj3avxk+KvykI0vGsi9tfs7LP8AExsdGFgEBV80DazgIf7lKQdX4KYEDvrJGE15 h7KsQ/NjfLARGyQzZgehMPliAxmrTnE= 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-336-jqm1IG-TPt2i8qvlC7D-9A-1; Tue, 12 May 2026 03:20:05 -0400 X-MC-Unique: jqm1IG-TPt2i8qvlC7D-9A-1 X-Mimecast-MFC-AGG-ID: jqm1IG-TPt2i8qvlC7D-9A_1778570404 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-488bd1ee9e7so56931975e9.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=ncsMiJJIw/D0/FwibBggKAMc1QU990PAbrXfEzagKVsvYXJsJZJ9sIfNi7mkTVEydA ByT8Ozf8WafXrWpH6+ouvSNSyCRu95LLnfRffUKuH8Va+3qatghAzfOhkBhgSzPg3L7r g1jspY/ZW/t8a4pODzWUgvKjbmAkwYk2U5q6CmpKGEUFowIJ+cBnZAgvdF/KRLkS9pDj 9itnz+1bdjDorNQSiw3I3OcjJqZxjE2rftwyNpDe/QaHg/m1MYNlQMoqJmh9eW9tPsNZ nrYWe2KRS9Q5oRFJZf228lcyp3K5wDiOAS1C5nKM4f0M2H8FQxsQCd0Rqn8F+O0PMoCI FVXg== X-Forwarded-Encrypted: i=1; AFNElJ9dlk3NSioVzrMXssOjutH7WxwQ2nCNrF9E/bXP0P03mi+4MVJdo5ypQF3NjsWa0mygMvW6IvBghdTS5hA=@vger.kernel.org X-Gm-Message-State: AOJu0YxtgpqhiC+vZHHZ5NCmVHbcEHZ8C7oPU+NcxkHSZ9DWgN3XGxwC m1NbvYCehJWQLPQAUTXyBBW+BB6+nLnpX+2T69BHr6ylZv7swEp1hUtp1yiW5aosRifWnOckTNi 2VLzsm3498RP7s+vkfBPpZnSjWSCEDKsKjkIvxGR38ponpoTEr3+xAD8p5bCOhVjtaw== X-Gm-Gg: Acq92OGKOO3TYI1PQlt1k/XrY1Y9pBIKaEX5eOF7eZfUAegqbg4+b2I39b1Pqx0X3ye L03xuGGUkHjESvN8YVyAUGYt14BoU58zxe3LknJ+y9ISbXa2SusEQ2BBmn1GmPjPG4hTGj3pswD btelEIVHp/tstIifOLA8vuWDJA5m1ikc5AFxlt0CVHydzz5vkWTdf1/blJxdJUWcwbBWRyaDrTR CJyHSYB39PEw0pFm/tNt+ONM/nQxkC6H+l/TwoEhwNrGUOVp/KGkJp0WH1ZZD8SgUk+FAa8PbGI fCdfVj5pWOfJShLELgrMf7AzD024Z5YoTeG218JP4ujzy5a5kcLc2USSdUaJfUGp3nf8CO1czM7 /A0GgJpQnV6d5dMhgocTGbHf5Y5kHqBwiUPo9euUmVsuBTV56ahFi2ROlSgbpLI8zZhD0t4PiVg == X-Received: by 2002:a05:600c:3ba8:b0:48a:97b6:7420 with SMTP id 5b1f17b1804b1-48e707fbac7mr215488945e9.24.1778570403941; 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: linux-kernel@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