1. 20 Jun, 2016 15 commits
    • Sergei Shtylyov's avatar
      of: irq: fix of_irq_get[_byname]() kernel-doc · 014694d9
      Sergei Shtylyov authored
      [ Upstream commit 39935466 ]
      
      The kernel-doc for the of_irq_get[_byname]()  is clearly inadequate in
      describing the return values -- of_irq_get_byname() is documented better
      than of_irq_get() but it  still doesn't mention that 0 is returned iff
      irq_create_of_mapping() fails (it doesn't return an error code in this
      case). Document all possible return value variants, making the writing
      of the word "IRQ" consistent, while at it...
      
      Fixes: 9ec36caf ("of/irq: do irq resolution in platform_get_irq")
      Fixes: ad69674e ("of/irq: do irq resolution in platform_get_irq_byname()")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      014694d9
    • AceLan Kao's avatar
      ALSA: hda - Fix headset mic detection problem for Dell machine · 1155365d
      AceLan Kao authored
      [ Upstream commit f90d83b3 ]
      
      Add the pin configuration value of this machine into the pin_quirk
      table to make DELL1_MIC_NO_PRESENCE apply to this machine.
      Signed-off-by: default avatarAceLan Kao <acelan.kao@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1155365d
    • Chris Wilson's avatar
      locking/ww_mutex: Report recursive ww_mutex locking early · 33fae4cc
      Chris Wilson authored
      [ Upstream commit 0422e83d ]
      
      Recursive locking for ww_mutexes was originally conceived as an
      exception. However, it is heavily used by the DRM atomic modesetting
      code. Currently, the recursive deadlock is checked after we have queued
      up for a busy-spin and as we never release the lock, we spin until
      kicked, whereupon the deadlock is discovered and reported.
      
      A simple solution for the now common problem is to move the recursive
      deadlock discovery to the first action when taking the ww_mutex.
      Suggested-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/1464293297-19777-1-git-send-email-chris@chris-wilson.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      33fae4cc
    • Marc Zyngier's avatar
      irqchip/gic-v3: Fix ICC_SGI1R_EL1.INTID decoding mask · d822ea89
      Marc Zyngier authored
      [ Upstream commit dd5f1b04 ]
      
      The INTID mask is wrong, and is made a signed value, which has
      nteresting effects in the KVM emulation. Let's sanitize it.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d822ea89
    • Andre Przywara's avatar
      arm64: GICv3: introduce symbolic names for GICv3 ICC_SGI1R_EL1 fields · 045f0890
      Andre Przywara authored
      [ Upstream commit 7e580278 ]
      
      The gic_send_sgi() function used hardcoded bit shift values to
      generate the ICC_SGI1R_EL1 register value.
      Replace this with symbolic names to allow reusing them later.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      045f0890
    • Paolo Bonzini's avatar
      KVM: x86: fix OOPS after invalid KVM_SET_DEBUGREGS · 26c6a777
      Paolo Bonzini authored
      [ Upstream commit d14bdb55 ]
      
      MOV to DR6 or DR7 causes a #GP if an attempt is made to write a 1 to
      any of bits 63:32.  However, this is not detected at KVM_SET_DEBUGREGS
      time, and the next KVM_RUN oopses:
      
         general protection fault: 0000 [#1] SMP
         CPU: 2 PID: 14987 Comm: a.out Not tainted 4.4.9-300.fc23.x86_64 #1
         Hardware name: LENOVO 2325F51/2325F51, BIOS G2ET32WW (1.12 ) 05/30/2012
         [...]
         Call Trace:
          [<ffffffffa072c93d>] kvm_arch_vcpu_ioctl_run+0x141d/0x14e0 [kvm]
          [<ffffffffa071405d>] kvm_vcpu_ioctl+0x33d/0x620 [kvm]
          [<ffffffff81241648>] do_vfs_ioctl+0x298/0x480
          [<ffffffff812418a9>] SyS_ioctl+0x79/0x90
          [<ffffffff817a0f2e>] entry_SYSCALL_64_fastpath+0x12/0x71
         Code: 55 83 ff 07 48 89 e5 77 27 89 ff ff 24 fd 90 87 80 81 0f 23 fe 5d c3 0f 23 c6 5d c3 0f 23 ce 5d c3 0f 23 d6 5d c3 0f 23 de 5d c3 <0f> 23 f6 5d c3 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
         RIP  [<ffffffff810639eb>] native_set_debugreg+0x2b/0x40
          RSP <ffff88005836bd50>
      
      Testcase (beautified/reduced from syzkaller output):
      
          #include <unistd.h>
          #include <sys/syscall.h>
          #include <string.h>
          #include <stdint.h>
          #include <linux/kvm.h>
          #include <fcntl.h>
          #include <sys/ioctl.h>
      
          long r[8];
      
          int main()
          {
              struct kvm_debugregs dr = { 0 };
      
              r[2] = open("/dev/kvm", O_RDONLY);
              r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
              r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
      
              memcpy(&dr,
                     "\x5d\x6a\x6b\xe8\x57\x3b\x4b\x7e\xcf\x0d\xa1\x72"
                     "\xa3\x4a\x29\x0c\xfc\x6d\x44\x00\xa7\x52\xc7\xd8"
                     "\x00\xdb\x89\x9d\x78\xb5\x54\x6b\x6b\x13\x1c\xe9"
                     "\x5e\xd3\x0e\x40\x6f\xb4\x66\xf7\x5b\xe3\x36\xcb",
                     48);
              r[7] = ioctl(r[4], KVM_SET_DEBUGREGS, &dr);
              r[6] = ioctl(r[4], KVM_RUN, 0);
          }
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      26c6a777
    • Paolo Bonzini's avatar
      KVM: irqfd: fix NULL pointer dereference in kvm_irq_map_gsi · 9a579331
      Paolo Bonzini authored
      [ Upstream commit c622a3c2 ]
      
      Found by syzkaller:
      
          BUG: unable to handle kernel NULL pointer dereference at 0000000000000120
          IP: [<ffffffffa0797202>] kvm_irq_map_gsi+0x12/0x90 [kvm]
          PGD 6f80b067 PUD b6535067 PMD 0
          Oops: 0000 [#1] SMP
          CPU: 3 PID: 4988 Comm: a.out Not tainted 4.4.9-300.fc23.x86_64 #1
          [...]
          Call Trace:
           [<ffffffffa0795f62>] irqfd_update+0x32/0xc0 [kvm]
           [<ffffffffa0796c7c>] kvm_irqfd+0x3dc/0x5b0 [kvm]
           [<ffffffffa07943f4>] kvm_vm_ioctl+0x164/0x6f0 [kvm]
           [<ffffffff81241648>] do_vfs_ioctl+0x298/0x480
           [<ffffffff812418a9>] SyS_ioctl+0x79/0x90
           [<ffffffff817a1062>] tracesys_phase2+0x84/0x89
          Code: b5 71 a7 e0 5b 41 5c 41 5d 5d f3 c3 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 8f 10 2e 00 00 31 c0 48 89 e5 <39> 91 20 01 00 00 76 6a 48 63 d2 48 8b 94 d1 28 01 00 00 48 85
          RIP  [<ffffffffa0797202>] kvm_irq_map_gsi+0x12/0x90 [kvm]
           RSP <ffff8800926cbca8>
          CR2: 0000000000000120
      
      Testcase:
      
          #include <unistd.h>
          #include <sys/syscall.h>
          #include <string.h>
          #include <stdint.h>
          #include <linux/kvm.h>
          #include <fcntl.h>
          #include <sys/ioctl.h>
      
          long r[26];
      
          int main()
          {
              memset(r, -1, sizeof(r));
              r[2] = open("/dev/kvm", 0);
              r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
      
              struct kvm_irqfd ifd;
              ifd.fd = syscall(SYS_eventfd2, 5, 0);
              ifd.gsi = 3;
              ifd.flags = 2;
              ifd.resamplefd = ifd.fd;
              r[25] = ioctl(r[3], KVM_IRQFD, &ifd);
              return 0;
          }
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      9a579331
    • Russell King's avatar
      ARM: fix PTRACE_SETVFPREGS on SMP systems · b0f8d64a
      Russell King authored
      [ Upstream commit e2dfb4b8 ]
      
      PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
      reloaded, because it undoes one of the effects of vfp_flush_hwstate().
      
      Specifically vfp_flush_hwstate() sets thread->vfpstate.hard.cpu to
      an invalid CPU number, but vfp_set() overwrites this with the original
      CPU number, thereby rendering the hardware state as apparently "valid",
      even though the software state is more recent.
      
      Fix this by reverting the previous change.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 8130b9d7 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Tested-by: default avatarSimon Marchi <simon.marchi@ericsson.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b0f8d64a
    • Ben Skeggs's avatar
      drm/nouveau/fbcon: fix out-of-bounds memory accesses · 6a962d0a
      Ben Skeggs authored
      [ Upstream commit f045f459 ]
      
      Reported by KASAN.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6a962d0a
    • Thierry Reding's avatar
      drm/fb-helper: Propagate errors from initial config failure · ee20274f
      Thierry Reding authored
      [ Upstream commit 01934c2a ]
      
      Make drm_fb_helper_initial_config() return an int rather than a bool so
      that the error can be properly propagated. While at it, update drivers
      to propagate errors further rather than just ignore them.
      
      v2:
      - cirrus: No cleanup is required, the top-level cirrus_driver_load()
        will do it as part of cirrus_driver_unload() in its cleanup path.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      [danvet: Squash in simplification patch from kbuild.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ee20274f
    • Ewan D. Milne's avatar
      scsi: Add QEMU CD-ROM to VPD Inquiry Blacklist · 403b9535
      Ewan D. Milne authored
      [ Upstream commit fbd83006 ]
      
      Linux fails to boot as a guest with a QEMU CD-ROM:
      
      [    4.439488] ata2.00: ATAPI: QEMU CD-ROM, 0.8.2, max UDMA/100
      [    4.443649] ata2.00: configured for MWDMA2
      [    4.450267] scsi 1:0:0:0: CD-ROM            QEMU     QEMU CD-ROM      0.8. PQ: 0 ANSI: 5
      [    4.464317] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
      [    4.464319] ata2.00: BMDMA stat 0x5
      [    4.464339] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in
      [    4.464339]          Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
      [    4.464341] ata2.00: status: { DRDY DRQ }
      [    4.465864] ata2: soft resetting link
      [    4.625971] ata2.00: configured for MWDMA2
      [    4.628290] ata2: EH complete
      [    4.646670] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
      [    4.646671] ata2.00: BMDMA stat 0x5
      [    4.646683] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in
      [    4.646683]          Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
      [    4.646685] ata2.00: status: { DRDY DRQ }
      [    4.648193] ata2: soft resetting link
      
      ...
      
      Fix this by suppressing VPD inquiry for this device.
      Signed-off-by: default avatarEwan D. Milne <emilne@redhat.com>
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Tested-by: default avatarJan Stancek <jstancek@redhat.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      403b9535
    • Bob Copeland's avatar
      mac80211: mesh: flush mesh paths unconditionally · 9cac3aff
      Bob Copeland authored
      [ Upstream commit fe7a7c57 ]
      
      Currently, the mesh paths associated with a nexthop station are cleaned
      up in the following code path:
      
          __sta_info_destroy_part1
          synchronize_net()
          __sta_info_destroy_part2
           -> cleanup_single_sta
             -> mesh_sta_cleanup
               -> mesh_plink_deactivate
                 -> mesh_path_flush_by_nexthop
      
      However, there are a couple of problems here:
      
      1) the paths aren't flushed at all if the MPM is running in userspace
         (e.g. when using wpa_supplicant or authsae)
      
      2) there is no synchronize_rcu between removing the path and readers
         accessing the nexthop, which means the following race is possible:
      
      CPU0                            CPU1
      ~~~~                            ~~~~
                                      sta_info_destroy_part1()
                                      synchronize_net()
      rcu_read_lock()
      mesh_nexthop_resolve()
        mpath = mesh_path_lookup()
                                      [...] -> mesh_path_flush_by_nexthop()
        sta = rcu_dereference(
          mpath->next_hop)
                                      kfree(sta)
        access sta <-- CRASH
      
      Fix both of these by unconditionally flushing paths before destroying
      the sta, and by adding a synchronize_net() after path flush to ensure
      no active readers can still dereference the sta.
      
      Fixes this crash:
      
      [  348.529295] BUG: unable to handle kernel paging request at 00020040
      [  348.530014] IP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
      [  348.530014] *pde = 00000000
      [  348.530014] Oops: 0000 [#1] PREEMPT
      [  348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ]
      [  348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G           O 4.6.0-rc5-wt=V1 #1
      [  348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016  11/07/2014
      [  348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000
      [  348.530014] EIP: 0060:[<f929245d>] EFLAGS: 00010246 CPU: 0
      [  348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
      [  348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008
      [  348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40
      [  348.530014]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      [  348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690
      [  348.530014] Stack:
      [  348.530014]  00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0
      [  348.530014]  f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320
      [  348.530014]  f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1
      [  348.530014] Call Trace:
      [  348.530014]  [<f9291d80>] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
      [  348.530014]  [<f9291dc1>] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
      [  348.530014]  [<f9277f6f>] ieee80211_xmit+0x92/0xc1 [mac80211]
      [  348.530014]  [<f9278dd1>] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
      [  348.530014]  [<c04df012>] ? sch_direct_xmit+0xd7/0x1b3
      [  348.530014]  [<c022a8c6>] ? __local_bh_enable_ip+0x5d/0x7b
      [  348.530014]  [<f956870c>] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
      [  348.530014]  [<f957e036>] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
      [  348.530014]  [<c04c6f45>] ? netif_skb_features+0x14d/0x30a
      [  348.530014]  [<f9278e10>] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
      [  348.530014]  [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
      [  348.530014]  [<c04c7261>] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
      [  348.530014]  [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
      [  348.530014]  [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
      [  348.530014]  [<c04c7cfb>] dev_queue_xmit+0xa/0xc
      [  348.530014]  [<f91bfc7a>] batadv_send_skb_packet+0xd6/0xec [batman_adv]
      [  348.530014]  [<f91bfdc4>] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
      [  348.530014]  [<f91b5938>] batadv_dat_send_data+0x27e/0x310 [batman_adv]
      [  348.530014]  [<f91c30b5>] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
      [  348.530014]  [<f91b63f3>] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
      [  348.530014]  [<f91c0cd9>] batadv_interface_tx+0x206/0x385 [batman_adv]
      [  348.530014]  [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
      [  348.530014]  [<c04c7261>] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
      [  348.530014]  [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
      [  348.530014]  [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
      [  348.530014]  [<f80cbd2a>] ? igb_xmit_frame+0x57/0x72 [igb]
      [  348.530014]  [<c04c7cfb>] dev_queue_xmit+0xa/0xc
      [  348.530014]  [<f843a326>] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
      [  348.530014]  [<f843a35f>] br_forward_finish+0x29/0x74 [bridge]
      [  348.530014]  [<f843a23b>] ? deliver_clone+0x3b/0x3b [bridge]
      [  348.530014]  [<f843a714>] __br_forward+0x89/0xe7 [bridge]
      [  348.530014]  [<f843a336>] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
      [  348.530014]  [<f843a234>] deliver_clone+0x34/0x3b [bridge]
      [  348.530014]  [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
      [  348.530014]  [<f843a66d>] br_flood+0x77/0x95 [bridge]
      [  348.530014]  [<f843a809>] br_flood_forward+0x13/0x1a [bridge]
      [  348.530014]  [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
      [  348.530014]  [<f843b877>] br_handle_frame_finish+0x392/0x3db [bridge]
      [  348.530014]  [<c04e9b2b>] ? nf_iterate+0x2b/0x6b
      [  348.530014]  [<f843baa6>] br_handle_frame+0x1e6/0x240 [bridge]
      [  348.530014]  [<f843b4e5>] ? br_handle_local_finish+0x6a/0x6a [bridge]
      [  348.530014]  [<c04c4ba0>] __netif_receive_skb_core+0x43a/0x66b
      [  348.530014]  [<f843b8c0>] ? br_handle_frame_finish+0x3db/0x3db [bridge]
      [  348.530014]  [<c023cea4>] ? resched_curr+0x19/0x37
      [  348.530014]  [<c0240707>] ? check_preempt_wakeup+0xbf/0xfe
      [  348.530014]  [<c0255dec>] ? ktime_get_with_offset+0x5c/0xfc
      [  348.530014]  [<c04c4fc1>] __netif_receive_skb+0x47/0x55
      [  348.530014]  [<c04c57ba>] netif_receive_skb_internal+0x40/0x5a
      [  348.530014]  [<c04c61ef>] napi_gro_receive+0x3a/0x94
      [  348.530014]  [<f80ce8d5>] igb_poll+0x6fd/0x9ad [igb]
      [  348.530014]  [<c0242bd8>] ? swake_up_locked+0x14/0x26
      [  348.530014]  [<c04c5d29>] net_rx_action+0xde/0x250
      [  348.530014]  [<c022a743>] __do_softirq+0x8a/0x163
      [  348.530014]  [<c022a6b9>] ? __hrtimer_tasklet_trampoline+0x19/0x19
      [  348.530014]  [<c021100f>] do_softirq_own_stack+0x26/0x2c
      [  348.530014]  <IRQ>
      [  348.530014]  [<c022a957>] irq_exit+0x31/0x6f
      [  348.530014]  [<c0210eb2>] do_IRQ+0x8d/0xa0
      [  348.530014]  [<c058152c>] common_interrupt+0x2c/0x40
      [  348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005
      [  348.530014] EIP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40
      [  348.530014] CR2: 0000000000020040
      [  348.530014] ---[ end trace 48556ac26779732e ]---
      [  348.530014] Kernel panic - not syncing: Fatal exception in interrupt
      [  348.530014] Kernel Offset: disabled
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarFred Veldini <fred.veldini@gmail.com>
      Tested-by: default avatarFred Veldini <fred.veldini@gmail.com>
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      9cac3aff
    • Martin Willi's avatar
      mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL · 46c57e77
      Martin Willi authored
      [ Upstream commit 62397da5 ]
      
      A wmediumd that does not send this attribute causes a NULL pointer
      dereference, as the attribute is accessed even if it does not exist.
      
      The attribute was required but never checked ever since userspace frame
      forwarding has been introduced. The issue gets more problematic once we
      allow wmediumd registration from user namespaces.
      
      Cc: stable@vger.kernel.org
      Fixes: 7882513b ("mac80211_hwsim driver support userspace frame tx/rx")
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      46c57e77
    • Thomas Huth's avatar
      powerpc: Use privileged SPR number for MMCR2 · de31d25a
      Thomas Huth authored
      [ Upstream commit 8dd75ccb ]
      
      We are already using the privileged versions of MMCR0, MMCR1
      and MMCRA in the kernel, so for MMCR2, we should better use
      the privileged versions, too, to be consistent.
      
      Fixes: 240686c1 ("powerpc: Initialise PMU related regs on Power8")
      Cc: stable@vger.kernel.org # v3.10+
      Suggested-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      Acked-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      de31d25a
    • Thomas Huth's avatar
      powerpc: Fix definition of SIAR and SDAR registers · e342ed8f
      Thomas Huth authored
      [ Upstream commit d23fac2b ]
      
      The SIAR and SDAR registers are available twice, one time as SPRs
      780 / 781 (unprivileged, but read-only), and one time as the SPRs
      796 / 797 (privileged, but read and write). The Linux kernel code
      currently uses the unprivileged  SPRs - while this is OK for reading,
      writing to that register of course does not work.
      Since the KVM code tries to write to this register, too (see the mtspr
      in book3s_hv_rmhandlers.S), the contents of this register sometimes get
      lost for the guests, e.g. during migration of a VM.
      To fix this issue, simply switch to the privileged SPR numbers instead.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      Acked-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e342ed8f
  2. 18 Jun, 2016 4 commits
  3. 06 Jun, 2016 21 commits