linux-kernel - Re: [patch V3 58/64] futex: Clarify comment in futex

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: <87lf5bt4ip.ffs@tglx>
Date:   Mon, 09 Aug 2021 10:18:38 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Davidlohr Bueso <dave@...olabs.net>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Mike Galbraith <efault@....de>
Subject: Re: [patch V3 58/64] futex: Clarify comment in futex_requeue()

On Sun, Aug 08 2021 at 11:43, Davidlohr Bueso wrote:

> On Thu, 05 Aug 2021, Thomas Gleixner wrote:
>
>>From: Thomas Gleixner <tglx@...utronix.de>
>>
>>The comment about the restriction of the number of waiters to wake for the
>>REQUEUE_PI case is confusing at best. Rewrite it.
>
> This certainly reads better.
>
>>
>>Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
>>---
>> kernel/futex.c |   28 ++++++++++++++++++++--------
>> 1 file changed, 20 insertions(+), 8 deletions(-)
>>---
>>--- a/kernel/futex.c
>>+++ b/kernel/futex.c
>>@@ -1960,15 +1960,27 @@ static int futex_requeue(u32 __user *uad
>>		 */
>>		if (refill_pi_state_cache())
>>			return -ENOMEM;
>
> Perhaps this can be moved after the nr_wake check below? No sense
> in calling refill_pi_state_cache() if the user is passing bogus
> parameters.

Yes.