From: David Daney <ddaney@caviumnetworks.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
David Daney <david.daney@cavium.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Linux 3.10-rc6
Date: Mon, 17 Jun 2013 14:08:13 -0700 [thread overview]
Message-ID: <51BF7ABD.3080508@caviumnetworks.com> (raw)
In-Reply-To: <20130617135920.587959a34da85d7940a6936f@linux-foundation.org>
On 06/17/2013 01:59 PM, Andrew Morton wrote:
> On Mon, 17 Jun 2013 13:48:16 -0700 David Daney <ddaney@caviumnetworks.com> wrote:
>
>> On 06/17/2013 01:30 PM, Andrew Morton wrote:
>> [...]
>>>
>>> From: Andrew Morton <akpm@linux-foundation.org>
>>> Subject: include/linux/smp.h:on_each_cpu(): switch back to a macro
>>>
>>> f21afc25f9ed4 ("smp.h: Use local_irq_{save,restore}() in !SMP version of
>>> on_each_cpu()") converted on_each_cpu() to a C function. This required
>>> inclusion of irqflags.h, which broke ia64 and mn10300 (at least) due to
>>> header ordering hell.
>>>
>>> Switch on_each_cpu() back to a macro to fix this.
>>
>> FYI: I have already sent a pair of patches that fix the include
>> dependencies:
>>
>> https://lkml.org/lkml/2013/6/16/113
>> https://lkml.org/lkml/2013/6/17/422
>
> I wasn't cc'ed.
>
>> Obviously, it is Linus' choice as to how best to handle the failure, but
>> I think it is important to know that there are two options (fixing ia64
>> and mn10300, or reverting the patch).
>
> I certainly prefer the inline function over a crappy macro. The
> additional nested include is regrettable - more complexity.
>
> Also, it's good to have the SMP and non-SMP versions either both using
> macros or both using C. Having them different can cause irritating
> unused-variable compilation warnings when using the macro version.
Although all these points are true, they are not why I wrote the patch.
The key difference, for me, between the SMP and !SMP versions is that
the !SMP version unconditionally enables interrupts, and this enabling
interrupts breaks my kernel
>
> I think switch-back-to-a-macro is simplest and safest for now. Perhaps
> you can queue a 3.11 patch which restores the C function and fixes up
> mn10300 and ia64?
>
If the patch is reverted, I will do that.
David Daney
next prev parent reply other threads:[~2013-06-17 21:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-15 22:12 Linux 3.10-rc6 Linus Torvalds
2013-06-16 8:36 ` Geert Uytterhoeven
2013-06-16 18:01 ` Linus Torvalds
2013-06-17 20:30 ` Andrew Morton
2013-06-17 20:48 ` David Daney
2013-06-17 20:59 ` Andrew Morton
2013-06-17 21:08 ` David Daney [this message]
2013-06-17 21:13 ` Andrew Morton
2013-06-17 21:26 ` David Daney
2013-06-17 21:38 ` Andrew Morton
2013-06-18 8:37 ` Geert Uytterhoeven
2013-06-19 16:57 ` David Daney
2013-06-17 21:22 ` Geert Uytterhoeven
2013-06-16 12:37 ` Martin Steigerwald
2013-06-16 12:52 ` Linus Walleij
2013-06-16 13:45 ` Martin Steigerwald
2013-06-16 18:09 ` Linus Torvalds
2013-06-16 18:28 ` Linus Torvalds
2013-06-16 22:18 ` Davidlohr Bueso
2013-06-16 18:51 ` Martin Steigerwald
2013-06-16 19:51 ` Al Viro
2013-06-20 3:14 ` Steven Rostedt
2013-06-16 19:26 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51BF7ABD.3080508@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=akpm@linux-foundation.org \
--cc=david.daney@cavium.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.