1. 24 7月, 2015 8 次提交
  2. 25 6月, 2015 1 次提交
    • J
      mm: oom_kill: simplify OOM killer locking · dc56401f
      Johannes Weiner 提交于
      The zonelist locking and the oom_sem are two overlapping locks that are
      used to serialize global OOM killing against different things.
      
      The historical zonelist locking serializes OOM kills from allocations with
      overlapping zonelists against each other to prevent killing more tasks
      than necessary in the same memory domain.  Only when neither tasklists nor
      zonelists from two concurrent OOM kills overlap (tasks in separate memcgs
      bound to separate nodes) are OOM kills allowed to execute in parallel.
      
      The younger oom_sem is a read-write lock to serialize OOM killing against
      the PM code trying to disable the OOM killer altogether.
      
      However, the OOM killer is a fairly cold error path, there is really no
      reason to optimize for highly performant and concurrent OOM kills.  And
      the oom_sem is just flat-out redundant.
      
      Replace both locking schemes with a single global mutex serializing OOM
      kills regardless of context.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc56401f
  3. 23 6月, 2015 2 次提交
  4. 22 6月, 2015 2 次提交
  5. 17 6月, 2015 3 次提交
    • S
      tty/vt/keyboard: define LED triggers for VT keyboard lock states · eeb64c14
      Samuel Thibault 提交于
      In addition to defining triggers for VT LED states, let's define triggers
      for VT keyboard lock states, such as "kbd-shiftlock", "kbd-altgrlock", etc.
      
      This permits to fix #7063 from userland by using a modifier to implement
      proper CapsLock behavior and have the keyboard caps lock led show that
      modifier state.
      Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
      Tested-by: NPavel Machek <pavel@ucw.cz>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      eeb64c14
    • S
      tty/vt/keyboard: define LED triggers for VT LED states · 52355522
      Samuel Thibault 提交于
      Now that input core allows controlling keyboards LEDs via standard LED
      subsystem triggers let's switch VT keyboard code to make use of this
      feature. We will define the following standard triggers: "kbd-scrollock",
      "kbd-numlock", "kbd-capslock", and "kbd-kanalock" which are default
      triggers for respective LEDs on keyboards.
      Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
      Tested-by: NPavel Machek <pavel@ucw.cz>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      52355522
    • J
      tty/metag_da: Avoid module_init/module_exit in non-modular code · 4d38e5c4
      James Hogan 提交于
      The metag_da TTY driver can't get built as a module at the moment, but
      it still uses module_init() and module_exit(). Those macros are moving
      to module.h which isn't included by metag_da.c, which will result in the
      following build warnings (remarkably no build errors) and an apparent
      failure to boot as the TTY driver won't be loaded.
      
      drivers/tty/metag_da.c:660: warning: data definition has no type or storage class
      drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration of ‘module_init’
      drivers/tty/metag_da.c:660: warning: parameter names (without types) in function declaration
      drivers/tty/metag_da.c:661: warning: data definition has no type or storage class
      drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration of ‘module_exit’
      drivers/tty/metag_da.c:661: warning: parameter names (without types) in function declaration
      drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used
      drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used
      drivers/tty/metag_da.c In function ‘dash_console_write’:
      drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ discards qualifiers from pointer target type
      
      Instead of just adding the module.h include, now would be a good time to
      remove the use of these macros, replacing the module_init with
      device_initcall, and removing the exit function altogether since it
      isn't needed. If module support is added later the code can always be
      resurrected.
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: linux-metag@vger.kernel.org
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      4d38e5c4
  6. 13 6月, 2015 4 次提交
  7. 11 6月, 2015 1 次提交
  8. 10 6月, 2015 3 次提交
  9. 03 6月, 2015 1 次提交
    • A
      tty: remove platform_sysrq_reset_seq · ffb6e0c9
      Arnd Bergmann 提交于
      The platform_sysrq_reset_seq code was intended as a way for an embedded
      platform to provide its own sysrq sequence at compile time. After over two
      years, nobody has started using it in an upstream kernel, and the platforms
      that were interested in it have moved on to devicetree, which can be used
      to configure the sequence without requiring kernel changes. The method is
      also incompatible with the way that most architectures build support for
      multiple platforms into a single kernel.
      
      Now the code is producing warnings when built with gcc-5.1:
      
      drivers/tty/sysrq.c: In function 'sysrq_init':
      drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds]
         key = platform_sysrq_reset_seq[i];
      
      We could fix this, but it seems unlikely that it will ever be used, so
      let's just remove the code instead. We still have the option to pass the
      sequence either in DT, using the kernel command line, or using the
      /sys/module/sysrq/parameters/reset_seq file.
      
      Fixes: 154b7a48 ("Input: sysrq - allow specifying alternate reset sequence")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      ffb6e0c9
  10. 01 6月, 2015 15 次提交