]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 7 Sep 2017 14:48:45 +0000 (16:48 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 7 Sep 2017 14:48:45 +0000 (16:48 +0200)
added patches:
ath10k-fix-memory-leak-in-rx-ring-buffer-allocation.patch
bluetooth-add-support-of-13d3-3494-rtl8723be-device.patch
dlm-avoid-double-free-on-error-path-in-dlm_device_-register-unregister.patch
driver-core-bus-fix-a-potential-double-free.patch
drm-nouveau-pci-msi-disable-msi-on-big-endian-platforms-by-default.patch
input-trackpoint-assume-3-buttons-when-buttons-detection-fails.patch
intel_th-pci-add-cannon-lake-pch-h-support.patch
intel_th-pci-add-cannon-lake-pch-lp-support.patch
mwifiex-correct-channel-stat-buffer-overflows.patch
rtlwifi-rtl_pci_probe-fix-fail-path-of-_rtl_pci_find_adapter.patch
staging-rts5208-fix-incorrect-shift-to-extract-upper-nybble.patch
usb-core-avoid-race-of-async_completed-w-usbdev_release.patch
workqueue-fix-flag-collision.patch

14 files changed:
queue-4.4/ath10k-fix-memory-leak-in-rx-ring-buffer-allocation.patch [new file with mode: 0644]
queue-4.4/bluetooth-add-support-of-13d3-3494-rtl8723be-device.patch [new file with mode: 0644]
queue-4.4/dlm-avoid-double-free-on-error-path-in-dlm_device_-register-unregister.patch [new file with mode: 0644]
queue-4.4/driver-core-bus-fix-a-potential-double-free.patch [new file with mode: 0644]
queue-4.4/drm-nouveau-pci-msi-disable-msi-on-big-endian-platforms-by-default.patch [new file with mode: 0644]
queue-4.4/input-trackpoint-assume-3-buttons-when-buttons-detection-fails.patch [new file with mode: 0644]
queue-4.4/intel_th-pci-add-cannon-lake-pch-h-support.patch [new file with mode: 0644]
queue-4.4/intel_th-pci-add-cannon-lake-pch-lp-support.patch [new file with mode: 0644]
queue-4.4/mwifiex-correct-channel-stat-buffer-overflows.patch [new file with mode: 0644]
queue-4.4/rtlwifi-rtl_pci_probe-fix-fail-path-of-_rtl_pci_find_adapter.patch [new file with mode: 0644]
queue-4.4/series
queue-4.4/staging-rts5208-fix-incorrect-shift-to-extract-upper-nybble.patch [new file with mode: 0644]
queue-4.4/usb-core-avoid-race-of-async_completed-w-usbdev_release.patch [new file with mode: 0644]
queue-4.4/workqueue-fix-flag-collision.patch [new file with mode: 0644]

diff --git a/queue-4.4/ath10k-fix-memory-leak-in-rx-ring-buffer-allocation.patch b/queue-4.4/ath10k-fix-memory-leak-in-rx-ring-buffer-allocation.patch
new file mode 100644 (file)
index 0000000..8aa06b5
--- /dev/null
@@ -0,0 +1,65 @@
+From f35a7f91f66af528b3ee1921de16bea31d347ab0 Mon Sep 17 00:00:00 2001
+From: Rakesh Pillai <pillair@qti.qualcomm.com>
+Date: Wed, 2 Aug 2017 16:03:37 +0530
+Subject: ath10k: fix memory leak in rx ring buffer allocation
+
+From: Rakesh Pillai <pillair@qti.qualcomm.com>
+
+commit f35a7f91f66af528b3ee1921de16bea31d347ab0 upstream.
+
+The rx ring buffers are added to a hash table if
+firmware support full rx reorder. If the full rx
+reorder support flag is not set before allocating
+the rx ring buffers, none of the buffers are added
+to the hash table.
+
+There is a race condition between rx ring refill and
+rx buffer replenish from napi poll. The interrupts are
+enabled in hif start, before the rx ring is refilled during init.
+We replenish buffers from napi poll due to the interrupts which
+get enabled after hif start. Hence before the entire rx ring is
+refilled during the init, the napi poll replenishes a few buffers
+in steps of 100 buffers per attempt. During this rx ring replenish
+from napi poll, the rx reorder flag has not been set due to which
+the replenished buffers are not added to the hash table
+
+Set the rx full reorder support flag before we allocate
+the rx ring buffer to avoid the memory leak.
+
+Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com>
+Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
+Cc: Christian Lamparter <chunkeey@googlemail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/ath/ath10k/core.c |   12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/drivers/net/wireless/ath/ath10k/core.c
++++ b/drivers/net/wireless/ath/ath10k/core.c
+@@ -1607,6 +1607,12 @@ int ath10k_core_start(struct ath10k *ar,
+               goto err_wmi_detach;
+       }
++      /* If firmware indicates Full Rx Reorder support it must be used in a
++       * slightly different manner. Let HTT code know.
++       */
++      ar->htt.rx_ring.in_ord_rx = !!(test_bit(WMI_SERVICE_RX_FULL_REORDER,
++                                              ar->wmi.svc_map));
++
+       status = ath10k_htt_rx_alloc(&ar->htt);
+       if (status) {
+               ath10k_err(ar, "failed to alloc htt rx: %d\n", status);
+@@ -1669,12 +1675,6 @@ int ath10k_core_start(struct ath10k *ar,
+               goto err_hif_stop;
+       }
+-      /* If firmware indicates Full Rx Reorder support it must be used in a
+-       * slightly different manner. Let HTT code know.
+-       */
+-      ar->htt.rx_ring.in_ord_rx = !!(test_bit(WMI_SERVICE_RX_FULL_REORDER,
+-                                              ar->wmi.svc_map));
+-
+       status = ath10k_htt_rx_ring_refill(ar);
+       if (status) {
+               ath10k_err(ar, "failed to refill htt rx ring: %d\n", status);
diff --git a/queue-4.4/bluetooth-add-support-of-13d3-3494-rtl8723be-device.patch b/queue-4.4/bluetooth-add-support-of-13d3-3494-rtl8723be-device.patch
new file mode 100644 (file)
index 0000000..24b1a78
--- /dev/null
@@ -0,0 +1,57 @@
+From a81d72d2002d6a932bd83022cbf8c442b1b97512 Mon Sep 17 00:00:00 2001
+From: Dmitry Tunin <hanipouspilot@gmail.com>
+Date: Tue, 8 Aug 2017 14:09:02 +0300
+Subject: Bluetooth: Add support of 13d3:3494 RTL8723BE device
+
+From: Dmitry Tunin <hanipouspilot@gmail.com>
+
+commit a81d72d2002d6a932bd83022cbf8c442b1b97512 upstream.
+
+T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=12 MxCh= 0
+D: Ver= 2.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=13d3 ProdID=3494 Rev= 2.00
+S: Manufacturer=Realtek
+S: Product=Bluetooth Radio
+S: SerialNumber=00e04c000001
+C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
+I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
+E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+
+Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/btusb.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -333,6 +333,7 @@ static const struct usb_device_id blackl
+       { USB_DEVICE(0x13d3, 0x3410), .driver_info = BTUSB_REALTEK },
+       { USB_DEVICE(0x13d3, 0x3416), .driver_info = BTUSB_REALTEK },
+       { USB_DEVICE(0x13d3, 0x3459), .driver_info = BTUSB_REALTEK },
++      { USB_DEVICE(0x13d3, 0x3494), .driver_info = BTUSB_REALTEK },
+       /* Additional Realtek 8821AE Bluetooth devices */
+       { USB_DEVICE(0x0b05, 0x17dc), .driver_info = BTUSB_REALTEK },
diff --git a/queue-4.4/dlm-avoid-double-free-on-error-path-in-dlm_device_-register-unregister.patch b/queue-4.4/dlm-avoid-double-free-on-error-path-in-dlm_device_-register-unregister.patch
new file mode 100644 (file)
index 0000000..1867c23
--- /dev/null
@@ -0,0 +1,151 @@
+From 55acdd926f6b21a5cdba23da98a48aedf19ac9c3 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= <edvin.torok@citrix.com>
+Date: Thu, 3 Aug 2017 10:30:06 +0100
+Subject: dlm: avoid double-free on error path in dlm_device_{register,unregister}
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Edwin Török <edvin.torok@citrix.com>
+
+commit 55acdd926f6b21a5cdba23da98a48aedf19ac9c3 upstream.
+
+Can be reproduced when running dlm_controld (tested on 4.4.x, 4.12.4):
+ # seq 1 100 | xargs -P0 -n1 dlm_tool join
+ # seq 1 100 | xargs -P0 -n1 dlm_tool leave
+
+misc_register fails due to duplicate sysfs entry, which causes
+dlm_device_register to free ls->ls_device.name.
+In dlm_device_deregister the name was freed again, causing memory
+corruption.
+
+According to the comment in dlm_device_deregister the name should've been
+set to NULL when registration fails,
+so this patch does that.
+
+sysfs: cannot create duplicate filename '/dev/char/10:1'
+------------[ cut here ]------------
+warning: cpu: 1 pid: 4450 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x56/0x70
+modules linked in: msr rfcomm dlm ccm bnep dm_crypt uvcvideo
+videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev
+btusb media btrtl btbcm btintel bluetooth ecdh_generic intel_rapl
+x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
+snd_hda_codec_hdmi irqbypass crct10dif_pclmul crc32_pclmul
+ghash_clmulni_intel thinkpad_acpi pcbc nvram snd_seq_midi
+snd_seq_midi_event aesni_intel snd_hda_codec_realtek snd_hda_codec_generic
+snd_rawmidi aes_x86_64 crypto_simd glue_helper snd_hda_intel snd_hda_codec
+cryptd intel_cstate arc4 snd_hda_core snd_seq snd_seq_device snd_hwdep
+iwldvm intel_rapl_perf mac80211 joydev input_leds iwlwifi serio_raw
+cfg80211 snd_pcm shpchp snd_timer snd mac_hid mei_me lpc_ich mei soundcore
+sunrpc parport_pc ppdev lp parport autofs4 i915 psmouse
+ e1000e ahci libahci i2c_algo_bit sdhci_pci ptp drm_kms_helper sdhci
+pps_core syscopyarea sysfillrect sysimgblt fb_sys_fops drm wmi video
+cpu: 1 pid: 4450 comm: dlm_test.exe not tainted 4.12.4-041204-generic
+hardware name: lenovo 232425u/232425u, bios g2et82ww (2.02 ) 09/11/2012
+task: ffff96b0cbabe140 task.stack: ffffb199027d0000
+rip: 0010:sysfs_warn_dup+0x56/0x70
+rsp: 0018:ffffb199027d3c58 eflags: 00010282
+rax: 0000000000000038 rbx: ffff96b0e2c49158 rcx: 0000000000000006
+rdx: 0000000000000000 rsi: 0000000000000086 rdi: ffff96b15e24dcc0
+rbp: ffffb199027d3c70 r08: 0000000000000001 r09: 0000000000000721
+r10: ffffb199027d3c00 r11: 0000000000000721 r12: ffffb199027d3cd1
+r13: ffff96b1592088f0 r14: 0000000000000001 r15: ffffffffffffffef
+fs:  00007f78069c0700(0000) gs:ffff96b15e240000(0000)
+knlgs:0000000000000000
+cs:  0010 ds: 0000 es: 0000 cr0: 0000000080050033
+cr2: 000000178625ed28 cr3: 0000000091d3e000 cr4: 00000000001406e0
+call trace:
+ sysfs_do_create_link_sd.isra.2+0x9e/0xb0
+ sysfs_create_link+0x25/0x40
+ device_add+0x5a9/0x640
+ device_create_groups_vargs+0xe0/0xf0
+ device_create_with_groups+0x3f/0x60
+ ? snprintf+0x45/0x70
+ misc_register+0x140/0x180
+ device_write+0x6a8/0x790 [dlm]
+ __vfs_write+0x37/0x160
+ ? apparmor_file_permission+0x1a/0x20
+ ? security_file_permission+0x3b/0xc0
+ vfs_write+0xb5/0x1a0
+ sys_write+0x55/0xc0
+ ? sys_fcntl+0x5d/0xb0
+ entry_syscall_64_fastpath+0x1e/0xa9
+rip: 0033:0x7f78083454bd
+rsp: 002b:00007f78069bbd30 eflags: 00000293 orig_rax: 0000000000000001
+rax: ffffffffffffffda rbx: 0000000000000006 rcx: 00007f78083454bd
+rdx: 000000000000009c rsi: 00007f78069bee00 rdi: 0000000000000005
+rbp: 00007f77f8000a20 r08: 000000000000fcf0 r09: 0000000000000032
+r10: 0000000000000024 r11: 0000000000000293 r12: 00007f78069bde00
+r13: 00007f78069bee00 r14: 000000000000000a r15: 00007f78069bbd70
+code: 85 c0 48 89 c3 74 12 b9 00 10 00 00 48 89 c2 31 f6 4c 89 ef e8 2c c8
+ff ff 4c 89 e2 48 89 de 48 c7 c7 b0 8e 0c a8 e8 41 e8 ed ff <0f> ff 48 89
+df e8 00 d5 f4 ff 5b 41 5c 41 5d 5d c3 66 0f 1f 84
+---[ end trace 40412246357cc9e0 ]---
+
+dlm: 59f24629-ae39-44e2-9030-397ebc2eda26: leaving the lockspace group...
+bug: unable to handle kernel null pointer dereference at 0000000000000001
+ip: [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
+pgd 0
+oops: 0000 [#1] smp
+modules linked in: dlm 8021q garp mrp stp llc openvswitch nf_defrag_ipv6
+nf_conntrack libcrc32c iptable_filter dm_multipath crc32_pclmul dm_mod
+aesni_intel psmouse aes_x86_64 sg ablk_helper cryptd lrw gf128mul
+glue_helper i2c_piix4 nls_utf8 tpm_tis tpm isofs nfsd auth_rpcgss
+oid_registry nfs_acl lockd grace sunrpc xen_wdt ip_tables x_tables autofs4
+hid_generic usbhid hid sr_mod cdrom sd_mod ata_generic pata_acpi 8139too
+serio_raw ata_piix 8139cp mii uhci_hcd ehci_pci ehci_hcd libata
+scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_mod ipv6
+cpu: 0 pid: 394 comm: systemd-udevd tainted: g w 4.4.0+0 #1
+hardware name: xen hvm domu, bios 4.7.2-2.2 05/11/2017
+task: ffff880002410000 ti: ffff88000243c000 task.ti: ffff88000243c000
+rip: e030:[<ffffffff811a3b4a>] [<ffffffff811a3b4a>]
+kmem_cache_alloc+0x7a/0x140
+rsp: e02b:ffff88000243fd90 eflags: 00010202
+rax: 0000000000000000 rbx: ffff8800029864d0 rcx: 000000000007b36c
+rdx: 000000000007b36b rsi: 00000000024000c0 rdi: ffff880036801c00
+rbp: ffff88000243fdc0 r08: 0000000000018880 r09: 0000000000000054
+r10: 000000000000004a r11: ffff880034ace6c0 r12: 00000000024000c0
+r13: ffff880036801c00 r14: 0000000000000001 r15: ffffffff8118dcc2
+fs: 00007f0ab77548c0(0000) gs:ffff880036e00000(0000) knlgs:0000000000000000
+cs: e033 ds: 0000 es: 0000 cr0: 0000000080050033
+cr2: 0000000000000001 cr3: 000000000332d000 cr4: 0000000000040660
+stack:
+ffffffff8118dc90 ffff8800029864d0 0000000000000000 ffff88003430b0b0
+ffff880034b78320 ffff88003430b0b0 ffff88000243fdf8 ffffffff8118dcc2
+ffff8800349c6700 ffff8800029864d0 000000000000000b 00007f0ab7754b90
+call trace:
+[<ffffffff8118dc90>] ? anon_vma_fork+0x60/0x140
+[<ffffffff8118dcc2>] anon_vma_fork+0x92/0x140
+[<ffffffff8107033e>] copy_process+0xcae/0x1a80
+[<ffffffff8107128b>] _do_fork+0x8b/0x2d0
+[<ffffffff81071579>] sys_clone+0x19/0x20
+[<ffffffff815a30ae>] entry_syscall_64_fastpath+0x12/0x71
+] code: f6 75 1c 4c 89 fa 44 89 e6 4c 89 ef e8 a7 e4 00 00 41 f7 c4 00 80
+00 00 49 89 c6 74 47 eb 32 49 63 45 20 48 8d 4a 01 4d 8b 45 00 <49> 8b 1c
+06 4c 89 f0 65 49 0f c7 08 0f 94 c0 84 c0 74 ac 49 63
+rip [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
+rsp <ffff88000243fd90>
+cr2: 0000000000000001
+--[ end trace 70cb9fd1b164a0e8 ]--
+
+Signed-off-by: Edwin Török <edvin.torok@citrix.com>
+Signed-off-by: David Teigland <teigland@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/dlm/user.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/dlm/user.c
++++ b/fs/dlm/user.c
+@@ -355,6 +355,10 @@ static int dlm_device_register(struct dl
+       error = misc_register(&ls->ls_device);
+       if (error) {
+               kfree(ls->ls_device.name);
++              /* this has to be set to NULL
++               * to avoid a double-free in dlm_device_deregister
++               */
++              ls->ls_device.name = NULL;
+       }
+ fail:
+       return error;
diff --git a/queue-4.4/driver-core-bus-fix-a-potential-double-free.patch b/queue-4.4/driver-core-bus-fix-a-potential-double-free.patch
new file mode 100644 (file)
index 0000000..eb9032d
--- /dev/null
@@ -0,0 +1,33 @@
+From 0f9b011d3321ca1079c7a46c18cb1956fbdb7bcb Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Tue, 29 Aug 2017 21:23:49 +0200
+Subject: driver core: bus: Fix a potential double free
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit 0f9b011d3321ca1079c7a46c18cb1956fbdb7bcb upstream.
+
+The .release function of driver_ktype is 'driver_release()'.
+This function frees the container_of this kobject.
+
+So, this memory must not be freed explicitly in the error handling path of
+'bus_add_driver()'. Otherwise a double free will occur.
+
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/bus.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/base/bus.c
++++ b/drivers/base/bus.c
+@@ -737,7 +737,7 @@ int bus_add_driver(struct device_driver
+ out_unregister:
+       kobject_put(&priv->kobj);
+-      kfree(drv->p);
++      /* drv->p is freed in driver_release()  */
+       drv->p = NULL;
+ out_put_bus:
+       bus_put(bus);
diff --git a/queue-4.4/drm-nouveau-pci-msi-disable-msi-on-big-endian-platforms-by-default.patch b/queue-4.4/drm-nouveau-pci-msi-disable-msi-on-big-endian-platforms-by-default.patch
new file mode 100644 (file)
index 0000000..c98e84a
--- /dev/null
@@ -0,0 +1,37 @@
+From bc60c90f472b6e762ea96ef384072145adc8d4af Mon Sep 17 00:00:00 2001
+From: Ilia Mirkin <imirkin@alum.mit.edu>
+Date: Thu, 10 Aug 2017 12:13:40 -0400
+Subject: drm/nouveau/pci/msi: disable MSI on big-endian platforms by default
+
+From: Ilia Mirkin <imirkin@alum.mit.edu>
+
+commit bc60c90f472b6e762ea96ef384072145adc8d4af upstream.
+
+It appears that MSI does not work on either G5 PPC nor on a E5500-based
+platform, where other hardware is reported to work fine with MSI.
+
+Both tests were conducted with NV4x hardware, so perhaps other (or even
+this) hardware can be made to work. It's still possible to force-enable
+with config=NvMSI=1 on load.
+
+Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
+@@ -180,6 +180,10 @@ nvkm_pci_new_(const struct nvkm_pci_func
+               }
+       }
++#ifdef __BIG_ENDIAN
++      pci->msi = false;
++#endif
++
+       pci->msi = nvkm_boolopt(device->cfgopt, "NvMSI", pci->msi);
+       if (pci->msi && func->msi_rearm) {
+               pci->msi = pci_enable_msi(pci->pdev) == 0;
diff --git a/queue-4.4/input-trackpoint-assume-3-buttons-when-buttons-detection-fails.patch b/queue-4.4/input-trackpoint-assume-3-buttons-when-buttons-detection-fails.patch
new file mode 100644 (file)
index 0000000..b831cde
--- /dev/null
@@ -0,0 +1,37 @@
+From 293b915fd9bebf33cdc906516fb28d54649a25ac Mon Sep 17 00:00:00 2001
+From: Oscar Campos <oscar.campos@member.fsf.org>
+Date: Tue, 18 Jul 2017 17:20:36 -0700
+Subject: Input: trackpoint - assume 3 buttons when buttons detection fails
+
+From: Oscar Campos <oscar.campos@member.fsf.org>
+
+commit 293b915fd9bebf33cdc906516fb28d54649a25ac upstream.
+
+Trackpoint buttons detection fails on ThinkPad 570 and 470 series,
+this makes the middle button of the trackpoint to not being recogized.
+As I don't believe there is any trackpoint with less than 3 buttons this
+patch just assumes three buttons when the extended button information
+read fails.
+
+Signed-off-by: Oscar Campos <oscar.campos@member.fsf.org>
+Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/mouse/trackpoint.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/input/mouse/trackpoint.c
++++ b/drivers/input/mouse/trackpoint.c
+@@ -381,8 +381,8 @@ int trackpoint_detect(struct psmouse *ps
+               return 0;
+       if (trackpoint_read(&psmouse->ps2dev, TP_EXT_BTN, &button_info)) {
+-              psmouse_warn(psmouse, "failed to get extended button data\n");
+-              button_info = 0;
++              psmouse_warn(psmouse, "failed to get extended button data, assuming 3 buttons\n");
++              button_info = 0x33;
+       }
+       psmouse->private = kzalloc(sizeof(struct trackpoint_data), GFP_KERNEL);
diff --git a/queue-4.4/intel_th-pci-add-cannon-lake-pch-h-support.patch b/queue-4.4/intel_th-pci-add-cannon-lake-pch-h-support.patch
new file mode 100644 (file)
index 0000000..0df3e36
--- /dev/null
@@ -0,0 +1,32 @@
+From 84331e1390b6378a5129a3678c87a42c6f697d29 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Thu, 30 Jun 2016 16:11:13 +0300
+Subject: intel_th: pci: Add Cannon Lake PCH-H support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 84331e1390b6378a5129a3678c87a42c6f697d29 upstream.
+
+This adds Intel(R) Trace Hub PCI ID for Cannon Lake PCH-H.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwtracing/intel_th/pci.c |    5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -72,6 +72,11 @@ static const struct pci_device_id intel_
+               PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa2a6),
+               .driver_data = (kernel_ulong_t)0,
+       },
++      {
++              /* Cannon Lake H */
++              PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa326),
++              .driver_data = (kernel_ulong_t)0,
++      },
+       { 0 },
+ };
diff --git a/queue-4.4/intel_th-pci-add-cannon-lake-pch-lp-support.patch b/queue-4.4/intel_th-pci-add-cannon-lake-pch-lp-support.patch
new file mode 100644 (file)
index 0000000..05e7af3
--- /dev/null
@@ -0,0 +1,32 @@
+From efb3669e14fe17d0ec4ecf57d0365039fe726f59 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Thu, 30 Jun 2016 16:11:31 +0300
+Subject: intel_th: pci: Add Cannon Lake PCH-LP support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit efb3669e14fe17d0ec4ecf57d0365039fe726f59 upstream.
+
+This adds Intel(R) Trace Hub PCI ID for Cannon Lake PCH-LP.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwtracing/intel_th/pci.c |    5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -77,6 +77,11 @@ static const struct pci_device_id intel_
+               PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa326),
+               .driver_data = (kernel_ulong_t)0,
+       },
++      {
++              /* Cannon Lake LP */
++              PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9da6),
++              .driver_data = (kernel_ulong_t)0,
++      },
+       { 0 },
+ };
diff --git a/queue-4.4/mwifiex-correct-channel-stat-buffer-overflows.patch b/queue-4.4/mwifiex-correct-channel-stat-buffer-overflows.patch
new file mode 100644 (file)
index 0000000..af43a95
--- /dev/null
@@ -0,0 +1,74 @@
+From 4b5dde2d6234ff5bc68e97e6901d1f2a0a7f3749 Mon Sep 17 00:00:00 2001
+From: Brian Norris <briannorris@chromium.org>
+Date: Thu, 29 Jun 2017 18:23:54 -0700
+Subject: mwifiex: correct channel stat buffer overflows
+
+From: Brian Norris <briannorris@chromium.org>
+
+commit 4b5dde2d6234ff5bc68e97e6901d1f2a0a7f3749 upstream.
+
+mwifiex records information about various channels as it receives scan
+information. It does this by appending to a buffer that was sized
+to the max number of supported channels on any band, but there are
+numerous problems:
+
+(a) scans can return info from more than one band (e.g., both 2.4 and 5
+    GHz), so the determined "max" is not large enough
+(b) some firmware appears to return multiple results for a given
+    channel, so the max *really* isn't large enough
+(c) there is no bounds checking when stashing these stats, so problems
+    (a) and (b) can easily lead to buffer overflows
+
+Let's patch this by setting a slightly-more-correct max (that accounts
+for a combination of both 2.4G and 5G bands) and adding a bounds check
+when writing to our statistics buffer.
+
+Due to problem (b), we still might not properly report all known survey
+information (e.g., with "iw <dev> survey dump"), since duplicate results
+(or otherwise "larger than expected" results) will cause some
+truncation. But that's a problem for a future bugfix.
+
+(And because of this known deficiency, only log the excess at the WARN
+level, since that isn't visible by default in this driver and would
+otherwise be a bit too noisy.)
+
+Fixes: bf35443314ac ("mwifiex: channel statistics support for mwifiex")
+Cc: Avinash Patil <patila@marvell.com>
+Cc: Xinming Hu <huxm@marvell.com>
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Reviewed-by: Ganapathi Bhat <gbhat@marvell.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/mwifiex/cfg80211.c |    2 +-
+ drivers/net/wireless/mwifiex/scan.c     |    6 ++++++
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/mwifiex/cfg80211.c
++++ b/drivers/net/wireless/mwifiex/cfg80211.c
+@@ -3740,7 +3740,7 @@ int mwifiex_init_channel_scan_gap(struct
+       if (adapter->config_bands & BAND_A)
+               n_channels_a = mwifiex_band_5ghz.n_channels;
+-      adapter->num_in_chan_stats = max_t(u32, n_channels_bg, n_channels_a);
++      adapter->num_in_chan_stats = n_channels_bg + n_channels_a;
+       adapter->chan_stats = vmalloc(sizeof(*adapter->chan_stats) *
+                                     adapter->num_in_chan_stats);
+--- a/drivers/net/wireless/mwifiex/scan.c
++++ b/drivers/net/wireless/mwifiex/scan.c
+@@ -2170,6 +2170,12 @@ mwifiex_update_chan_statistics(struct mw
+                                             sizeof(struct mwifiex_chan_stats);
+       for (i = 0 ; i < num_chan; i++) {
++              if (adapter->survey_idx >= adapter->num_in_chan_stats) {
++                      mwifiex_dbg(adapter, WARN,
++                                  "FW reported too many channel results (max %d)\n",
++                                  adapter->num_in_chan_stats);
++                      return;
++              }
+               chan_stats.chan_num = fw_chan_stats->chan_num;
+               chan_stats.bandcfg = fw_chan_stats->bandcfg;
+               chan_stats.flags = fw_chan_stats->flags;
diff --git a/queue-4.4/rtlwifi-rtl_pci_probe-fix-fail-path-of-_rtl_pci_find_adapter.patch b/queue-4.4/rtlwifi-rtl_pci_probe-fix-fail-path-of-_rtl_pci_find_adapter.patch
new file mode 100644 (file)
index 0000000..bee5f14
--- /dev/null
@@ -0,0 +1,53 @@
+From fc81bab5eeb103711925d7510157cf5cd2b153f4 Mon Sep 17 00:00:00 2001
+From: Malcolm Priestley <tvboxspy@gmail.com>
+Date: Sun, 30 Jul 2017 09:02:19 +0100
+Subject: rtlwifi: rtl_pci_probe: Fix fail path of _rtl_pci_find_adapter
+
+From: Malcolm Priestley <tvboxspy@gmail.com>
+
+commit fc81bab5eeb103711925d7510157cf5cd2b153f4 upstream.
+
+_rtl_pci_find_adapter fail path will jump to label fail3 for
+unsupported adapter types.
+
+However, on course for fail3 there will be call rtl_deinit_core
+before rtl_init_core.
+
+For the inclusion of checking pci_iounmap this fail can be moved to
+fail2.
+
+Fixes
+[    4.492963] BUG: unable to handle kernel NULL pointer dereference at           (null)
+[    4.493067] IP: rtl_deinit_core+0x31/0x90 [rtlwifi]
+
+Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/realtek/rtlwifi/pci.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
++++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
+@@ -2269,7 +2269,7 @@ int rtl_pci_probe(struct pci_dev *pdev,
+       /* find adapter */
+       if (!_rtl_pci_find_adapter(pdev, hw)) {
+               err = -ENODEV;
+-              goto fail3;
++              goto fail2;
+       }
+       /* Init IO handler */
+@@ -2339,10 +2339,10 @@ fail3:
+       pci_set_drvdata(pdev, NULL);
+       rtl_deinit_core(hw);
++fail2:
+       if (rtlpriv->io.pci_mem_start != 0)
+               pci_iounmap(pdev, (void __iomem *)rtlpriv->io.pci_mem_start);
+-fail2:
+       pci_release_regions(pdev);
+       complete(&rtlpriv->firmware_loading_complete);
index fc7d85d5de75bd4f65e19f7bfce99af424aa03a3..e1d142e8687088b28d773e4877a4f05c536894f4 100644 (file)
@@ -2,3 +2,16 @@ usb-quirks-add-delay-init-quirk-for-corsair-strafe-rgb-keyboard.patch
 usb-serial-option-add-support-for-d-link-dwm-157-c1.patch
 usb-add-device-quirk-for-logitech-hd-pro-webcam-c920-c.patch
 usb-xhci-fix-regression-when-ati-chipsets-detected.patch
+usb-core-avoid-race-of-async_completed-w-usbdev_release.patch
+staging-rts5208-fix-incorrect-shift-to-extract-upper-nybble.patch
+driver-core-bus-fix-a-potential-double-free.patch
+intel_th-pci-add-cannon-lake-pch-h-support.patch
+intel_th-pci-add-cannon-lake-pch-lp-support.patch
+ath10k-fix-memory-leak-in-rx-ring-buffer-allocation.patch
+input-trackpoint-assume-3-buttons-when-buttons-detection-fails.patch
+rtlwifi-rtl_pci_probe-fix-fail-path-of-_rtl_pci_find_adapter.patch
+bluetooth-add-support-of-13d3-3494-rtl8723be-device.patch
+dlm-avoid-double-free-on-error-path-in-dlm_device_-register-unregister.patch
+mwifiex-correct-channel-stat-buffer-overflows.patch
+drm-nouveau-pci-msi-disable-msi-on-big-endian-platforms-by-default.patch
+workqueue-fix-flag-collision.patch
diff --git a/queue-4.4/staging-rts5208-fix-incorrect-shift-to-extract-upper-nybble.patch b/queue-4.4/staging-rts5208-fix-incorrect-shift-to-extract-upper-nybble.patch
new file mode 100644 (file)
index 0000000..55a5094
--- /dev/null
@@ -0,0 +1,34 @@
+From 34ff1bf4920471cff66775dc39537b15c5f0feff Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@canonical.com>
+Date: Fri, 18 Aug 2017 14:34:16 +0100
+Subject: staging/rts5208: fix incorrect shift to extract upper nybble
+
+From: Colin Ian King <colin.king@canonical.com>
+
+commit 34ff1bf4920471cff66775dc39537b15c5f0feff upstream.
+
+The mask of sns_key_info1 suggests the upper nybble is being extracted
+however the following shift of 8 bits is too large and always results in
+0.  Fix this by shifting only by 4 bits to correctly get the upper nybble.
+
+Detected by CoverityScan, CID#142891 ("Operands don't affect result")
+
+Fixes: fa590c222fba ("staging: rts5208: add support for rts5208 and rts5288")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/rts5208/rtsx_scsi.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/rts5208/rtsx_scsi.c
++++ b/drivers/staging/rts5208/rtsx_scsi.c
+@@ -414,7 +414,7 @@ void set_sense_data(struct rtsx_chip *ch
+       sense->ascq = ascq;
+       if (sns_key_info0 != 0) {
+               sense->sns_key_info[0] = SKSV | sns_key_info0;
+-              sense->sns_key_info[1] = (sns_key_info1 & 0xf0) >> 8;
++              sense->sns_key_info[1] = (sns_key_info1 & 0xf0) >> 4;
+               sense->sns_key_info[2] = sns_key_info1 & 0x0f;
+       }
+ }
diff --git a/queue-4.4/usb-core-avoid-race-of-async_completed-w-usbdev_release.patch b/queue-4.4/usb-core-avoid-race-of-async_completed-w-usbdev_release.patch
new file mode 100644 (file)
index 0000000..5bbf993
--- /dev/null
@@ -0,0 +1,105 @@
+From ed62ca2f4f51c17841ea39d98c0c409cb53a3e10 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Thu, 10 Aug 2017 15:42:22 -0700
+Subject: USB: core: Avoid race of async_completed() w/ usbdev_release()
+
+From: Douglas Anderson <dianders@chromium.org>
+
+commit ed62ca2f4f51c17841ea39d98c0c409cb53a3e10 upstream.
+
+While running reboot tests w/ a specific set of USB devices (and
+slub_debug enabled), I found that once every few hours my device would
+be crashed with a stack that looked like this:
+
+[   14.012445] BUG: spinlock bad magic on CPU#0, modprobe/2091
+[   14.012460]  lock: 0xffffffc0cb055978, .magic: ffffffc0, .owner: cryption contexts: %lu/%lu
+[   14.012460] /1025536097, .owner_cpu: 0
+[   14.012466] CPU: 0 PID: 2091 Comm: modprobe Not tainted 4.4.79 #352
+[   14.012468] Hardware name: Google Kevin (DT)
+[   14.012471] Call trace:
+[   14.012483] [<....>] dump_backtrace+0x0/0x160
+[   14.012487] [<....>] show_stack+0x20/0x28
+[   14.012494] [<....>] dump_stack+0xb4/0xf0
+[   14.012500] [<....>] spin_dump+0x8c/0x98
+[   14.012504] [<....>] spin_bug+0x30/0x3c
+[   14.012508] [<....>] do_raw_spin_lock+0x40/0x164
+[   14.012515] [<....>] _raw_spin_lock_irqsave+0x64/0x74
+[   14.012521] [<....>] __wake_up+0x2c/0x60
+[   14.012528] [<....>] async_completed+0x2d0/0x300
+[   14.012534] [<....>] __usb_hcd_giveback_urb+0xc4/0x138
+[   14.012538] [<....>] usb_hcd_giveback_urb+0x54/0xf0
+[   14.012544] [<....>] xhci_irq+0x1314/0x1348
+[   14.012548] [<....>] usb_hcd_irq+0x40/0x50
+[   14.012553] [<....>] handle_irq_event_percpu+0x1b4/0x3f0
+[   14.012556] [<....>] handle_irq_event+0x4c/0x7c
+[   14.012561] [<....>] handle_fasteoi_irq+0x158/0x1c8
+[   14.012564] [<....>] generic_handle_irq+0x30/0x44
+[   14.012568] [<....>] __handle_domain_irq+0x90/0xbc
+[   14.012572] [<....>] gic_handle_irq+0xcc/0x18c
+
+Investigation using kgdb() found that the wait queue that was passed
+into wake_up() had been freed (it was filled with slub_debug poison).
+
+I analyzed and instrumented the code and reproduced.  My current
+belief is that this is happening:
+
+1. async_completed() is called (from IRQ).  Moves "as" onto the
+   completed list.
+2. On another CPU, proc_reapurbnonblock_compat() calls
+   async_getcompleted().  Blocks on spinlock.
+3. async_completed() releases the lock; keeps running; gets blocked
+   midway through wake_up().
+4. proc_reapurbnonblock_compat() => async_getcompleted() gets the
+   lock; removes "as" from completed list and frees it.
+5. usbdev_release() is called.  Frees "ps".
+6. async_completed() finally continues running wake_up().  ...but
+   wake_up() has a pointer to the freed "ps".
+
+The instrumentation that led me to believe this was based on adding
+some trace_printk() calls in a select few functions and then using
+kdb's "ftdump" at crash time.  The trace follows (NOTE: in the trace
+below I cheated a little bit and added a udelay(1000) in
+async_completed() after releasing the spinlock because I wanted it to
+trigger quicker):
+
+<...>-2104   0d.h2 13759034us!: async_completed at start: as=ffffffc0cc638200
+mtpd-2055    3.... 13759356us : async_getcompleted before spin_lock_irqsave
+mtpd-2055    3d..1 13759362us : async_getcompleted after list_del_init: as=ffffffc0cc638200
+mtpd-2055    3.... 13759371us+: proc_reapurbnonblock_compat: free_async(ffffffc0cc638200)
+mtpd-2055    3.... 13759422us+: async_getcompleted before spin_lock_irqsave
+mtpd-2055    3.... 13759479us : usbdev_release at start: ps=ffffffc0cc042080
+mtpd-2055    3.... 13759487us : async_getcompleted before spin_lock_irqsave
+mtpd-2055    3.... 13759497us!: usbdev_release after kfree(ps): ps=ffffffc0cc042080
+<...>-2104   0d.h2 13760294us : async_completed before wake_up(): as=ffffffc0cc638200
+
+To fix this problem we can just move the wake_up() under the ps->lock.
+There should be no issues there that I'm aware of.
+
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/devio.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/core/devio.c
++++ b/drivers/usb/core/devio.c
+@@ -519,6 +519,8 @@ static void async_completed(struct urb *
+       if (as->status < 0 && as->bulk_addr && as->status != -ECONNRESET &&
+                       as->status != -ENOENT)
+               cancel_bulk_urbs(ps, as->bulk_addr);
++
++      wake_up(&ps->wait);
+       spin_unlock(&ps->lock);
+       if (signr) {
+@@ -526,8 +528,6 @@ static void async_completed(struct urb *
+               put_pid(pid);
+               put_cred(cred);
+       }
+-
+-      wake_up(&ps->wait);
+ }
+ static void destroy_async(struct usb_dev_state *ps, struct list_head *list)
diff --git a/queue-4.4/workqueue-fix-flag-collision.patch b/queue-4.4/workqueue-fix-flag-collision.patch
new file mode 100644 (file)
index 0000000..0278cf1
--- /dev/null
@@ -0,0 +1,34 @@
+From fbf1c41fc0f4d3574ac2377245efd666c1fa3075 Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <ben@decadent.org.uk>
+Date: Sun, 3 Sep 2017 01:18:41 +0100
+Subject: workqueue: Fix flag collision
+
+From: Ben Hutchings <ben@decadent.org.uk>
+
+commit fbf1c41fc0f4d3574ac2377245efd666c1fa3075 upstream.
+
+Commit 0a94efb5acbb ("workqueue: implicit ordered attribute should be
+overridable") introduced a __WQ_ORDERED_EXPLICIT flag but gave it the
+same value as __WQ_LEGACY.  I don't believe these were intended to
+mean the same thing, so renumber __WQ_ORDERED_EXPLICIT.
+
+Fixes: 0a94efb5acbb ("workqueue: implicit ordered attribute should be ...")
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/workqueue.h |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/workqueue.h
++++ b/include/linux/workqueue.h
+@@ -311,7 +311,7 @@ enum {
+       __WQ_DRAINING           = 1 << 16, /* internal: workqueue is draining */
+       __WQ_ORDERED            = 1 << 17, /* internal: workqueue is ordered */
+-      __WQ_ORDERED_EXPLICIT   = 1 << 18, /* internal: alloc_ordered_workqueue() */
++      __WQ_ORDERED_EXPLICIT   = 1 << 19, /* internal: alloc_ordered_workqueue() */
+       WQ_MAX_ACTIVE           = 512,    /* I like 512, better ideas? */
+       WQ_MAX_UNBOUND_PER_CPU  = 4,      /* 4 * #cpus for unbound wq */