1. 10 3月, 2017 6 次提交
  2. 09 3月, 2017 1 次提交
    • M
      Input: sparse-keymap - use a managed allocation for keymap copy · fabeb165
      Michał Kępień 提交于
      Some platform drivers use devm_input_allocate_device() together with
      sparse_keymap_setup() in their .probe callbacks.  While using the former
      simplifies error handling, using the latter necessitates calling
      sparse_keymap_free() in the error path and upon module unloading to
      avoid leaking the copy of the keymap allocated by sparse_keymap_setup().
      
      To help prevent such leaks and enable simpler error handling, make
      sparse_keymap_setup() use devm_kmemdup() to create the keymap copy so
      that it gets automatically freed.
      
      This works for both managed and non-managed input devices as the keymap
      is freed after the last reference to the input device is dropped.
      
      Note that actions previously taken by sparse_keymap_free(), i.e. taking
      the input device's mutex and zeroing its keycode and keycodemax fields,
      are now redundant because the managed keymap will always be freed after
      the input device is unregistered.
      Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      fabeb165
  3. 08 3月, 2017 4 次提交
  4. 02 3月, 2017 4 次提交
  5. 26 2月, 2017 2 次提交
  6. 24 2月, 2017 8 次提交
  7. 23 2月, 2017 3 次提交
  8. 21 2月, 2017 1 次提交
  9. 20 2月, 2017 3 次提交
    • L
      Linux 4.10 · c470abd4
      Linus Torvalds 提交于
      c470abd4
    • A
      Fix missing sanity check in /dev/sg · 137d01df
      Al Viro 提交于
      What happens is that a write to /dev/sg is given a request with non-zero
      ->iovec_count combined with zero ->dxfer_len.  Or with ->dxferp pointing
      to an array full of empty iovecs.
      
      Having write permission to /dev/sg shouldn't be equivalent to the
      ability to trigger BUG_ON() while holding spinlocks...
      
      Found by Dmitry Vyukov and syzkaller.
      
      [ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the
        underlying issue.  - Linus ]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      137d01df
    • J
      scsi: don't BUG_ON() empty DMA transfers · fd3fc0b4
      Johannes Thumshirn 提交于
      Don't crash the machine just because of an empty transfer. Use WARN_ON()
      combined with returning an error.
      
      Found by Dmitry Vyukov and syzkaller.
      
      [ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root
        cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON()
        might still be a cause of excessive log spamming.
      
        NOTE! If this warning ever triggers, we may end up leaking resources,
        since this doesn't bother to try to clean the command up. So this
        WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is
        much worse.
      
        People really need to stop using BUG_ON() for "this shouldn't ever
        happen". It makes pretty much any bug worse.     - Linus ]
      Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: James Bottomley <jejb@linux.vnet.ibm.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fd3fc0b4
  10. 19 2月, 2017 8 次提交