1. 07 Dec, 2017 1 commit
  2. 01 Dec, 2017 3 commits
  3. 14 Nov, 2017 5 commits
  4. 10 Nov, 2017 9 commits
  5. 09 Nov, 2017 3 commits
    • Ilya Dryomov's avatar
      rbd: use GFP_NOIO for parent stat and data requests · 1e37f2f8
      Ilya Dryomov authored
      rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on
      the writeback path for cloned images -- we attempt a stat on the parent
      object to see if it exists and potentially read it in to call copyup.
      GFP_NOIO should be used instead of GFP_KERNEL here.
      
      Cc: stable@vger.kernel.org
      Link: http://tracker.ceph.com/issues/22014Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarDavid Disseldorp <ddiss@suse.de>
      1e37f2f8
    • Andrey Konovalov's avatar
      net: usb: asix: fill null-ptr-deref in asix_suspend · 8f562462
      Andrey Konovalov authored
      When asix_suspend() is called dev->driver_priv might not have been
      assigned a value, so we need to check that it's not NULL.
      
      Similar issue is present in asix_resume(), this patch fixes it as well.
      
      Found by syzkaller.
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      Modules linked in:
      CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc4-43422-geccacdd69a8c #400
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Workqueue: usb_hub_wq hub_event
      task: ffff88006bb36300 task.stack: ffff88006bba8000
      RIP: 0010:asix_suspend+0x76/0xc0 drivers/net/usb/asix_devices.c:629
      RSP: 0018:ffff88006bbae718 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff880061ba3b80 RCX: 1ffff1000c34d644
      RDX: 0000000000000001 RSI: 0000000000000402 RDI: 0000000000000008
      RBP: ffff88006bbae738 R08: 1ffff1000d775cad R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800630a8b40
      R13: 0000000000000000 R14: 0000000000000402 R15: ffff880061ba3b80
      FS:  0000000000000000(0000) GS:ffff88006c600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ff33cf89000 CR3: 0000000061c0a000 CR4: 00000000000006f0
      Call Trace:
       usb_suspend_interface drivers/usb/core/driver.c:1209
       usb_suspend_both+0x27f/0x7e0 drivers/usb/core/driver.c:1314
       usb_runtime_suspend+0x41/0x120 drivers/usb/core/driver.c:1852
       __rpm_callback+0x339/0xb60 drivers/base/power/runtime.c:334
       rpm_callback+0x106/0x220 drivers/base/power/runtime.c:461
       rpm_suspend+0x465/0x1980 drivers/base/power/runtime.c:596
       __pm_runtime_suspend+0x11e/0x230 drivers/base/power/runtime.c:1009
       pm_runtime_put_sync_autosuspend ./include/linux/pm_runtime.h:251
       usb_new_device+0xa37/0x1020 drivers/usb/core/hub.c:2487
       hub_port_connect drivers/usb/core/hub.c:4903
       hub_port_connect_change drivers/usb/core/hub.c:5009
       port_event drivers/usb/core/hub.c:5115
       hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
       process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
       worker_thread+0x221/0x1850 kernel/workqueue.c:2253
       kthread+0x3a1/0x470 kernel/kthread.c:231
       ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
      Code: 8d 7c 24 20 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5b 48 b8 00 00
      00 00 00 fc ff df 4d 8b 6c 24 20 49 8d 7d 08 48 89 fa 48 c1 ea 03 <80>
      3c 02 00 75 34 4d 8b 6d 08 4d 85 ed 74 0b e8 26 2b 51 fd 4c
      RIP: asix_suspend+0x76/0xc0 RSP: ffff88006bbae718
      ---[ end trace dfc4f5649284342c ]---
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f562462
    • David S. Miller's avatar
      Revert "net: usb: asix: fill null-ptr-deref in asix_suspend" · 1a8e6b48
      David S. Miller authored
      This reverts commit baedf68a.
      
      There is an updated version of this fix which covers
      the problem more thoroughly.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a8e6b48
  6. 08 Nov, 2017 12 commits
    • Chris Wilson's avatar
      drm/i915: Deconstruct struct sgt_dma initialiser · 423a8a94
      Chris Wilson authored
      gcc-4.4 complains about:
      
      	struct sgt_dma iter = {
      		.sg = vma->pages->sgl,
      		.dma = sg_dma_address(iter.sg),
      		.max = iter.dma + iter.sg->length,
      	};
      
      drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen8_ppgtt_insert_4lvl’:
      drivers/gpu/drm/i915/i915_gem_gtt.c:938: error: ‘iter.sg’ is used uninitialized in this function
      drivers/gpu/drm/i915/i915_gem_gtt.c:939: error: ‘iter.dma’ is used uninitialized in this function
      
      and worse generates invalid code that triggers a GPF:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      IP: gen8_ppgtt_insert_4lvl+0x1b/0x1e0 [i915]
      PGD 0
      Oops: 0000 [#1] SMP
      Modules linked in: snd_aloop nf_conntrack_ipv6 nf_defrag_ipv6 nf_log_ipv6 ip6table_filter ip6_tables ctr ccm xt_state nf_log_ipv4
      nf_log_common xt_LOG xt_limit xt_recent xt_owner xt_addrtype iptable_filter ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat
      nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c ip_tables dm_mod vhost_net macvtap macvlan vhost tun kvm_intel kvm
      irqbypass uas usb_storage hid_multitouch btusb btrtl uvcvideo videobuf2_v4l2 videobuf2_core videodev media videobuf2_vmalloc videobuf2_memops
      sg ppdev dell_wmi sparse_keymap mei_wdt sd_mod iTCO_wdt iTCO_vendor_support rtsx_pci_ms memstick rtsx_pci_sdmmc mmc_core dell_smm_hwmon hwmon
      dell_laptop dell_smbios dcdbas joydev input_leds hci_uart btintel btqca btbcm bluetooth parport_pc parport i2c_hid
        intel_lpss_acpi intel_lpss pcspkr wmi int3400_thermal acpi_thermal_rel dell_rbtn mei_me mei snd_hda_codec_hdmi snd_hda_codec_realtek
      snd_hda_codec_generic ahci libahci acpi_pad xhci_pci xhci_hcd snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device
      snd_pcm snd_timer snd soundcore int3403_thermal arc4 e1000e ptp pps_core i2c_i801 iwlmvm mac80211 rtsx_pci iwlwifi cfg80211 rfkill
      intel_pch_thermal processor_thermal_device int340x_thermal_zone intel_soc_dts_iosf i915 video fjes
      CPU: 2 PID: 2408 Comm: X Not tainted 4.10.0-rc5+ #1
      Hardware name: Dell Inc. Latitude E7470/0T6HHJ, BIOS 1.11.3 11/09/2016
      task: ffff880219fe4740 task.stack: ffffc90005f98000
      RIP: 0010:gen8_ppgtt_insert_4lvl+0x1b/0x1e0 [i915]
      RSP: 0018:ffffc90005f9b8c8 EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff8802167d8000 RCX: 0000000000000001
      RDX: 00000000ffff7000 RSI: ffff880219f94140 RDI: ffff880228444000
      RBP: ffffc90005f9b948 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000080
      R13: 0000000000000001 R14: ffffc90005f9bcd7 R15: ffff88020c9a83c0
      FS:  00007fb53e1ee920(0000) GS:ffff88024dd00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000010 CR3: 000000022ef95000 CR4: 00000000003406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        ppgtt_bind_vma+0x40/0x50 [i915]
        i915_vma_bind+0xcb/0x1c0 [i915]
        __i915_vma_do_pin+0x6e/0xd0 [i915]
        i915_gem_execbuffer_reserve_vma+0x162/0x1d0 [i915]
        i915_gem_execbuffer_reserve+0x4fc/0x510 [i915]
        ? __kmalloc+0x134/0x250
        ? i915_gem_wait_for_error+0x25/0x100 [i915]
        ? i915_gem_wait_for_error+0x25/0x100 [i915]
        i915_gem_do_execbuffer+0x2df/0xa00 [i915]
        ? drm_malloc_gfp.clone.0+0x42/0x80 [i915]
        ? path_put+0x22/0x30
        ? __check_object_size+0x62/0x1f0
        ? terminate_walk+0x44/0x90
        i915_gem_execbuffer2+0x95/0x1e0 [i915]
        drm_ioctl+0x243/0x490
        ? handle_pte_fault+0x1d7/0x220
        ? i915_gem_do_execbuffer+0xa00/0xa00 [i915]
        ? handle_mm_fault+0x10d/0x2a0
        vfs_ioctl+0x18/0x30
        do_vfs_ioctl+0x14b/0x3f0
        SyS_ioctl+0x92/0xa0
        entry_SYSCALL_64_fastpath+0x1a/0xa9
      RIP: 0033:0x7fb53b4fcb77
      RSP: 002b:00007ffe0c572898 EFLAGS: 00003246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00007fb53e17c038 RCX: 00007fb53b4fcb77
      RDX: 00007ffe0c572900 RSI: 0000000040406469 RDI: 000000000000000b
      RBP: 00007fb5376d67e0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000028 R11: 0000000000003246 R12: 0000000000000000
      R13: 0000000000000000 R14: 000055eecb314d00 R15: 000055eecb315460
      Code: 0f 84 5d ff ff ff eb a2 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 58 0f 1f 44 00 00 31 c0 89 4d b0 <4c>
      8b 60 10 44 8b 70 0c 48 89 d0 4c 8b 2e 48 c1 e8 27 25 ff 01
      RIP: gen8_ppgtt_insert_4lvl+0x1b/0x1e0 [i915] RSP: ffffc90005f9b8c8
      CR2: 0000000000000010
      
      Recent gccs, such as 4.9, 6.3 or 7.2, do not generate the warning nor do
      they explode on use. If we manually create the struct using locals from
      the stack, this should eliminate this issue, and does not alter code
      generation with gcc-7.2.
      
      Fixes: 894ccebe ("drm/i915: Micro-optimise gen8_ppgtt_insert_entries()")
      Reported-by: default avatarKelly French <kfrench@federalhill.net>
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Kelly French <kfrench@federalhill.net>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171106211128.12538-1-chris@chris-wilson.co.ukTested-by: default avatarKelly French <kfrench@federalhill.net>
      Reviewed-by: Tvrtko Ursulin's avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      (cherry picked from commit 5684514b)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      423a8a94
    • Tvrtko Ursulin's avatar
      drm/i915: Reject unknown syncobj flags · 40a48845
      Tvrtko Ursulin authored
      We have to reject unknown flags for uAPI considerations, and also
      because the curent implementation limits their i915 storage space
      to two bits.
      
      v2: (Chris Wilson)
       * Fix fail in ABI check.
       * Added unknown flags and BUILD_BUG_ON.
      
      v3:
       * Use ARCH_KMALLOC_MINALIGN instead of alignof. (Chris Wilson)
      Signed-off-by: Tvrtko Ursulin's avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Fixes: cf6e7bac ("drm/i915: Add support for drm syncobjs")
      Cc: Jason Ekstrand <jason@jlekstrand.net>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: dri-devel@lists.freedesktop.org
      Reviewed-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171031102326.9738-1-tvrtko.ursulin@linux.intel.com
      (cherry picked from commit ebcaa1ff)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      40a48845
    • Kristian Evensen's avatar
      qmi_wwan: Add missing skb_reset_mac_header-call · 0de0add1
      Kristian Evensen authored
      When we receive a packet on a QMI device in raw IP mode, we should call
      skb_reset_mac_header() to ensure that skb->mac_header contains a valid
      offset in the packet. While it shouldn't really matter, the packets have
      no MAC header and the interface is configured as-such, it seems certain
      parts of the network stack expects a "good" value in skb->mac_header.
      
      Without the skb_reset_mac_header() call added in this patch, for example
      shaping traffic (using tc) triggers the following oops on the first
      received packet:
      
      [  303.642957] skbuff: skb_under_panic: text:8f137918 len:177 put:67 head:8e4b0f00 data:8e4b0eff tail:0x8e4b0fb0 end:0x8e4b1520 dev:wwan0
      [  303.655045] Kernel bug detected[#1]:
      [  303.658622] CPU: 1 PID: 1002 Comm: logd Not tainted 4.9.58 #0
      [  303.664339] task: 8fdf05e0 task.stack: 8f15c000
      [  303.668844] $ 0   : 00000000 00000001 0000007a 00000000
      [  303.674062] $ 4   : 8149a2fc 8149a2fc 8149ce20 00000000
      [  303.679284] $ 8   : 00000030 3878303a 31623465 20303235
      [  303.684510] $12   : ded731e3 2626a277 00000000 03bd0000
      [  303.689747] $16   : 8ef62b40 00000043 8f137918 804db5fc
      [  303.694978] $20   : 00000001 00000004 8fc13800 00000003
      [  303.700215] $24   : 00000001 8024ab10
      [  303.705442] $28   : 8f15c000 8fc19cf0 00000043 802cc920
      [  303.710664] Hi    : 00000000
      [  303.713533] Lo    : 74e58000
      [  303.716436] epc   : 802cc920 skb_panic+0x58/0x5c
      [  303.721046] ra    : 802cc920 skb_panic+0x58/0x5c
      [  303.725639] Status: 11007c03 KERNEL EXL IE
      [  303.729823] Cause : 50800024 (ExcCode 09)
      [  303.733817] PrId  : 0001992f (MIPS 1004Kc)
      [  303.737892] Modules linked in: rt2800pci rt2800mmio rt2800lib qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 mt76x2i
      Process logd (pid: 1002, threadinfo=8f15c000, task=8fdf05e0, tls=77b3eee4)
      [  303.962509] Stack : 00000000 80408990 8f137918 000000b1 00000043 8e4b0f00 8e4b0eff 8e4b0fb0
      [  303.970871]         8e4b1520 8fec1800 00000043 802cd2a4 6e000045 00000043 00000000 8ef62000
      [  303.979219]         8eef5d00 8ef62b40 8fea7300 8f137918 00000000 00000000 0002bb01 793e5664
      [  303.987568]         8ef08884 00000001 8fea7300 00000002 8fc19e80 8eef5d00 00000006 00000003
      [  303.995934]         00000000 8030ba90 00000003 77ab3fd0 8149dc80 8004d1bc 8f15c000 8f383700
      [  304.004324]         ...
      [  304.006767] Call Trace:
      [  304.009241] [<802cc920>] skb_panic+0x58/0x5c
      [  304.013504] [<802cd2a4>] skb_push+0x78/0x90
      [  304.017783] [<8f137918>] 0x8f137918
      [  304.021269] Code: 00602825  0c02a3b4  24842888 <000c000d> 8c870060  8c8200a0  0007382b  00070336  8c88005c
      [  304.031034]
      [  304.032805] ---[ end trace b778c482b3f0bda9 ]---
      [  304.041384] Kernel panic - not syncing: Fatal exception in interrupt
      [  304.051975] Rebooting in 3 seconds..
      
      While the oops is for a 4.9-kernel, I was able to trigger the same oops with
      net-next as of yesterday.
      
      Fixes: 32f7adf6 ("net: qmi_wwan: support "raw IP" mode")
      Signed-off-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0de0add1
    • Jay Vosburgh's avatar
      bonding: fix slave stuck in BOND_LINK_FAIL state · 055db695
      Jay Vosburgh authored
      The bonding miimon logic has a flaw, in that a failure of the
      rtnl_trylock can cause a slave to become permanently stuck in
      BOND_LINK_FAIL state.
      
      	The sequence of events to cause this is as follows:
      
      	1) bond_miimon_inspect finds that a slave's link is down, and so
      calls bond_propose_link_state, setting slave->new_link_state to
      BOND_LINK_FAIL, then sets slave->new_link to BOND_LINK_DOWN and returns
      non-zero.
      
      	2) In bond_mii_monitor, the rtnl_trylock fails, and the timer is
      rescheduled.  No change is committed.
      
      	3) bond_miimon_inspect is called again, but this time the slave
      from step 1 has recovered.  slave->new_link is reset to NOCHANGE, and, as
      slave->link was never changed, the switch enters the BOND_LINK_UP case,
      and does nothing.  The pending BOND_LINK_FAIL state from step 1 remains
      pending, as new_link_state is not reset.
      
      	4) The state from step 3 persists until another slave changes link
      state and causes bond_miimon_inspect to return non-zero.  At this point,
      the BOND_LINK_FAIL state change on the slave from steps 1-3 is committed,
      and the slave will remain stuck in BOND_LINK_FAIL state even though it
      is actually link up.
      
      	The remedy for this is to initialize new_link_state on each entry
      to bond_miimon_inspect, as is already done with new_link.
      
      Fixes: fb9eb899 ("bonding: handle link transition from FAIL to UP correctly")
      Reported-by: default avatarAlex Sidorenko <alexandre.sidorenko@hpe.com>
      Reviewed-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Acked-by: default avatarMahesh Bandewar <maheshb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      055db695
    • Bjørn Mork's avatar
      net: qmi_wwan: fix divide by 0 on bad descriptors · 7fd07833
      Bjørn Mork authored
      A CDC Ethernet functional descriptor with wMaxSegmentSize = 0 will
      cause a divide error in usbnet_probe:
      
      divide error: 0000 [#1] PREEMPT SMP KASAN
      Modules linked in:
      CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Workqueue: usb_hub_wq hub_event
      task: ffff88006bef5c00 task.stack: ffff88006bf60000
      RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355
      RSP: 0018:ffff88006bf67508 EFLAGS: 00010246
      RAX: 00000000000163c8 RBX: ffff8800621fce40 RCX: ffff8800621fcf34
      RDX: 0000000000000000 RSI: ffffffff837ecb7a RDI: ffff8800621fcf34
      RBP: ffff88006bf67520 R08: ffff88006bef5c00 R09: ffffed000c43f881
      R10: ffffed000c43f880 R11: ffff8800621fc406 R12: 0000000000000003
      R13: ffffffff85c71de0 R14: 0000000000000000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffe9c0d6dac CR3: 00000000614f4000 CR4: 00000000000006f0
      Call Trace:
       usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783
       qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338
       usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361
       really_probe drivers/base/dd.c:413
       driver_probe_device+0x522/0x740 drivers/base/dd.c:557
      
      Fix by simply ignoring the bogus descriptor, as it is optional
      for QMI devices anyway.
      
      Fixes: 423ce8ca ("net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7fd07833
    • Bjørn Mork's avatar
      net: cdc_ether: fix divide by 0 on bad descriptors · 2cb80187
      Bjørn Mork authored
      Setting dev->hard_mtu to 0 will cause a divide error in
      usbnet_probe. Protect against devices with bogus CDC Ethernet
      functional descriptors by ignoring a zero wMaxSegmentSize.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cb80187
    • Hangbin Liu's avatar
      bonding: discard lowest hash bit for 802.3ad layer3+4 · b5f86218
      Hangbin Liu authored
      After commit 07f4c900 ("tcp/dccp: try to not exhaust ip_local_port_range
      in connect()"), we will try to use even ports for connect(). Then if an
      application (seen clearly with iperf) opens multiple streams to the same
      destination IP and port, each stream will be given an even source port.
      
      So the bonding driver's simple xmit_hash_policy based on layer3+4 addressing
      will always hash all these streams to the same interface. And the total
      throughput will limited to a single slave.
      
      Change the tcp code will impact the whole tcp behavior, only for bonding
      usage. Paolo Abeni suggested fix this by changing the bonding code only,
      which should be more reasonable, and less impact.
      
      Fix this by discarding the lowest hash bit because it contains little entropy.
      After the fix we can re-balance between slaves.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5f86218
    • Yiannis Marangos's avatar
      Input: synaptics-rmi4 - RMI4 can also use SMBUS version 3 · 26dd633e
      Yiannis Marangos authored
      Some Synaptics devices, such as LEN0073, use SMBUS version 3.
      Signed-off-by: default avatarYiannis Marangos <yiannis.marangos@gmail.com>
      Acked-by: default avatarBenjamin Tissoires <benjamion.tissoires@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      26dd633e
    • Martin Kepplinger's avatar
      Input: tsc200x-core - set INPUT_PROP_DIRECT · eca25391
      Martin Kepplinger authored
      If INPUT_PROP_DIRECT is set, userspace doesn't have to fall back to old
      ways of identifying touchscreen devices.
      
      In order to identify a touchscreen device, Android for example, seems to
      already depend on INPUT_PROP_DIRECT to be present in drivers. udev still
      checks for either BTN_TOUCH or INPUT_PROP_DIRECT. Checking for BTN_TOUCH
      however can quite easily lead to false positives; it's a code that not only
      touchscreen device drivers use.
      
      According to the documentation, touchscreen drivers should have this
      property set and in order to make life easy for userspace, let's set it.
      Signed-off-by: default avatarMartin Kepplinger <martink@posteo.de>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      eca25391
    • Kai-Heng Feng's avatar
      Input: elan_i2c - add ELAN060C to the ACPI table · cdea6a30
      Kai-Heng Feng authored
      ELAN060C touchpad uses elan_i2c as its driver. It can be
      found on Lenovo ideapad 320-14AST.
      
      BugLink: https://bugs.launchpad.net/bugs/1727544Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      cdea6a30
    • Gustavo A. R. Silva's avatar
      net/mlx5e/core/en_fs: fix pointer dereference after free in mlx5e_execute_l2_action · 39a4b86f
      Gustavo A. R. Silva authored
      hn is being kfree'd in mlx5e_del_l2_from_hash and then dereferenced
      by accessing hn->ai.addr
      
      Fix this by copying the MAC address into a local variable for its safe use
      in all possible execution paths within function mlx5e_execute_l2_action.
      
      Addresses-Coverity-ID: 1417789
      Fixes: eeb66cdb ("net/mlx5: Separate between E-Switch and MPFS")
      Signed-off-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Acked-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      39a4b86f
    • Marc Zyngier's avatar
      net: mvpp2: Prevent userspace from changing TX affinities · 13c249a9
      Marc Zyngier authored
      The mvpp2 driver can't cope at all with the TX affinities being
      changed from userspace, and spit an endless stream of
      
      [   91.779920] mvpp2 f4000000.ethernet eth2: wrong cpu on the end of Tx processing
      [   91.779930] mvpp2 f4000000.ethernet eth2: wrong cpu on the end of Tx processing
      [   91.780402] mvpp2 f4000000.ethernet eth2: wrong cpu on the end of Tx processing
      [   91.780406] mvpp2 f4000000.ethernet eth2: wrong cpu on the end of Tx processing
      [   91.780415] mvpp2 f4000000.ethernet eth2: wrong cpu on the end of Tx processing
      [   91.780418] mvpp2 f4000000.ethernet eth2: wrong cpu on the end of Tx processing
      
      rendering the box completely useless (I've measured around 600k
      interrupts/s on a 8040 box) once irqbalance kicks in and start
      doing its job.
      
      Obviously, the driver was never designed with this in mind. So let's
      work around the problem by preventing userspace from interacting
      with these interrupts altogether.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13c249a9
  7. 07 Nov, 2017 2 commits
    • Borislav Petkov's avatar
      drivers/ide-cd: Handle missing driver data during status check gracefully · fbc3edf7
      Borislav Petkov authored
      The 0day bot reports the below failure which happens occasionally, with
      their randconfig testing (once every ~100 boots).  The Code points at
      the private pointer ->driver_data being NULL, which hints at a race of
      sorts where the private driver_data descriptor has disappeared by the
      time we get to run the workqueue.
      
      So let's check that pointer before we continue with issuing the command
      to the drive.
      
      This fix is of the brown paper bag nature but considering that IDE is
      long deprecated, let's do that so that random testing which happens to
      enable CONFIG_IDE during randconfig builds, doesn't fail because of
      this.
      
      Besides, failing the TEST_UNIT_READY command because the drive private
      data is gone is something which we could simply do anyway, to denote
      that there was a problem communicating with the device.
      
        BUG: unable to handle kernel NULL pointer dereference at 000001c0
        IP: cdrom_check_status
        *pde = 00000000
        Oops: 0000 [#1] SMP
        CPU: 1 PID: 155 Comm: kworker/1:2 Not tainted 4.14.0-rc8 #127
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
        Workqueue: events_freezable_power_ disk_events_workfn
        task: 4fe90980 task.stack: 507ac000
        EIP: cdrom_check_status+0x2c/0x90
        EFLAGS: 00210246 CPU: 1
        EAX: 00000000 EBX: 4fefec00 ECX: 00000000 EDX: 00000000
        ESI: 00000003 EDI: ffffffff EBP: 467a9340 ESP: 507aded0
         DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
        CR0: 80050033 CR2: 000001c0 CR3: 06e0f000 CR4: 00000690
        Call Trace:
         ? ide_cdrom_check_events_real
         ? cdrom_check_events
         ? disk_check_events
         ? process_one_work
         ? process_one_work
         ? worker_thread
         ? kthread
         ? process_one_work
         ? __kthread_create_on_node
         ? ret_from_fork
        Code: 53 83 ec 14 89 c3 89 d1 be 03 00 00 00 65 a1 14 00 00 00 89 44 24 10 31 c0 8b 43 18 c7 44 24 04 00 00 00 00 c7 04 24 00 00 00 00 <8a> 80 c0 01 00 00 c7 44 24 08 00 00 00 00 83 e0 03 c7 44 24 0c
        EIP: cdrom_check_status+0x2c/0x90 SS:ESP: 0068:507aded0
        CR2: 00000000000001c0
        ---[ end trace 2410e586dd8f88b2 ]---
      Reported-and-tested-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Bart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fbc3edf7
    • Linus Torvalds's avatar
      Revert "scsi: make 'state' device attribute pollable" · a817e73f
      Linus Torvalds authored
      This reverts commit 8a97712e.
      
      This commit added a call to sysfs_notify() from within
      scsi_device_set_state(), which in turn turns out to make libata very
      unhappy, because ata_eh_detach_dev() does
      
              spin_lock_irqsave(ap->lock, flags);
              ..
              if (ata_scsi_offline_dev(dev)) {
                      dev->flags |= ATA_DFLAG_DETACHED;
                      ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
              }
      
      and ata_scsi_offline_dev() then does that scsi_device_set_state() to set
      it offline.
      
      So now we called sysfs_notify() from within a spinlocked region, which
      really doesn't work.  The 0day robot reported this as:
      
         BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
      
      because sysfs_notify() ends up calling kernfs_find_and_get_ns() which
      then does mutex_lock(&kernfs_mutex)..
      
      The pollability of the device state isn't critical, so revert this all
      for now, and maybe we'll do it differently in the future.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a817e73f
  8. 06 Nov, 2017 1 commit
  9. 04 Nov, 2017 3 commits
    • Andy Lutomirski's avatar
      Revert "x86/mm: Stop calling leave_mm() in idle code" · 67535736
      Andy Lutomirski authored
      This reverts commit 43858b4f.
      
      The reason I removed the leave_mm() calls in question is because the
      heuristic wasn't needed after that patch.  With the original version
      of my PCID series, we never flushed a "lazy cpu" (i.e. a CPU running
      kernel thread) due a flush on the loaded mm.
      
      Unfortunately, that caused architectural issues, so now I've
      reinstated these flushes on non-PCID systems in:
      
          commit b956575b ("x86/mm: Flush more aggressively in lazy TLB mode").
      
      That, in turn, gives us a power management and occasionally
      performance regression as compared to old kernels: a process that
      goes into a deep idle state on a given CPU and gets its mm flushed
      due to activity on a different CPU will wake the idle CPU.
      
      Reinstate the old ugly heuristic: if a CPU goes into ACPI C3 or an
      intel_idle state that is likely to cause a TLB flush gets its mm
      switched to init_mm before going idle.
      
      FWIW, this heuristic is lousy.  Whether we should change CR3 before
      idle isn't a good hint except insofar as the performance hit is a bit
      lower if the TLB is getting flushed by the idle code anyway.  What we
      really want to know is whether we anticipate being idle long enough
      that the mm is likely to be flushed before we wake up.  This is more a
      matter of the expected latency than the idle state that gets chosen.
      This heuristic also completely fails on systems that don't know
      whether the TLB will be flushed (e.g. AMD systems?).  OTOH it may be a
      bit obsolete anyway -- PCID systems don't presently benefit from this
      heuristic at all.
      
      We also shouldn't do this callback from innermost bit of the idle code
      due to the RCU nastiness it causes.  All the information need is
      available before rcu_idle_enter() needs to happen.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bpetkov@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 43858b4f "x86/mm: Stop calling leave_mm() in idle code"
      Link: http://lkml.kernel.org/r/c513bbd4e653747213e05bc7062de000bf0202a5.1509793738.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      67535736
    • Andrey Konovalov's avatar
      net: usb: asix: fill null-ptr-deref in asix_suspend · baedf68a
      Andrey Konovalov authored
      When asix_suspend() is called dev->driver_priv might not have been
      assigned a value, so we need to check that it's not NULL.
      
      Found by syzkaller.
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      Modules linked in:
      CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc4-43422-geccacdd69a8c #400
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Workqueue: usb_hub_wq hub_event
      task: ffff88006bb36300 task.stack: ffff88006bba8000
      RIP: 0010:asix_suspend+0x76/0xc0 drivers/net/usb/asix_devices.c:629
      RSP: 0018:ffff88006bbae718 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff880061ba3b80 RCX: 1ffff1000c34d644
      RDX: 0000000000000001 RSI: 0000000000000402 RDI: 0000000000000008
      RBP: ffff88006bbae738 R08: 1ffff1000d775cad R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800630a8b40
      R13: 0000000000000000 R14: 0000000000000402 R15: ffff880061ba3b80
      FS:  0000000000000000(0000) GS:ffff88006c600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ff33cf89000 CR3: 0000000061c0a000 CR4: 00000000000006f0
      Call Trace:
       usb_suspend_interface drivers/usb/core/driver.c:1209
       usb_suspend_both+0x27f/0x7e0 drivers/usb/core/driver.c:1314
       usb_runtime_suspend+0x41/0x120 drivers/usb/core/driver.c:1852
       __rpm_callback+0x339/0xb60 drivers/base/power/runtime.c:334
       rpm_callback+0x106/0x220 drivers/base/power/runtime.c:461
       rpm_suspend+0x465/0x1980 drivers/base/power/runtime.c:596
       __pm_runtime_suspend+0x11e/0x230 drivers/base/power/runtime.c:1009
       pm_runtime_put_sync_autosuspend ./include/linux/pm_runtime.h:251
       usb_new_device+0xa37/0x1020 drivers/usb/core/hub.c:2487
       hub_port_connect drivers/usb/core/hub.c:4903
       hub_port_connect_change drivers/usb/core/hub.c:5009
       port_event drivers/usb/core/hub.c:5115
       hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
       process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
       worker_thread+0x221/0x1850 kernel/workqueue.c:2253
       kthread+0x3a1/0x470 kernel/kthread.c:231
       ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
      Code: 8d 7c 24 20 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5b 48 b8 00 00
      00 00 00 fc ff df 4d 8b 6c 24 20 49 8d 7d 08 48 89 fa 48 c1 ea 03 <80>
      3c 02 00 75 34 4d 8b 6d 08 4d 85 ed 74 0b e8 26 2b 51 fd 4c
      RIP: asix_suspend+0x76/0xc0 RSP: ffff88006bbae718
      ---[ end trace dfc4f5649284342c ]---
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      baedf68a
    • Ganesh Goudar's avatar
      cxgb4: update latest firmware version supported · 24de79e5
      Ganesh Goudar authored
      Change t4fw_version.h to update latest firmware version
      number to 1.16.63.0.
      Signed-off-by: default avatarGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24de79e5
  10. 03 Nov, 2017 1 commit