1. 28 Oct, 2015 16 commits
    • Jann Horn's avatar
      fs: if a coredump already exists, unlink and recreate with O_EXCL · 57170087
      Jann Horn authored
      commit fbb18169 upstream.
      
      It was possible for an attacking user to trick root (or another user) into
      writing his coredumps into an attacker-readable, pre-existing file using
      rename() or link(), causing the disclosure of secret data from the victim
      process' virtual memory.  Depending on the configuration, it was also
      possible to trick root into overwriting system files with coredumps.  Fix
      that issue by never writing coredumps into existing files.
      
      Requirements for the attack:
       - The attack only applies if the victim's process has a nonzero
         RLIMIT_CORE and is dumpable.
       - The attacker can trick the victim into coredumping into an
         attacker-writable directory D, either because the core_pattern is
         relative and the victim's cwd is attacker-writable or because an
         absolute core_pattern pointing to a world-writable directory is used.
       - The attacker has one of these:
        A: on a system with protected_hardlinks=0:
           execute access to a folder containing a victim-owned,
           attacker-readable file on the same partition as D, and the
           victim-owned file will be deleted before the main part of the attack
           takes place. (In practice, there are lots of files that fulfill
           this condition, e.g. entries in Debian's /var/lib/dpkg/info/.)
           This does not apply to most Linux systems because most distros set
           protected_hardlinks=1.
        B: on a system with protected_hardlinks=1:
           execute access to a folder containing a victim-owned,
           attacker-readable and attacker-writable file on the same partition
           as D, and the victim-owned file will be deleted before the main part
           of the attack takes place.
           (This seems to be uncommon.)
        C: on any system, independent of protected_hardlinks:
           write access to a non-sticky folder containing a victim-owned,
           attacker-readable file on the same partition as D
           (This seems to be uncommon.)
      
      The basic idea is that the attacker moves the victim-owned file to where
      he expects the victim process to dump its core.  The victim process dumps
      its core into the existing file, and the attacker reads the coredump from
      it.
      
      If the attacker can't move the file because he does not have write access
      to the containing directory, he can instead link the file to a directory
      he controls, then wait for the original link to the file to be deleted
      (because the kernel checks that the link count of the corefile is 1).
      
      A less reliable variant that requires D to be non-sticky works with link()
      and does not require deletion of the original link: link() the file into
      D, but then unlink() it directly before the kernel performs the link count
      check.
      
      On systems with protected_hardlinks=0, this variant allows an attacker to
      not only gain information from coredumps, but also clobber existing,
      victim-writable files with coredumps.  (This could theoretically lead to a
      privilege escalation.)
      Signed-off-by: default avatarJann Horn <jann@thejh.net>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      57170087
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Fix kernel NULL pointer dereference on older hardware · fd3a964b
      Thomas Hellstrom authored
      commit ed7d78b2 upstream.
      
      The commit "drm/vmwgfx: Fix up user_dmabuf refcounting", while fixing a
      kernel crash introduced a NULL pointer dereference on older hardware.
      Fix this.
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarSinclair Yeh <syeh@vmware.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fd3a964b
    • Joonsoo Kim's avatar
      mm/slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE+1) · 2efdc7e5
      Joonsoo Kim authored
      commit 03a2d2a3 upstream.
      
      Commit description is copied from the original post of this bug:
      
        http://comments.gmane.org/gmane.linux.kernel.mm/135349
      
      Kernels after v3.9 use kmalloc_size(INDEX_NODE + 1) to get the next
      larger cache size than the size index INDEX_NODE mapping.  In kernels
      3.9 and earlier we used malloc_sizes[INDEX_L3 + 1].cs_size.
      
      However, sometimes we can't get the right output we expected via
      kmalloc_size(INDEX_NODE + 1), causing a BUG().
      
      The mapping table in the latest kernel is like:
          index = {0,   1,  2 ,  3,  4,   5,   6,   n}
           size = {0,   96, 192, 8, 16,  32,  64,   2^n}
      The mapping table before 3.10 is like this:
          index = {0 , 1 , 2,   3,  4 ,  5 ,  6,   n}
          size  = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)}
      
      The problem on my mips64 machine is as follows:
      
      (1) When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC
          && DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150",
          and the macro INDEX_NODE turns out to be "2": #define INDEX_NODE
          kmalloc_index(sizeof(struct kmem_cache_node))
      
      (2) Then the result of kmalloc_size(INDEX_NODE + 1) is 8.
      
      (3) Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size
          = PAGE_SIZE".
      
      (4) Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and
          "flags |= CFLGS_OFF_SLAB" will be covered.
      
      (5) if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go to
          "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result
          here may be NULL while kernel bootup.
      
      (6) Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" causes the
          BUG info as the following shows (may be only mips64 has this problem):
      
      This patch fixes the problem of kmalloc_size(INDEX_NODE + 1) and removes
      the BUG by adding 'size >= 256' check to guarantee that all necessary
      small sized slabs are initialized regardless sequence of slab size in
      mapping table.
      
      Fixes: e3366016 ("slab: Use common kmalloc_index/kmalloc_size...")
      Signed-off-by: default avatarJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Reported-by: default avatarLiuhailong <liu.hailong6@zte.com.cn>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2efdc7e5
    • Andy Shevchenko's avatar
      dmaengine: dw: properly read DWC_PARAMS register · f92cf18e
      Andy Shevchenko authored
      commit 6bea0f6d upstream.
      
      In case we have less than maximum allowed channels (8) and autoconfiguration is
      enabled the DWC_PARAMS read is wrong because it uses different arithmetic to
      what is needed for channel priority setup.
      
      Re-do the caclulations properly. This now works on AVR32 board well.
      
      Fixes: fed2574b (dw_dmac: introduce software emulation of LLP transfers)
      Cc: yitian.bu@tangramtek.com
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f92cf18e
    • John Stultz's avatar
      clocksource: Fix abs() usage w/ 64bit values · 9b0cf919
      John Stultz authored
      commit 67dfae0c upstream.
      
      This patch fixes one cases where abs() was being used with 64-bit
      nanosecond values, where the result may be capped at 32-bits.
      
      This potentially could cause watchdog false negatives on 32-bit
      systems, so this patch addresses the issue by using abs64().
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Link: http://lkml.kernel.org/r/1442279124-7309-2-git-send-email-john.stultz@linaro.orgSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9b0cf919
    • Stephen Smalley's avatar
      x86/mm: Set NX on gap between __ex_table and rodata · 45771796
      Stephen Smalley authored
      commit ab76f7b4 upstream.
      
      Unused space between the end of __ex_table and the start of
      rodata can be left W+x in the kernel page tables.  Extend the
      setting of the NX bit to cover this gap by starting from
      text_end rather than rodata_start.
      
        Before:
        ---[ High Kernel Mapping ]---
        0xffffffff80000000-0xffffffff81000000          16M                               pmd
        0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
        0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
        0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB x  pte
        0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
        0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
        0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
        0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
        0xffffffff82200000-0xffffffffa0000000         478M                               pmd
      
        After:
        ---[ High Kernel Mapping ]---
        0xffffffff80000000-0xffffffff81000000          16M                               pmd
        0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
        0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
        0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB NX pte
        0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
        0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
        0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
        0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
        0xffffffff82200000-0xffffffffa0000000         478M                               pmd
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1443704662-3138-1-git-send-email-sds@tycho.nsa.govSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      45771796
    • Mel Gorman's avatar
      mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault · f8d164d4
      Mel Gorman authored
      commit 2f84a899 upstream.
      
      SunDong reported the following on
      
        https://bugzilla.kernel.org/show_bug.cgi?id=103841
      
      	I think I find a linux bug, I have the test cases is constructed. I
      	can stable recurring problems in fedora22(4.0.4) kernel version,
      	arch for x86_64.  I construct transparent huge page, when the parent
      	and child process with MAP_SHARE, MAP_PRIVATE way to access the same
      	huge page area, it has the opportunity to lead to huge page copy on
      	write failure, and then it will munmap the child corresponding mmap
      	area, but then the child mmap area with VM_MAYSHARE attributes, child
      	process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
      	functions (vma - > vm_flags & VM_MAYSHARE).
      
      There were a number of problems with the report (e.g.  it's hugetlbfs that
      triggers this, not transparent huge pages) but it was fundamentally
      correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that
      looks like this
      
      	 vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
      	 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
      	 prot 8000000000000027 anon_vma           (null) vm_ops ffffffff8182a7a0
      	 pgoff 0 file ffff88106bdb9800 private_data           (null)
      	 flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
      	 ------------
      	 kernel BUG at mm/hugetlb.c:462!
      	 SMP
      	 Modules linked in: xt_pkttype xt_LOG xt_limit [..]
      	 CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
      	 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
      	 set_vma_resv_flags+0x2d/0x30
      
      The VM_BUG_ON is correct because private and shared mappings have
      different reservation accounting but the warning clearly shows that the
      VMA is shared.
      
      When a private COW fails to allocate a new page then only the process
      that created the VMA gets the page -- all the children unmap the page.
      If the children access that data in the future then they get killed.
      
      The problem is that the same file is mapped shared and private.  During
      the COW, the allocation fails, the VMAs are traversed to unmap the other
      private pages but a shared VMA is found and the bug is triggered.  This
      patch identifies such VMAs and skips them.
      Signed-off-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Reported-by: default avatarSunDong <sund_sky@126.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: David Rientjes <rientjes@google.com>
      Reviewed-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f8d164d4
    • Dirk Müller's avatar
      Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS · 0436b7e1
      Dirk Müller authored
      commit d2922422 upstream.
      
      The cpu feature flags are not ever going to change, so warning
      everytime can cause a lot of kernel log spam
      (in our case more than 10GB/hour).
      
      The warning seems to only occur when nested virtualization is
      enabled, so it's probably triggered by a KVM bug.  This is a
      sensible and safe change anyway, and the KVM bug fix might not
      be suitable for stable releases anyway.
      Signed-off-by: default avatarDirk Mueller <dmueller@suse.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0436b7e1
    • Matt Fleming's avatar
      x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down · 6d149d78
      Matt Fleming authored
      commit a5caa209 upstream.
      
      Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
      that signals that the firmware PE/COFF loader supports splitting
      code and data sections of PE/COFF images into separate EFI
      memory map entries. This allows the kernel to map those regions
      with strict memory protections, e.g. EFI_MEMORY_RO for code,
      EFI_MEMORY_XP for data, etc.
      
      Unfortunately, an unwritten requirement of this new feature is
      that the regions need to be mapped with the same offsets
      relative to each other as observed in the EFI memory map. If
      this is not done crashes like this may occur,
      
        BUG: unable to handle kernel paging request at fffffffefe6086dd
        IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
        Call Trace:
         [<ffffffff8104c90e>] efi_call+0x7e/0x100
         [<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
         [<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
         [<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
         [<ffffffff81f37e1b>] start_kernel+0x38a/0x417
         [<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
         [<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
      
      Here 0xfffffffefe6086dd refers to an address the firmware
      expects to be mapped but which the OS never claimed was mapped.
      The issue is that included in these regions are relative
      addresses to other regions which were emitted by the firmware
      toolchain before the "splitting" of sections occurred at
      runtime.
      
      Needless to say, we don't satisfy this unwritten requirement on
      x86_64 and instead map the EFI memory map entries in reverse
      order. The above crash is almost certainly triggerable with any
      kernel newer than v3.13 because that's when we rewrote the EFI
      runtime region mapping code, in commit d2f7cbe7 ("x86/efi:
      Runtime services virtual mapping"). For kernel versions before
      v3.13 things may work by pure luck depending on the
      fragmentation of the kernel virtual address space at the time we
      map the EFI regions.
      
      Instead of mapping the EFI memory map entries in reverse order,
      where entry N has a higher virtual address than entry N+1, map
      them in the same order as they appear in the EFI memory map to
      preserve this relative offset between regions.
      
      This patch has been kept as small as possible with the intention
      that it should be applied aggressively to stable and
      distribution kernels. It is very much a bugfix rather than
      support for a new feature, since when EFI_PROPERTIES_TABLE is
      enabled we must map things as outlined above to even boot - we
      have no way of asking the firmware not to split the code/data
      regions.
      
      In fact, this patch doesn't even make use of the more strict
      memory protections available in UEFI v2.5. That will come later.
      Suggested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reported-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Chun-Yi <jlee@suse.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: James Bottomley <JBottomley@Odin.com>
      Cc: Lee, Chun-Yi <jlee@suse.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6d149d78
    • Ben Hutchings's avatar
      genirq: Fix race in register_irq_proc() · 0eb16874
      Ben Hutchings authored
      commit 95c2b175 upstream.
      
      Per-IRQ directories in procfs are created only when a handler is first
      added to the irqdesc, not when the irqdesc is created.  In the case of
      a shared IRQ, multiple tasks can race to create a directory.  This
      race condition seems to have been present forever, but is easier to
      hit with async probing.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Link: http://lkml.kernel.org/r/1443266636.2004.2.camel@decadent.org.ukSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0eb16874
    • Fabiano Fidêncio's avatar
      drm/qxl: recreate the primary surface when the bo is not primary · 489abfce
      Fabiano Fidêncio authored
      commit 8d0d9401 upstream.
      
      When disabling/enabling a crtc the primary area must be updated
      independently of which crtc has been disabled/enabled.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264735Signed-off-by: default avatarFabiano Fidêncio <fidencio@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      489abfce
    • Linus Torvalds's avatar
      Initialize msg/shm IPC objects before doing ipc_addid() · 792d3057
      Linus Torvalds authored
      commit b9a53227 upstream.
      
      As reported by Dmitry Vyukov, we really shouldn't do ipc_addid() before
      having initialized the IPC object state.  Yes, we initialize the IPC
      object in a locked state, but with all the lockless RCU lookup work,
      that IPC object lock no longer means that the state cannot be seen.
      
      We already did this for the IPC semaphore code (see commit e8577d1f:
      "ipc/sem.c: fully initialize sem_array before making it visible") but we
      clearly forgot about msg and shm.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Davidlohr Bueso <dbueso@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      792d3057
    • Paul Burton's avatar
      MIPS: CPS: #ifdef on CONFIG_MIPS_MT_SMP rather than CONFIG_MIPS_MT · 1e65ce65
      Paul Burton authored
      commit 7a63076d upstream.
      
      The CONFIG_MIPS_MT symbol can be selected by CONFIG_MIPS_VPE_LOADER in
      addition to CONFIG_MIPS_MT_SMP. We only want MT code in the CPS SMP boot
      vector if we're using MT for SMP. Thus switch the config symbol we ifdef
      against to CONFIG_MIPS_MT_SMP.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/10867/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1e65ce65
    • Paul Burton's avatar
      MIPS: CPS: Don't include MT code in non-MT kernels. · fe76180c
      Paul Burton authored
      commit a5b0f6db upstream.
      
      The MT-specific code in mips_cps_boot_vpes can safely be omitted from
      kernels which don't support MT, with the default VPE==0 case being used
      as it would be after the has_mt (Config3.MT) check failed at runtime.
      Discarding the code entirely will save us a few bytes & allow cleaner
      handling of MT ASE instructions by later patches.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/10866/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fe76180c
    • Paul Burton's avatar
      MIPS: CPS: Stop dangling delay slot from has_mt. · dde7288f
      Paul Burton authored
      commit 1e5fb282 upstream.
      
      The has_mt macro ended with a branch, leaving its callers with a delay
      slot that would be executed if Config3.MT is not set. However it would
      not be executed if Config3 (or earlier Config registers) don't exist
      which makes it somewhat inconsistent at best. Fill the delay slot in the
      macro & fix the mips_cps_boot_vpes caller appropriately.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/10865/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dde7288f
    • James Hogan's avatar
      MIPS: dma-default: Fix 32-bit fall back to GFP_DMA · 99c6cedf
      James Hogan authored
      commit 53960059 upstream.
      
      If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32
      zone, as is the case for some 32-bit kernels, then massage_gfp_flags()
      will cause DMA memory allocated for devices with a 32..63-bit
      coherent_dma_mask to fall back to using __GFP_DMA, even though there may
      only be 32-bits of physical address available anyway.
      
      Correct that case to compare against a mask the size of phys_addr_t
      instead of always using a 64-bit mask.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Fixes: a2e715a8 ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.")
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9610/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      99c6cedf
  2. 19 Oct, 2015 24 commits
    • shengyong's avatar
      UBI: return ENOSPC if no enough space available · 05743f7b
      shengyong authored
      commit 7c7feb2e upstream.
      
      UBI: attaching mtd1 to ubi0
      UBI: scanning is finished
      UBI error: init_volumes: not enough PEBs, required 706, available 686
      UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1)
      UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM
      UBI error: ubi_init: cannot attach mtd1
      
      If available PEBs are not enough when initializing volumes, return -ENOSPC
      directly. If available PEBs are not enough when initializing WL, return
      -ENOSPC instead of -ENOMEM.
      Signed-off-by: default avatarSheng Yong <shengyong1@huawei.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Reviewed-by: default avatarDavid Gstir <david@sigma-star.at>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      05743f7b
    • Richard Weinberger's avatar
      UBI: Validate data_size · 80fe92d4
      Richard Weinberger authored
      commit 281fda27 upstream.
      
      Make sure that data_size is less than LEB size.
      Otherwise a handcrafted UBI image is able to trigger
      an out of bounds memory access in ubi_compare_lebs().
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Reviewed-by: default avatarDavid Gstir <david@sigma-star.at>
      [ luis: backported to 3.16:
        - no ubi_device parameter for the ubi_err() macro in 3.16 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      80fe92d4
    • Andreas Schwab's avatar
      m68k: Define asmlinkage_protect · 5ae1b59c
      Andreas Schwab authored
      commit 8474ba74 upstream.
      
      Make sure the compiler does not modify arguments of syscall functions.
      This can happen if the compiler generates a tailcall to another
      function.  For example, without asmlinkage_protect sys_openat is compiled
      into this function:
      
      sys_openat:
      	clr.l %d0
      	move.w 18(%sp),%d0
      	move.l %d0,16(%sp)
      	jbra do_sys_open
      
      Note how the fourth argument is modified in place, modifying the register
      %d4 that gets restored from this stack slot when the function returns to
      user-space.  The caller may expect the register to be unmodified across
      system calls.
      Signed-off-by: default avatarAndreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5ae1b59c
    • Adrian Hunter's avatar
      perf tools: Fix copying of /proc/kcore · 8b9cce7b
      Adrian Hunter authored
      commit b5cabbcb upstream.
      
      A copy of /proc/kcore containing the kernel text can be made to the
      buildid cache. e.g.
      
      	perf buildid-cache -v -k /proc/kcore
      
      To workaround objdump limitations, a copy is also made when annotating
      against /proc/kcore.
      
      The copying process stops working from libelf about v1.62 onwards (the
      problem was found with v1.63).
      
      The cause is that a call to gelf_getphdr() in kcore__add_phdr() fails
      because additional validation has been added to gelf_getphdr().
      
      The use of gelf_getphdr() is a misguided attempt to get default
      initialization of the Gelf_Phdr structure.  That should not be
      necessary because every member of the Gelf_Phdr structure is
      subsequently assigned.  So just remove the call to gelf_getphdr().
      
      Similarly, a call to gelf_getehdr() in gelf_kcore__init() can be
      removed also.
      
      Committer notes:
      
      Note to stable@kernel.org, from Adrian in the cover letter for this
      patchkit:
      
      The "Fix copying of /proc/kcore" problem goes back to v3.13 if you think
      it is important enough for stable.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lkml.kernel.org/r/1443089122-19082-3-git-send-email-adrian.hunter@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8b9cce7b
    • Kapileshwar Singh's avatar
      tools lib traceevent: Fix string handling in heterogeneous arch environments · c98cc93e
      Kapileshwar Singh authored
      commit c2e4b24f upstream.
      
      When a trace recorded on a 32-bit device is processed with a 64-bit
      binary, the higher 32-bits of the address need to ignored.
      
      The lack of this results in the output of the 64-bit pointer
      value to the trace as the 32-bit address lookup fails in find_printk().
      
      Before:
      
        burn-1778  [003]   548.600305: bputs:   0xc0046db2s: 2cec5c058d98c
      
      After:
      
        burn-1778  [003]   548.600305: bputs:   0xc0046db2s: RT throttling activated
      
      The problem occurs in PRINT_FIELD when the field is recognized as a
      pointer to a string (of the type const char *)
      
      Heterogeneous architectures cases below can arise and should be handled:
      
      * Traces recorded using 32-bit addresses processed on a 64-bit machine
      * Traces recorded using 64-bit addresses processed on a 32-bit machine
      Reported-by: default avatarJuri Lelli <juri.lelli@arm.com>
      Signed-off-by: default avatarKapileshwar Singh <kapileshwar.singh@arm.com>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Javi Merino <javi.merino@arm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c98cc93e
    • Prarit Bhargava's avatar
      intel_pstate: Fix overflow in busy_scaled due to long delay · e60f66b5
      Prarit Bhargava authored
      commit 7180dddf upstream.
      
      The kernel may delay interrupts for a long time which can result in timers
      being delayed. If this occurs the intel_pstate driver will crash with a
      divide by zero error:
      
      divide error: 0000 [#1] SMP
      Modules linked in: btrfs zlib_deflate raid6_pq xor msdos ext4 mbcache jbd2 binfmt_misc arc4 md4 nls_utf8 cifs dns_resolver tcp_lp bnep bluetooth rfkill fuse dm_service_time iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ftp ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables intel_powerclamp coretemp vfat fat kvm_intel iTCO_wdt iTCO_vendor_support ipmi_devintf sr_mod kvm crct10dif_pclmul
       crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel cdc_ether lrw usbnet cdrom mii gf128mul glue_helper ablk_helper cryptd lpc_ich mfd_core pcspkr sb_edac edac_core ipmi_si ipmi_msghandler ioatdma wmi shpchp acpi_pad nfsd auth_rpcgss nfs_acl lockd uinput dm_multipath sunrpc xfs libcrc32c usb_storage sd_mod crc_t10dif crct10dif_common ixgbe mgag200 syscopyarea sysfillrect sysimgblt mdio drm_kms_helper ttm igb drm ptp pps_core dca i2c_algo_bit megaraid_sas i2c_core dm_mirror dm_region_hash dm_log dm_mod
      CPU: 113 PID: 0 Comm: swapper/113 Tainted: G        W   --------------   3.10.0-229.1.2.el7.x86_64 #1
      Hardware name: IBM x3950 X6 -[3837AC2]-/00FN827, BIOS -[A8E112BUS-1.00]- 08/27/2014
      task: ffff880fe8abe660 ti: ffff880fe8ae4000 task.ti: ffff880fe8ae4000
      RIP: 0010:[<ffffffff814a9279>]  [<ffffffff814a9279>] intel_pstate_timer_func+0x179/0x3d0
      RSP: 0018:ffff883fff4e3db8  EFLAGS: 00010206
      RAX: 0000000027100000 RBX: ffff883fe6965100 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000000010 RDI: 000000002e53632d
      RBP: ffff883fff4e3e20 R08: 000e6f69a5a125c0 R09: ffff883fe84ec001
      R10: 0000000000000002 R11: 0000000000000005 R12: 00000000000049f5
      R13: 0000000000271000 R14: 00000000000049f5 R15: 0000000000000246
      FS:  0000000000000000(0000) GS:ffff883fff4e0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f7668601000 CR3: 000000000190a000 CR4: 00000000001407e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Stack:
       ffff883fff4e3e58 ffffffff81099dc1 0000000000000086 0000000000000071
       ffff883fff4f3680 0000000000000071 fbdc8a965e33afee ffffffff810b69dd
       ffff883fe84ec000 ffff883fe6965108 0000000000000100 ffffffff814a9100
      Call Trace:
       <IRQ>
      
       [<ffffffff81099dc1>] ? run_posix_cpu_timers+0x51/0x840
       [<ffffffff810b69dd>] ? trigger_load_balance+0x5d/0x200
       [<ffffffff814a9100>] ? pid_param_set+0x130/0x130
       [<ffffffff8107df56>] call_timer_fn+0x36/0x110
       [<ffffffff814a9100>] ? pid_param_set+0x130/0x130
       [<ffffffff8107fdcf>] run_timer_softirq+0x21f/0x320
       [<ffffffff81077b2f>] __do_softirq+0xef/0x280
       [<ffffffff816156dc>] call_softirq+0x1c/0x30
       [<ffffffff81015d95>] do_softirq+0x65/0xa0
       [<ffffffff81077ec5>] irq_exit+0x115/0x120
       [<ffffffff81616355>] smp_apic_timer_interrupt+0x45/0x60
       [<ffffffff81614a1d>] apic_timer_interrupt+0x6d/0x80
       <EOI>
      
       [<ffffffff814a9c32>] ? cpuidle_enter_state+0x52/0xc0
       [<ffffffff814a9c28>] ? cpuidle_enter_state+0x48/0xc0
       [<ffffffff814a9d65>] cpuidle_idle_call+0xc5/0x200
       [<ffffffff8101d14e>] arch_cpu_idle+0xe/0x30
       [<ffffffff810c67c1>] cpu_startup_entry+0xf1/0x290
       [<ffffffff8104228a>] start_secondary+0x1ba/0x230
      Code: 42 0f 00 45 89 e6 48 01 c2 43 8d 44 6d 00 39 d0 73 26 49 c1 e5 08 89 d2 4d 63 f4 49 63 c5 48 c1 e2 08 48 c1 e0 08 48 63 ca 48 99 <48> f7 f9 48 98 4c 0f af f0 49 c1 ee 08 8b 43 78 c1 e0 08 44 29
      RIP  [<ffffffff814a9279>] intel_pstate_timer_func+0x179/0x3d0
       RSP <ffff883fff4e3db8>
      
      The kernel values for cpudata for CPU 113 were:
      
      struct cpudata {
        cpu = 113,
        timer = {
          entry = {
            next = 0x0,
            prev = 0xdead000000200200
          },
          expires = 8357799745,
          base = 0xffff883fe84ec001,
          function = 0xffffffff814a9100 <intel_pstate_timer_func>,
          data = 18446612406765768960,
      <snip>
          i_gain = 0,
          d_gain = 0,
          deadband = 0,
          last_err = 22489
        },
        last_sample_time = {
          tv64 = 4063132438017305
        },
        prev_aperf = 287326796397463,
        prev_mperf = 251427432090198,
        sample = {
          core_pct_busy = 23081,
          aperf = 2937407,
          mperf = 3257884,
          freq = 2524484,
          time = {
            tv64 = 4063149215234118
          }
        }
      }
      
      which results in the time between samples = last_sample_time - sample.time
      = 4063149215234118 - 4063132438017305 = 16777216813 which is 16.777 seconds.
      
      The duration between reads of the APERF and MPERF registers overflowed a s32
      sized integer in intel_pstate_get_scaled_busy()'s call to div_fp().  The result
      is that int_tofp(duration_us) == 0, and the kernel attempts to divide by 0.
      
      While the kernel shouldn't be delaying for a long time, it can and does
      happen and the intel_pstate driver should not panic in this situation.  This
      patch changes the div_fp() function to use div64_s64() to allow for "long"
      division.  This will avoid the overflow condition on long delays.
      
      [v2]: use div64_s64() in div_fp()
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e60f66b5
    • Stratos Karafotis's avatar
      cpufreq: intel_pstate: Remove unnecessary type casting in div_s64() call · dba2c0bb
      Stratos Karafotis authored
      commit fa30dff9 upstream.
      
      div_s64() accepts the divisor parameter as s32. Helper div_fp()
      also accepts divisor as int32_t.
      
      So, remove the unnecessary int64_t type casting.
      Signed-off-by: default avatarStratos Karafotis <stratosk@semaphore.gr>
      Signed-off-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dba2c0bb
    • Chas Williams's avatar
      net/xen-netfront: only napi_synchronize() if running · a77af0e3
      Chas Williams authored
      commit 274b0455 upstream.
      
      If an interface isn't running napi_synchronize() will hang forever.
      
      [  392.248403] rmmod           R  running task        0   359    343 0x00000000
      [  392.257671]  ffff88003760fc88 ffff880037193b40 ffff880037193160 ffff88003760fc88
      [  392.267644]  ffff880037610000 ffff88003760fcd8 0000000100014c22 ffffffff81f75c40
      [  392.277524]  0000000000bc7010 ffff88003760fca8 ffffffff81796927 ffffffff81f75c40
      [  392.287323] Call Trace:
      [  392.291599]  [<ffffffff81796927>] schedule+0x37/0x90
      [  392.298553]  [<ffffffff8179985b>] schedule_timeout+0x14b/0x280
      [  392.306421]  [<ffffffff810f91b9>] ? irq_free_descs+0x69/0x80
      [  392.314006]  [<ffffffff811084d0>] ? internal_add_timer+0xb0/0xb0
      [  392.322125]  [<ffffffff81109d07>] msleep+0x37/0x50
      [  392.329037]  [<ffffffffa00ec79a>] xennet_disconnect_backend.isra.24+0xda/0x390 [xen_netfront]
      [  392.339658]  [<ffffffffa00ecadc>] xennet_remove+0x2c/0x80 [xen_netfront]
      [  392.348516]  [<ffffffff81481c69>] xenbus_dev_remove+0x59/0xc0
      [  392.356257]  [<ffffffff814e7217>] __device_release_driver+0x87/0x120
      [  392.364645]  [<ffffffff814e7cf8>] driver_detach+0xb8/0xc0
      [  392.371989]  [<ffffffff814e6e69>] bus_remove_driver+0x59/0xe0
      [  392.379883]  [<ffffffff814e84f0>] driver_unregister+0x30/0x70
      [  392.387495]  [<ffffffff814814b2>] xenbus_unregister_driver+0x12/0x20
      [  392.395908]  [<ffffffffa00ed89b>] netif_exit+0x10/0x775 [xen_netfront]
      [  392.404877]  [<ffffffff81124e08>] SyS_delete_module+0x1d8/0x230
      [  392.412804]  [<ffffffff8179a8ee>] system_call_fastpath+0x12/0x71
      Signed-off-by: default avatarChas Williams <3chas3@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Kamata, Munehisa <kamatam@amazon.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a77af0e3
    • Roland Dreier's avatar
      fib_rules: Fix dump_rules() not to exit early · ca3f157b
      Roland Dreier authored
      Backports of 41fc0143 ("fib_rules: fix fib rule dumps across
      multiple skbs") introduced a regression in "ip rule show" - it ends up
      dumping the first rule over and over and never exiting, because 3.19
      and earlier are missing commit 053c095a ("netlink: make
      nlmsg_end() and genlmsg_end() void"), so fib_nl_fill_rule() ends up
      returning skb->len (i.e. > 0) in the success case.
      
      Fix this by checking the return code for < 0 instead of != 0.
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ca3f157b
    • Charles Keepax's avatar
      asix: Do full reset during ax88772_bind · 26fc260c
      Charles Keepax authored
      commit 436c2a50 upstream.
      
      commit 3cc81d85 ("asix: Don't reset PHY on if_up for ASIX 88772")
      causes the ethernet on Arndale to no longer function. This appears to
      be because the Arndale ethernet requires a full reset before it will
      function correctly, however simply reverting the above patch causes
      problems with ethtool settings getting reset.
      
      It seems the problem is that the ethernet is not properly reset during
      bind, and indeed the code in ax88772_bind that resets the device is a
      very small subset of the actual ax88772_reset function. This patch uses
      ax88772_reset in place of the existing reset code in ax88772_bind which
      removes some code duplication and fixes the ethernet on Arndale.
      
      It is still possible that the original patch causes some issues with
      suspend and resume but that seems like a separate issue and I haven't
      had a chance to test that yet.
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Tested-by: default avatarRiku Voipio <riku.voipio@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      26fc260c
    • Michel Stam's avatar
      asix: Don't reset PHY on if_up for ASIX 88772 · 5b2f9c75
      Michel Stam authored
      commit 3cc81d85 upstream.
      
      I've noticed every time the interface is set to 'up,', the kernel
      reports that the link speed is set to 100 Mbps/Full Duplex, even
      when ethtool is used to set autonegotiation to 'off', half
      duplex, 10 Mbps.
      It can be tested by:
       ifconfig eth0 down
       ethtool -s eth0 autoneg off speed 10 duplex half
       ifconfig eth0 up
      
      Then checking 'dmesg' for the link speed.
      Signed-off-by: default avatarMichel Stam <m.stam@fugro.nl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5b2f9c75
    • Jan Kara's avatar
      jbd2: avoid infinite loop when destroying aborted journal · 4163c028
      Jan Kara authored
      commit 841df7df upstream.
      
      Commit 6f6a6fda "jbd2: fix ocfs2 corrupt when updating journal
      superblock fails" changed jbd2_cleanup_journal_tail() to return EIO
      when the journal is aborted. That makes logic in
      jbd2_log_do_checkpoint() bail out which is fine, except that
      jbd2_journal_destroy() expects jbd2_log_do_checkpoint() to always make
      a progress in cleaning the journal. Without it jbd2_journal_destroy()
      just loops in an infinite loop.
      
      Fix jbd2_journal_destroy() to cleanup journal checkpoint lists of
      jbd2_log_do_checkpoint() fails with error.
      Reported-by: default avatarEryu Guan <guaneryu@gmail.com>
      Tested-by: default avatarEryu Guan <guaneryu@gmail.com>
      Fixes: 6f6a6fdaSigned-off-by: default avatarJan Kara <jack@suse.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      [ luis: backported to 3.16: used Jan's backport ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4163c028
    • Luis Henriques's avatar
      Revert "ARM: orion5x: fix legacy orion5x IRQ numbers" · 10690398
      Luis Henriques authored
      This reverts commit b5614b19,
      which was commit 5be9fc23 upstream.
      
      Ben Hutchings pointed out this was not applicable to the 3.16-ckt kernel.
      
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
      Cc: Benjamin Cama <benoar@dolka.fr>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      10690398
    • Jiri Benc's avatar
      vxlan: set needed headroom correctly · e4f4ae66
      Jiri Benc authored
      commit 9dc2ad10 upstream.
      
      vxlan_setup is called when allocating the net_device, i.e. way before
      vxlan_newlink (or vxlan_dev_configure) is called. This means
      vxlan->default_dst is actually unset in vxlan_setup and the condition that
      sets needed_headroom always takes the else branch.
      
      Set the needed_headrom at the point when we have the information about
      the address family available.
      
      Fixes: e4c7ed41 ("vxlan: add ipv6 support")
      Fixes: 2853af6a ("vxlan: use dev->needed_headroom instead of dev->hard_header_len")
      CC: Cong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16:
        - initialise needed_headrom in vxlan_newlink() instead of
          vxlan_dev_configure() ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e4f4ae66
    • Grazvydas Ignotas's avatar
      ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets · 398c3f47
      Grazvydas Ignotas authored
      commit 1dbdad75 upstream.
      
      The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
      pins up, communication with tca6424a doesn't work (controller timeouts)
      and it is not possible to enable HDMI.
      
      Fixes: 9be495c4 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      398c3f47
    • Robert Jarzmik's avatar
      ASoC: fix broken pxa SoC support · 87d42cac
      Robert Jarzmik authored
      commit 3c8f7710 upstream.
      
      The previous fix of pxa library support, which was introduced to fix the
      library dependency, broke the previous SoC behavior, where a machine
      code binding pxa2xx-ac97 with a coded relied on :
       - sound/soc/pxa/pxa2xx-ac97.c
       - sound/soc/codecs/XXX.c
      
      For example, the mioa701_wm9713.c machine code is currently broken. The
      "select ARM" statement wrongly selects the soc/arm/pxa2xx-ac97 for
      compilation, as per an unfortunate fate SND_PXA2XX_AC97 is both declared
      in sound/arm/Kconfig and sound/soc/pxa/Kconfig.
      
      Fix this by ensuring that SND_PXA2XX_SOC correctly triggers the correct
      pxa2xx-ac97 compilation.
      
      Fixes: 846172df ("ASoC: fix SND_PXA2XX_LIB Kconfig warning")
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      87d42cac
    • Pablo Neira Ayuso's avatar
      netfilter: nft_compat: skip family comparison in case of NFPROTO_UNSPEC · cc4bc062
      Pablo Neira Ayuso authored
      commit ba378ca9 upstream.
      
      Fix lookup of existing match/target structures in the corresponding list
      by skipping the family check if NFPROTO_UNSPEC is used.
      
      This is resulting in the allocation and insertion of one match/target
      structure for each use of them. So this not only bloats memory
      consumption but also severely affects the time to reload the ruleset
      from the iptables-compat utility.
      
      After this patch, iptables-compat-restore and iptables-compat take
      almost the same time to reload large rulesets.
      
      Fixes: 0ca743a5 ("netfilter: nf_tables: add compatibility layer for x_tables")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cc4bc062
    • Alex Williamson's avatar
      PCI: Use function 0 VPD for identical functions, regular VPD for others · 34ad4e3e
      Alex Williamson authored
      commit da2d03ea upstream.
      
      932c435c ("PCI: Add dev_flags bit to access VPD through function 0")
      added PCI_DEV_FLAGS_VPD_REF_F0.  Previously, we set the flag on every
      non-zero function of quirked devices.  If a function turned out to be
      different from function 0, i.e., it had a different class, vendor ID, or
      device ID, the flag remained set but we didn't make VPD accessible at all.
      
      Flip this around so we only set PCI_DEV_FLAGS_VPD_REF_F0 for functions that
      are identical to function 0, and allow regular VPD access for any other
      functions.
      
      [bhelgaas: changelog, stable tag]
      Fixes: 932c435c ("PCI: Add dev_flags bit to access VPD through function 0")
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <helgaas@kernel.org>
      Acked-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Acked-by: default avatarMark Rustad <mark.d.rustad@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      34ad4e3e
    • Alex Williamson's avatar
      PCI: Fix devfn for VPD access through function 0 · 1a74f72d
      Alex Williamson authored
      commit 9d924075 upstream.
      
      Commit 932c435c ("PCI: Add dev_flags bit to access VPD through function
      0") passes PCI_SLOT(devfn) for the devfn parameter of pci_get_slot().
      Generally this works because we're fairly well guaranteed that a PCIe
      device is at slot address 0, but for the general case, including
      conventional PCI, it's incorrect.  We need to get the slot and then convert
      it back into a devfn.
      
      Fixes: 932c435c ("PCI: Add dev_flags bit to access VPD through function 0")
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <helgaas@kernel.org>
      Acked-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Acked-by: default avatarMark Rustad <mark.d.rustad@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1a74f72d
    • Dave Airlie's avatar
      drm/qxl: only report first monitor as connected if we have no state · d0633d21
      Dave Airlie authored
      commit 69e5d3f8 upstream.
      
      If the server isn't new enough to give us state, report the first
      monitor as always connected, otherwise believe the server side.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d0633d21
    • Johan Hovold's avatar
      USB: whiteheat: fix potential null-deref at probe · 73e63917
      Johan Hovold authored
      commit cbb4be65 upstream.
      
      Fix potential null-pointer dereference at probe by making sure that the
      required endpoints are present.
      
      The whiteheat driver assumes there are at least five pairs of bulk
      endpoints, of which the final pair is used for the "command port". An
      attempt to bind to an interface with fewer bulk endpoints would
      currently lead to an oops.
      
      Fixes CVE-2015-5257.
      Reported-by: default avatarMoein Ghasemzadeh <moein@istuary.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      73e63917
    • Jani Nikula's avatar
      drm/i915/bios: handle MIPI Sequence Block v3+ gracefully · bacda5a9
      Jani Nikula authored
      commit cd67d226 upstream.
      
      The VBT MIPI Sequence Block version 3 has forward incompatible changes:
      
      First, the block size in the header has been specified reserved, and the
      actual size is a separate 32-bit value within the block. The current
      find_section() function to will only look at the size in the block
      header, and, depending on what's in that now reserved size field,
      continue looking for other sections in the wrong place.
      
      Fix this by taking the new block size field into account. This will
      ensure that the lookups for other sections will work properly, as long
      as the new 32-bit size does not go beyond the opregion VBT mailbox size.
      
      Second, the contents of the block have been completely
      changed. Gracefully refuse parsing the yet unknown data version.
      
      Cc: Deepak M <m.deepak@intel.com>
      Reviewed-by: default avatarDeepak M <m.deepak@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bacda5a9
    • Joseph Qi's avatar
      ocfs2/dlm: fix deadlock when dispatch assert master · 7d70db1c
      Joseph Qi authored
      commit 012572d4 upstream.
      
      The order of the following three spinlocks should be:
      dlm_domain_lock < dlm_ctxt->spinlock < dlm_lock_resource->spinlock
      
      But dlm_dispatch_assert_master() is called while holding
      dlm_ctxt->spinlock and dlm_lock_resource->spinlock, and then it calls
      dlm_grab() which will take dlm_domain_lock.
      
      Once another thread (for example, dlm_query_join_handler) has already
      taken dlm_domain_lock, and tries to take dlm_ctxt->spinlock deadlock
      happens.
      Signed-off-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: "Junxiao Bi" <junxiao.bi@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7d70db1c
    • Robert Jarzmik's avatar
      ASoC: pxa: pxa2xx-ac97: fix dma requestor lines · b10e26bc
      Robert Jarzmik authored
      commit 8811191f upstream.
      
      PCM receive and transmit DMA requestor lines were reverted, breaking the
      PCM playback interface for PXA platforms using the sound/soc/ variant
      instead of the sound/arm variant.
      
      The commit below shows the inversion in the requestor lines.
      
      Fixes: d65a1458 ("ASoC: pxa: use snd_dmaengine_dai_dma_data")
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b10e26bc