From nobody Wed Aug 17 16:26:31 2022 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7D155hzJz4ZqV1; Wed, 17 Aug 2022 16:26:33 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7D153lrXz3nJ5; Wed, 17 Aug 2022 16:26:33 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 27HGQVkR031617 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 17 Aug 2022 09:26:31 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 27HGQVuO031616; Wed, 17 Aug 2022 09:26:31 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Wed, 17 Aug 2022 09:26:31 -0700 From: Gleb Smirnoff To: Mateusz Guzik Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 9ac6eda6c6a3 - main - pipe: try to skip locking the pipe if a non-blocking fd is used Message-ID: References: <202208171423.27HENpvp024623@gitrepo.freebsd.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M7D153lrXz3nJ5 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Aug 17, 2022 at 06:21:33PM +0200, Mateusz Guzik wrote: M> I don't understand this whatsoever. I patched the read side, not write. M> M> So in particular, should you find there is free space in the pipe to M> write to, there is literally no change. M> M> At worst, if a non-blocking read was racing a write, there is a bigger M> window where the reader will conclude there is nothing to get and M> leave. M> M> I see the following races: M> 1. non-blocking reader arrived before the writer managed to busy the M> pipe, in which case the outcome is the same in both old and new code M> 2. non-blocking reader arrived after the writer managed to unbusy the M> pipe, in which case the outcome is once again the same -- the write M> was completed and reader sees it M> 3. non-blocking reader arrived after the writer managed to busy the M> pipe, but before it got unbusied. here the old code would always wait, M> while the new will or will not wait depending on whether the writer M> managed to bump data counters or not. M> M> Ultimately there is no *new* outcome for any of it. The problem is symmetrical for both read and write. I'm sorry that I used write scenario to describe a problem. So, let's look into third case. We got event dispatcher reporting to us that next read(2) would be successful: POLLRDNORM Normal data may be read without blocking. or EVFILT_READ Takes a descriptor as the identifier, and returns whenever there is data available to read. The behavior of the filter is slightly different depending on the descriptor type. Fifos, Pipes Returns when the there is data to read; data contains the number of bytes available. But next read(2) would return EAGAIN. This is broken contract. -- Gleb Smirnoff