1. 20 Nov, 2016 4 commits
    • Javier Martinez Canillas's avatar
      s5p-mfc: Set device name for reserved memory region devs · cd99653c
      Javier Martinez Canillas authored
      commit 29debab0 upstream.
      
      The devices don't have a name set, so makes dev_name() returns NULL which
      makes harder to identify the devices that are causing issues, for example:
      
      WARNING: CPU: 2 PID: 616 at drivers/base/core.c:251 device_release+0x8c/0x90
      Device '(null)' does not have a release() function, it is broken and must be fixed.
      
      And after setting the device name:
      
      WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90
      Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed.
      
      Fixes: 6e83e6e2 ("[media] s5p-mfc: Fix kernel warning on memory init")
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cd99653c
    • Herbert Xu's avatar
      macvlan: Fix potential use-after free for broadcasts · a218ab30
      Herbert Xu authored
      commit 260916df upstream.
      
      When we postpone a broadcast packet we save the source port in
      the skb if it is local.  However, the source port can disappear
      before we get a chance to process the packet.
      
      This patch fixes this by holding a ref count on the netdev.
      
      It also delays the skb->cb modification until after we allocate
      the new skb as you should not modify shared skbs.
      
      Fixes: 412ca155 ("macvlan: Move broadcasts into a work queue")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a218ab30
    • Roderick Colenbrander's avatar
      HID: uhid: fix timeout when probe races with IO · c35ceff2
      Roderick Colenbrander authored
      commit 67f8ecc5 upstream.
      
      Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination
      with uhid. If any of these stacks is used with a HID device for which the driver
      performs a HID request as part .probe (or technically another HID operation),
      this results in a deadlock situation. The deadlock results in a 5 second timeout
      for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations
      have a chance of succeeding.
      
      The root cause for the problem is that uhid only allows for one request to be
      processed at a time per uhid instance and locks out other operations. This means
      that if a user space is creating a new HID device through 'UHID_CREATE', which
      ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a
      read for calibration data would trigger a HID operation on uhid again, but it
      won't go out to userspace, because it is still stuck in UHID_CREATE.
      In addition bluetooth stacks are typically single threaded, so they wouldn't be
      able to handle any requests while waiting on uhid.
      
      Lucikly the UHID spec is somewhat flexible and allows for fixing the issue,
      without breaking user space. The idea which the patch implements as discussed
      with David Herrmann is to decouple adding of a hid device (which triggers .probe)
      from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or
      else will wait a tiny bit of time in .probe for a lock). A HID driver has to call
      HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which
      triggers UHID_START to user space. Any HID operations should function now within
      .probe and won't deadlock because userspace is stuck on UHID_CREATE.
      
      We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with
      BlueZ stacks. Prior to the patch they had the deadlock issue.
      
      [jkosina@suse.cz: reword subject]
      Signed-off-by: default avatarRoderick Colenbrander <roderick.colenbrander@sony.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c35ceff2
    • Nicolai Stange's avatar
      lib/mpi: mpi_read_raw_data(): fix nbits calculation · b15ff947
      Nicolai Stange authored
      commit eef0df6a upstream.
      
      The number of bits, nbits, is calculated in mpi_read_raw_data() as follows:
      
        nbits = nbytes * 8;
      
      Afterwards, the number of leading zero bits of the first byte get
      subtracted:
      
        nbits -= count_leading_zeros(buffer[0]);
      
      However, count_leading_zeros() takes an unsigned long and thus,
      the u8 gets promoted to an unsigned long.
      
      Thus, the above doesn't subtract the number of leading zeros in the most
      significant nonzero input byte from nbits, but the number of leading
      zeros of the most significant nonzero input byte promoted to unsigned long,
      i.e. BITS_PER_LONG - 8 too many.
      
      Fix this by subtracting
      
        count_leading_zeros(...) - (BITS_PER_LONG - 8)
      
      from nbits only.
      
      Fixes: e1045992 ("MPILIB: Provide a function to read raw data into an
                           MPI")
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b15ff947
  2. 20 Oct, 2016 2 commits
    • Ben Hutchings's avatar
      Linux 3.16.38 · fa1703ff
      Ben Hutchings authored
      fa1703ff
    • Linus Torvalds's avatar
      mm: remove gup_flags FOLL_WRITE games from __get_user_pages() · 2649c26f
      Linus Torvalds authored
      commit 19be0eaf upstream.
      
      This is an ancient bug that was actually attempted to be fixed once
      (badly) by me eleven years ago in commit 4ceb5db9 ("Fix
      get_user_pages() race for write access") but that was then undone due to
      problems on s390 by commit f33ea7f4 ("fix get_user_pages bug").
      
      In the meantime, the s390 situation has long been fixed, and we can now
      fix it by checking the pte_dirty() bit properly (and do it better).  The
      s390 dirty bit was implemented in abf09bed ("s390/mm: implement
      software dirty bits") which made it into v3.9.  Earlier kernels will
      have to look at the page state itself.
      
      Also, the VM has become more scalable, and what used a purely
      theoretical race back then has become easier to trigger.
      
      To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
      we already did a COW" rather than play racy games with FOLL_WRITE that
      is very fundamental, and then use the pte dirty flag to validate that
      the FOLL_COW flag is still valid.
      Reported-and-tested-by: default avatarPhil "not Paul" Oester <kernel@linuxace.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Nick Piggin <npiggin@gmail.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [carnil: backport to 3.16, adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2649c26f
  3. 22 Aug, 2016 34 commits