On 07/17/2013 11:23 PM, Greg KH wrote:
On Wed, Jul 17, 2013 at 10:32:22PM -0700, Andrew Morton wrote:
On Wed, 17 Jul 2013 21:59:54 -0700 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
On Thu, Jul 04, 2013 at 10:34:52AM -0700, Andrew Morton wrote:
On Thu, 4 Jul 2013 15:26:02 +0000 "Daney, David" <David.Daney@xxxxxxxxxxxxxxxxxx> wrote:
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.
Please excuse the top posting,
Fixed it!
but weren't these issues resolved weeks ago?
That indeed appears to be the case. Given that I'd merged the
offending patch, it would perhaps have made sense to cc me on its
fixes...
Not really possible, I had already fixed all the problems and the
corresponding fixes were in the pipeline for merging *before* you got
involved. By the time you started sending patches, there was no
problem. Now, because of the miscommunication, we now have a seemingly
unending stream of patches reverting and unreverting this thing.
So, this patch is now in Linus's tree, should it be reverted? Should it
be applied to the stable tree as it was originally marked, or just
dropped and not worried about for 3.10?
confused,
Heh. I have a queued a patch to switch it back to an inline function,
but things are OK in mainline as-is so that's for 3.12.
So 3.11 will have the macro implementation of on_each_cpu(), and I
suggest that 3.10.x do the same.
Thanks for that, I've now queued this up for 3.10-stable.
I don't see why it is either necessary, or even desirable, to muck
around in 3.10. To my knowledge, there are no known problems related to
the on_each_cpu() implementation in 3.10.1.
Do we really want to track upstream merging snafus that neither fix nor
cause bugs in the stable branches? I don't know. But if so, are there
other upstream NOP and code cleanup patches that should also be
considered for the stable branches?
David Daney
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html