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=MECFxaww; 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 64B805A0269 for ; Sat, 16 May 2026 17:46:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778946380; 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=Bk3LkmwMIYSEfpmmsyKoV0l9t4V+qW7Yi9fVAh+fz+8=; b=MECFxawwEEygJYDxNS/ukm93xvXF8+qjQGxoB/0VvW0wFlVQyMg4TjA7qw3xNNxpKn/hub RoSqmGk4AZn7Ze5NIGQoG0Nmo2LxTM6wYViWrpVlc2Sag6mYJFB7PE7ytzRX0oqsowUoPv gw2FXpMoxASafV9WhfwhifATJqeiOD8= 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-442-aGWiyZQdOme6F4fTD7oYgw-1; Sat, 16 May 2026 11:46:18 -0400 X-MC-Unique: aGWiyZQdOme6F4fTD7oYgw-1 X-Mimecast-MFC-AGG-ID: aGWiyZQdOme6F4fTD7oYgw_1778946378 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-45d95cba6f1so393288f8f.0 for ; Sat, 16 May 2026 08:46:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778946377; x=1779551177; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Bk3LkmwMIYSEfpmmsyKoV0l9t4V+qW7Yi9fVAh+fz+8=; b=eqkZmVXpAkJrwrO62l2p8HBoKLzSSmwm6UrZAlsKr5r+plTGv43Rc+cG9vIvwGIs+E rGqRwJo/Fk3rUw3L40Hk5C6JqdxBqKcRSd5a63x6xldWQ4rNLs67Rg8V1Z5XavgJ5bmh +Z8+NgIKBb0Lxpu1X/fQzt1qkfGXk0UAF+N5hkEL3nawqLqT3yghV0786GWq/pf1L25w d2FqXshb21nMoTze1jVB3OC36Y5Wwa0PYcCum3D2cKsUVWkwmLKjXdlgYaS6jVAyNhcp BcelEu+pZ4xSHcEzSOdvDpkWKUHlzy31QG7qQCECEeIu+TGhLNfLKiFlZjK8fyMjNQ8Z k1Jg== X-Gm-Message-State: AOJu0YxHD0z8d1Wp2nX6tQkU6shWGR1oAgcFX+NnwG1gh8lE/gyKf8NI ATXWsO8e9J1wY68h3V/bAP3/jbPd+YVQrULnYxR8axYMZRHz/ouFXGVp9izuW+bN9pKdFMT9P/M YbH/NYNN+xRxfj+eIbazcIJlFymWNaMmn0L1TKcZqRhhH+EbXgO8HFA== X-Gm-Gg: Acq92OHaIqUBVNFOzXWaPRHEyuI/6n3uQCg54XsBqhVwG0a3iLSWdkWVdDO/pENC9V2 0XW2xcEP/G4N401HLGpJvQjeY9ipbEEG37oSIRJh9RDMFYGxJM4NfeQDtXLjp7EmZqLAUB7PaTb QEyiQTXwNOS0KVWVB4EY9YGPSqwy8RzkPOLcdWXZjqO4vvrx0ReP2vX9u2VcPYl45lGnYzSON2B sFiLOFWoYRpnr+ftgHp0hGclMdCcaWfQGh6qOmk3RwFgV+cwYlUSHjDiOhDIXgX3G3s9K/2X7UY nFvS/gaduvBZlM5y5Z5776RBPh3Ze1JHZGqbZ3JjORUr3SuauHaCDUXtQFbfbGSgV0qaC06QHi2 DiRjtFVQ0IzNCC6lHzST+slrbi1oqHIjz X-Received: by 2002:a05:600c:c10b:b0:48f:d1b8:9aa4 with SMTP id 5b1f17b1804b1-48fe5fcdef4mr88347935e9.7.1778946377483; Sat, 16 May 2026 08:46:17 -0700 (PDT) X-Received: by 2002:a05:600c:c10b:b0:48f:d1b8:9aa4 with SMTP id 5b1f17b1804b1-48fe5fcdef4mr88347725e9.7.1778946376943; Sat, 16 May 2026 08:46:16 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48ff43f8799sm45353205e9.2.2026.05.16.08.46.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 May 2026 08:46:16 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 3/3] conf, repair, tap: More caution about blocking flag on Unix sockets Message-ID: <20260516174615.0cb33d6e@elisabeth> In-Reply-To: <20260513041423.2446716-4-david@gibson.dropbear.id.au> References: <20260513041423.2446716-1-david@gibson.dropbear.id.au> <20260513041423.2446716-4-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Sat, 16 May 2026 17:46:16 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: N_wJPL4QJl91LT314adzyFPkFzS7xhMoR3nX9_LlUvc_1778946378 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: XQBVCTFICVOV4MOT3DUUBBZUWIZE65NH X-Message-ID-Hash: XQBVCTFICVOV4MOT3DUUBBZUWIZE65NH 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 Wed, 13 May 2026 14:14:23 +1000 David Gibson wrote: > Most of our operation is asynchronous, based on non-blocking fds handled > in our epoll loop. However, our several Unix sockets (tap client, repair > helper, control client) are all blocking fds after accept(). > > That's correct for the repair helper, and (for now) correct for the control > client. However, the reasons for that might not be obvious, so add some > extra comments giving the rationale. > > I don't believe it's correct for the tap client; having this socket be > blocking means we could potentially block the main loop if we ever got a > a spurious EPOLL{IN,OUT} event on the tap socket. Switch the tap socket > to non-blocking for better robustness, and consistency with nearly every > other fd we track. That socket needs to be blocking for the second usage we make of it in tap_send_frames_passt(), that is, the one via write_remainder() without MSG_DONTWAIT. While a part of https://bugs.passt.top/show_bug.cgi?id=38 is solved (there are no blocking reads left in tap_passt_input()), this isn't the case for the writing side of it. Some nits below: > Signed-off-by: David Gibson > --- > conf.c | 6 ++++++ > repair.c | 4 ++++ > tap.c | 3 ++- > 3 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/conf.c b/conf.c > index dec43fca..dc85f0f8 100644 > --- a/conf.c > +++ b/conf.c > @@ -2082,6 +2082,12 @@ static void conf_accept(struct ctx *c) > int fd, rc; > > retry: > + /* Currently we perform the configuration transaction more-or-less > + * synchronously, so we want the accepted socket to be blocking. > + * > + * FIXME: We should make the configuration update asynchronous, like > + * most of our operation, so a misbehaving configuration client can't > + * block the main forwarding loop */ * ... loop. */ > fd = accept4(c->fd_control_listen, NULL, NULL, SOCK_CLOEXEC); > if (fd < 0) { > if (errno != EAGAIN) > diff --git a/repair.c b/repair.c > index 42c4ae97..8a2d119d 100644 > --- a/repair.c > +++ b/repair.c > @@ -99,6 +99,10 @@ int repair_listen_handler(struct ctx *c, uint32_t events) > return EEXIST; > } > > + /* We want accepted socket to be blocking; we use it during migration "the accepted socket" > + * which is a synchronous interruption to our normal non-blocking > + * behaviour. > + */ > if ((c->fd_repair = accept4(c->fd_repair_listen, NULL, NULL, > SOCK_CLOEXEC)) < 0) { > if ((rc = errno) != EAGAIN) > diff --git a/tap.c b/tap.c > index fda2da9b..3b8a3f3d 100644 > --- a/tap.c > +++ b/tap.c > @@ -1490,7 +1490,8 @@ void tap_listen_handler(struct ctx *c, uint32_t events) > return; > } > > - c->fd_tap = accept4(c->fd_tap_listen, NULL, NULL, SOCK_CLOEXEC); > + c->fd_tap = accept4(c->fd_tap_listen, NULL, NULL, > + SOCK_NONBLOCK | SOCK_CLOEXEC); ...so this part would need to be dropped. > if (c->fd_tap < 0) { > if (errno != EAGAIN) > warn_perror("Error accepting tap client"); The rest looks good to me. -- Stefano