1. 25 Apr, 2018 1 commit
  2. 23 Apr, 2018 2 commits
  3. 21 Apr, 2018 1 commit
  4. 19 Apr, 2018 20 commits
  5. 18 Apr, 2018 7 commits
    • Bjørn Mork's avatar
      tun: fix vlan packet truncation · 81c89507
      Bjørn Mork authored
      Bogus trimming in tun_net_xmit() causes truncated vlan packets.
      
      skb->len is correct whether or not skb_vlan_tag_present() is true. There
      is no more reason to adjust the skb length on xmit in this driver than
      any other driver. tun_put_user() adds 4 bytes to the total for tagged
      packets because it transmits the tag inline to userspace.  This is
      similar to a nic transmitting the tag inline on the wire.
      
      Reproducing the bug by sending any tagged packet through back-to-back
      connected tap interfaces:
      
       socat TUN,tun-type=tap,iff-up,tun-name=in TUN,tun-type=tap,iff-up,tun-name=out &
       ip link add link in name in.20 type vlan id 20
       ip addr add 10.9.9.9/24 dev in.20
       ip link set in.20 up
       tshark -nxxi in -f arp -c1 2>/dev/null &
       tshark -nxxi out -f arp -c1 2>/dev/null &
       ping -c 1 10.9.9.5 >/dev/null 2>&1
      
      The output from the 'in' and 'out' interfaces are different when the
      bug is present:
      
       Capturing on 'in'
       0000  ff ff ff ff ff ff 76 cf 76 37 d5 0a 81 00 00 14   ......v.v7......
       0010  08 06 00 01 08 00 06 04 00 01 76 cf 76 37 d5 0a   ..........v.v7..
       0020  0a 09 09 09 00 00 00 00 00 00 0a 09 09 05         ..............
      
       Capturing on 'out'
       0000  ff ff ff ff ff ff 76 cf 76 37 d5 0a 81 00 00 14   ......v.v7......
       0010  08 06 00 01 08 00 06 04 00 01 76 cf 76 37 d5 0a   ..........v.v7..
       0020  0a 09 09 09 00 00 00 00 00 00                     ..........
      
      Fixes: aff3d70a
      
       ("tun: allow to attach ebpf socket filter")
      Cc: Jason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81c89507
    • Imre Deak's avatar
      drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state · 7eb2c4dd
      Imre Deak authored
      LSPCON adapters in low-power state may ignore the first I2C write during
      TMDS output buffer enabling, resulting in a blank screen even with an
      otherwise enabled pipe. Fix this by reading back and validating the
      written value a few times.
      
      The problem was noticed on GLK machines with an onboard LSPCON adapter
      after entering/exiting DC5 power state. Doing an I2C read of the adapter
      ID as the first transaction - instead of the I2C write to enable the
      TMDS buffers - returns the correct value. Based on this we assume that
      the transaction itself is sent properly, it's only the adapter that is
      not ready for some reason to accept this first write after waking from
      low-power state. In my case the second I2C write attempt always
      succeeded.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105854
      
      
      Cc: Clinton Taylor <clinton.a.taylor@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180416155309.11100-1-imre.deak@intel.com
      7eb2c4dd
    • Gaurav K Singh's avatar
      drm/i915/audio: Fix audio detection issue on GLK · b4615730
      Gaurav K Singh authored
      On Geminilake, sometimes audio card is not getting
      detected after reboot. This is a spurious issue happening on
      Geminilake. HW codec and HD audio controller link was going
      out of sync for which there was a fix in i915 driver but
      was not getting invoked for GLK. Extending this fix to GLK as well.
      
      Tested by Du,Wenkai on GLK board.
      
      Bspec: 21829
      
      v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N)
      
      Cc: <stable@vger.kernel.org> # b651bd2a
      
       ("drm/i915/audio: Fix audio enumeration issue on BXT")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGaurav K Singh <gaurav.k.singh@intel.com>
      Reviewed-by: default avatarAbhay Kumar <abhay.Kumar@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1523989338-29677-1-git-send-email-gaurav.k.singh@intel.com
      (cherry picked from commit 82212290
      
      )
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      b4615730
    • Chris Wilson's avatar
      drm/i915: Call i915_perf_fini() on init_hw error unwind · 4a0559ed
      Chris Wilson authored
      We have to cleanup after i915_perf_init(), even on the error path, as it
      passes a pointer into the module to the sysfs core. If we fail to
      unregister the sysctl table, we leave a dangling pointer which then may
      explode anytime later.
      
      Fixes: 9f9b2792
      
       ("drm/i915/perf: reuse timestamp frequency from device info")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Reviewed-by: default avatarMichal Wajdeczko <michal.wajdeczko@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180414091233.32224-1-chris@chris-wilson.co.uk
      (cherry picked from commit 9f172f6f
      
      )
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      4a0559ed
    • Jani Nikula's avatar
      drm/i915/bios: filter out invalid DDC pins from VBT child devices · a3520b89
      Jani Nikula authored
      
      
      The VBT contains the DDC pin to use for specific ports. Alas, sometimes
      the field appears to contain bogus data, and while we check for it later
      on in intel_gmbus_get_adapter() we fail to check the returned NULL on
      errors. Oops results.
      
      The simplest approach seems to be to catch and ignore the bogus DDC pins
      already at the VBT parsing phase, reverting to fixed per port default
      pins. This doesn't guarantee display working, but at least it prevents
      the oops. And we continue to be fuzzed by VBT.
      
      One affected machine is Dell Latitude 5590 where a BIOS upgrade added
      invalid DDC pins.
      
      Typical backtrace:
      
      [   35.461411] WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin))
      [   35.461432] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
      [   35.461437] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
      [   35.461445] CPU: 6 PID: 411 Comm: kworker/u16:2 Not tainted 4.16.0-rc7.x64-g1cda370ffded #1
      [   35.461447] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
      [   35.461450] Workqueue: events_unbound async_run_entry_fn
      [   35.461465] RIP: 0010:intel_gmbus_get_adapter+0x32/0x37 [i915]
      [   35.461467] RSP: 0018:ffff9b4e43d47c40 EFLAGS: 00010286
      [   35.461469] RAX: 0000000000000000 RBX: ffff98f90639f800 RCX: ffffffffae051960
      [   35.461471] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000246
      [   35.461472] RBP: ffff98f905410000 R08: 0000004d062a83f6 R09: 00000000000003bd
      [   35.461474] R10: 0000000000000031 R11: ffffffffad4eda58 R12: ffff98f905410000
      [   35.461475] R13: ffff98f9064c1000 R14: ffff9b4e43d47cf0 R15: ffff98f905410000
      [   35.461477] FS:  0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000
      [   35.461479] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   35.461481] CR2: 00007f5682359008 CR3: 00000001b700c005 CR4: 00000000003606e0
      [   35.461483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   35.461484] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   35.461486] Call Trace:
      [   35.461501]  intel_hdmi_set_edid+0x37/0x27f [i915]
      [   35.461515]  intel_hdmi_detect+0x7c/0x97 [i915]
      [   35.461518]  drm_helper_probe_single_connector_modes+0xe1/0x6c0
      [   35.461521]  drm_setup_crtcs+0x129/0xa6a
      [   35.461523]  ? __switch_to_asm+0x34/0x70
      [   35.461525]  ? __switch_to_asm+0x34/0x70
      [   35.461527]  ? __switch_to_asm+0x40/0x70
      [   35.461528]  ? __switch_to_asm+0x34/0x70
      [   35.461529]  ? __switch_to_asm+0x40/0x70
      [   35.461531]  ? __switch_to_asm+0x34/0x70
      [   35.461532]  ? __switch_to_asm+0x40/0x70
      [   35.461534]  ? __switch_to_asm+0x34/0x70
      [   35.461536]  __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
      [   35.461538]  ? __switch_to_asm+0x40/0x70
      [   35.461541]  ? _cond_resched+0x10/0x33
      [   35.461557]  intel_fbdev_initial_config+0xf/0x1c [i915]
      [   35.461560]  async_run_entry_fn+0x2e/0xf5
      [   35.461563]  process_one_work+0x15b/0x364
      [   35.461565]  worker_thread+0x2c/0x3a0
      [   35.461567]  ? process_one_work+0x364/0x364
      [   35.461568]  kthread+0x10c/0x122
      [   35.461570]  ? _kthread_create_on_node+0x5d/0x5d
      [   35.461572]  ret_from_fork+0x35/0x40
      [   35.461574] Code: 74 16 89 f6 48 8d 04 b6 48 c1 e0 05 48 29 f0 48 8d 84 c7 e8 11 00 00 c3 48 c7 c6 b0 19 1e c0 48 c7 c7 64 8a 1c c0 e8 47 88 ed ec <0f> 0b 31 c0 c3 8b 87 a4 04 00 00 80 e4 fc 09 c6 89 b7 a4 04 00
      [   35.461604] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
      [   35.461606] ---[ end trace 4fe1e63e2dd93373 ]---
      [   35.461609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      [   35.461613] IP: i2c_transfer+0x4/0x86
      [   35.461614] PGD 0 P4D 0
      [   35.461616] Oops: 0000 [#1] SMP PTI
      [   35.461618] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
      [   35.461624] CPU: 6 PID: 411 Comm: kworker/u16:2 Tainted: G        W        4.16.0-rc7.x64-g1cda370ffded #1
      [   35.461625] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
      [   35.461628] Workqueue: events_unbound async_run_entry_fn
      [   35.461630] RIP: 0010:i2c_transfer+0x4/0x86
      [   35.461631] RSP: 0018:ffff9b4e43d47b30 EFLAGS: 00010246
      [   35.461633] RAX: ffff9b4e43d47b6e RBX: 0000000000000005 RCX: 0000000000000001
      [   35.461635] RDX: 0000000000000002 RSI: ffff9b4e43d47b80 RDI: 0000000000000000
      [   35.461636] RBP: ffff9b4e43d47bd8 R08: 0000004d062a83f6 R09: 00000000000003bd
      [   35.461638] R10: 0000000000000031 R11: ffffffffad4eda58 R12: 0000000000000002
      [   35.461639] R13: 0000000000000001 R14: ffff9b4e43d47b6f R15: ffff9b4e43d47c07
      [   35.461641] FS:  0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000
      [   35.461643] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   35.461645] CR2: 0000000000000010 CR3: 00000001b700c005 CR4: 00000000003606e0
      [   35.461646] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   35.461647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   35.461649] Call Trace:
      [   35.461652]  drm_do_probe_ddc_edid+0xb3/0x128
      [   35.461654]  drm_get_edid+0xe5/0x38d
      [   35.461669]  intel_hdmi_set_edid+0x45/0x27f [i915]
      [   35.461684]  intel_hdmi_detect+0x7c/0x97 [i915]
      [   35.461687]  drm_helper_probe_single_connector_modes+0xe1/0x6c0
      [   35.461689]  drm_setup_crtcs+0x129/0xa6a
      [   35.461691]  ? __switch_to_asm+0x34/0x70
      [   35.461693]  ? __switch_to_asm+0x34/0x70
      [   35.461694]  ? __switch_to_asm+0x40/0x70
      [   35.461696]  ? __switch_to_asm+0x34/0x70
      [   35.461697]  ? __switch_to_asm+0x40/0x70
      [   35.461698]  ? __switch_to_asm+0x34/0x70
      [   35.461700]  ? __switch_to_asm+0x40/0x70
      [   35.461701]  ? __switch_to_asm+0x34/0x70
      [   35.461703]  __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
      [   35.461705]  ? __switch_to_asm+0x40/0x70
      [   35.461707]  ? _cond_resched+0x10/0x33
      [   35.461724]  intel_fbdev_initial_config+0xf/0x1c [i915]
      [   35.461727]  async_run_entry_fn+0x2e/0xf5
      [   35.461729]  process_one_work+0x15b/0x364
      [   35.461731]  worker_thread+0x2c/0x3a0
      [   35.461733]  ? process_one_work+0x364/0x364
      [   35.461734]  kthread+0x10c/0x122
      [   35.461736]  ? _kthread_create_on_node+0x5d/0x5d
      [   35.461738]  ret_from_fork+0x35/0x40
      [   35.461739] Code: 5c fa e1 ad 48 89 df e8 ea fb ff ff e9 2a ff ff ff 0f 1f 44 00 00 31 c0 e9 43 fd ff ff 31 c0 45 31 e4 e9 c5 fd ff ff 41 54 55 53 <48> 8b 47 10 48 83 78 10 00 74 70 41 89 d4 48 89 f5 48 89 fb 65
      [   35.461756] RIP: i2c_transfer+0x4/0x86 RSP: ffff9b4e43d47b30
      [   35.461757] CR2: 0000000000000010
      [   35.461759] ---[ end trace 4fe1e63e2dd93374 ]---
      
      Based on a patch by Fei Li.
      
      v2: s/reverting/sticking/ (Chris)
      
      Cc: stable@vger.kernel.org
      Cc: Fei Li <fei.li@intel.com>
      Co-developed-by: default avatarFei Li <fei.li@intel.com>
      Reported-by: default avatarPavel Nakonechnyi <zorg1331@gmail.com>
      Reported-and-tested-by: default avatarSeweryn Kokot <sewkokot@gmail.com>
      Reported-and-tested-by: default avatarLaszlo Valko <valko@linux.karinthy.hu>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105549
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105961
      
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180411131519.9091-1-jani.nikula@intel.com
      (cherry picked from commit f212bf9a
      
      )
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      a3520b89
    • Tvrtko Ursulin's avatar
      drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 · e6be6bd8
      Tvrtko Ursulin authored
      
      
      While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
      on some CI machines I have concluded that: a) the PMU readout of RC6 can
      race against runtime PM transitions, and b) there are other reasons than
      being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
      fail.
      
      Therefore when estimating RC6 the code needs to assert we are indeed in
      suspended state, and if not, the best we can do is return the last known
      RC6 value.
      
      Without this check we can calculate the estimated value based on un-
      initialized or inappropriate internal state, which can result in over-
      estimation, or in any case incorrect value being returned.
      
      v2:
       * Re-arrange the code a bit to avoid second unlock and return branch.
         (Chris Wilson)
      
      v3:
       * Insert some strategic blank lines and improve commit msg.
         (Chris Wilson)
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Fixes: 1fe699e3 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
      
      
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Imre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180410112704.24462-1-tvrtko.ursulin@linux.intel.com
      (cherry picked from commit 2924bdee
      
      )
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      e6be6bd8
    • Xidong Wang's avatar
      drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value · fcf1fadf
      Xidong Wang authored
      Along the eb_lookup_vmas() error path, the return value from
      kmem_cache_alloc() was freed using kfree(). Fix it to use the proper
      kmem_cache_free() instead.
      
      Fixes: d1b48c1e
      
       ("drm/i915: Replace execbuf vma ht with an idr")
      Signed-off-by: default avatarXidong Wang <wangxidong_97@163.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: <stable@vger.kernel.org> # v4.14+
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180404093824.9313-1-chris@chris-wilson.co.uk
      (cherry picked from commit 6be1187d
      
      )
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      fcf1fadf
  6. 17 Apr, 2018 5 commits
  7. 16 Apr, 2018 4 commits
    • Thomas Falcon's avatar
      ibmvnic: Clear pending interrupt after device reset · f23e0643
      Thomas Falcon authored
      
      
      Due to a firmware bug, the hypervisor can send an interrupt to a
      transmit or receive queue just prior to a partition migration, not
      allowing the device enough time to handle it and send an EOI. When
      the partition migrates, the interrupt is lost but an "EOI-pending"
      flag for the interrupt line is still set in firmware. No further
      interrupts will be sent until that flag is cleared, effectively
      freezing that queue. To workaround this, the driver will disable the
      hardware interrupt and send an H_EOI signal prior to re-enabling it.
      This will flush the pending EOI and allow the driver to continue
      operation.
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f23e0643
    • Dan Williams's avatar
      libnvdimm, dimm: handle EACCES failures from label reads · e7c5a571
      Dan Williams authored
      The new support for the standard _LSR and _LSW methods neglected to also
      update the nvdimm_init_config_data() and nvdimm_set_config_data() to
      return the translated error code from failed commands. This precision is
      necessary because the locked status that was previously returned on
      ND_CMD_GET_CONFIG_SIZE commands is now returned on
      ND_CMD_{GET,SET}_CONFIG_DATA commands.
      
      If the kernel misses this indication it can inadvertently fall back to
      label-less mode when it should otherwise avoid all access to locked
      regions.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 4b27db7e
      
       ("acpi, nfit: add support for the _LSI, _LSR, and...")
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      e7c5a571
    • Paolo Abeni's avatar
      team: avoid adding twice the same option to the event list · 4fb0534f
      Paolo Abeni authored
      
      
      When parsing the options provided by the user space,
      team_nl_cmd_options_set() insert them in a temporary list to send
      multiple events with a single message.
      While each option's attribute is correctly validated, the code does
      not check for duplicate entries before inserting into the event
      list.
      
      Exploiting the above, the syzbot was able to trigger the following
      splat:
      
      kernel BUG at lib/list_debug.c:31!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
          (ftrace buffer empty)
      Modules linked in:
      CPU: 0 PID: 4466 Comm: syzkaller556835 Not tainted 4.16.0+ #17
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:__list_add_valid+0xaa/0xb0 lib/list_debug.c:29
      RSP: 0018:ffff8801b04bf248 EFLAGS: 00010286
      RAX: 0000000000000058 RBX: ffff8801c8fc7a90 RCX: 0000000000000000
      RDX: 0000000000000058 RSI: ffffffff815fbf41 RDI: ffffed0036097e3f
      RBP: ffff8801b04bf260 R08: ffff8801b0b2a700 R09: ffffed003b604f90
      R10: ffffed003b604f90 R11: ffff8801db027c87 R12: ffff8801c8fc7a90
      R13: ffff8801c8fc7a90 R14: dffffc0000000000 R15: 0000000000000000
      FS:  0000000000b98880(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000000043fc30 CR3: 00000001afe8e000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        __list_add include/linux/list.h:60 [inline]
        list_add include/linux/list.h:79 [inline]
        team_nl_cmd_options_set+0x9ff/0x12b0 drivers/net/team/team.c:2571
        genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599
        genl_rcv_msg+0xc6/0x170 net/netlink/genetlink.c:624
        netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
        genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
        netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
        netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336
        netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901
        sock_sendmsg_nosec net/socket.c:629 [inline]
        sock_sendmsg+0xd5/0x120 net/socket.c:639
        ___sys_sendmsg+0x805/0x940 net/socket.c:2117
        __sys_sendmsg+0x115/0x270 net/socket.c:2155
        SYSC_sendmsg net/socket.c:2164 [inline]
        SyS_sendmsg+0x29/0x30 net/socket.c:2162
        do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x42/0xb7
      RIP: 0033:0x4458b9
      RSP: 002b:00007ffd1d4a7278 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 000000000000001b RCX: 00000000004458b9
      RDX: 0000000000000010 RSI: 0000000020000d00 RDI: 0000000000000004
      RBP: 00000000004a74ed R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000213 R12: 00007ffd1d4a7348
      R13: 0000000000402a60 R14: 0000000000000000 R15: 0000000000000000
      Code: 75 e8 eb a9 48 89 f7 48 89 75 e8 e8 d1 85 7b fe 48 8b 75 e8 eb bb 48
      89 f2 48 89 d9 4c 89 e6 48 c7 c7 a0 84 d8 87 e8 ea 67 28 fe <0f> 0b 0f 1f
      40 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41
      RIP: __list_add_valid+0xaa/0xb0 lib/list_debug.c:29 RSP: ffff8801b04bf248
      
      This changeset addresses the avoiding list_add() if the current
      option is already present in the event list.
      
      Reported-and-tested-by: syzbot+4d4af685432dc0e56c91@syzkaller.appspotmail.com
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Fixes: 2fcdb2c9
      
       ("team: allow to send multiple set events in one message")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4fb0534f
    • Jia-Ju Bai's avatar
      xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_reg_add · de3d01fd
      Jia-Ju Bai authored
      
      
      pcistub_reg_add() is never called in atomic context.
      
      pcistub_reg_add() is only called by pcistub_quirk_add, which is
      only set in DRIVER_ATTR().
      
      Despite never getting called from atomic context,
      pcistub_reg_add() calls kzalloc() with GFP_ATOMIC,
      which does not sleep for allocation.
      GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
      which can sleep and improve the possibility of sucessful allocation.
      
      This is found by a static analysis tool named DCNS written by myself.
      And I also manually check it.
      Signed-off-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      de3d01fd