linux-kernel - Re: [PATCH] smp.h: Use local_irq_{save,restore}() in !SMP version of on_each

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+55aFziBGnSgLimDe7WBRPQ+f3RVAsrdbo212oj85c-XSz4oA@mail.gmail.com>
Date:	Thu, 13 Jun 2013 22:46:02 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Daney <ddaney.cavm@...il.com>
Cc:	Ralf Baechle <ralf@...ux-mips.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-mips <linux-mips@...ux-mips.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Daney <david.daney@...ium.com>
Subject: Re: [PATCH] smp.h: Use local_irq_{save,restore}() in !SMP version of on_each_cpu().

On Thu, Jun 13, 2013 at 6:07 PM, David Daney <ddaney.cavm@...il.com> wrote:
>
> Suggested fix: Do what we already do in the SMP version of
> on_each_cpu(), and use local_irq_save/local_irq_restore.

I was going to apply this, but started looking a bit more.

Using "flags" as a variable name inside a macro like this is a
*really* bad idea.

Lookie here:

    [torvalds@...el linux]$ git grep on_each_cpu.*flags
    arch/s390/kernel/perf_cpum_cf.c:        on_each_cpu(setup_pmc_cpu,
&flags, 1);
    arch/s390/kernel/perf_cpum_cf.c:        on_each_cpu(setup_pmc_cpu,
&flags, 1);

and ask yourself what happens when the "info" argument expands to
"&flags", and it all compiles perfectly fine, but the "&flags" takes
the address of the new _inner_ variable called "flags" from the macro
expansion. Not the one that the caller actually intends..

Oops.

Not a good idea.

So I would suggest trivially renaming "flags" as "__flags" or
something, or perhaps even just making it a real function and avoiding
the whole namespace issue.

And rather than doing that blindly by editing the patch at after -rc5,
I'm just going to ask you to re-send a tested patch. Ok?

                    Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/