From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine 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=fOx/u1Fq; 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 ESMTPS id 95A015A0008 for ; Fri, 28 Mar 2025 10:23:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743153826; 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=ROUlHx/woOUkuGet+m943kfWH7Pj8a7jcTClQgkjog0=; b=fOx/u1FqeIKv5i5dI4t/xa7uuPKhowDaOuG2DldA+Am+paYrE6/h5QBDTGbrD+Y/zt/9wN +tFUKHLutPtDxIvHZ9DfW9ixKdPerAdH03vK64Rm4EQ6I65V5S3w3uaoNRfTcx3YzGxogs RbhIq3SCPqvImtYOfAx6pBndtND+yUY= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-318-SuyvbRgTOgCgfaMAwwGXvA-1; Fri, 28 Mar 2025 05:23:44 -0400 X-MC-Unique: SuyvbRgTOgCgfaMAwwGXvA-1 X-Mimecast-MFC-AGG-ID: SuyvbRgTOgCgfaMAwwGXvA_1743153823 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-3913aaf1e32so1102983f8f.0 for ; Fri, 28 Mar 2025 02:23:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743153823; x=1743758623; 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=ROUlHx/woOUkuGet+m943kfWH7Pj8a7jcTClQgkjog0=; b=T1vA7/6NUWkbs0a4D4+EAZ8XbZiQsAzNcrWjTkqSfOkBxeaLmPAdZHeLHilAiTYuaN RMtdrHw9Cq9ib/MCWfpwfdLFeM3xLJLWn7IITqgDWmaU/zpmEs3kvvA+6xLT+BCbJqIg /drbYWGSDMYpeLwYauDtYlkh/7ZDoadySOvCvLJGLnMvs5PSaHPsiLHEKEUCfzYZDD8f SIyDdhKnRbpHoPVUSh1I9BvcXfKVUaXAUxXdqjLDgG3uBIKebaD0xAuXk2Cs1p7F7q2k JEAnQZMr+d/Gu/OqpW0Z+WJa1O0H2W++mQZtb2qCtF9KQsftNbEvboLa+wIGNstiTb/6 WqZw== X-Gm-Message-State: AOJu0Yyu/AT8Nf/GBKgwLoHbHJDcJ3orDfTk/2NiVMoZmHr71py8ilea rSFH9cqYrYVA3af70+9dt0wZD/uUeh+gtDE43GMZdGA6/2cGmyVbWBlHBTiB9AzNLCKaWmE7G/G W6FMy+13+fXhRyOXz85YLMPUFEsLIrzQsn0MCkdtmmo5LUqOW2UJnZMGrMw== X-Gm-Gg: ASbGnctxj4zgROEiRJMHV14xSf6Rcyw900kNExqY1hLZokDuytoJ5FJ27OGnisOpFFO 2qZkVo3AcXDQ+gb8wJEvvyu/CiO0DSLsyCbU2K8tRoE5RJhdF5Jfsa66yWu52cAm+Cd5MrfGgg7 gdvvpEiSSBgIUSw9EMQu226PnAhZuIgqFMKqMzLKchnxd+JVfG4/jbp/m58N92fE3y3dBPAkj5E Aq7+8sQgOP0hEC3z0E4r1TeEqceJM+lx7Gcue6JQGTXlPzZtG6p3IuXSgNttIAyd968fQukEifG kJFRhMoBS2JaU1yyedT477e8xdf/Q5lqXfGpBfWXRLua X-Received: by 2002:a05:6000:40e1:b0:391:41c9:7a8d with SMTP id ffacd0b85a97d-39ad1773b64mr5834461f8f.54.1743153822717; Fri, 28 Mar 2025 02:23:42 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGaIdEKxM+fhlOeWmvBN/zXaGAOb/RxEnsqnIxLY1xQmUs/57e+IAKdodKJCNQmvmN0DAMdng== X-Received: by 2002:a05:6000:40e1:b0:391:41c9:7a8d with SMTP id ffacd0b85a97d-39ad1773b64mr5834425f8f.54.1743153821952; Fri, 28 Mar 2025 02:23:41 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-39c0b79e467sm2011231f8f.79.2025.03.28.02.23.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Mar 2025 02:23:41 -0700 (PDT) Date: Fri, 28 Mar 2025 10:23:40 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [RFC PATCH] pasta, passt-repair: Support multiple events per read() in inotify handlers Message-ID: <20250328102340.0ede3ca8@elisabeth> In-Reply-To: References: <20250327212822.3315053-1-sbrivio@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: HzRPmiRWHRPgHXzrQhx7DdIaIQoL4OHWYFVozjquDVM_1743153823 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: JDY2GTRGXEV7LCIKILSSX6IQYOGD5AG4 X-Message-ID-Hash: JDY2GTRGXEV7LCIKILSSX6IQYOGD5AG4 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, 28 Mar 2025 10:36:39 +1100 David Gibson wrote: > On Thu, Mar 27, 2025 at 10:28:22PM +0100, Stefano Brivio wrote: > > The current code assumes that we'll get one event per read() on > > inotify descriptors, but that's not the case, not from documentation, > > and not from reports. > > > > Add loops in the two inotify handlers we have, in pasta-specific code > > and passt-repair, to go through all the events we receive. > > > > While in pasta the the inotify watch is in an epoll list, and we'll > > "the the" > > > get epoll wakeups as long as there's data to read, in passt-repair > > that's not the case. So, in pasta we can simply size the buffer for > > a single event and try to read one, but in passt-repair, we'll need > > to size the buffer to a safer, reasonable amount of events. > > I'm not following the reasoning here. In passt-repair we're just > looping on the read() until we find what we want, so we'll still > eventually get what we want. AFAICT it's a stream-like interface, so > we won't lose events just because we didn't get them in the first > read(). Under the assumption that message (event) boundaries are preserved across read() calls, yes. And... this assumption actually holds (I had forgotten about that), so expanding the buffer as I did makes no sense, because by reading sizeof(struct inotify_event) + NAME_MAX + 1) bytes we always read one or more events, but never a partial buffer. So, yes, never mind. > > Link: https://bugs.passt.top/show_bug.cgi?id=119 > > Signed-off-by: Stefano Brivio > > Otherwise, LGTM. > > > --- > > I'm posting this as RFC because, while it seems to do the job and I > > tested all the code paths, Coverity isn't amused by the fact that > > we assume that inotify 'name' attributes (ev->name) are > > NULL-terminated. They actually are, but the code is not very robust. > > > > Addressing that is kind of trivial but I keep getting it wrong, so > > I'll start posting this and fix that up later (direct fixes/edits of > > this patch are also welcome, of course). > > Ok, I might try to polish this up today Thanks! -- Stefano