From nobody Wed Aug 17 17:07:26 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 4M7DwK1Vmkz4Yh4x; Wed, 17 Aug 2022 17:07:29 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7DwK12TWz3tyC; Wed, 17 Aug 2022 17:07:29 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lf1-x136.google.com with SMTP id o2so19832551lfb.1; Wed, 17 Aug 2022 10:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc; bh=fpcpCbuZH9n+0EOTT+/P6cngPblLBbQanJjyBF+OwOk=; b=eviM1hYD9UN1vYu1PF5JF2xmmHqPxeFqb/7Ysxv0LZE7hGQAosBo/SqYkBFb7krV+j MnSj3hoaHU6ORLtH4q+Tvb6kAtETOeSJ7J+u7ulIwvltlHXUPNbV1R0b23d5cdnLnGFG GmbdAL3G/lJTu59ImLskup8boo/ZNcLquRsxj/gDik+S1aiZU+5UaOK9fgIDS0kfZdVd bBa5R2UnL9lWuMRjU4BMk8n/J3CWae2XHOv5EJTcln3eFZqLTY/Ae1s2P8RhyMIYmG2N IGmrzGCP46WH/T6DUFcylpTmn0OP3zPCVxDG8W3a6z3zCo3Lp3HEf0BeGDJYdF2jH2R/ 6NDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc; bh=fpcpCbuZH9n+0EOTT+/P6cngPblLBbQanJjyBF+OwOk=; b=gljMAWbmLTTyJCEKBKr9bDrFd55Tcb2OEboeYT0Y1YXSO3k/0dzU8Qwf9DirALfJD4 o3l5xEKC1WCBKA7H4Wy/jWA1V/NtUiyokqlOxzwP3+r82a6ggtDOf8OMJ7xHR6m4IH70 IDZqjEjAyCBG9mVlvKXkGNhCxWRbqHnQhTzKCoxdeprFeVSQ+EgcrcxSBNueJhUyLAOJ +5b5Y8rdVUtDiixECJUSZDFTrAds+fcel4H2rF7VFdwypF49XV2AHS12kjr3EQAJusmV QSsOlQtnyegJc5JI4c1BU/nhJsSnpawhvWHWj3EHwGMwdJ3J4s9SggEWvjID51FE9dTw owpQ== X-Gm-Message-State: ACgBeo2giZssQtPquxMsnjlbelE4uPifyP5EYIW6wQhjmdraCkPAw2fU m+2D21t4vwbshGRZFF5r0840yPo4expofqV585Bd8GQu X-Google-Smtp-Source: AA6agR4KvAANjngYWyA0vHiKus/N9ONv4cWGg+j+H4rV/e195x+LjLJ2K2EQKrkLrLj91YXrbzJBFWuX3IMg16833EI= X-Received: by 2002:a05:6512:c0f:b0:48a:fef0:c8fe with SMTP id z15-20020a0565120c0f00b0048afef0c8femr8538856lfu.283.1660756047645; Wed, 17 Aug 2022 10:07:27 -0700 (PDT) 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 Received: by 2002:a05:6520:2b8a:b0:1fe:cc4c:a235 with HTTP; Wed, 17 Aug 2022 10:07:26 -0700 (PDT) In-Reply-To: References: <202208171423.27HENpvp024623@gitrepo.freebsd.org> From: Mateusz Guzik Date: Wed, 17 Aug 2022 19:07:26 +0200 Message-ID: Subject: Re: git: 9ac6eda6c6a3 - main - pipe: try to skip locking the pipe if a non-blocking fd is used To: Gleb Smirnoff Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M7DwK12TWz3tyC 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 8/17/22, Gleb Smirnoff wrote: > 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. > Once more I don't see it, can you show a simple graph how this is supposed to happen all while not being possible on the previous kernel? See below for an example. Say there is only one thread which sees the reader side and that thread performs the poll/select/kqueue call. Once it gets the notification, it proceeds to do the read which of course works fine. Say there are more threads or even multiple processes. If userspace took no measures to synchronize read calls vs poll/select/kqueue calls (that is some threads just read while others poll and only then read, for example), it runs into races which are the same for both old and new code (with one slight distinction of what happens when the write is in progress) thread1 thread2 poll write ret read thread1 finds data no problem. thread1 thread2 thread3 poll write ret read read thread1 got scooped and gets EAGAIN on both old and new kernels -- Mateusz Guzik