linux-kernel - Re: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping processes during pipe read/write

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-=wjST86WXn2FRYuL7WVqwvdtXPmmsKKCuJviepeSP2=LPg@mail.gmail.com>
Date: Tue, 31 Dec 2024 11:38:17 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Manfred Spraul <manfred@...orfullife.com>
Cc: Oleg Nesterov <oleg@...hat.com>, WangYuli <wangyuli@...ontech.com>, 
	linux-fsdevel <linux-fsdevel@...r.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Christian Brauner <brauner@...nel.org>, 1vier1@....de
Subject: Re: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping
 processes during pipe read/write

On Tue, 31 Dec 2024 at 03:14, Manfred Spraul <manfred@...orfullife.com> wrote:
>
> Should we add the missing memory barriers and switch to
> wait_queue_active() in front of all wakeup calls?

If we *really* want to optimize this, we could even get rid of the
memory barrier at least on x86, because

 (a) mutex_unlock() is a full memory barrier on x86 (it involves a
locked cmpxchg)

 (b) the condition is always set inside the locked region

 (c) the wakeup is after releasing the lock

but this is architecture-specific (ie "mutex_unlock()" is not
*guaranteed* to be a memory barrier (ie on other architectures it
might be only a release barrier).

We have "smp_mb__after_atomic()" and "smp_mb__after_spinlock()", but
we don't have a "smp_mb__after_mutex_unlock()".

So we'd have to add a new helper or config option.

Anyway, I'm perfectly happy to get these optimizations, but because of
historical trouble in this area, I want any patches to be very clearly
documented.

Oleg's patch to only wake up writers when readers have actually opened
up a slot may not make any actual difference (because readers in
*practice* always do big reads), but I like it because it feels
obviously correct and doesn't have any locking or memory ordering
subtleties (and actually makes the logic more logical and
straightforward).

                Linus