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 0910B38228C for ; Fri, 8 May 2026 10:11:53 +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=1778235115; cv=none; b=hd5UkbKwacVqLugQrLif2ckQrdQnV1L+07iErqy9vxp13AFvZ7/U+SE0z7NAUUNWWp8k8At4xkBqYHLCsfvG779OReuE6jxoxQmd6xz0W3AH0JpHZ1YfIe//oneeZ5vBOxjMmoMzqjxHYts8FXcg/7IF8J+55KMOVxKqs1Tysac= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778235115; c=relaxed/simple; bh=5elEoYj/5z4XlNxRebDQfE/NWKivBbNLq4gq+S9kA1U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lb93liwXxNLvH7DmNDLLuuhrCgQWGKyK1HR/ZNIjiRrEQ0JbN1oOGANGkOFdorKxpffNo6hgCX2hhXbyuvkcFRGCzHNhUURzMIv1ekUcORdUr1U/SHyerIeAHUbilxQ3VyXIFMm1eZrPTXrBsR2+L2aTQGT7mD+YRH2calweK5w= 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=VRm+9gbc; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=eAT+xl3a; 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="VRm+9gbc"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="eAT+xl3a" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778235113; 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=fa/C2+f55nR6HMXUZTO/HqGU3IIvZs20T/G6LNckFSc=; b=VRm+9gbcXIUXq3vz5pKOaTFeoKDPGYPqelNiF26r/ZbiJxF7efx99GdB4GPGdiI9B3Xy31 5QknXi3PawUe6CPeuO9R0+IeJLX8XIagGjEkdgXZSaBIAkJDNPdBRXrq7uqSlKLbh5eU9a HEYQTgEwBC8derAvX/vS28WdZa9hc8w= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-286-IH_Qv7jUO-2h2v_3onfmWQ-1; Fri, 08 May 2026 06:11:49 -0400 X-MC-Unique: IH_Qv7jUO-2h2v_3onfmWQ-1 X-Mimecast-MFC-AGG-ID: IH_Qv7jUO-2h2v_3onfmWQ_1778235109 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-44a122a5128so1388724f8f.0 for ; Fri, 08 May 2026 03:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1778235109; x=1778839909; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=fa/C2+f55nR6HMXUZTO/HqGU3IIvZs20T/G6LNckFSc=; b=eAT+xl3auvACwYVDWNQ/a/vXSSWf7cexflo1EFIy+uSrTc8FpxbKEpEqpfuWWVsxxX TdliVyhZCqrZUbhqEf8cbaMOzU12zH9lVg7xk7mypnkmmEfsxHsyZKazvvIWtakdDQ6S Hs0OHJmYjVubr/7tgAkJzZbirMrDj5GyjLvJqzFOigNw5NaID9jreA52fXtjBBATKqAF VzwfU/FMfTu3C76ri+atdwSEYnIIyUUstgc1vGwQQSIy5bbYifTis2bbIMX6nZLR1jT5 8w1VcjX+PvN/dn6RR16FXKDRxWsJa0v0WtN9z+8lHzGW28UcObahfcfTPbYQ8kLxZoHu CTOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778235109; x=1778839909; h=in-reply-to: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=fa/C2+f55nR6HMXUZTO/HqGU3IIvZs20T/G6LNckFSc=; b=RVO9rJPTiszOhRDT18HK5jq4KJOHwVBsb1DDyAw/+Owix+r3FeO8o31IW6czfXrRrK 30N3pWr3F3Y22jAPYRQpxe3zyuMx40zaEau4qAtJfe03hfxgwP9oPvHCZNud2Cq00yPD NHEa6ulxAgsCK7FHDgsTdj75aDHqxe5Xo4TPHreYHtdcbDYAe67mT4Qq6/zXNXnDWwi9 xj8w1NlSvTOrmcb5diP4tTz+rWEx3z3orvuDt1T6qoeiT0HDvKOxdSgx6u7EM53H2YwA 4hLTOzCae/KfkgX/ANsf47wpoRWjPTI/QsHJmJ/1BrXm4R/LaZL+jw3J2Vjei7yWWn25 dWVQ== X-Forwarded-Encrypted: i=1; AFNElJ+IOs0+z5YHAtD91vcCPENqzz61X53uyGAhU5Dji5umocCVha4O7BnjX1SlMpDGhA0KauPHn04=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4JbOmOG6R5rfX/Z3TscQdUbpQZNzAVmowQO8wft+3okq59Hl5 Kir87BESwdosZSzs5syLibWe5Oopn+2Ogz8XfPI87l+UhZ25yULRganm/s9E3OevZz2y6w+VvAA Y5H/bQw88ePKKZczo/K267gA+n0nrXum/LmLJ6SNtDUV+XZv+M4yBhIB6Mg== X-Gm-Gg: AeBDieubPU6o1OdkQvZn22GnuAWZT3mtTfd6u9TKWgl+4MeYU1EKr3e2dNEdMA8+2eG i3/N9SkWFr5Li3TB2N5PRtfU2O/oMEMkHgXS66C/9LYOUCaYEKIcYXROaNHks+zzin5eNkx4jKl nhuKtUQ6D5pTq5hG84EGUeAIzz0jvS3vNao7S1utc1OxUKoXPxKBrWfHdjvOZMdU1EqMarVgIqI oJZCyma4WNdEL+lX8c+zRCjxe42gCGYAHXIaKbPF2kr3bEVP+n/VLmU4UX/D1GvMvA+WOaci+U6 RRzwWv2clFIATqK3r7uQZ5vFmtNPKT7e0HvX88cckzfBL7kV5++Mz9J5zweHCFUN9kDNUN+AZDt OFa0gFsH7POkm78YSFYPRb//qYv1fULkESyVS0+0gSgVh3L+0onCaxLdwzX4wl3c= X-Received: by 2002:a05:600d:8:b0:48a:58ae:993b with SMTP id 5b1f17b1804b1-48e676a4e03mr30602955e9.16.1778235108732; Fri, 08 May 2026 03:11:48 -0700 (PDT) X-Received: by 2002:a05:600d:8:b0:48a:58ae:993b with SMTP id 5b1f17b1804b1-48e676a4e03mr30602315e9.16.1778235108187; Fri, 08 May 2026 03:11:48 -0700 (PDT) Received: from sgarzare-redhat (host-87-11-6-2.retail.telecomitalia.it. [87.11.6.2]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4548e6a6470sm2848938f8f.7.2026.05.08.03.11.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2026 03:11:47 -0700 (PDT) Date: Fri, 8 May 2026 12:11:42 +0200 From: Stefano Garzarella To: "Michael S. Tsirkin" Cc: Eric Dumazet , Arseniy Krasnov , Bobby Eshleman , Stefan Hajnoczi , "David S . Miller" , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org, eric.dumazet@gmail.com, Arseniy Krasnov , Jason Wang , Xuan Zhuo , Eugenio =?utf-8?B?UMOpcmV6?= , kvm@vger.kernel.org, virtualization@lists.linux.dev Subject: Re: [PATCH net] vsock/virtio: fix potential unbounded skb queue Message-ID: References: <20260506113554-mutt-send-email-mst@kernel.org> <20260507074113-mutt-send-email-mst@kernel.org> <20260507163710-mutt-send-email-mst@kernel.org> <20260508055343-mutt-send-email-mst@kernel.org> Precedence: bulk X-Mailing-List: netdev@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: <20260508055343-mutt-send-email-mst@kernel.org> On Fri, May 08, 2026 at 05:58:06AM -0400, Michael S. Tsirkin wrote: >On Fri, May 08, 2026 at 11:41:21AM +0200, Stefano Garzarella wrote: >> On Thu, May 07, 2026 at 06:48:47PM -0400, Michael S. Tsirkin wrote: >> > On Thu, May 07, 2026 at 02:59:13PM +0200, Stefano Garzarella wrote: >> > > On Thu, May 07, 2026 at 07:45:10AM -0400, Michael S. Tsirkin wrote: >> > > > On Thu, May 07, 2026 at 11:09:47AM +0200, Stefano Garzarella wrote: >> >> [...] >> >> > > > > For now, we're already doing something: >> > > > > merging the skuffs if they don't have EOM set. >> > > > >> > > > >> > > > Right that's good. You could go further and merge with EOM too >> > > > if you stick the info about message boundaries somewhere else. >> > > >> > > This adds a lot of complexity IMO, but we can try. >> > > >> > > Do you have something in mind? >> > >> > BER is clearly overkill but here's a POC that claude made for me, >> > just to give u an idea. It's clearly has a ton of issues, >> > for example I dislike how GFP_ATOMIC is handled. >> >> Okay, I somewhat understand, but clearly this isn't net material > >I doubt we have many other options given reverting the regression was >ruled out. As Eric pointed out, we can't revert it. > > >> so for now >> I think the best thing to do is to merge the fixup I sent (or something >> similar): >> https://lore.kernel.org/netdev/20260508092330.69690-1-sgarzare@redhat.com/ > >I reviewed that one, problem is it's a spec violation/change that we'll >have to support forever. I have a few points to make on this, but let's discuss them there. > >> This is a major change that should be merged with more caution. >> Could this have too much of an impact on performance? >> >> Thanks, >> Stefano > >It's really a POC, real patch is left as an excersise for the reader >:). eheh, I see, but honestly, this overcomplication scares me. I'll try to think it over. >The correct approach IMHO is to only start using this >when we wasted a lot of memory on small packets. > >For example, if sum(truesize) >= buf size. > >then we'll not see a perf impact unless it's already pathological. Agree on this, which is similar to what I'm doing in that patch. Reducing the advertised buf_alloc only in pathological cases (e.g. overhead > buf_alloc). Stefano