This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 29 Nov, 2016 1 commit
  2. 21 Oct, 2016 1 commit
  3. 14 Oct, 2016 2 commits
  4. 13 Oct, 2016 1 commit
    • Tom Herbert's avatar
      net/mlx5: Add MLX5_ARRAY_SET64 to fix BUILD_BUG_ON · b8a4ddb2
      Tom Herbert authored
      I am hitting this in mlx5:
      
      drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function
      reclaim_pages_cmd.clone.0:
      drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:346: error: call
      to __compiletime_assert_346 declared with attribute error:
      BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_out, pas[i]) % 64
      drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function give_pages:
      drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:291: error: call
      to __compiletime_assert_291 declared with attribute error:
      BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_in, pas[i]) % 64
      
      Problem is that this is doing a BUILD_BUG_ON on a non-constant
      expression because of trying to take offset of pas[i] in the
      structure.
      
      Fix is to create MLX5_ARRAY_SET64 that takes an additional argument
      that is the field index to separate between BUILD_BUG_ON on the array
      constant field and the indexed field to assign the value to.
      There are two callers of MLX5_SET64 that are trying to get a variable
      offset, change those to call MLX5_ARRAY_SET64 passing 'pas' and 'i'
      as the arguments to use in the offset check and the indexed value
      assignment.
      
      Fixes: a533ed5e
      
       ("net/mlx5: Pages management commands via mlx5 ifc")
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8a4ddb2
  5. 12 Oct, 2016 1 commit
  6. 11 Oct, 2016 24 commits
    • Michal Hocko's avatar
      mm: split gfp_mask and mapping flags into separate fields · 9c5d760b
      Michal Hocko authored
      mapping->flags currently encodes two different things into a single flag.
      It contains sticky gfp_mask for page cache allocations and AS_ codes used
      to report errors/enospace and other states which are mapping specific.
      Condensing the two semantically unrelated things saves few bytes but it
      also complicates other things.  For one thing the gfp flags space is
      reduced and in fact we are already running out of available bits.  It can
      be assumed that more gfp flags will be necessary later on.
      
      To not introduce the address_space grow (at least on x86_64) we can stick
      it right after private_lock because we have a hole there.
      
      struct address_space {
              struct inode *             host;                 /*     0     8 */
              struct radix_tree_root     page_tree;            /*     8    16 */
              spinlock_t                 tree_lock;            /*    24     4 */
              atomic_t                   i_mmap_writable;      /*    28     4 */
              struct rb_root             i_mmap;               /*    32     8 */
              struct rw_semaphore        i_mmap_rwsem;         /*    40    40 */
              /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */
              long unsigned int          nrpages;              /*    80     8 */
              long unsigned int          nrexceptional;        /*    88     8 */
              long unsigned int          writeback_index;      /*    96     8 */
              const struct address_space_operations  * a_ops;  /*   104     8 */
              long unsigned int          flags;                /*   112     8 */
              spinlock_t                 private_lock;         /*   120     4 */
      
              /* XXX 4 bytes hole, try to pack */
      
              /* --- cacheline 2 boundary (128 bytes) --- */
              struct list_head           private_list;         /*   128    16 */
              void *                     private_data;         /*   144     8 */
      
              /* size: 152, cachelines: 3, members: 14 */
              /* sum members: 148, holes: 1, sum holes: 4 */
              /* last cacheline: 24 bytes */
      };
      
      Link: http://lkml.kernel.org/r/20160912114852.GI14524@dhcp22.suse.cz
      
      
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9c5d760b
    • Masahiro Yamada's avatar
      treewide: remove redundant #include <linux/kconfig.h> · 97139d4a
      Masahiro Yamada authored
      Kernel source files need not include <linux/kconfig.h> explicitly
      because the top Makefile forces to include it with:
      
        -include $(srctree)/include/linux/kconfig.h
      
      This commit removes explicit includes except the following:
      
        * arch/s390/include/asm/facilities_src.h
        * tools/testing/radix-tree/linux/kernel.h
      
      These two are used for host programs.
      
      Link: http://lkml.kernel.org/r/1473656164-11929-1-git-send-email-yamada.masahiro@socionext.com
      
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      97139d4a
    • Jonathan Corbet's avatar
      kthread: add kerneldoc for kthread_create() · e154ccc8
      Jonathan Corbet authored
      This macro is referenced in other kerneldoc comments, but lacks one of its
      own; fix that.
      
      Link: http://lkml.kernel.org/r/20160826072313.726a3485@lwn.net
      
      
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      Reported-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e154ccc8
    • Petr Mladek's avatar
      kthread: better support freezable kthread workers · dbf52682
      Petr Mladek authored
      This patch allows to make kthread worker freezable via a new @flags
      parameter. It will allow to avoid an init work in some kthreads.
      
      It currently does not affect the function of kthread_worker_fn()
      but it might help to do some optimization or fixes eventually.
      
      I currently do not know about any other use for the @flags
      parameter but I believe that we will want more flags
      in the future.
      
      Finally, I hope that it will not cause confusion with @flags member
      in struct kthread. Well, I guess that we will want to rework the
      basic kthreads implementation once all kthreads are converted into
      kthread workers or workqueues. It is possible that we will merge
      the two structures.
      
      Link: http://lkml.kernel.org/r/1470754545-17632-12-git-send-email-pmladek@suse.com
      
      
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dbf52682
    • Petr Mladek's avatar
      kthread: allow to modify delayed kthread work · 9a6b06c8
      Petr Mladek authored
      There are situations when we need to modify the delay of a delayed kthread
      work. For example, when the work depends on an event and the initial delay
      means a timeout. Then we want to queue the work immediately when the event
      happens.
      
      This patch implements kthread_mod_delayed_work() as inspired workqueues.
      It cancels the timer, removes the work from any worker list and queues it
      again with the given timeout.
      
      A very special case is when the work is being canceled at the same time.
      It might happen because of the regular kthread_cancel_delayed_work_sync()
      or by another kthread_mod_delayed_work(). In this case, we do nothing and
      let the other operation win. This should not normally happen as the caller
      is supposed to synchronize these operations a reasonable way.
      
      Link: http://lkml.kernel.org/r/1470754545-17632-11-git-send-email-pmladek@suse.com
      
      
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9a6b06c8
    • Petr Mladek's avatar
      kthread: allow to cancel kthread work · 37be45d4
      Petr Mladek authored
      We are going to use kthread workers more widely and sometimes we will need
      to make sure that the work is neither pending nor running.
      
      This patch implements cancel_*_sync() operations as inspired by
      workqueues.  Well, we are synchronized against the other operations via
      the worker lock, we use del_timer_sync() and a counter to count parallel
      cancel operations.  Therefore the implementation might be easier.
      
      First, we check if a worker is assigned.  If not, the work has newer been
      queued after it was initialized.
      
      Second, we take the worker lock.  It must be the right one.  The work must
      not be assigned to another worker unless it is initialized in between.
      
      Third, we try to cancel the timer when it exists.  The timer is deleted
      synchronously to make sure that the timer call back is not running.  We
      need to temporary release the worker->lock to avoid a possible deadlock
      with the callback.  In the meantime, we set work->canceling counter to
      avoid any queuing.
      
      Fourth, we try to remove the work from a worker list. It might be
      the list of either normal or delayed works.
      
      Fifth, if the work is running, we call kthread_flush_work().  It might
      take an arbitrary time.  We need to release the worker-lock again.  In the
      meantime, we again block any queuing by the canceling counter.
      
      As already mentioned, the check for a pending kthread work is done under a
      lock.  In compare with workqueues, we do not need to fight for a single
      PENDING bit to block other operations.  Therefore we do not suffer from
      the thundering storm problem and all parallel canceling jobs might use
      kthread_flush_work().  Any queuing is blocked until the counter gets zero.
      
      Link: http://lkml.kernel.org/r/1470754545-17632-10-git-send-email-pmladek@suse.com
      
      
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      37be45d4
    • Petr Mladek's avatar
      kthread: initial support for delayed kthread work · 22597dc3
      Petr Mladek authored
      We are going to use kthread_worker more widely and delayed works
      will be pretty useful.
      
      The implementation is inspired by workqueues.  It uses a timer to queue
      the work after the requested delay.  If the delay is zero, the work is
      queued immediately.
      
      In compare with workqueues, each work is associated with a single worker
      (kthread).  Therefore the implementation could be much easier.  In
      particular, we use the worker->lock to synchronize all the operations with
      the work.  We do not need any atomic operation with a flags variable.
      
      In fact, we do not need any state variable at all.  Instead, we add a list
      of delayed works into the worker.  Then the pending work is listed either
      in the list of queued or delayed works.  And the existing check of pending
      works is the same even for the delayed ones.
      
      A work must not be assigned to another worker unless reinitialized.
      Therefore the timer handler might expect that dwork->work->worker is valid
      and it could simply take the lock.  We just add some sanity checks to help
      with debugging a potential misuse.
      
      Link: http://lkml.kernel.org/r/1470754545-17632-9-git-send-email-pmladek@suse.com
      
      
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      22597dc3
    • Petr Mladek's avatar
      kthread: add kthread_destroy_worker() · 35033fe9
      Petr Mladek authored
      The current kthread worker users call flush() and stop() explicitly.
      This function does the same plus it frees the kthread_worker struct
      in one call.
      
      It is supposed to be used together with kthread_create_worker*() that
      allocates struct kthread_worker.
      
      Link: http://lkml.kernel.org/r/1470754545-17632-7-git-send-email-pmladek@suse.com
      
      
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      35033fe9
    • Petr Mladek's avatar
      kthread: add kthread_create_worker*() · fbae2d44
      Petr Mladek authored
      Kthread workers are currently created using the classic kthread API,
      namely kthread_run().  kthread_worker_fn() is passed as the @threadfn
      parameter.
      
      This patch defines kthread_create_worker() and
      kthread_create_worker_on_cpu() functions that hide implementation details.
      
      They enforce using kthread_worker_fn() for the main thread.  But I doubt
      that there are any plans to create any alternative.  In fact, I think that
      we do not want any alternative main thread because it would be hard to
      support consistency with the rest of the kthread worker API.
      
      The naming and function of kthread_create_worker() is inspired by the
      workqueues API like the rest of the kthread worker API.
      
      The kthread_create_worker_on_cpu() variant is motivated by the original
      kthread_create_on_cpu().  Note that we need to bind per-CPU kthread
      workers already when they are created.  It makes the life easier.
      kthread_bind() could not be used later for an already running worker.
      
      This patch does _not_ convert existing kthread workers.  The kthread
      worker API need more improvements first, e.g.  a function to destroy the
      worker.
      
      IMPORTANT:
      
      kthread_create_worker_on_cpu() allows to use any format of the worker
      name, in compare with kthread_create_on_cpu().  The good thing is that it
      is more generic.  The bad thing is that most users will need to pass the
      cpu number in two parameters, e.g.  kthread_create_worker_on_cpu(cpu,
      "helper/%d", cpu).
      
      To be honest, the main motivation was to avoid the need for an empty
      va_list.  The only legal way was to create a helper function that would be
      called with an empty list.  Other attempts caused compilation warnings or
      even errors on different architectures.
      
      There were also other alternatives, for example, using #define or
      splitting __kthread_create_worker().  The used solution looked like the
      least ugly.
      
      Link: http://lkml.kernel.org/r/1470754545-17632-6-git-send-email-pmladek@suse.com
      
      
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fbae2d44
    • Petr Mladek's avatar
      kthread: kthread worker API cleanup · 3989144f
      Petr Mladek authored
      A good practice is to prefix the names of functions by the name
      of the subsystem.
      
      The kthread worker API is a mix of classic kthreads and workqueues.  Each
      worker has a dedicated kthread.  It runs a generic function that process
      queued works.  It is implemented as part of the kthread subsystem.
      
      This patch renames the existing kthread worker API to use
      the corresponding name from the workqueues API prefixed by
      kthread_:
      
      __init_kthread_worker()		-> __kthread_init_worker()
      init_kthread_worker()		-> kthread_init_worker()
      init_kthread_work()		-> kthread_init_work()
      insert_kthread_work()		-> kthread_insert_work()
      queue_kthread_work()		-> kthread_queue_work()
      flush_kthread_work()		-> kthread_flush_work()
      flush_kthread_worker()		-> kthread_flush_worker()
      
      Note that the names of DEFINE_KTHREAD_WORK*() macros stay
      as they are. It is common that the "DEFINE_" prefix has
      precedence over the subsystem names.
      
      Note that INIT() macros and init() functions use different
      naming scheme. There is no good solution. There are several
      reasons for this solution:
      
        + "init" in the function names stands for the verb "initialize"
          aka "initialize worker". While "INIT" in the macro names
          stands for the noun "INITIALIZER" aka "worker initializer".
      
        + INIT() macros are used only in DEFINE() macros
      
        + init() functions are used close to the other kthread()
          functions. It looks much better if all the functions
          use the same scheme.
      
        + There will be also kthread_destroy_worker() that will
          be used close to kthread_cancel_work(). It is related
          to the init() function. Again it looks better if all
          functions use the same naming scheme.
      
        + there are several precedents for such init() function
          names, e.g. amd_iommu_init_device(), free_area_init_node(),
          jump_label_init_type(),  regmap_init_mmio_clk(),
      
        + It is not an argument but it was inconsistent even before.
      
      [arnd@arndb.de: fix linux-next merge conflict]
       Link: http://lkml.kernel.org/r/20160908135724.1311726-1-arnd@arndb.de
      Link: http://lkml.kernel.org/r/1470754545-17632-3-git-send-email-pmladek@suse.com
      
      
      Suggested-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3989144f
    • Petr Mladek's avatar
      kthread: rename probe_kthread_data() to kthread_probe_data() · e700591a
      Petr Mladek authored
      Patch series "kthread: Kthread worker API improvements"
      
      The intention of this patchset is to make it easier to manipulate and
      maintain kthreads.  Especially, I want to replace all the custom main
      cycles with a generic one.  Also I want to make the kthreads sleep in a
      consistent state in a common place when there is no work.
      
      This patch (of 11):
      
      A good practice is to prefix the names of functions by the name of the
      subsystem.
      
      This patch fixes the name of probe_kthread_data().  The other wrong
      functions names are part of the kthread worker API and will be fixed
      separately.
      
      Link: http://lkml.kernel.org/r/1470754545-17632-2-git-send-email-pmladek@suse.com
      
      
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Suggested-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e700591a
    • Catalin Marinas's avatar
      mm: kmemleak: avoid using __va() on addresses that don't have a lowmem mapping · 9099daed
      Catalin Marinas authored
      Some of the kmemleak_*() callbacks in memblock, bootmem, CMA convert a
      physical address to a virtual one using __va().  However, such physical
      addresses may sometimes be located in highmem and using __va() is
      incorrect, leading to inconsistent object tracking in kmemleak.
      
      The following functions have been added to the kmemleak API and they take
      a physical address as the object pointer.  They only perform the
      corresponding action if the address has a lowmem mapping:
      
      kmemleak_alloc_phys
      kmemleak_free_part_phys
      kmemleak_not_leak_phys
      kmemleak_ignore_phys
      
      The affected calling places have been updated to use the new kmemleak
      API.
      
      Link: http://lkml.kernel.org/r/1471531432-16503-1-git-send-email-catalin.marinas@arm.com
      
      
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: default avatarVignesh R <vigneshr@ti.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9099daed
    • Thomas Garnier's avatar
      kdump, vmcoreinfo: report memory sections virtual addresses · 0549a3c0
      Thomas Garnier authored
      KASLR memory randomization can randomize the base of the physical memory
      mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
      (VMEMMAP_START).  Adding these variables on VMCOREINFO so tools can easily
      identify the base of each memory section.
      
      Link: http://lkml.kernel.org/r/1471531632-23003-1-git-send-email-thgarnie@google.com
      
      
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Acked-by: default avatarBaoquan He <bhe@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Xunlei Pang <xlpang@redhat.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Eugene Surovegin <surovegin@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0549a3c0
    • Manfred Spraul's avatar
      ipc/sem.c: fix complex_count vs. simple op race · 5864a2fd
      Manfred Spraul authored
      Commit 6d07b68c ("ipc/sem.c: optimize sem_lock()") introduced a
      race:
      
      sem_lock has a fast path that allows parallel simple operations.
      There are two reasons why a simple operation cannot run in parallel:
       - a non-simple operations is ongoing (sma->sem_perm.lock held)
       - a complex operation is sleeping (sma->complex_count != 0)
      
      As both facts are stored independently, a thread can bypass the current
      checks by sleeping in the right positions.  See below for more details
      (or kernel bugzilla 105651).
      
      The patch fixes that by creating one variable (complex_mode)
      that tracks both reasons why parallel operations are not possible.
      
      The patch also updates stale documentation regarding the locking.
      
      With regards to stable kernels:
      The patch is required for all kernels that include the
      commit 6d07b68c ("ipc/sem.c: optimize sem_lock()") (3.10?)
      
      The alternative is to revert the patch that introduced the race.
      
      The patch is safe for backporting, i.e. it makes no assumptions
      about memory barriers in spin_unlock_wait().
      
      Background:
      Here is the race of the current implementation:
      
      Thread A: (simple op)
      - does the first "sma->complex_count == 0" test
      
      Thread B: (complex op)
      - does sem_lock(): This includes an array scan. But the scan can't
        find Thread A, because Thread A does not own sem->lock yet.
      - the thread does the operation, increases complex_count,
        drops sem_lock, sleeps
      
      Thread A:
      - spin_lock(&sem->lock), spin_is_locked(sma->sem_perm.lock)
      - sleeps before the complex_count test
      
      Thread C: (complex op)
      - does sem_lock (no array scan, complex_count==1)
      - wakes up Thread B.
      - decrements complex_count
      
      Thread A:
      - does the complex_count test
      
      Bug:
      Now both thread A and thread C operate on the same array, without
      any synchronization.
      
      Fixes: 6d07b68c ("ipc/sem.c: optimize sem_lock()")
      Link: http://lkml.kernel.org/r/1469123695-5661-1-git-send-email-manfred@colorfullife.com
      
      
      Reported-by: default avatar <felixh@informatik.uni-bremen.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: <1vier1@web.de>
      Cc: <stable@vger.kernel.org>	[3.10+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5864a2fd
    • Peter Zijlstra's avatar
      relay: Use irq_work instead of plain timer for deferred wakeup · 26b5679e
      Peter Zijlstra authored
      Relay avoids calling wake_up_interruptible() for doing the wakeup of
      readers/consumers, waiting for the generation of new data, from the
      context of a process which produced the data.  This is apparently done to
      prevent the possibility of a deadlock in case Scheduler itself is is
      generating data for the relay, after acquiring rq->lock.
      
      The following patch used a timer (to be scheduled at next jiffy), for
      delegating the wakeup to another context.
      	commit 7c9cb383
      	Author: Tom Zanussi <zanussi@comcast.net>
      	Date:   Wed May 9 02:34:01 2007 -0700
      
      	relay: use plain timer instead of delayed work
      
      	relay doesn't need to use schedule_delayed_work() for waking readers
      	when a simple timer will do.
      
      Scheduling a plain timer, at next jiffies boundary, to do the wakeup
      causes a significant wakeup latency for the Userspace client, which makes
      relay less suitable for the high-frequency low-payload use cases where the
      data gets generated at a very high rate, like multiple sub buffers getting
      filled within a milli second.  Moreover the timer is re-scheduled on every
      newly produced sub buffer so the timer keeps getting pushed out if sub
      buffers are filled in a very quick succession (less than a jiffy gap
      between filling of 2 sub buffers).  As a result relay runs out of sub
      buffers to store the new data.
      
      By using irq_work it is ensured that wakeup of userspace client, blocked
      in the poll call, is done at earliest (through self IPI or next timer
      tick) enabling it to always consume the data in time.  Also this makes
      relay consistent with printk & ring buffers (trace), as they too use
      irq_work for deferred wake up of readers.
      
      [arnd@arndb.de: select CONFIG_IRQ_WORK]
       Link: http://lkml.kernel.org/r/20160912154035.3222156-1-arnd@arndb.de
      [akpm@linux-foundation.org: coding-style fixes]
      Link: http://lkml.kernel.org/r/1472906487-1559-1-git-send-email-akash.goel@intel.com
      
      
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      26b5679e
    • Mauricio Faria de Oliveira's avatar
      dma-mapping: introduce the DMA_ATTR_NO_WARN attribute · a9a62c93
      Mauricio Faria de Oliveira authored
      Introduce the DMA_ATTR_NO_WARN attribute, and document it.
      
      Link: http://lkml.kernel.org/r/1470092390-25451-2-git-send-email-mauricfo@linux.vnet.ibm.com
      
      
      Signed-off-by: default avatarMauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a9a62c93
    • Jason Cooper's avatar
      random: remove unused randomize_range() · 7425154d
      Jason Cooper authored
      All call sites for randomize_range have been updated to use the much
      simpler and more robust randomize_addr().  Remove the now unnecessary
      code.
      
      Link: http://lkml.kernel.org/r/20160803233913.32511-8-jason@lakedaemon.net
      
      
      Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7425154d
    • Jason Cooper's avatar
      random: simplify API for random address requests · 99fdafde
      Jason Cooper authored
      To date, all callers of randomize_range() have set the length to 0, and
      check for a zero return value.  For the current callers, the only way to
      get zero returned is if end <= start.  Since they are all adding a
      constant to the start address, this is unnecessary.
      
      We can remove a bunch of needless checks by simplifying the API to do just
      what everyone wants, return an address between [start, start + range).
      
      While we're here, s/get_random_int/get_random_long/.  No current call site
      is adversely affected by get_random_int(), since all current range
      requests are < UINT_MAX.  However, we should match caller expectations to
      avoid coming up short (ha!) in the future.
      
      All current callers to randomize_range() chose to use the start address if
      randomize_range() failed.  Therefore, we simplify things by just returning
      the start address on error.
      
      randomize_range() will be removed once all callers have been converted
      over to randomize_addr().
      
      Link: http://lkml.kernel.org/r/20160803233913.32511-2-jason@lakedaemon.net
      
      
      Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: "Roberts, William C" <william.c.roberts@intel.com>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Nick Kralevich <nnk@google.com>
      Cc: Jeffrey Vander Stoep <jeffv@google.com>
      Cc: Daniel Cashman <dcashman@android.com>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      99fdafde
    • Ian Kent's avatar
      autofs4: move linux/auto_dev-ioctl.h to uapi/linux · 9b88ee0f
      Ian Kent authored
      Since linux/auto_dev-ioctl.h wasn't included in include/linux/Kbuild
      it wasn't moved to uapi/linux as part of the uapi series.
      
      Link: http://lkml.kernel.org/r/20160812024901.12352.10984.stgit@pluto.themaw.net
      
      
      Signed-off-by: default avatarIan Kent <raven@themaw.net>
      Cc: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b88ee0f
    • Tomohiro Kusumi's avatar
      autofs: move inclusion of linux/limits.h to uapi · f58b3c91
      Tomohiro Kusumi authored
      linux/limits.h should be included by uapi instead of linux/auto_fs.h
      so as not to cause compile error in userspace.
      
       # cat << EOF > ./test1.c
       > #include <stdio.h>
       > #include <linux/auto_fs.h>
       > int main(void) {
       >     return 0;
       > }
       > EOF
       # gcc -Wall -g ./test1.c
       In file included from ./test1.c:2:0:
       /usr/include/linux/auto_fs.h:54:12: error: 'NAME_MAX' undeclared here (not in a function)
         char name[NAME_MAX+1];
                   ^
      
      Link: http://lkml.kernel.org/r/20160812024856.12352.24092.stgit@pluto.themaw.net
      
      
      Signed-off-by: default avatarTomohiro Kusumi <kusumi.tomohiro@gmail.com>
      Signed-off-by: default avatarIan Kent <ikent@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f58b3c91
    • Tomohiro Kusumi's avatar
      autofs: remove AUTOFS_DEVID_LEN · 72063e01
      Tomohiro Kusumi authored
      This macro was never used by neither kernel nor userspace, and also
      doesn't represent "devid length" in bytes.  (unless it was added to mean
      something else).
      
      Link: http://lkml.kernel.org/r/20160812024820.12352.21210.stgit@pluto.themaw.net
      
      
      Signed-off-by: default avatarTomohiro Kusumi <kusumi.tomohiro@gmail.com>
      Signed-off-by: default avatarIan Kent <ikent@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      72063e01
    • Alexey Dobriyan's avatar
      include/linux/ctype.h: make isdigit() table lookupless · 1204c77f
      Alexey Dobriyan authored
      Make isdigit into a simple range checking inline function:
      
      	return '0' <= c && c <= '9';
      
      This code is 1 branch, not 2 because any reasonable compiler can
      optimize this code into SUB+CMP, so the code
      
      	while (isdigit((c = *s++)))
      		...
      
      remains 1 branch per iteration HOWEVER it suddenly doesn't do table
      lookup priming cacheline nobody cares about.
      
      Link: http://lkml.kernel.org/r/20160826190047.GA12536@p183.telecom.by
      
      
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1204c77f
    • Ross Zwisler's avatar
      radix-tree: 'slot' can be NULL in radix_tree_next_slot() · 915045fe
      Ross Zwisler authored
      There are four cases I can see where we could end up with a NULL 'slot' in
      radix_tree_next_slot().  Yet radix_tree_next_slot() never actually checks
      whether 'slot' is NULL.  It just happens that for the cases where 'slot'
      is NULL, some other combination of factors prevents us from dereferencing
      it.
      
      It would be very easy for someone to unwittingly change one of these
      factors without realizing that we are implicitly depending on it to save
      us from a NULL pointer dereference.
      
      Add a comment documenting the things that allow 'slot' to be safely passed
      as NULL to radix_tree_next_slot().
      
      Here are details on the four cases:
      
      1) radix_tree_iter_retry() via a non-tagged iteration like
      radix_tree_for_each_slot().  In this case we currently aren't seeing a bug
      because radix_tree_iter_retry() sets
      
      	iter->next_index = iter->index;
      
      which means that in in the else case in radix_tree_next_slot(), 'count' is
      zero, so we skip over the while() loop and effectively just return NULL
      without ever dereferencing 'slot'.
      
      2) radix_tree_iter_retry() via tagged iteration like
      radix_tree_for_each_tagged().  This case was giving us NULL pointer
      dereferences in testing, and was fixed with this commit:
      
      commit 3cb9185c ("radix-tree: fix radix_tree_iter_retry() for tagged
      iterators.")
      
      This fix doesn't explicitly check for 'slot' being NULL, though, it works
      around the NULL pointer dereference by instead zeroing iter->tags in
      radix_tree_iter_retry(), which makes us bail out of the if() case in
      radix_tree_next_slot() before we dereference 'slot'.
      
      3) radix_tree_iter_next() via via a non-tagged iteration like
      radix_tree_for_each_slot().  This currently happens in shmem_tag_pins()
      and shmem_partial_swap_usage().
      
      As with non-tagged iteration, 'count' in the else case of
      radix_tree_next_slot() is zero, so we skip over the while() loop and
      effectively just return NULL without ever dereferencing 'slot'.
      
      4) radix_tree_iter_next() via tagged iteration like
      radix_tree_for_each_tagged().  This happens in shmem_wait_for_pins().
      
      radix_tree_iter_next() zeros out iter->tags, so we end up exiting
      radix_tree_next_slot() here:
      
      	if (flags & RADIX_TREE_ITER_TAGGED) {
      		void *canon = slot;
      
      		iter->tags >>= 1;
      		if (unlikely(!iter->tags))
      			return NULL;
      
      Link: http://lkml.kernel.org/r/20160815194237.25967-2-ross.zwisler@linux.intel.com
      
      
      Signed-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Shuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      915045fe
    • Mika Westerberg's avatar
      ACPI / property: Allow holes in reference properties · b60e4ea4
      Mika Westerberg authored
      
      
      DT allows holes or empty phandles for references. This is used for example
      in SPI subsystem where some chip selects are native and others are regular
      GPIOs. In ACPI _DSD we currently do not support this but instead the
      preceding reference consumes all following integer arguments.
      
      For example we would like to support something like the below ASL fragment
      for SPI:
      
        Package () {
            "cs-gpios",
            Package () {
                ^GPIO, 19, 0, 0, // GPIO CS0
                0,               // Native CS
                ^GPIO, 20, 0, 0, // GPIO CS1
            }
        }
      
      The zero in the middle means "no entry" or NULL reference. To support this
      we change acpi_data_get_property_reference() to take firmware node and
      num_args as argument and rename it to __acpi_node_get_property_reference().
      The function returns -ENOENT if the given index resolves to "no entry"
      reference and -ENODATA when there are no more entries in the property.
      
      We then add static inline wrapper acpi_node_get_property_reference() that
      passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
      behaviour which some drivers have been relying on.
      
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b60e4ea4
  7. 10 Oct, 2016 3 commits
    • Emese Revfy's avatar
      latent_entropy: Mark functions with __latent_entropy · 0766f788
      Emese Revfy authored
      
      
      The __latent_entropy gcc attribute can be used only on functions and
      variables.  If it is on a function then the plugin will instrument it for
      gathering control-flow entropy. If the attribute is on a variable then
      the plugin will initialize it with random contents.  The variable must
      be an integer, an integer array type or a structure with integer fields.
      
      These specific functions have been selected because they are init
      functions (to help gather boot-time entropy), are called at unpredictable
      times, or they have variable loops, each of which provide some level of
      latent entropy.
      
      Signed-off-by: default avatarEmese Revfy <re.emese@gmail.com>
      [kees: expanded commit message]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      0766f788
    • Emese Revfy's avatar
      gcc-plugins: Add latent_entropy plugin · 38addce8
      Emese Revfy authored
      
      
      This adds a new gcc plugin named "latent_entropy". It is designed to
      extract as much possible uncertainty from a running system at boot time as
      possible, hoping to capitalize on any possible variation in CPU operation
      (due to runtime data differences, hardware differences, SMP ordering,
      thermal timing variation, cache behavior, etc).
      
      At the very least, this plugin is a much more comprehensive example for
      how to manipulate kernel code using the gcc plugin internals.
      
      The need for very-early boot entropy tends to be very architecture or
      system design specific, so this plugin is more suited for those sorts
      of special cases. The existing kernel RNG already attempts to extract
      entropy from reliable runtime variation, but this plugin takes the idea to
      a logical extreme by permuting a global variable based on any variation
      in code execution (e.g. a different value (and permutation function)
      is used to permute the global based on loop count, case statement,
      if/then/else branching, etc).
      
      To do this, the plugin starts by inserting a local variable in every
      marked function. The plugin then adds logic so that the value of this
      variable is modified by randomly chosen operations (add, xor and rol) and
      random values (gcc generates separate static values for each location at
      compile time and also injects the stack pointer at runtime). The resulting
      value depends on the control flow path (e.g., loops and branches taken).
      
      Before the function returns, the plugin mixes this local variable into
      the latent_entropy global variable. The value of this global variable
      is added to the kernel entropy pool in do_one_initcall() and _do_fork(),
      though it does not credit any bytes of entropy to the pool; the contents
      of the global are just used to mix the pool.
      
      Additionally, the plugin can pre-initialize arrays with build-time
      random contents, so that two different kernel builds running on identical
      hardware will not have the same starting values.
      
      Signed-off-by: default avatarEmese Revfy <re.emese@gmail.com>
      [kees: expanded commit message and code comments]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      38addce8
    • Al Viro's avatar
      constify iov_iter_count() and iter_is_iovec() · b57332b4
      Al Viro authored
      
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      b57332b4
  8. 09 Oct, 2016 1 commit
    • Linus Torvalds's avatar
      printk: reinstate KERN_CONT for printing continuation lines · 4bcc595c
      Linus Torvalds authored
      Long long ago the kernel log buffer was a buffered stream of bytes, very
      much like stdio in user space.  It supported log levels by scanning the
      stream and noticing the log level markers at the beginning of each line,
      but if you wanted to print a partial line in multiple chunks, you just
      did multiple printk() calls, and it just automatically worked.
      
      Except when it didn't, and you had very confusing output when different
      lines got all mixed up with each other.  Then you got fragment lines
      mixing with each other, or with non-fragment lines, because it was
      traditionally impossible to tell whether a printk() call was a
      continuation or not.
      
      To at least help clarify the issue of continuation lines, we added a
      KERN_CONT marker back in 2007 to mark continuation lines:
      
        47492527 ("printk: add KERN_CONT annotation").
      
      That continuation marker was initially an empty string, and didn't
      actuall make any semantic difference.  But it at least made it possible
      to annotate the source code, and have check-patch notice that a printk()
      didn't need or want a log level marker, because it was a continuation of
      a previous line.
      
      To avoid the ambiguity between a continuation line that had that
      KERN_CONT marker, and a printk with no level information at all, we then
      in 2009 made KERN_CONT be a real log level marker which meant that we
      could now reliably tell the difference between the two cases.
      
        5fd29d6c ("printk: clean up handling of log-levels and newlines")
      
      and we could take advantage of that to make sure we didn't mix up
      continuation lines with lines that just didn't have any loglevel at all.
      
      Then, in 2012, the kernel log buffer was changed to be a "record" based
      log, where each line was a record that has a loglevel and a timestamp.
      
      You can see the beginning of that conversion in commits
      
        e11fea92 ("kmsg: export printk records to the /dev/kmsg interface")
        7ff9554b ("printk: convert byte-buffer to variable-length record buffer")
      
      with a number of follow-up commits to fix some painful fallout from that
      conversion.  Over all, it took a couple of months to sort out most of
      it.  But the upside was that you could have concurrent readers (and
      writers) of the kernel log and not have lines with mixed output in them.
      
      And one particular pain-point for the record-based kernel logging was
      exactly the fragmentary lines that are generated in smaller chunks.  In
      order to still log them as one recrod, the continuation lines need to be
      attached to the previous record properly.
      
      However the explicit continuation record marker that is actually useful
      for this exact case was actually removed in aroundm the same time by commit
      
        61e99ab8
      
       ("printk: remove the now unnecessary "C" annotation for KERN_CONT")
      
      due to the incorrect belief that KERN_CONT wasn't meaningful.  The
      ambiguity between "is this a continuation line" or "is this a plain
      printk with no log level information" was reintroduced, and in fact
      became an even bigger pain point because there was now the whole
      record-level merging of kernel messages going on.
      
      This patch reinstates the KERN_CONT as a real non-empty string marker,
      so that the ambiguity is fixed once again.
      
      But it's not a plain revert of that original removal: in the four years
      since we made KERN_CONT an empty string again, not only has the format
      of the log level markers changed, we've also had some usage changes in
      this area.
      
      For example, some ACPI code seems to use KERN_CONT _together_ with a log
      level, and now uses both the KERN_CONT marker and (for example) a
      KERN_INFO marker to show that it's an informational continuation of a
      line.
      
      Which is actually not a bad idea - if the continuation line cannot be
      attached to its predecessor, without the log level information we don't
      know what log level to assign to it (and we traditionally just assigned
      it the default loglevel).  So having both a log level and the KERN_CONT
      marker is not necessarily a bad idea, but it does mean that we need to
      actually iterate over potentially multiple markers, rather than just a
      single one.
      
      Also, since KERN_CONT was still conceptually needed, and encouraged, but
      didn't actually _do_ anything, we've also had the reverse problem:
      rather than having too many annotations it has too few, and there is bit
      rot with code that no longer marks the continuation lines with the
      KERN_CONT marker.
      
      So this patch not only re-instates the non-empty KERN_CONT marker, it
      also fixes up the cases of bit-rot I noticed in my own logs.
      
      There are probably other cases where KERN_CONT will be needed to be
      added, either because it is new code that never dealt with the need for
      KERN_CONT, or old code that has bitrotted without anybody noticing.
      
      That said, we should strive to avoid the need for KERN_CONT.  It does
      result in real problems for logging, and should generally not be seen as
      a good feature.  If we some day can get rid of the feature entirely,
      because nobody does any fragmented printk calls, that would be lovely.
      
      But until that point, let's at mark the code that relies on the hacky
      multi-fragment kernel printk's.  Not only does it avoid the ambiguity,
      it also annotates code as "maybe this would be good to fix some day".
      
      (That said, particularly during single-threaded bootup, the downsides of
      KERN_CONT are very limited.  Things get much hairier when you have
      multiple threads going on and user level reading and writing logs too).
      
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4bcc595c
  9. 08 Oct, 2016 6 commits
    • Vladimir Zapolskiy's avatar
      watchdog: add watchdog pretimeout governor framework · ff84136c
      Vladimir Zapolskiy authored
      
      
      The change adds a simple watchdog pretimeout framework infrastructure,
      its purpose is to allow users to select a desired handling of watchdog
      pretimeout events, which may be generated by some watchdog devices.
      
      A user selects a default watchdog pretimeout governor during
      compilation stage.
      
      Watchdogs with WDIOF_PRETIMEOUT capability now have one more device
      attribute in sysfs, pretimeout_governor attribute is intended to display
      the selected watchdog pretimeout governor.
      
      The framework has no impact at runtime on watchdog devices with no
      WDIOF_PRETIMEOUT capability set.
      
      Signed-off-by: default avatarVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Tested-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarWim Van Sebroeck <wim@iguana.be>
      ff84136c
    • Alex Sidorenko's avatar
      Fixing a bug in team driver due to incorrect 'unsigned int' to 'int' conversion · 21d9629a
      Alex Sidorenko authored
      
      
      Roundrobin runner of team driver uses 'unsigned int' variable to count
      the number of sent_packets. Later it is passed to a subroutine
      team_num_to_port_index(struct team *team, int num) as 'num' and when
      we reach MAXINT (2**31-1), 'num' becomes negative.
      
      This leads to using incorrect hash-bucket for port lookup
      and as a result, packets are dropped. The fix consists of changing
      'int num' to 'unsigned int num'. Testing of a fixed kernel shows that
      there is no packet drop anymore.
      
      Signed-off-by: default avatarAlex Sidorenko <alexandre.sidorenko@hpe.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21d9629a
    • Andreas Gruenbacher's avatar
      vfs: Remove {get,set,remove}xattr inode operations · fd50ecad
      Andreas Gruenbacher authored
      
      
      These inode operations are no longer used; remove them.
      
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      fd50ecad
    • Paul Burton's avatar
      console: don't prefer first registered if DT specifies stdout-path · 05fd007e
      Paul Burton authored
      If a device tree specifies a preferred device for kernel console output
      via the stdout-path or linux,stdout-path chosen node properties or the
      stdout alias then the kernel ought to honor it & output the kernel
      console to that device.  As it stands, this isn't the case.  Whilst we
      parse the stdout-path properties & set an of_stdout variable from
      of_alias_scan(), and use that from of_console_check() to determine
      whether to add a console device as a preferred console whilst
      registering it, we also prefer the first registered console if no other
      has been selected at the time of its registration.
      
      This means that if a console other than the one the device tree selects
      via stdout-path is registered first, we will switch to using it & when
      the stdout-path console is later registered the call to
      add_preferred_console() via of_console_check() is too late to do
      anything useful.  In practice this seems to mean that we switch to the
      dummy console device fairly early & see no further console output:
      
          Console: colour dummy device 80x25
          console [tty0] enabled
          bootconsole [ns16550a0] disabled
      
      Fix this by not automatically preferring the first registered console if
      one is specified by the device tree.  This allows consoles to be
      registered but not enabled, and once the driver for the console selected
      by stdout-path calls of_console_check() the driver will be added to the
      list of preferred consoles before any other console has been enabled.
      When that console is then registered via register_console() it will be
      enabled as expected.
      
      Link: http://lkml.kernel.org/r/20160809151937.26118-1-paul.burton@imgtec.com
      
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ivan Delalande <colona@arista.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Jan Kara <jack@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      05fd007e
    • Alexey Dobriyan's avatar
      cred: simpler, 1D supplementary groups · 81243eac
      Alexey Dobriyan authored
      Current supplementary groups code can massively overallocate memory and
      is implemented in a way so that access to individual gid is done via 2D
      array.
      
      If number of gids is <= 32, memory allocation is more or less tolerable
      (140/148 bytes).  But if it is not, code allocates full page (!)
      regardless and, what's even more fun, doesn't reuse small 32-entry
      array.
      
      2D array means dependent shifts, loads and LEAs without possibility to
      optimize them (gid is never known at compile time).
      
      All of the above is unnecessary.  Switch to the usual
      trailing-zero-len-array scheme.  Memory is allocated with
      kmalloc/vmalloc() and only as much as needed.  Accesses become simpler
      (LEA 8(gi,idx,4) or even without displacement).
      
      Maximum number of gids is 65536 which translates to 256KB+8 bytes.  I
      think kernel can handle such allocation.
      
      On my usual desktop system with whole 9 (nine) aux groups, struct
      group_info shrinks from 148 bytes to 44 bytes, yay!
      
      Nice side effects:
      
       - "gi->gid[i]" is shorter than "GROUP_AT(gi, i)", less typing,
      
       - fix little mess in net/ipv4/ping.c
         should have been using GROUP_AT macro but this point becomes moot,
      
       - aux group allocation is persistent and should be accounted as such.
      
      Link: http://lkml.kernel.org/r/20160817201927.GA2096@p183.telecom.by
      
      
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Vasily Kulikov <segoon@openwall.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      81243eac
    • Chris Metcalf's avatar
      nmi_backtrace: generate one-line reports for idle cpus · 6727ad9e
      Chris Metcalf authored
      When doing an nmi backtrace of many cores, most of which are idle, the
      output is a little overwhelming and very uninformative.  Suppress
      messages for cpus that are idling when they are interrupted and just
      emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN".
      
      We do this by grouping all the cpuidle code together into a new
      .cpuidle.text section, and then checking the address of the interrupted
      PC to see if it lies within that section.
      
      This commit suitably tags x86 and tile idle routines, and only adds in
      the minimal framework for other architectures.
      
      Link: http://lkml.kernel.org/r/1472487169-14923-5-git-send-email-cmetcalf@mellanox.com
      
      
      Signed-off-by: default avatarChris Metcalf <cmetcalf@mellanox.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Tested-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm]
      Tested-by: default avatarPetr Mladek <pmladek@suse.com>
      Cc: Aaron Tomlin <atomlin@redhat.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6727ad9e