lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjoTncMYdQFmY4yspKOUsDSNn1dHp1FWvJ0eRO94ZM3dQ@mail.gmail.com>
Date:   Sun, 27 Oct 2019 12:12:56 -0400
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
Cc:     David Howells <dhowells@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pipe: wakeup writer only if pipe buffer is at least half empty

On Sun, Oct 27, 2019 at 11:46 AM Konstantin Khlebnikov
<khlebnikov@...dex-team.ru> wrote:
>
> There is no reason to wakeup writer if pipe has only one empty page.
> This means reader consumes data slower then writer produces it.
>
> This patch waits until buffer is at least half empty before waking writer.

This is a bit dangerous, at least with David's other changes.

In particular, there's now a "max_usage" in his series means that the
writer might be blocked even if there's lots of free slots, because
the writer is only allowed to use part of those slots.

So I'd rather not see this logic particularly now that David is
working on modifying the overall pipe logic.

I do agree with the overall idea, but I'm not entirely happy about the
"half full" logic, because it gets subtle with David's changes.

Also, I'm a bit worried about cases where the readers and writers
block on each other, and depend on "there's enough space in the pipe
that we won't deadlock". Maybe the writer is blocked (because it
filled the pipe), the reader reads just part of the pipe, and then the
reader blocks on the writer doing something else, knowing that it just
free'd up resources for the writer. But the writer is still blocked,
and not woken up, because the pipe is still more than half full. See
what I'm saying?

I'm not sure anything like that exists, but it's an example of a "hmm"
condition.

              Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ