1. 14 Aug, 2016 3 commits
    • Javier Martinez Canillas's avatar
      s5p-mfc: Set device name for reserved memory region devs · 1dd12c31
      Javier Martinez Canillas authored
      [ Upstream commit 29debab0 ]
      
      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.
      
      Cc: <stable@vger.kernel.org>
      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 avatarSasha Levin <alexander.levin@verizon.com>
      1dd12c31
    • Roderick Colenbrander's avatar
      HID: uhid: fix timeout when probe races with IO · fce67161
      Roderick Colenbrander authored
      [ Upstream commit 67f8ecc5 ]
      
      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>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      fce67161
    • James Morse's avatar
      arm64: kernel: Save and restore addr_limit on exception entry · 223b3917
      James Morse authored
      commit e19a6ee2 upstream.
      
      If we take an exception while at EL1, the exception handler inherits
      the original context's addr_limit value. To be consistent always reset
      addr_limit and PSTATE.UAO on (re-)entry to EL1. This prevents accidental
      re-use of the original context's addr_limit.
      
      Based on a similar patch for arm from Russell King.
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      [ backport to stop perf misusing inherited addr_limit.
        Removed code interacting with UAO and the irqstack ]
      Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=822Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Cc: <stable@vger.kernel.org> #4.1
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      223b3917
  2. 12 Aug, 2016 1 commit
    • Kenny Keslar's avatar
      fs/proc/task_mmu.c: fix mm_access() mode parameter in pagemap_read() · 5c576457
      Kenny Keslar authored
      Backport of caaee623 ("ptrace: use fsuid,
      fsgid, effective creds for fs access checks") to v4.1 failed to update the
      mode parameter in the mm_access() call in pagemap_read() to have one of the
      new PTRACE_MODE_*CREDS flags.
      
      Attempting to read any other process' pagemap results in a WARN()
      
      WARNING: CPU: 0 PID: 883 at kernel/ptrace.c:229 __ptrace_may_access+0x14a/0x160()
      denying ptrace access check without PTRACE_MODE_*CREDS
      Modules linked in: loop sg e1000 i2c_piix4 ppdev virtio_balloon virtio_pci parport_pc i2c_core virtio_ring ata_generic serio_raw pata_acpi virtio parport pcspkr floppy acpi_cpufreq ip_tables ext3 mbcache jbd sd_mod ata_piix crc32c_intel libata
      CPU: 0 PID: 883 Comm: cat Tainted: G        W       4.1.12-51.el7uek.x86_64 #2
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
        0000000000000286 00000000619f225a ffff88003b6fbc18 ffffffff81717021
        ffff88003b6fbc70 ffffffff819be870 ffff88003b6fbc58 ffffffff8108477a
        000000003b6fbc58 0000000000000001 ffff88003d287000 0000000000000001
      Call Trace:
        [<ffffffff81717021>] dump_stack+0x63/0x81
        [<ffffffff8108477a>] warn_slowpath_common+0x8a/0xc0
        [<ffffffff81084805>] warn_slowpath_fmt+0x55/0x70
        [<ffffffff8108e57a>] __ptrace_may_access+0x14a/0x160
        [<ffffffff8108f372>] ptrace_may_access+0x32/0x50
        [<ffffffff81081bad>] mm_access+0x6d/0xb0
        [<ffffffff81278c81>] pagemap_read+0xe1/0x360
        [<ffffffff811a046b>] ? lru_cache_add_active_or_unevictable+0x2b/0xa0
        [<ffffffff8120d2e7>] __vfs_read+0x37/0x100
        [<ffffffff812b9ab4>] ? security_file_permission+0x84/0xa0
        [<ffffffff8120d8b6>] ? rw_verify_area+0x56/0xe0
        [<ffffffff8120d9c6>] vfs_read+0x86/0x140
        [<ffffffff8120e945>] SyS_read+0x55/0xd0
        [<ffffffff8171eb6e>] system_call_fastpath+0x12/0x71
      
      Fixes: ab88ce5f (ptrace: use fsuid, fsgid, effective creds for fs access checks)
      Signed-off-by: default avatarKenny Keslar <kenny.keslar@oracle.com>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5c576457
  3. 11 Aug, 2016 1 commit
    • Munehisa Kamata's avatar
      netfilter: nf_nat_redirect: add missing NULL pointer check · 6a468737
      Munehisa Kamata authored
      [ Upstream commit 94f9cd81 ]
      
      Commit 8b13eddf ("netfilter: refactor NAT
      redirect IPv4 to use it from nf_tables") has introduced a trivial logic
      change which can result in the following crash.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
      IP: [<ffffffffa033002d>] nf_nat_redirect_ipv4+0x2d/0xa0 [nf_nat_redirect]
      PGD 3ba662067 PUD 3ba661067 PMD 0
      Oops: 0000 [#1] SMP
      Modules linked in: ipv6(E) xt_REDIRECT(E) nf_nat_redirect(E) xt_tcpudp(E) iptable_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) ip_tables(E) x_tables(E) binfmt_misc(E) xfs(E) libcrc32c(E) evbug(E) evdev(E) psmouse(E) i2c_piix4(E) i2c_core(E) acpi_cpufreq(E) button(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
      CPU: 0 PID: 2536 Comm: ip Tainted: G            E   4.1.7-15.23.amzn1.x86_64 #1
      Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/06/2015
      task: ffff8800eb438000 ti: ffff8803ba664000 task.ti: ffff8803ba664000
      [...]
      Call Trace:
       <IRQ>
       [<ffffffffa0334065>] redirect_tg4+0x15/0x20 [xt_REDIRECT]
       [<ffffffffa02e2e99>] ipt_do_table+0x2b9/0x5e1 [ip_tables]
       [<ffffffffa0328045>] iptable_nat_do_chain+0x25/0x30 [iptable_nat]
       [<ffffffffa031777d>] nf_nat_ipv4_fn+0x13d/0x1f0 [nf_nat_ipv4]
       [<ffffffffa0328020>] ? iptable_nat_ipv4_fn+0x20/0x20 [iptable_nat]
       [<ffffffffa031785e>] nf_nat_ipv4_in+0x2e/0x90 [nf_nat_ipv4]
       [<ffffffffa03280a5>] iptable_nat_ipv4_in+0x15/0x20 [iptable_nat]
       [<ffffffff81449137>] nf_iterate+0x57/0x80
       [<ffffffff814491f7>] nf_hook_slow+0x97/0x100
       [<ffffffff814504d4>] ip_rcv+0x314/0x400
      
      unsigned int
      nf_nat_redirect_ipv4(struct sk_buff *skb,
      ...
      {
      ...
      		rcu_read_lock();
      		indev = __in_dev_get_rcu(skb->dev);
      		if (indev != NULL) {
      			ifa = indev->ifa_list;
      			newdst = ifa->ifa_local; <---
      		}
      		rcu_read_unlock();
      ...
      }
      
      Before the commit, 'ifa' had been always checked before access. After the
      commit, however, it could be accessed even if it's NULL. Interestingly,
      this was once fixed in 2003.
      
      http://marc.info/?l=netfilter-devel&m=106668497403047&w=2
      
      In addition to the original one, we have seen the crash when packets that
      need to be redirected somehow arrive on an interface which hasn't been
      yet fully configured.
      
      This change just reverts the logic to the old behavior to avoid the crash.
      
      Fixes: 8b13eddf ("netfilter: refactor NAT redirect IPv4 to use it from nf_tables")
      Signed-off-by: default avatarMunehisa Kamata <kamatam@amazon.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6a468737
  4. 09 Aug, 2016 1 commit
  5. 08 Aug, 2016 4 commits
    • Lukas Wunner's avatar
      x86/quirks: Reintroduce scanning of secondary buses · 629d0452
      Lukas Wunner authored
      [ Upstream commit 850c3210 ]
      
      We used to scan secondary buses until the following commit that
      was applied in 2009:
      
        8659c406 ("x86: only scan the root bus in early PCI quirks")
      
      which commit constrained early quirks to the root bus only. Its
      motivation was to prevent application of the nvidia_bugs quirk
      on secondary buses.
      
      We're about to add a quirk to reset the Broadcom 4331 wireless card on
      2011/2012 Macs, which is located on a secondary bus behind a PCIe root
      port. To facilitate that, reintroduce scanning of secondary buses.
      
      The commit message of 8659c406 notes that scanning only the root bus
      "saves quite some unnecessary scanning work". The algorithm used prior
      to 8659c406 was particularly time consuming because it scanned
      buses 0 to 31 brute force. To avoid lengthening boot time, employ a
      recursive strategy which only scans buses that are actually reachable
      from the root bus.
      
      Yinghai Lu pointed out that the secondary bus number read from a
      bridge's config space may be invalid, in particular a value of 0 would
      cause an infinite loop. The PCI core goes beyond that and recurses to a
      child bus only if its bus number is greater than the parent bus number
      (see pci_scan_bridge()). Since the root bus is numbered 0, this implies
      that secondary buses may not be 0. Do the same on early scanning.
      
      If this algorithm is found to significantly impact boot time or cause
      infinite loops on broken hardware, it would be possible to limit its
      recursion depth: The Broadcom 4331 quirk applies at depth 1, all others
      at depth 0, so the bus need not be scanned deeper than that for now. An
      alternative approach would be to revert to scanning only the root bus,
      and apply the Broadcom 4331 quirk to the root ports 8086:1c12, 8086:1e12
      and 8086:1e16. Apple always positioned the card behind either of these
      three ports. The quirk would then check presence of the card in slot 0
      below the root port and do its deed.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-pci@vger.kernel.org
      Link: http://lkml.kernel.org/r/f0daa70dac1a9b2483abdb31887173eb6ab77bdf.1465690253.git.lukas@wunner.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      629d0452
    • Lukas Wunner's avatar
      x86/quirks: Apply nvidia_bugs quirk only on root bus · f2da7dfd
      Lukas Wunner authored
      [ Upstream commit 447d29d1 ]
      
      Since the following commit:
      
        8659c406 ("x86: only scan the root bus in early PCI quirks")
      
      ... early quirks are only applied to devices on the root bus.
      
      The motivation was to prevent application of the nvidia_bugs quirk on
      secondary buses.
      
      We're about to reintroduce scanning of secondary buses for a quirk to
      reset the Broadcom 4331 wireless card on 2011/2012 Macs. To prevent
      regressions, open code the requirement to apply nvidia_bugs only on the
      root bus.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/4d5477c1d76b2f0387a780f2142bbcdd9fee869b.1465690253.git.lukas@wunner.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f2da7dfd
    • Sasha Levin's avatar
      Revert "MIPS: Reserve nosave data for hibernation" · 6264b577
      Sasha Levin authored
      This reverts commit e8ebd0cf.
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6264b577
    • Sasha Levin's avatar
      Revert "sparc64: Fix numa node distance initialization" · 84d08218
      Sasha Levin authored
      This reverts commit bfbe327d556707c59c5c0536d831078b41a68429.
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      84d08218
  6. 06 Aug, 2016 17 commits
  7. 03 Aug, 2016 10 commits
  8. 30 Jul, 2016 1 commit
  9. 19 Jul, 2016 2 commits
    • Steven Rostedt's avatar
      4.1.28 Fix bad backport of 8f182270 "mm/swap.c: flush lru pvecs on compound page arrival" · 74225a4c
      Steven Rostedt authored
      When I pulled in 4.1.28 into my stable 4.1-rt tree and ran the tests,
      it crashed with a severe OOM killing everything. I then tested 4.1.28
      without -rt and it had the same issue. I did a bisect between 4.1.27
      and 4.1.28 and found that the bug started at:
      
      commit 8f182270 "mm/swap.c: flush lru pvecs on compound page
      arrival"
      
      Looking at that patch and what's in mainline, I see that there's a
      mismatch in one of the hunks:
      
      Mainline:
      
      @@ -391,9 +391,8 @@ static void __lru_cache_add(struct page *page)
              struct pagevec *pvec = &get_cpu_var(lru_add_pvec);
      
              get_page(page);
      -       if (!pagevec_space(pvec))
      +       if (!pagevec_add(pvec, page) || PageCompound(page))
                      __pagevec_lru_add(pvec);
      -       pagevec_add(pvec, page);
              put_cpu_var(lru_add_pvec);
       }
      
      Stable 4.1.28:
      
      @@ -631,9 +631,8 @@ static void __lru_cache_add(struct page *page)
              struct pagevec *pvec = &get_cpu_var(lru_add_pvec);
      
              page_cache_get(page);
      -       if (!pagevec_space(pvec))
      +       if (!pagevec_space(pvec) || PageCompound(page))
                      __pagevec_lru_add(pvec);
      -       pagevec_add(pvec, page);
              put_cpu_var(lru_add_pvec);
       }
      
      Where mainline replace pagevec_space() with pagevec_add, and stable did
      not.
      
      Fixing this makes the OOM go away.
      
      Note, 3.18 has the same bug.
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      74225a4c
    • Michael Ellerman's avatar
      powerpc: Fix build break due to missing PPC_FEATURE2_HTM_NOSC · 62d7a454
      Michael Ellerman authored
      The backport of 4705e024 ("powerpc: Update TM user feature bits in
      scan_features()") (f49eb503), missed the fact that 4.1 doesn't
      include the commit that added PPC_FEATURE2_HTM_NOSC.
      
      The correct fix is simply to omit PPC_FEATURE2_HTM_NOSC.
      
      Fixes: f49eb503 ("powerpc: Update TM user feature bits in scan_features()")
      Reported-by: default avatarChristian Zigotzky <chzigotzky@bayern-mail.de>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      62d7a454