From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=X3k1Cqeo; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 70F4C5A004E for ; Fri, 15 Nov 2024 12:23:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1731669800; 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=0b6p6l5ODOzskFotJm7WPtX4FzQEb2GiiPRQn7HNIO4=; b=X3k1CqeoyqfxmDvoz3OWKhsTNwTbJ+s+Ah3vu+9AXovjalNU40nnim22ZK/jGtiJixAQdp 622evUI/S/j02xvtRvdUx18f8Ugzxs3XLCZc/K1f+xp6jXb7UWQz/or2pEVRRCm3H/VVb8 nqtbDyH7RjVqUl9V+8N1aWUSU872FJU= 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-568-NwekewNHO7O4hzj2f5ykpQ-1; Fri, 15 Nov 2024 06:23:18 -0500 X-MC-Unique: NwekewNHO7O4hzj2f5ykpQ-1 X-Mimecast-MFC-AGG-ID: NwekewNHO7O4hzj2f5ykpQ Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-3822ecd84b3so41237f8f.3 for ; Fri, 15 Nov 2024 03:23:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731669797; x=1732274597; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0b6p6l5ODOzskFotJm7WPtX4FzQEb2GiiPRQn7HNIO4=; b=TBND31gZAJXCIx0QBRgzQp/4fUpxIlskpOfXhsv1Wq5slSejQA9kUDaoi4vw4tTfDy M8PeBOVkn1D5QQuMGkbXsK1hsPWWUdxsUC4OLQxtNz6Ufz2wUYq0VA01+4UCuDBqerL8 YwrL9rbfO+XROc5OwpGwXom3locfgcdMz23Q0MXIgMMWAeS/1+Tfi8k8klWm97eWZABf Mfpocg368NoMmwz246BtM2W81GX/BWVCHHDIEGIqMHGHtBaQruDHgGcELaTpSYz0cYNF sWgcTxyTRS6vWBNakYlUq3Pl8C8ReeSjgHnXfaGiwYGmqf1InREgkQb0pTRRunylRb3w Kyaw== X-Gm-Message-State: AOJu0Yy2PEI7asEkhSspQsBgejJW+P4Jty56odW/SQfkgig4mlPwOQEz u4Ire33BTkmSHXypSnypBdiUlvMiPE5bIZ0KcFUbrjoR6j6zFsjV1cdwwhX9oBxR/XcHWxBivs5 yOU6rg/3iSCyEdMXLIXkVO7Uoj+N/wqzdtv7M1Pa2YDQJ8a/7imqS2iDtIWLSrg28DIc66c74/8 nFlGeV4d/wRNXIBD9T1jUTHniQHWk9xZmz X-Received: by 2002:a05:6000:1565:b0:37d:38a1:6470 with SMTP id ffacd0b85a97d-38225a91eacmr1662133f8f.46.1731669796799; Fri, 15 Nov 2024 03:23:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IETtbHRHUENKJLnKyGcRg2QBXDTDKjfYAr8DSrsq1iCMsf6hQjM1IuI7eVuDunu12PQnBy3Eg== X-Received: by 2002:a05:6000:1565:b0:37d:38a1:6470 with SMTP id ffacd0b85a97d-38225a91eacmr1662112f8f.46.1731669796388; Fri, 15 Nov 2024 03:23:16 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3821b461a84sm3974933f8f.34.2024.11.15.03.23.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Nov 2024 03:23:15 -0800 (PST) Date: Fri, 15 Nov 2024 12:23:10 +0100 From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v8 7/8] vhost-user: add vhost-user Message-ID: <20241115122310.54ebf21a@elisabeth> In-Reply-To: <7593b3ea-c3ad-445d-b737-87f42f74e5b0@redhat.com> References: <20241010122903.1188992-1-lvivier@redhat.com> <20241010122903.1188992-8-lvivier@redhat.com> <20241017021034.437f3757@elisabeth> <20241114152319.722bff4e@elisabeth> <7593b3ea-c3ad-445d-b737-87f42f74e5b0@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: eDmd2g8iInpL-cSoeUz3bozqe_8ke_jz4JCk3hXfaOk_1731669798 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: GWTKEFHJX2AJYIVREZ7ZRMSVAC7P5T4L X-Message-ID-Hash: GWTKEFHJX2AJYIVREZ7ZRMSVAC7P5T4L X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, 15 Nov 2024 12:13:23 +0100 Laurent Vivier wrote: > On 14/11/2024 15:23, Stefano Brivio wrote: > > On Thu, 14 Nov 2024 11:29:36 +0100 > > Laurent Vivier wrote: > > > >> On 17/10/2024 02:10, Stefano Brivio wrote: > >>>> +/** > >>>> + * tcp_vu_prepare() - Prepare the packet header > >>>> + * @c: Execution context > >>>> + * @conn: Connection pointer > >>>> + * @first: Pointer to the array of IO vectors > >>>> + * @dlen: Packet data length > >>>> + * @check: Checksum, if already known > >>>> + */ > >>>> +static void tcp_vu_prepare(const struct ctx *c, > >>>> + struct tcp_tap_conn *conn, struct iovec *first, > >>>> + size_t dlen, const uint16_t **check) > >>>> +{ > >>>> + const struct flowside *toside = TAPFLOW(conn); > >>>> + char *base = first->iov_base; > >>>> + struct ethhdr *eh; > >>>> + > >>>> + /* we guess the first iovec provided by the guest can embed > >>>> + * all the headers needed by L2 frame > >>>> + */ > >>> What happens if it doesn't (buggy guest)? Do we have a way to make sure > >>> it's the case? I guess it's more straightforward to do this in > >>> tcp_vu_data_from_sock() where we check and set iov_len (even though the > >>> implication of VIRTIO_NET_F_MRG_RXBUF isn't totally clear to me). > >> > >> According to spec, minimum size of a buffer is 1526 bytes > >> (https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html#x1-2340003) > >> > >> So if the guest is buggy, we will write in the guest memory out of the (buggy) provided > >> buffer, and we can crash the guest. But it's what happens to a buggy guest. > >> > >> We can't fix the guest, IMO passt should crash in this case (add an ASSERT()?). > > > > I think we should rather call tap_sock_reset() (see tap_passt_input()) > > so that the guest has a chance to reconnect (you implemented this in > > QEMU...). > > If I add a call to tap_sock_reset() in tcp_vu_data_from_sock(), I need to remove all the > "const" from "struct ctx *" in the entire call chain. It's a lot. I'm not sure it is worth it. ...or you drop c->fd_tap = -1 from tap_sock_reset(). At a glance it looks fine to me, we never check it afterwards, but please double check. :) If that's not feasible, yeah, I guess an ASSERT() will do for the moment. -- Stefano