[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091217094041.GA24708@elte.hu>
Date: Thu, 17 Dec 2009 10:40:41 +0100
From: Ingo Molnar <mingo@...e.hu>
To: linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Wu Fengguang <fengguang.wu@...el.com>,
Andi Kleen <ak@...ux.intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Morton <akpm@...ux-foundation.org>,
Matt Mackall <mpm@...enic.com>, Nick Piggin <npiggin@...e.de>,
Christoph Lameter <cl@...ux-foundation.org>,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: -tip: origin tree build failure
Today's -tip fails to build due to upstream commit
1a9b5b7fe0c5dad8a635288882d36785dea742f9 ("mm: export stable page flags")
(authored and merged yesterday) causing the following build failure on x86
when CONFIG_PROC_PAGE_MONITOR is disabled:
mm/built-in.o: In function `hwpoison_filter':
(.text+0x39fbf): undefined reference to `stable_page_flags'
The bug is that the stable_page_flags() API is only available under
CONFIG_PROC_PAGE_MONITOR, but utilized in mm/memory-failure.c unconditionally.
I've applied the patch below to -tip for now, which expresses this dependency
in the Kconfig. (Eventually a cleaner solution would be to factor such ABI
details out of procfs, they dont belong there.)
A technical critique: as i pointed it out in the past on lkml, this whole
ad-hoc exporting of MM details via /proc is ill advised. It's a limiting
interface for instrumentation (we could do so much more and could integrate it
so much better with a similar amount of intrusion), and it also creates
needless ABI dependencies with user-space tooling.
This should be prototyped in debugfs and sufficiently integrated with other
instrumentation frameworks in the kernel. I made a few suggestions and we even
wrote patches in the past to help that out:
3383e37: tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events
c33b359: tracing, page-allocator: Add trace event for page traffic related to the buddy lists
0d524fb: tracing, mm: Add trace events for anti-fragmentation falling back to other migratetypes
b9a2817: tracing, page-allocator: Add trace events for page allocation and page freeing
eb46710: tracing/mm: rename 'trigger' file to 'dump_range'
1487a7a: tracing/mm: fix mapcount trace record field
dcac8cd: tracing/mm: add page frame snapshot trace
Unfortunately nothing of that was pursued from the MM and hwpoison side and
now this inferior version goes upstream, and as two separate ABIs straight
away. (the /proc ABI and the memory-failure filter ABI) Not very well designed
and not very helpful IMO, and this will come back to haunt us in the future.
We know how to do this correctly, why not embrace, utilize and expand those
instrumentation facilities?
Also, a workflow observation - i tried to figure out the history of the bug
but the Git timestamps show this weirdness:
commit 1a9b5b7fe0c5dad8a635288882d36785dea742f9
Author: Wu Fengguang <fengguang.wu@...el.com>
AuthorDate: Wed Dec 16 12:19:59 2009 +0100
Commit: Andi Kleen <ak@...ux.intel.com>
CommitDate: Wed Dec 16 12:19:59 2009 +0100
that's precisely the same author and commit date, but author and committer are
different - how is that possible? No combination of git-am, git-rebase and git
commit --amend can achieve this kind of timestamp.
I checked the other 'HWPOISON' commits as well that were merged yesterday -
they have a similarly damaged history.
Thanks,
Ingo
Signed-off-by: Ingo Molnar <mingo@...e.hu>
diff --git a/mm/Kconfig b/mm/Kconfig
index 43ea8c3..d7bd560 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -243,6 +243,7 @@ config ARCH_SUPPORTS_MEMORY_FAILURE
config MEMORY_FAILURE
depends on MMU
depends on ARCH_SUPPORTS_MEMORY_FAILURE
+ select PROC_PAGE_MONITOR
bool "Enable recovery from hardware memory errors"
help
Enables code to recover from some memory failures on systems
--
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/
Powered by blists - more mailing lists