From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E06B3F788D for ; Mon, 25 May 2026 17:14:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779729285; cv=none; b=BLBN+l5I7f5nRcGfC4jiG7ptabUM4XD5hWKN+N0I1Qa1h7nmjRSeV51DwOR25lT1CuB1vjUucKyHPGkSmKQ3b+kFEDC2LDqG2gi5SLRoMyWbArkk0b3537Qcb0tQEk9nUXDRaNAxrYu40rWZaFku2uLBQRBrAcDDpl4lyM0hwns= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779729285; c=relaxed/simple; bh=2sV4pz6YR0OYuF0/R7iMTf2Mnfa/i7KDjcdfesmU1nU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Y2YaWVzr57Qu0nnO0hVVH030E6Z0r73lltGn7SGoVomElyPqAC12REHV02NiLpjcLUIG0Q2lUnHSXaBt0rV47UKTYSj9SKYDlZnlbPUEYOMLozTgDNY/RbsKygHasM2Jqug+eaZ949Mq/ar9rt6VhWMMlbdnDOGo38WVDTSYCTw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rBKKHIJq; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rBKKHIJq" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-444826c16ffso8342380f8f.1 for ; Mon, 25 May 2026 10:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779729282; x=1780334082; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=yBpakHiyp2Ixi6ETxg8xxyuYG4nYq7ywoAzoB8P6KoU=; b=rBKKHIJqBeVByHkP4pPb8OpYiOdtN++0V/VhA8o14xzAwl3DDAuoxgkRZs3FE1m/th 394zKqYgB6xVOb/knFqxgajG/u9rwCs9CjYBd+hxjood2wTexs+X7hi+/syZjnqL2XzU JYh74o/GXTcH4OKGPr+eU2KjpdRCQ97wA5OaQbiT+LHa9dnbdd9EpcfKkEa4T5MZGZQA yuqwWB1d3ldlYBaCsI20Fji3Ta1XLXsdxDQ3c2OLBu7K6A3LDv9kTcaSso/rE146RVbW 0Uoo0e12ay/14kljA/zeU02gMsVQkzSr7DumHcZfVgqpTQG5hcA6quY/Lf/VYTKKfhJK npgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779729282; x=1780334082; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=yBpakHiyp2Ixi6ETxg8xxyuYG4nYq7ywoAzoB8P6KoU=; b=OgNoHvDMmhR7F43NmSFveHI5RNK2JfEBI50ovEAkSEJ7GOLUcOirQDMmCJMTiX3huG n1oMd73uYe2wWsKZMwFzZwDPfijji4VjnvOP+DVgIqqBkwk05eTSeoKT604uDmUu6uhy EG9qv/JHqZhUu/40kdqClSZppNcZOIoIGzwpvAH0HWFSPehMRwfzEwZAGvVYzJUDdIdv cBd04x6oEUtmiyogmzCnOBrPbCO2La+bai8j5BNprCbkwTlTtdmjw30Cx5cHfnqwMNuT boQ2KgEaGpVT3jIjuRqu1SVMro2/z3CYxSQY5JRdb4n8GhFz7ijywu/tvwZOdK+n+jf1 0XjA== X-Forwarded-Encrypted: i=1; AFNElJ8d511bNomfB6SWUHR8mjs5Cri5N2purm1tU0t/NviPaQPrDGncBBo5N+tDUaNhdcxGVwGbzdOCOlSbnYw=@vger.kernel.org X-Gm-Message-State: AOJu0YwwD8FNZo+cDgBQ2XtO9VL1MmXrxdy1UXbr8AIrPjhbeGOeMapu BdhJK7S4H8tr6Zh5Kbr7FcS783UX0YKNjuwC1jWNMDSlF8vKLGLDTkB7 X-Gm-Gg: Acq92OEnPzm/OuVMCHrnkinne2KXAWY8Ra1m4OnRZIT5HZ0ffpNH3K+XWpPPtQ3RjXI p1FlOdhfSFPTmhpE82bqTzuVqd3IJ/yf9Pw4QyqcuJ2PhgNk8Wgw69p7hGqICeiGNmq2eYS0CCe SrxrozTjPRlKQbkjN0iWzPmPrmakpvpHWqOPoqZ9TNsMUwyvQopLeesJojpfT6g5WhayO3Myf6y txdb2wBIe9p+cYNKtX8mzWgLBKo8Dg+bJmssTYXUwI84aa90wNWC+oD65NBzaDBWgNfSRKzDDnH iH16NpG0hvGQlgG2nKFrl9velvww4cEUn6n3Ta1A9PQfTHwdFrWOlkXLFVuGMxAIPWBsgAKDpZa jyaaNThUDl935aHMEKGk6NAp1hkAkMMd1TYiqGHsXQLkncl84AUUDqcwCeGmnFsJMmmSbvb0y7K jlmqlK+cGHqvlfyBfhRzPXz+dO0epTFYwUfi/yAFujonR/40R0c38x/JrcCmeyN0e2 X-Received: by 2002:a05:6000:4606:b0:45e:8727:be87 with SMTP id ffacd0b85a97d-45eb36aa72amr24711421f8f.15.1779729282272; Mon, 25 May 2026 10:14:42 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45eb6d7167dsm28840763f8f.35.2026.05.25.10.14.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2026 10:14:41 -0700 (PDT) Date: Mon, 25 May 2026 18:14:40 +0100 From: David Laight To: Stefano Garzarella Cc: "Michael S. Tsirkin" , patchwork-bot+netdevbpf@kernel.org, netdev@vger.kernel.org, xuanzhuo@linux.alibaba.com, horms@kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kuba@kernel.org, eperezma@redhat.com, pabeni@redhat.com, davem@davemloft.net, jasowang@redhat.com, stefanha@redhat.com, edumazet@google.com, stable@vger.kernel.org Subject: Re: [PATCH net] vsock/virtio: fix skb overhead overflow on 32-bit builds Message-ID: <20260525181440.5a6cdb43@pumpkin> In-Reply-To: References: <20260521124732.125771-1-sgarzare@redhat.com> <177950282964.1445071.6600517211632117224.git-patchwork-notify@kernel.org> <20260523173557.5cc4f4f6@pumpkin> <20260525115314.3cf310e6@pumpkin> <20260525083859-mutt-send-email-mst@kernel.org> <20260525155322.240fbd87@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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 Content-Transfer-Encoding: 7bit On Mon, 25 May 2026 17:16:18 +0200 Stefano Garzarella wrote: > On Mon, May 25, 2026 at 03:53:22PM +0100, David Laight wrote: > >On Mon, 25 May 2026 15:09:54 +0200 > >Stefano Garzarella wrote: ... > >> >Indeed, I wasn't thinking. For this to even get close to overflowing > >> >we'd have to have almost all of 4G available to the 32 bit kernel taken > >> >up by this single queue. > > > >Except there is usually only 1G or 2G available to the kernel. > >And all the skb would have to contain no data. > > `skb_overhead` was introduced to prevent exactly queueing skb without > any data (essentially containing just the EOM for SEQPACKET) that we > plan to fix properly in some other way instead of queueing empty skb. I think most of the network code counts skb->truesize so that it limits kernel memory on the queue rather than the amount of data. This does rather rely on the low level code setting it to a sane value. Last time I looked some of the usbnet drivers lied badly. (IIRC short packets in a 64k buffer with the truesize set to the data length.) You need to do something to limit the number of single (or even zero) byte SEQPACKET messages that can be queued. -- David