linux-kernel - Re: [futex] 8019ad13ef: will-it-scale.per_process

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-next>] [day] [month] [year] [list]

Date:   Sun, 8 Mar 2020 10:28:44 -0500
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     kernel test robot <rong.a.chen@...el.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Jann Horn <jannh@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>, x86-ml <x86@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...e.de>, lkp@...ts.01.org
Subject: Re: [futex] 8019ad13ef: will-it-scale.per_process_ops -97.8% regression

[ Just a re-send without html crud that makes all the lists unhappy.
I'm still on the road, the flight I was supposed to be on yesterday
got cancelled.. ]

I do note that the futex hashing seems to be broken by that commit. Or
at least it's questionable.  It keeps hashing on "both.word",  and
doesn't use the u64 field at all for hashing.

Maybe I'm mis-reading it - I didn't apply the patch, I just looked at
the patch and my source base separately.

But the 98% regression sure says something went wrong ;)

           Linus

On Sun, Mar 8, 2020 at 9:22 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Sun, Mar 8, 2020, 08:02 kernel test robot <rong.a.chen@...el.com> wrote:
>>
>>
>> FYI, we noticed a -97.8% regression of will-it-scale.per_process_ops due to commit:
>>
>> commit: 8019ad13ef7f64be44d4f892af9c840179009254 ("futex: Fix inode life-time issue")
>
> Well, that's not optimal.
>
> Peter, any ideas? One of the things that worried me about changing to
> an u64 was what I think it causes extra padding, I think. And maybe
> that messes with the comparison and hashing of the futexes?