1. 22 2月, 2011 1 次提交
  2. 19 2月, 2011 1 次提交
    • L
      Expand CONFIG_DEBUG_LIST to several other list operations · 3c18d4de
      Linus Torvalds 提交于
      When list debugging is enabled, we aim to readably show list corruption
      errors, and the basic list_add/list_del operations end up having extra
      debugging code in them to do some basic validation of the list entries.
      
      However, "list_del_init()" and "list_move[_tail]()" ended up avoiding
      the debug code due to how they were written. This fixes that.
      
      So the _next_ time we have list_move() problems with stale list entries,
      we'll hopefully have an easier time finding them..
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3c18d4de
  3. 18 2月, 2011 2 次提交
  4. 17 2月, 2011 1 次提交
  5. 16 2月, 2011 1 次提交
  6. 14 2月, 2011 1 次提交
  7. 11 2月, 2011 3 次提交
  8. 09 2月, 2011 2 次提交
  9. 05 2月, 2011 2 次提交
    • T
      genirq: Add missing status flags to modification mask · 872434d6
      Thomas Gleixner 提交于
      The mask which filters out the valid bits which can be set via
      irq_modify_status() is missing IRQ_NO_BALANCING, which breaks UV.
      
      Add IRQ_PER_CPU as well to avoid another one line patch for 39.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      872434d6
    • P
      USB: Fix trout build failure with ci13xxx_msm gadget · 8cf28f1f
      Pavankumar Kondeti 提交于
      This patch fixes the below compilation errors.
      
        CC      drivers/usb/gadget/ci13xxx_msm.o
        CC      net/mac80211/led.o
        drivers/usb/gadget/ci13xxx_msm.c: In function 'ci13xxx_msm_notify_event':
        drivers/usb/gadget/ci13xxx_msm.c:42: error: 'USB_AHBBURST' undeclared (first use in this function)
        drivers/usb/gadget/ci13xxx_msm.c:42: error: (Each undeclared identifier is reported only once
        drivers/usb/gadget/ci13xxx_msm.c:42: error: for each function it appears in.)
        drivers/usb/gadget/ci13xxx_msm.c:43: error: 'USB_AHBMODE' undeclared (first use in this function)
      make[4]: *** [drivers/usb/gadget/ci13xxx_msm.o] Error 1
      make[3]: *** [drivers/usb/gadget] Error 2
      
      MSM USB driver is not supported on boards like trout (MSM7201) which
      has an external PHY.
      Signed-off-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8cf28f1f
  10. 04 2月, 2011 1 次提交
  11. 03 2月, 2011 6 次提交
    • S
      tracing: Replace syscall_meta_data struct array with pointer array · 3d56e331
      Steven Rostedt 提交于
      Currently the syscall_meta structures for the syscall tracepoints are
      placed in the __syscall_metadata section, and at link time, the linker
      makes one large array of all these syscall metadata structures. On boot
      up, this array is read (much like the initcall sections) and the syscall
      data is processed.
      
      The problem is that there is no guarantee that gcc will place complex
      structures nicely together in an array format. Two structures in the
      same file may be placed awkwardly, because gcc has no clue that they
      are suppose to be in an array.
      
      A hack was used previous to force the alignment to 4, to pack the
      structures together. But this caused alignment issues with other
      architectures (sparc).
      
      Instead of packing the structures into an array, the structures' addresses
      are now put into the __syscall_metadata section. As pointers are always the
      natural alignment, gcc should always pack them tightly together
      (otherwise initcall, extable, etc would also fail).
      
      By having the pointers to the structures in the section, we can still
      iterate the trace_events without causing unnecessary alignment problems
      with other architectures, or depending on the current behaviour of
      gcc that will likely change in the future just to tick us kernel developers
      off a little more.
      
      The __syscall_metadata section is also moved into the .init.data section
      as it is now only needed at boot up.
      Suggested-by: NDavid Miller <davem@davemloft.net>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      3d56e331
    • M
      tracepoints: Fix section alignment using pointer array · 65498646
      Mathieu Desnoyers 提交于
      Make the tracepoints more robust, making them solid enough to handle compiler
      changes by not relying on anything based on compiler-specific behavior with
      respect to structure alignment. Implement an approach proposed by David Miller:
      use an array of const pointers to refer to the individual structures, and export
      this pointer array through the linker script rather than the structures per se.
      It will consume 32 extra bytes per tracepoint (24 for structure padding and 8
      for the pointers), but are less likely to break due to compiler changes.
      
      History:
      
      commit 7e066fb8 tracepoints: add DECLARE_TRACE() and DEFINE_TRACE()
      added the aligned(32) type and variable attribute to the tracepoint structures
      to deal with gcc happily aligning statically defined structures on 32-byte
      multiples.
      
      One attempt was to use a 8-byte alignment for tracepoint structures by applying
      both the variable and type attribute to tracepoint structures definitions and
      declarations. It worked fine with gcc 4.5.1, but broke with gcc 4.4.4 and 4.4.5.
      
      The reason is that the "aligned" attribute only specify the _minimum_ alignment
      for a structure, leaving both the compiler and the linker free to align on
      larger multiples. Because tracepoint.c expects the structures to be placed as an
      array within each section, up-alignment cause NULL-pointer exceptions due to the
      extra unexpected padding.
      
      (this patch applies on top of -tip)
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      LKML-Reference: <20110126222622.GA10794@Krystal>
      CC: Frederic Weisbecker <fweisbec@gmail.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Peter Zijlstra <peterz@infradead.org>
      CC: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      65498646
    • S
      tracing: Replace trace_event struct array with pointer array · e4a9ea5e
      Steven Rostedt 提交于
      Currently the trace_event structures are placed in the _ftrace_events
      section, and at link time, the linker makes one large array of all
      the trace_event structures. On boot up, this array is read (much like
      the initcall sections) and the events are processed.
      
      The problem is that there is no guarantee that gcc will place complex
      structures nicely together in an array format. Two structures in the
      same file may be placed awkwardly, because gcc has no clue that they
      are suppose to be in an array.
      
      A hack was used previous to force the alignment to 4, to pack the
      structures together. But this caused alignment issues with other
      architectures (sparc).
      
      Instead of packing the structures into an array, the structures' addresses
      are now put into the _ftrace_event section. As pointers are always the
      natural alignment, gcc should always pack them tightly together
      (otherwise initcall, extable, etc would also fail).
      
      By having the pointers to the structures in the section, we can still
      iterate the trace_events without causing unnecessary alignment problems
      with other architectures, or depending on the current behaviour of
      gcc that will likely change in the future just to tick us kernel developers
      off a little more.
      
      The _ftrace_event section is also moved into the .init.data section
      as it is now only needed at boot up.
      Suggested-by: NDavid Miller <davem@davemloft.net>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      e4a9ea5e
    • N
      vfs: sparse: add __FMODE_EXEC · 3cd90ea4
      Namhyung Kim 提交于
      FMODE_EXEC is a constant type of fmode_t but was used with normal integer
      constants.  This results in following warnings from sparse.  Fix it using
      new macro __FMODE_EXEC.
      
       fs/exec.c:116:58: warning: restricted fmode_t degrades to integer
       fs/exec.c:689:58: warning: restricted fmode_t degrades to integer
       fs/fcntl.c:777:9: warning: restricted fmode_t degrades to integer
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3cd90ea4
    • N
      vfs: sparse: remove a warning on OPEN_FMODE() · 1a44bc8c
      Namhyung Kim 提交于
      AND-ing FMODE_* constant with normal integer results in following
      sparse warnings. Fix it.
      
       fs/open.c:662:21: warning: restricted fmode_t degrades to integer
       fs/anon_inodes.c:123:34: warning: restricted fmode_t degrades to integer
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1a44bc8c
    • J
      memcg: prevent endless loop when charging huge pages to near-limit group · 19942822
      Johannes Weiner 提交于
      If reclaim after a failed charging was unsuccessful, the limits are
      checked again, just in case they settled by means of other tasks.
      
      This is all fine as long as every charge is of size PAGE_SIZE, because in
      that case, being below the limit means having at least PAGE_SIZE bytes
      available.
      
      But with transparent huge pages, we may end up in an endless loop where
      charging and reclaim fail, but we keep going because the limits are not
      yet exceeded, although not allowing for a huge page.
      
      Fix this up by explicitely checking for enough room, not just whether we
      are within limits.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Reviewed-by: NMinchan Kim <minchan.kim@gmail.com>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      19942822
  12. 01 2月, 2011 1 次提交
  13. 30 1月, 2011 2 次提交
  14. 27 1月, 2011 2 次提交
  15. 26 1月, 2011 4 次提交
  16. 25 1月, 2011 3 次提交
    • T
      block: reimplement FLUSH/FUA to support merge · ae1b1539
      Tejun Heo 提交于
      The current FLUSH/FUA support has evolved from the implementation
      which had to perform queue draining.  As such, sequencing is done
      queue-wide one flush request after another.  However, with the
      draining requirement gone, there's no reason to keep the queue-wide
      sequential approach.
      
      This patch reimplements FLUSH/FUA support such that each FLUSH/FUA
      request is sequenced individually.  The actual FLUSH execution is
      double buffered and whenever a request wants to execute one for either
      PRE or POSTFLUSH, it queues on the pending queue.  Once certain
      conditions are met, a flush request is issued and on its completion
      all pending requests proceed to the next sequence.
      
      This allows arbitrary merging of different type of flushes.  How they
      are merged can be primarily controlled and tuned by adjusting the
      above said 'conditions' used to determine when to issue the next
      flush.
      
      This is inspired by Darrick's patches to merge multiple zero-data
      flushes which helps workloads with highly concurrent fsync requests.
      
      * As flush requests are never put on the IO scheduler, request fields
        used for flush share space with rq->rb_node.  rq->completion_data is
        moved out of the union.  This increases the request size by one
        pointer.
      
        As rq->elevator_private* are used only by the iosched too, it is
        possible to reduce the request size further.  However, to do that,
        we need to modify request allocation path such that iosched data is
        not allocated for flush requests.
      
      * FLUSH/FUA processing happens on insertion now instead of dispatch.
      
      - Comments updated as per Vivek and Mike.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: "Darrick J. Wong" <djwong@us.ibm.com>
      Cc: Shaohua Li <shli@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      ae1b1539
    • T
      block: add REQ_FLUSH_SEQ · 414b4ff5
      Tejun Heo 提交于
      rq == &q->flush_rq was used to determine whether a rq is part of a
      flush sequence, which worked because all requests in a flush sequence
      were sequenced using the single dedicated request.  This is about to
      change, so introduce REQ_FLUSH_SEQ flag to distinguish flush sequence
      requests.
      
      This patch doesn't cause any behavior change.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      414b4ff5
    • A
      Input: sysrq - ensure sysrq_enabled and __sysrq_enabled are consistent · 8c6a98b2
      Andy Whitcroft 提交于
      Currently sysrq_enabled and __sysrq_enabled are initialised separately
      and inconsistently, leading to sysrq being actually enabled by reported
      as not enabled in sysfs.  The first change to the sysfs configurable
      synchronises these two:
      
          static int __read_mostly sysrq_enabled = 1;
          static int __sysrq_enabled;
      
      Add a common define to carry the default for these preventing them becoming
      out of sync again.  Default this to 1 to mirror previous behaviour.
      Signed-off-by: NAndy Whitcroft <apw@canonical.com>
      Cc: stable@kernel.org
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      8c6a98b2
  17. 24 1月, 2011 5 次提交
    • 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
    • L
      param: add null statement to compiled-in module params · b75be420
      Linus Walleij 提交于
      Add an unused struct declaration statement requiring a
      terminating semicolon to the compile-in case to provoke an
      error if __MODULE_INFO() is used without the terminating
      semicolon. Previously MODULE_ALIAS("foo") (no semicolon)
      compiled fine if MODULE was not selected.
      
      Cc: Dan Carpenter <error27@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      b75be420
    • R
      module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n · 3b90a5b2
      Rusty Russell 提交于
      lib/built-in.o:(__modver+0x8): undefined reference to `__modver_version_show'
      lib/built-in.o:(__modver+0x2c): undefined reference to `__modver_version_show'
      
      Simplest to just not emit anything: if they've disabled SYSFS they probably
      want the smallest kernel possible.
      Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      3b90a5b2
    • D
      module: show version information for built-in modules in sysfs · e94965ed
      Dmitry Torokhov 提交于
      Currently only drivers that are built as modules have their versions
      shown in /sys/module/<module_name>/version, but this information might
      also be useful for built-in drivers as well. This especially important
      for drivers that do not define any parameters - such drivers, if
      built-in, are completely invisible from userspace.
      
      This patch changes MODULE_VERSION() macro so that in case when we are
      compiling built-in module, version information is stored in a separate
      section. Kernel then uses this data to create 'version' sysfs attribute
      in the same fashion it creates attributes for module parameters.
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      e94965ed
  18. 23 1月, 2011 1 次提交
    • L
      USB: serial: handle Data Carrier Detect changes · d14fc1a7
      Libor Pechacek 提交于
      Alan's commit 335f8514 introduced
      .carrier_raised function in several drivers.  That also means
      tty_port_block_til_ready can now suspend the process trying to open the serial
      port when Carrier Detect is low and put it into tty_port.open_wait queue.  We
      need to wake up the process when Carrier Detect goes high and trigger TTY
      hangup when CD goes low.
      
      Some of the devices do not report modem status line changes, or at least we
      don't understand the status message, so for those we remove .carrier_raised
      again.
      Signed-off-by: NLibor Pechacek <lpechacek@suse.cz>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d14fc1a7
  19. 22 1月, 2011 1 次提交