1. 24 1月, 2011 2 次提交
    • R
      Remove MAYBE_BUILD_BUG_ON · 1765e3a4
      Rusty Russell 提交于
      Now BUILD_BUG_ON() can handle optimizable constants, we don't need
      MAYBE_BUILD_BUG_ON any more.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      1765e3a4
    • R
      BUILD_BUG_ON: make it handle more cases · 7ef88ad5
      Rusty Russell 提交于
      BUILD_BUG_ON used to use the optimizer to do code elimination or fail
      at link time; it was changed to first the size of a negative array (a
      nicer compile time error), then (in
      8c87df45) to a bitfield.
      
      This forced us to change some non-constant cases to MAYBE_BUILD_BUG_ON();
      as Jan points out in that commit, it didn't work as intended anyway.
      
      bitfields: needs a literal constant at parse time, and can't be put under
      	"if (__builtin_constant_p(x))" for example.
      negative array: can handle anything, but if the compiler can't tell it's
      	a constant, silently has no effect.
      link time: breaks link if the compiler can't determine the value, but the
      	linker output is not usually as informative as a compiler error.
      
      If we use the negative-array-size method *and* the link time trick,
      we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
      branches, and maximal ability for the compiler to detect errors at
      build time.
      
      We also document it thoroughly.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Jan Beulich <JBeulich@novell.com>
      Acked-by: NHollis Blanchard <hollisb@us.ibm.com>
      7ef88ad5
  2. 20 1月, 2011 1 次提交
    • T
      lockdep: Move early boot local IRQ enable/disable status to init/main.c · 2ce802f6
      Tejun Heo 提交于
      During early boot, local IRQ is disabled until IRQ subsystem is
      properly initialized.  During this time, no one should enable
      local IRQ and some operations which usually are not allowed with
      IRQ disabled, e.g. operations which might sleep or require
      communications with other processors, are allowed.
      
      lockdep tracked this with early_boot_irqs_off/on() callbacks.
      As other subsystems need this information too, move it to
      init/main.c and make it generally available.  While at it,
      toggle the boolean to early_boot_irqs_disabled instead of
      enabled so that it can be initialized with %false and %true
      indicates the exceptional condition.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NPekka Enberg <penberg@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20110120110635.GB6036@htj.dyndns.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2ce802f6
  3. 14 1月, 2011 2 次提交
    • M
      mm: vmscan: reclaim order-0 and use compaction instead of lumpy reclaim · 3e7d3449
      Mel Gorman 提交于
      Lumpy reclaim is disruptive.  It reclaims a large number of pages and
      ignores the age of the pages it reclaims.  This can incur significant
      stalls and potentially increase the number of major faults.
      
      Compaction has reached the point where it is considered reasonably stable
      (meaning it has passed a lot of testing) and is a potential candidate for
      displacing lumpy reclaim.  This patch introduces an alternative to lumpy
      reclaim whe compaction is available called reclaim/compaction.  The basic
      operation is very simple - instead of selecting a contiguous range of
      pages to reclaim, a number of order-0 pages are reclaimed and then
      compaction is later by either kswapd (compact_zone_order()) or direct
      compaction (__alloc_pages_direct_compact()).
      
      [akpm@linux-foundation.org: fix build]
      [akpm@linux-foundation.org: use conventional task_struct naming]
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Rik van Riel <riel@redhat.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Andy Whitcroft <apw@shadowen.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3e7d3449
    • A
      include/linux/kernel.h: abs(): fix handling of 32-bit unsigneds on 64-bit · 71a90484
      Andrew Morton 提交于
      Michal reports:
      
      In the framebuffer subsystem the abs() macro is often used as a part of
      the calculation of a Manhattan metric, which in turn is used as a measure
      of similarity between video modes.  The arguments of abs() are sometimes
      unsigned numbers.  This worked fine until commit a49c59c0 ("Make sure the
      value in abs() does not get truncated if it is greater than 2^32:) , which
      changed the definition of abs() to prevent truncation.  As a result of
      this change, in the following piece of code:
      
      u32 a = 0, b = 1;
      u32 c = abs(a - b);
      
      'c' will end up with a value of 0xffffffff instead of the expected 0x1.
      
      A problem caused by this change and visible by the end user is that
      framebuffer drivers relying on functions from modedb.c will fail to find
      high resolution video modes similar to that explicitly requested by the
      user if an exact match cannot be found (see e.g.
      
      Fix this by special-casing `long' types within abs().
      
      This patch reduces x86_64 code size a bit - drivers/video/uvesafb.o shrunk
      by 15 bytes, presumably because it is doing abs() on 4-byte quantities,
      and expanding those to 8-byte longs adds code.
      
      testcase:
      
      #define oldabs(x) ({				\
      		long __x = (x);			\
      		(__x < 0) ? -__x : __x;		\
      	})
      
      #define newabs(x) ({						\
      		long ret;					\
      		if (sizeof(x) == sizeof(long)) {		\
      			long __x = (x);				\
      			ret = (__x < 0) ? -__x : __x;		\
      		} else {					\
      			int __x = (x);				\
      			ret = (__x < 0) ? -__x : __x;		\
      		}						\
      		ret;						\
      	})
      
      typedef unsigned int u32;
      
      main()
      {
      	u32 a = 0;
      	u32 b = 1;
      	u32 oldc = oldabs(a - b);
      	u32 newc = newabs(a - b);
      
      	printf("%u %u\n", oldc, newc);
      }
      
      akpm:/home/akpm> gcc t.c
      akpm:/home/akpm> ./a.out
      4294967295 1
      Reported-by: NMichal Januszewski <michalj@gmail.com>
      Cc: Rolf Eike Beer <eike-kernel@sf-tec.de
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      71a90484
  4. 29 11月, 2010 1 次提交
  5. 16 11月, 2010 1 次提交
  6. 12 11月, 2010 1 次提交
  7. 10 11月, 2010 1 次提交
  8. 09 11月, 2010 1 次提交
  9. 27 10月, 2010 4 次提交
  10. 21 10月, 2010 2 次提交
  11. 11 9月, 2010 1 次提交
  12. 13 8月, 2010 1 次提交
  13. 11 8月, 2010 2 次提交
  14. 10 8月, 2010 1 次提交
  15. 20 7月, 2010 1 次提交
  16. 12 7月, 2010 1 次提交
  17. 05 7月, 2010 1 次提交
  18. 11 6月, 2010 1 次提交
  19. 25 5月, 2010 4 次提交
  20. 19 5月, 2010 1 次提交
  21. 22 4月, 2010 1 次提交
    • F
      tracing: Dump either the oops's cpu source or all cpus buffers · cecbca96
      Frederic Weisbecker 提交于
      The ftrace_dump_on_oops kernel parameter, sysctl and sysrq let one
      dump every cpu buffers when an oops or panic happens.
      
      It's nice when you have few cpus but it may take ages if have many,
      plus you miss the real origin of the problem in all the cpu traces.
      
      Sometimes, all you need is to dump the cpu buffer that triggered the
      opps, most of the time it is our main interest.
      
      This patch modifies ftrace_dump_on_oops to handle this choice.
      
      The ftrace_dump_on_oops kernel parameter, when it comes alone, has
      the same behaviour than before. But ftrace_dump_on_oops=orig_cpu
      will only dump the buffer of the cpu that oops'ed.
      
      Similarly, sysctl kernel.ftrace_dump_on_oops=1 and
      echo 1 > /proc/sys/kernel/ftrace_dump_on_oops keep their previous
      behaviour. But setting 2 jumps into cpu origin dump mode.
      
      v2: Fix double setup
      v3: Fix spelling issues reported by Randy Dunlap
      v4: Also update __ftrace_dump in the selftests
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      cecbca96
  22. 13 4月, 2010 2 次提交
  23. 07 4月, 2010 1 次提交
  24. 13 2月, 2010 1 次提交
  25. 17 1月, 2010 1 次提交
    • R
      kernel.h: add BUILD_BUG_ON_NOT_POWER_OF_2() · cc8ef6eb
      Roland Dreier 提交于
      Add BUILD_BUG_ON_NOT_POWER_OF_2()
      
      When code relies on a constant being a power of 2:
      
      	#define FOO	512	/* must be a power of 2 */
      
      it would be nice to be able to do:
      
      	BUILD_BUG_ON(!is_power_of_2(FOO));
      
      However applying an inline function does not result in a compile-time
      constant that can be used with BUILD_BUG_ON(), so trying that gives
      results in:
      
      	error: bit-field '<anonymous>' width not an integer constant
      
      As suggested by akpm, rather than monkeying around with is_power_of_2()
      and risking gcc warts about constant expressions, just create a macro
      BUILD_BUG_ON_NOT_POWER_OF_2() to encapsulate this common requirement.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Cc: Bart Van Assche <bvanassche@acm.org>
      Cc: David Dillow <dave@thedillows.org>
      Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cc8ef6eb
  26. 28 12月, 2009 1 次提交
  27. 16 12月, 2009 3 次提交