linux-kernel - Re: [GIT PULL] percpu fix for v4.10-rc6

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: <CA+55aFyn+pVeZKA1wEdbBMku_2UCL7BuUX1O_RvHpH5LJXEy5Q@mail.gmail.com>
Date:   Tue, 31 Jan 2017 14:17:10 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Tejun Heo <tj@...nel.org>
Cc:     "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dougmill@...ux.vnet.ibm.com
Subject: Re: [GIT PULL] percpu fix for v4.10-rc6

On Tue, Jan 31, 2017 at 2:11 PM, Tejun Heo <tj@...nel.org> wrote:
>
> We have a similar mess with bitops too.  x86 is cleaned up to have
> bool returns but the generic implementation and a lot of other archs
> return the tested bit instead of 1/0.  It'd be great to make all the
> boolean functions actually return bool.

If they really do return the tested bit, then those architectures
absolutely _will_ contain known bugs.

Because there definitely have been users of the bitop routines that
assign the result to an "int", and I have some dim memory of us also
having had things like drivers that made their own "bool" variables
and use "char" for them.

But I'm not seeing it. The generic bitop pattern seems to be

    static inline int test_and_change_bit(int nr, volatile unsigned long *addr)
    ...
        return (old & mask) != 0;

which is fine.

Just exactly what code did you look at?

                  Linus