commit 741143726d460b78539cacfa8d0c38396a8e8b47 Author: Alexandre Frade Date: Thu Oct 4 12:55:04 2018 -0300 4.18.12-xanmod7 Signed-off-by: Alexandre Frade commit ad479f9de521900418afcd06981d7a2441a360fe Merge: 22e6ef51441e 7da07a3216a0 Author: Alexandre Frade Date: Thu Oct 4 12:46:45 2018 -0300 Merge tag 'v4.18.12' into 4.18 This is the 4.18.12 stable release commit 7da07a3216a00aa3c523db4539fc6914497d0576 Author: Greg Kroah-Hartman Date: Wed Oct 3 16:59:28 2018 -0700 Linux 4.18.12 commit c483061d46103aa34daa8e53545a8a3f8cde5c2d Author: Sakari Ailus Date: Tue Sep 11 05:32:37 2018 -0400 media: v4l: event: Prevent freeing event subscriptions while accessed commit ad608fbcf166fec809e402d548761768f602702c upstream. The event subscriptions are added to the subscribed event list while holding a spinlock, but that lock is subsequently released while still accessing the subscription object. This makes it possible to unsubscribe the event --- and freeing the subscription object's memory --- while the subscription object is simultaneously accessed. Prevent this by adding a mutex to serialise the event subscription and unsubscription. This also gives a guarantee to the callback ops that the add op has returned before the del op is called. This change also results in making the elems field less special: subscriptions are only added to the event list once they are fully initialised. Signed-off-by: Sakari Ailus Reviewed-by: Hans Verkuil Reviewed-by: Laurent Pinchart Cc: stable@vger.kernel.org # for 4.14 and up Fixes: c3b5b0241f62 ("V4L/DVB: V4L: Events: Add backend") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 926415e1e4c94e452a258eeddad18db8d66a69cc Author: Marc Zyngier Date: Thu Sep 27 16:53:22 2018 +0100 arm64: KVM: Sanitize PSTATE.M when being set from userspace commit 2a3f93459d689d990b3ecfbe782fec89b97d3279 upstream. Not all execution modes are valid for a guest, and some of them depend on what the HW actually supports. Let's verify that what userspace provides is compatible with both the VM settings and the HW capabilities. Cc: Fixes: 0d854a60b1d7 ("arm64: KVM: enable initialization of a 32bit vcpu") Reviewed-by: Christoffer Dall Reviewed-by: Mark Rutland Reviewed-by: Dave Martin Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 5fddc4cd7aecaaa13bafd20dda499eb7248d3273 Author: Michael Bringmann Date: Thu Sep 20 11:45:13 2018 -0500 powerpc/pseries: Fix unitialized timer reset on migration commit 8604895a34d92f5e186ceb931b0d1b384030ea3d upstream. After migration of a powerpc LPAR, the kernel executes code to update the system state to reflect new platform characteristics. Such changes include modifications to device tree properties provided to the system by PHYP. Property notifications received by the post_mobility_fixup() code are passed along to the kernel in general through a call to of_update_property() which in turn passes such events back to all modules through entries like the '.notifier_call' function within the NUMA module. When the NUMA module updates its state, it resets its event timer. If this occurs after a previous call to stop_topology_update() or on a system without VPHN enabled, the code runs into an unitialized timer structure and crashes. This patch adds a safety check along this path toward the problem code. An example crash log is as follows. ibmvscsi 30000081: Re-enabling adapter! ------------[ cut here ]------------ kernel BUG at kernel/time/timer.c:958! Oops: Exception in kernel mode, sig: 5 [#1] LE SMP NR_CPUS=2048 NUMA pSeries Modules linked in: nfsv3 nfs_acl nfs tcp_diag udp_diag inet_diag lockd unix_diag af_packet_diag netlink_diag grace fscache sunrpc xts vmx_crypto pseries_rng sg binfmt_misc ip_tables xfs libcrc32c sd_mod ibmvscsi ibmveth scsi_transport_srp dm_mirror dm_region_hash dm_log dm_mod CPU: 11 PID: 3067 Comm: drmgr Not tainted 4.17.0+ #179 ... NIP mod_timer+0x4c/0x400 LR reset_topology_timer+0x40/0x60 Call Trace: 0xc0000003f9407830 (unreliable) reset_topology_timer+0x40/0x60 dt_update_callback+0x100/0x120 notifier_call_chain+0x90/0x100 __blocking_notifier_call_chain+0x60/0x90 of_property_notify+0x90/0xd0 of_update_property+0x104/0x150 update_dt_property+0xdc/0x1f0 pseries_devicetree_update+0x2d0/0x510 post_mobility_fixup+0x7c/0xf0 migration_store+0xa4/0xc0 kobj_attr_store+0x30/0x60 sysfs_kf_write+0x64/0xa0 kernfs_fop_write+0x16c/0x240 __vfs_write+0x40/0x200 vfs_write+0xc8/0x240 ksys_write+0x5c/0x100 system_call+0x58/0x6c Fixes: 5d88aa85c00b ("powerpc/pseries: Update CPU maps when device tree is updated") Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Michael Bringmann Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 7f3a5baeacdfbecacfb0bcd147fd30171ea5f9dd Author: Thiago Jung Bauermann Date: Thu Sep 20 01:38:58 2018 -0300 powerpc/pkeys: Fix reading of ibm, processor-storage-keys property commit c716a25b9b70084e1144f77423f5aedd772ea478 upstream. scan_pkey_feature() uses of_property_read_u32_array() to read the ibm,processor-storage-keys property and calls be32_to_cpu() on the value it gets. The problem is that of_property_read_u32_array() already returns the value converted to the CPU byte order. The value of pkeys_total ends up more or less sane because there's a min() call in pkey_initialize() which reduces pkeys_total to 32. So in practice the kernel ignores the fact that the hypervisor reserved one key for itself (the device tree advertises 31 keys in my test VM). This is wrong, but the effect in practice is that when a process tries to allocate the 32nd key, it gets an -EINVAL error instead of -ENOSPC which would indicate that there aren't any keys available Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Thiago Jung Bauermann Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4faeadc4f7b5deafc160132c3eb67eb4ae841b38 Author: Christophe Leroy Date: Mon Sep 10 06:09:04 2018 +0000 powerpc: fix csum_ipv6_magic() on little endian platforms commit 85682a7e3b9c664995ad477520f917039afdc330 upstream. On little endian platforms, csum_ipv6_magic() keeps len and proto in CPU byte order. This generates a bad results leading to ICMPv6 packets from other hosts being dropped by powerpc64le platforms. In order to fix this, len and proto should be converted to network byte order ie bigendian byte order. However checksumming 0x12345678 and 0x56341278 provide the exact same result so it is enough to rotate the sum of len and proto by 1 byte. PPC32 only support bigendian so the fix is needed for PPC64 only Fixes: e9c4943a107b ("powerpc: Implement csum_ipv6_magic in assembly") Reported-by: Jianlin Shi Reported-by: Xin Long Cc: # 4.18+ Signed-off-by: Christophe Leroy Tested-by: Xin Long Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 31d2bff9f6963d0dca0b31b4a68ef4ab79457ce6 Author: Michael Neuling Date: Thu Sep 13 15:33:47 2018 +1000 KVM: PPC: Book3S HV: Fix guest r11 corruption with POWER9 TM workarounds commit f14040bca89258b8a1c71e2112e430462172ce93 upstream. When we come into the softpatch handler (0x1500), we use r11 to store the HSRR0 for later use by the denorm handler. We also use the softpatch handler for the TM workarounds for POWER9. Unfortunately, in kvmppc_interrupt_hv we later store r11 out to the vcpu assuming it's still what we got from userspace. This causes r11 to be corrupted in the VCPU and hence when we restore the guest, we get a corrupted r11. We've seen this when running TM tests inside guests on P9. This fixes the problem by only touching r11 in the denorm case. Fixes: 4bb3c7a020 ("KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9") Cc: # 4.17+ Test-by: Suraj Jitindar Singh Reviewed-by: Paul Mackerras Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 8379aa480e9550039a966b38c1342d3e4b28a381 Author: Randy Dunlap Date: Sat Sep 1 21:01:28 2018 -0700 x86/pti: Fix section mismatch warning/error [ Upstream commit ff924c5a1ec7548825cc2d07980b03be4224ffac ] Fix the section mismatch warning in arch/x86/mm/pti.c: WARNING: vmlinux.o(.text+0x6972a): Section mismatch in reference from the function pti_clone_pgtable() to the function .init.text:pti_user_pagetable_walk_pte() The function pti_clone_pgtable() references the function __init pti_user_pagetable_walk_pte(). This is often because pti_clone_pgtable lacks a __init annotation or the annotation of pti_user_pagetable_walk_pte is wrong. FATAL: modpost: Section mismatches detected. Fixes: 85900ea51577 ("x86/pti: Map the vsyscall page if needed") Reported-by: kbuild test robot Signed-off-by: Randy Dunlap Signed-off-by: Thomas Gleixner Cc: Andy Lutomirski Link: https://lkml.kernel.org/r/43a6d6a3-d69d-5eda-da09-0b1c88215a2a@infradead.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0f40f4a21a10bf802860b27dba6bd48ad673deb7 Author: Akshu Agrawal Date: Tue Aug 21 12:21:57 2018 +0530 clk: x86: Set default parent to 48Mhz [ Upstream commit bded6c03e398dc6e862dc8301fb9a60175740653 ] System clk provided in ST soc can be set to: 48Mhz, non-spread 25Mhz, spread To get accurate rate, we need it to set it at non-spread option which is 48Mhz. Signed-off-by: Akshu Agrawal Reviewed-by: Daniel Kurtz Fixes: 421bf6a1f061 ("clk: x86: Add ST oscout platform clock") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d948acce9a0cc0445ea6d05652bb3d56ea107da4 Author: Mika Westerberg Date: Thu Aug 30 11:50:13 2018 +0300 i2c: i801: Allow ACPI AML access I/O ports not reserved for SMBus [ Upstream commit 7fd6d98b89f382d414e1db528e29a67bbd749457 ] Commit 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR") made it possible for AML code to access SMBus I/O ports by installing custom SystemIO OpRegion handler and blocking i80i driver access upon first AML read/write to this OpRegion. However, while ThinkPad T560 does have SystemIO OpRegion declared under the SMBus device, it does not access any of the SMBus registers: Device (SMBU) { ... OperationRegion (SMBP, PCI_Config, 0x50, 0x04) Field (SMBP, DWordAcc, NoLock, Preserve) { , 5, TCOB, 11, Offset (0x04) } Name (TCBV, 0x00) Method (TCBS, 0, NotSerialized) { If ((TCBV == 0x00)) { TCBV = (\_SB.PCI0.SMBU.TCOB << 0x05) } Return (TCBV) /* \_SB_.PCI0.SMBU.TCBV */ } OperationRegion (TCBA, SystemIO, TCBS (), 0x10) Field (TCBA, ByteAcc, NoLock, Preserve) { Offset (0x04), , 9, CPSC, 1 } } Problem with the current approach is that it blocks all I/O port access and because this system has touchpad connected to the SMBus controller after first AML access (happens during suspend/resume cycle) the touchpad fails to work anymore. Fix this so that we allow ACPI AML I/O port access if it does not touch the region reserved for the SMBus. Fixes: 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR") Link: https://bugzilla.kernel.org/show_bug.cgi?id=200737 Reported-by: Yussuf Khalil Signed-off-by: Mika Westerberg Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 31b5f66e90b22b5ac06bc00a309e3cd7ea3fa05a Author: Marc Zyngier Date: Fri Aug 24 15:08:30 2018 +0100 arm/arm64: smccc-1.1: Handle function result as parameters [ Upstream commit 755a8bf5579d22eb5636685c516d8dede799e27b ] If someone has the silly idea to write something along those lines: extern u64 foo(void); void bar(struct arm_smccc_res *res) { arm_smccc_1_1_smc(0xbad, foo(), res); } they are in for a surprise, as this gets compiled as: 0000000000000588 : 588: a9be7bfd stp x29, x30, [sp, #-32]! 58c: 910003fd mov x29, sp 590: f9000bf3 str x19, [sp, #16] 594: aa0003f3 mov x19, x0 598: aa1e03e0 mov x0, x30 59c: 94000000 bl 0 <_mcount> 5a0: 94000000 bl 0 5a4: aa0003e1 mov x1, x0 5a8: d4000003 smc #0x0 5ac: b4000073 cbz x19, 5b8 5b0: a9000660 stp x0, x1, [x19] 5b4: a9010e62 stp x2, x3, [x19, #16] 5b8: f9400bf3 ldr x19, [sp, #16] 5bc: a8c27bfd ldp x29, x30, [sp], #32 5c0: d65f03c0 ret 5c4: d503201f nop The call to foo "overwrites" the x0 register for the return value, and we end up calling the wrong secure service. A solution is to evaluate all the parameters before assigning anything to specific registers, leading to the expected result: 0000000000000588 : 588: a9be7bfd stp x29, x30, [sp, #-32]! 58c: 910003fd mov x29, sp 590: f9000bf3 str x19, [sp, #16] 594: aa0003f3 mov x19, x0 598: aa1e03e0 mov x0, x30 59c: 94000000 bl 0 <_mcount> 5a0: 94000000 bl 0 5a4: aa0003e1 mov x1, x0 5a8: d28175a0 mov x0, #0xbad 5ac: d4000003 smc #0x0 5b0: b4000073 cbz x19, 5bc 5b4: a9000660 stp x0, x1, [x19] 5b8: a9010e62 stp x2, x3, [x19, #16] 5bc: f9400bf3 ldr x19, [sp, #16] 5c0: a8c27bfd ldp x29, x30, [sp], #32 5c4: d65f03c0 ret Reported-by: Julien Grall Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c1baf3699d84af8dc242010263c91f6e2a0ce701 Author: Marc Zyngier Date: Fri Aug 24 15:08:29 2018 +0100 arm/arm64: smccc-1.1: Make return values unsigned long [ Upstream commit 1d8f574708a3fb6f18c85486d0c5217df893c0cf ] An unfortunate consequence of having a strong typing for the input values to the SMC call is that it also affects the type of the return values, limiting r0 to 32 bits and r{1,2,3} to whatever was passed as an input. Let's turn everything into "unsigned long", which satisfies the requirements of both architectures, and allows for the full range of return values. Reported-by: Julien Grall Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8ad1f551f802d7441938fca54a9459abdd169ab6 Author: Emily Deng Date: Tue Aug 28 20:52:40 2018 +0800 drm/amdgpu: Need to set moved to true when evict bo [ Upstream commit 6ddd9769db4fc11a98bd7e58be1764e47fdb8384 ] Fix the VMC page fault when the running sequence is as below: 1.amdgpu_gem_create_ioctl 2.ttm_bo_swapout->amdgpu_vm_bo_invalidate, as not called amdgpu_vm_bo_base_init, so won't called list_add_tail(&base->bo_list, &bo->va). Even the bo was evicted, it won't set the bo_base->moved. 3.drm_gem_open_ioctl->amdgpu_vm_bo_base_init, here only called list_move_tail(&base->vm_status, &vm->evicted), but not set the bo_base->moved. 4.amdgpu_vm_bo_map->amdgpu_vm_bo_insert_map, as the bo_base->moved is not set true, the function amdgpu_vm_bo_insert_map will call list_move(&bo_va->base.vm_status, &vm->moved) 5.amdgpu_cs_ioctl won't validate the swapout bo, as it is only in the moved list, not in the evict list. So VMC page fault occurs. Signed-off-by: Emily Deng Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 68327465ccdbf5c5ebc8972ed03a224d871fd364 Author: Tony Lindgren Date: Mon Aug 27 19:18:21 2018 -0700 ARM: dts: omap4-droid4: Fix emmc errors seen on some devices [ Upstream commit 2d59bb602314a4b2593fde267734266b5e872dd0 ] Otherwise we can get the following errors occasionally on some devices: mmc1: tried to HW reset card, got error -110 mmcblk1: error -110 requesting status mmcblk1: recovery failed! print_req_error: I/O error, dev mmcblk1, sector 14329 ... I have one device that hits this error almost on every boot, and another one that hits it only rarely with the other ones I've used behave without problems. I'm not sure if the issue is related to a particular eMMC card model, but in case it is, both of the machines with issues have: # cat /sys/class/mmc_host/mmc1/mmc1:0001/manfid \ /sys/class/mmc_host/mmc1/mmc1:0001/oemid \ /sys/class/mmc_host/mmc1/mmc1:0001/name 0x000045 0x0100 SEM16G and the working ones have: 0x000011 0x0100 016G92 Note that "ti,non-removable" is different as omap_hsmmc_reg_get() does not call omap_hsmmc_disable_boot_regulators() if no_regulator_off_init is set. And currently we set no_regulator_off_init only for "ti,non-removable" and not for "non-removable". It seems that we should have "non-removable" with some other mmc generic property behave in the same way instead of having to use a non-generic property. But let's fix the issue first. Fixes: 7e2f8c0ae670 ("ARM: dts: Add minimal support for motorola droid 4 xt894") Cc: Marcel Partap Cc: Merlijn Wajer Cc: Michael Scott Cc: NeKit Cc: Pavel Machek Cc: Sebastian Reichel Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b32e647a83751bc24d7ef7522915005b2bac9200 Author: James Smart Date: Thu Aug 9 16:00:14 2018 -0700 nvme-fcloop: Fix dropped LS's to removed target port [ Upstream commit afd299ca996929f4f98ac20da0044c0cdc124879 ] When a targetport is removed from the config, fcloop will avoid calling the LS done() routine thinking the targetport is gone. This leaves the initiator reset/reconnect hanging as it waits for a status on the Create_Association LS for the reconnect. Change the filter in the LS callback path. If tport null (set when failed validation before "sending to remote port"), be sure to call done. This was the main bug. But, continue the logic that only calls done if tport was set but there is no remoteport (e.g. case where remoteport has been removed, thus host doesn't expect a completion). Signed-off-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 22670e847f7ca72a4e871d00eaa7c720ff94ef6f Author: Linus Walleij Date: Sun Jul 15 22:09:29 2018 +0200 ata: ftide010: Add a quirk for SQ201 [ Upstream commit 46cb52ad414ac829680d0bb8cc7090ac2b577ca7 ] The DMA is broken on this specific device for some unknown reason (probably badly designed or plain broken interface electronics) and will only work with PIO. Other users of the same hardware does not have this problem. Add a specific quirk so that this Gemini device gets DMA turned off. Also fix up some code around passing the port information around in probe while we're at it. Signed-off-by: Linus Walleij Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 65c96da9c684946d0874bf911fdb50a3b497cb30 Author: Rex Zhu Date: Fri Aug 24 16:17:54 2018 +0800 drm/amdgpu: Update power state at the end of smu hw_init. [ Upstream commit 2ab4d0e74256fc49b7b270f63c1d1e47c2455abc ] For SI/Kv, the power state is managed by function amdgpu_pm_compute_clocks. when dpm enabled, we should call amdgpu_pm_compute_clocks to update current power state instand of set boot state. this change can fix the oops when kfd driver was enabled on Kv. Reviewed-by: Alex Deucher Tested-by: Michel Dänzer Signed-off-by: Rex Zhu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 21a73b809735e50956b6151785f60aa6897c85f0 Author: Rex Zhu Date: Fri Aug 24 17:26:23 2018 +0800 drm/amdgpu: Enable/disable gfx PG feature in rlc safe mode [ Upstream commit 8ef23364b654d44244400d79988e677e504b21ba ] This is required by gfx hw and can fix the rlc hang when do s3 stree test on Cz/St. Reviewed-by: Alex Deucher Signed-off-by: Hang Zhou Signed-off-by: Rex Zhu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4adf34c33950c75b38b0b4310d5a98d497094ede Author: Leonard Crestez Date: Tue Jul 24 19:14:19 2018 +0300 Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping" [ Upstream commit 538d6e9d597584e80514698e24321645debde78f ] This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d. That commit followed the reference manual but unfortunately the imx7d manual is incorrect. Tested with ath9k pcie card and confirmed internally. Signed-off-by: Leonard Crestez Acked-by: Lucas Stach Fixes: 1c86c9dd82f8 ("ARM: dts: imx7d: Invert legacy PCI irq mapping") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 78dabdae8108ccb7e833d8c318dcf83fecf5b55f Author: Dan Carpenter Date: Tue Aug 14 13:07:47 2018 +0300 hwmon: (adt7475) Make adt7475_read_word() return errors [ Upstream commit f196dec6d50abb2e65fb54a0621b2f1b4d922995 ] The adt7475_read_word() function was meant to return negative error codes on failure. Signed-off-by: Dan Carpenter Reviewed-by: Tokunori Ikegami Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e41ea7c77cb2ce589736856c8eaf0c9a3d9aeaaf Author: Lothar Felten Date: Tue Aug 14 09:09:37 2018 +0200 hwmon: (ina2xx) fix sysfs shunt resistor read access [ Upstream commit 3ad867001c91657c46dcf6656d52eb6080286fd5 ] fix the sysfs shunt resistor read access: return the shunt resistor value, not the calibration register contents. update email address Signed-off-by: Lothar Felten Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aada57693e8171cd441d55459526ecb0b0c288f6 Author: Srikanth Jampala Date: Wed Aug 22 12:40:52 2018 +0530 crypto: cavium/nitrox - fix for command corruption in queue full case with backlog submissions. [ Upstream commit 3d7c82060d1fe65bde4023aac41a0b1bd7718e07 ] Earlier used to post the current command without checking queue full after backlog submissions. So, post the current command only after confirming the space in queue after backlog submissions. Maintain host write index instead of reading device registers to get the next free slot to post the command. Return -ENOSPC in queue full case. Signed-off-by: Srikanth Jampala Reviewed-by: Gadam Sreerama Tested-by: Jha, Chandan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 19f2fedf4f434978a0f19ab8eeec7974d7518b32 Author: Ganesh Goudar Date: Fri Aug 10 18:27:41 2018 +0530 crypto: chtls - fix null dereference chtls_free_uld() [ Upstream commit 65b2c12dcdb883fc015c0ec65d6c2f857e0456ac ] call chtls_free_uld() only for the initialized cdev, this fixes NULL dereference in chtls_free_uld() Signed-off-by: Ganesh Goudar Signed-off-by: Atul Gupta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ff53d50516751b72412c98c53e968eb3e62e2f01 Author: Jacob Keller Date: Mon Aug 20 08:12:27 2018 -0700 i40e: fix condition of WARN_ONCE for stat strings [ Upstream commit 07f3701387dcab3a4fb0166098fb2754a1b927e1 ] Commit 9b10df596bd4 ("i40e: use WARN_ONCE to replace the commented BUG_ON size check") introduced a warning check to make sure that the size of the stat strings was always the expected value. This code accidentally inverted the check of the data pointer. Fix this so that we accurately count the size of the stats we copied in. This fixes an erroneous WARN kernel splat that occurs when requesting ethtool statistics. Signed-off-by: Jacob Keller Tested-by: Andrew Bowers Tested-by: Mauro S M Rodrigues Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit be97150c4a540d6d98bee479de2d270a55efb400 Author: Martyna Szapar Date: Tue Aug 7 17:11:23 2018 -0700 i40e: Fix for Tx timeouts when interface is brought up if DCB is enabled [ Upstream commit fa38e30ac73fbb01d7e5d0fd1b12d412fa3ac3ee ] If interface is connected to switch port configured for DCB there are TX timeouts when bringing up interface. Problem started appearing after adding in i40e driver code mqprio hardware offload mode. In function i40e_vsi_configure_bw_alloc was added resetting BW rate which should be executing when mqprio qdisc is removed but was also when there was no mqprio qdisc added and DCB was enabled. In this patch was added additional check for DCB flag so now when DCB is enabled the correct DCB configs from before mqprio patch are restored. Signed-off-by: Martyna Szapar Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4ef71783033a4073bab655609c7279b34ab78da1 Author: Sebastian Basierski Date: Tue Jul 31 18:16:00 2018 +0200 ixgbe: fix driver behaviour after issuing VFLR [ Upstream commit 939b701ad63314f5aa90dcd3d866f73954945209 ] Since VFLR doesn't clear VFMBMEM (VF Mailbox Memory) and is not re-enabling queues correctly we should fix this behavior. Signed-off-by: Sebastian Basierski Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3e8566205e04196b67a75cb0bc7218b5d3f00804 Author: Bo Chen Date: Mon Jul 23 09:01:30 2018 -0700 e1000: ensure to free old tx/rx rings in set_ringparam() [ Upstream commit ee400a3f1bfe7004a3e14b81c38ccc5583c26295 ] In 'e1000_set_ringparam()', the tx_ring and rx_ring are updated with new value and the old tx/rx rings are freed only when the device is up. There are resource leaks on old tx/rx rings when the device is not up. This bug is reported by COD, a tool for testing kernel module binaries I am building. This patch fixes the bug by always calling 'kfree()' on old tx/rx rings in 'e1000_set_ringparam()'. Signed-off-by: Bo Chen Reviewed-by: Alexander Duyck Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f9b0af8f9ad5ef703d66e6bdae25e34d8a764f34 Author: Bo Chen Date: Mon Jul 23 09:01:29 2018 -0700 e1000: check on netif_running() before calling e1000_up() [ Upstream commit cf1acec008f8d7761aa3fd7c4bca7e17b2d2512d ] When the device is not up, the call to 'e1000_up()' from the error handling path of 'e1000_set_ringparam()' causes a kernel oops with a null-pointer dereference. The null-pointer dereference is triggered in function 'e1000_alloc_rx_buffers()' at line 'buffer_info = &rx_ring->buffer_info[i]'. This bug was reported by COD, a tool for testing kernel module binaries I am building. This bug was also detected by KFI from Dr. Kai Cong. This patch fixes the bug by checking on 'netif_running()' before calling 'e1000_up()' in 'e1000_set_ringparam()'. Signed-off-by: Bo Chen Acked-by: Alexander Duyck Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1ca43c80d80f0e2e6f4f3942ab2e024104c64586 Author: Jesse Brandeburg Date: Thu Aug 9 06:29:01 2018 -0700 ice: Fix potential return of uninitialized value [ Upstream commit dab0588fb616c1774bbf108eab1749dda4ac6942 ] In ice_vsi_setup_[tx|rx]_rings, err is uninitialized which can result in a garbage value return to the caller. Fix that. Signed-off-by: Jesse Brandeburg Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0753c86efc6c1f62de843f5f1001ed38aff639cd Author: Anirudh Venkataramanan Date: Thu Aug 9 06:29:00 2018 -0700 ice: Fix a few null pointer dereference issues [ Upstream commit c7f2c42b80ed6009f44e355aefc1e40db9485a9d ] 1) When ice_ena_msix_range() fails to reserve vectors, a devm_kfree() warning was seen in the error flow path. So check pf->irq_tracker before use in ice_clear_interrupt_scheme(). 2) In ice_vsi_cfg(), check vsi->netdev before use. 3) In ice_get_link_status, check link_up before use. Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 939817cd00d233ecd9fafa5abd30d243f9dd6ad5 Author: Quentin Monnet Date: Thu Aug 23 17:46:25 2018 +0100 tools: bpftool: return from do_event_pipe() on bad arguments [ Upstream commit 785e76d7a2051a9e28b9134d5388a45b16f5eb72 ] When command line parsing fails in the while loop in do_event_pipe() because the number of arguments is incorrect or because the keyword is unknown, an error message is displayed, but bpftool remains stuck in the loop. Make sure we exit the loop upon failure. Fixes: f412eed9dfde ("tools: bpftool: add simple perf event output reader") Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1dec7a1e6a54d057ac6c851b74d21edefb7f8a90 Author: Brett Creeley Date: Thu Aug 9 06:28:58 2018 -0700 ice: Set VLAN flags correctly [ Upstream commit 5d8778d803e21f235e9bc727b5bd619f02abb88b ] In the struct ice_aqc_vsi_props the field port_vlan_flags is an overloaded term because it is used for both port VLANs (PVLANs) and regular VLANs. This is an issue and is very confusing especially when dealing with VFs because normal VLANs and port VLANs are not the same. To fix this the field was renamed to vlan_flags and all of the #define's labeled *_PVLAN_* were renamed to *_VLAN_* if they are not specific to port VLANs. Also in ice_vsi_manage_vlan_stripping, set the ICE_AQ_VSI_VLAN_MODE_ALL bit to allow the driver to add a VLAN tag to all packets it sends. Signed-off-by: Brett Creeley Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1c83a5aa0f263ff49b35d6f72579b282dd9c0019 Author: Jacob Keller Date: Thu Aug 9 06:28:57 2018 -0700 ice: Use order_base_2 to calculate higher power of 2 [ Upstream commit 1eb43fc754485d772b1165118a8fb80c385f0492 ] Currently, we use a combination of ilog2 and is_power_of_2() to calculate the next power of 2 for the qcount. This appears to be causing a warning on some combinations of GCC and the Linux kernel: MODPOST 1 modules WARNING: "____ilog2_NaN" [ice.ko] undefined! This appears to because because GCC realizes that qcount could be zero in some circumstances and thus attempts to link against the intentionally undefined ___ilog2_NaN function. The order_base_2 function is intentionally defined to return 0 when passed 0 as an argument, and thus will be safe to use here. This not only fixes the warning but makes the resulting code slightly cleaner, and is really what we should have used originally. Also update the comment to make it more clear that we are rounding up, not just incrementing the ilog2 of qcount unconditionally. Signed-off-by: Jacob Keller Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1dd0b6ce76ee1c60f2a7f3cd222872bf42ef10ca Author: Anirudh Venkataramanan Date: Thu Aug 9 06:28:56 2018 -0700 ice: Fix bugs in control queue processing [ Upstream commit 3d6b640efcc1b07709b42dd2e9609401c6f88633 ] This patch is a consolidation of multiple bug fixes for control queue processing. 1) In ice_clean_adminq_subtask() remove unnecessary reads/writes to registers. The bits PFINT_FW_CTL, PFINT_MBX_CTL and PFINT_SB_CTL are not set when an interrupt arrives, which means that clearing them again can be omitted. 2) Get an accurate value in "pending" by re-reading the control queue head register from the hardware. 3) Fix a corner case involving lost control queue messages by checking for new control messages (using ice_ctrlq_pending) before exiting the cleanup routine. Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9289b179fc4e20d663ffb6ce24721b6973d139c7 Author: Preethi Banala Date: Thu Aug 9 06:28:55 2018 -0700 ice: Clean control queues only when they are initialized [ Upstream commit b29bc220e2c7bd494a4605defcd93b18d5a8cf86 ] Clean control queues only when they are initialized. One of the ways to validate if the basic initialization is done is by checking value of cq->sq.head and cq->rq.head variables that specify the register address. This patch adds a check to avoid NULL pointer dereference crash when tried to shutdown uninitialized control queue. Signed-off-by: Preethi Banala Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 32d99e3e63c73f77d30a5f9ecca950a7cd7d62c4 Author: Jacob Keller Date: Thu Aug 9 06:28:54 2018 -0700 ice: Report stats for allocated queues via ethtool stats [ Upstream commit f8ba7db850350319348b6d3c276f8ba19bc098ef ] It is not safe to have the string table for statistics change order or size over the lifetime of a given netdevice. This is because of the nature of the 3-step process for obtaining stats. First, user space performs a request for the size of the strings table. Second it performs a separate request for the strings themselves, after allocating space for the table. Third, it requests the stats themselves, also allocating space for the table. If the size decreased, there is potential to see garbage data or stats values. In the worst case, we could potentially see stats values become mis-aligned with their strings, so that it looks like a statistic is being reported differently than it actually is. Even worse, if the size increased, there is potential that the strings table or stats table was not allocated large enough and the stats code could access and write to memory it should not, potentially resulting in undefined behavior and system crashes. It isn't even safe if the size always changes under the RTNL lock. This is because the calls take place over multiple user space commands, so it is not possible to hold the RTNL lock for the entire duration of obtaining strings and stats. Further, not all consumers of the ethtool API are the user space ethtool program, and it is possible that one assumes the strings will not change (valid under the current contract), and thus only requests the stats values when requesting stats in a loop. Finally, it's not possible in the general case to detect when the size changes, because it is quite possible that one value which could impact the stat size increased, while another decreased. This would result in the same total number of stats, but reordering them so that stats no longer line up with the strings they belong to. Since only size changes aren't enough, we would need some sort of hash or token to determine when the strings no longer match. This would require extending the ethtool stats commands, but there is no more space in the relevant structures. The real solution to resolve this would be to add a completely new API for stats, probably over netlink. In the ice driver, the only thing impacting the stats that is not constant is the number of queues. Instead of reporting stats for each used queue, report stats for each allocated queue. We do not change the number of queues allocated for a given netdevice, as we pass this into the alloc_etherdev_mq() function to set the num_tx_queues and num_rx_queues. This resolves the potential bugs at the slight cost of displaying many queue statistics which will not be activated. Signed-off-by: Jacob Keller Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c0f20df3b1fcc494cda24bb651be7043c5cbdc82 Author: Anirudh Venkataramanan Date: Thu Aug 9 06:28:51 2018 -0700 ice: Fix multiple static analyser warnings [ Upstream commit 4381147df9098706caa5cf9fda37e53b2fe4871f ] This patch fixes the following smatch errors: 1) Fix "odd binop '0x0 & 0xc'" when performing the bitwise-and with a constant value of zero (ICE_AQC_GSET_RSS_LUT_TABLE_SIZE_128_FLAG). Remove a similar bitwise-and with 0 in ice_add_marker_act() and use the right mask ICE_LG_ACT_GENERIC_OFFSET_M in the expression. 2) Fix a similar issue "odd binop '0x0 & 0x1800' in ice_req_irq_msix_misc. 3) Fix "odd binop '0x380000 & 0x7fff8'" in ice_add_marker_act(). Also, use a new define ICE_LG_ACT_GENERIC_OFF_RX_DESC_PROF_IDX instead of magic number '7'. 4) Fix warn: odd binop '0x0 & 0x18' in ice_set_dflt_vsi_ctx() by removing unnecessary logic to explicitly unset bits 3 and 4 in port_vlan_bits. These bits are unset already by the memset on ctxt->info. Reported-by: Dan Carpenter Signed-off-by: Anirudh Venkataramanan Tested-by: Tony Brelinski Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1801431dc7aa7f833dda0a64f66f38890796edc9 Author: Huazhong Tan Date: Thu Aug 23 11:37:15 2018 +0800 net: hns3: fix page_offset overflow when CONFIG_ARM64_64K_PAGES [ Upstream commit 27a5959308559fa6afcaa4e6cd81d25bcb2dda7c ] When enable the config item "CONFIG_ARM64_64K_PAGES", the size of PAGE_SIZE is 65536(64K). But the type of page_offset is u16, it will overflow. So change it to u32, when "CONFIG_ARM64_64K_PAGES" enabled. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Huazhong Tan Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 374eb417162b5f8f36b15ac854cd8faf60fa5aa5 Author: Huazhong Tan Date: Thu Aug 23 11:10:12 2018 +0800 net: hns: fix skb->truesize underestimation [ Upstream commit b1ccd4c0ab6ef499f47dd84ed4920502a7147bba ] skb->truesize is not meant to be tracking amount of used bytes in a skb, but amount of reserved/consumed bytes in memory. For instance, if we use a single byte in last page fragment, we have to account the full size of the fragment. So skb_add_rx_frag needs to calculate the length of the entire buffer into turesize. Fixes: 9cbe9fd5214e ("net: hns: optimize XGE capability by reducing cpu usage") Signed-off-by: Huazhong tan Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2d4a7923868606a4252ba11b296a09baa3355aa5 Author: Huazhong Tan Date: Thu Aug 23 11:10:10 2018 +0800 net: hns: fix length and page_offset overflow when CONFIG_ARM64_64K_PAGES [ Upstream commit 3ed614dce3ca9912d22be215ff0f11104b69fe62 ] When enable the config item "CONFIG_ARM64_64K_PAGES", the size of PAGE_SIZE is 65536(64K). But the type of length and page_offset are u16, they will overflow. So change them to u32. Fixes: 6fe6611ff275 ("net: add Hisilicon Network Subsystem hnae framework support") Signed-off-by: Huazhong Tan Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d96820d46bc315f669789e18d4aef76d3bc71cc0 Author: Kevin Yang Date: Wed Aug 22 17:43:15 2018 -0400 tcp_bbr: in restart from idle, see if we should exit PROBE_RTT [ Upstream commit 5490b32dce6932ea7ee8e3b2f76db2957c92af6e ] This patch fix the case where BBR does not exit PROBE_RTT mode when it restarts from idle. When BBR restarts from idle and if BBR is in PROBE_RTT mode, BBR should check if it's time to exit PROBE_RTT. If yes, then BBR should exit PROBE_RTT mode and restore the cwnd to its full value. Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") Signed-off-by: Kevin Yang Signed-off-by: Neal Cardwell Reviewed-by: Yuchung Cheng Reviewed-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e5e63d2bb9b2ce5cc84081ecd39c8b04779fe119 Author: Kevin Yang Date: Wed Aug 22 17:43:14 2018 -0400 tcp_bbr: add bbr_check_probe_rtt_done() helper [ Upstream commit fb99886224294b2291d267da41395022fa4200e2 ] This patch add a helper function bbr_check_probe_rtt_done() to 1. check the condition to see if bbr should exit probe_rtt mode; 2. process the logic of exiting probe_rtt mode. Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") Signed-off-by: Kevin Yang Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Reviewed-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a66193f585ebc3c63fb3b6c767bd20191b5820a2 Author: Samuel Mendoza-Jonas Date: Wed Aug 22 14:57:44 2018 +1000 net/ncsi: Fixup .dumpit message flags and ID check in Netlink handler [ Upstream commit 3d0371b313b84ba7c16ebf2526a7a34f1c57b19e ] The ncsi_pkg_info_all_nl() .dumpit handler is missing the NLM_F_MULTI flag, causing additional package information after the first to be lost. Also fixup a sanity check in ncsi_write_package_info() to reject out of range package IDs. Signed-off-by: Samuel Mendoza-Jonas Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d028c09d1cf21b33030e137905846c8bebea768 Author: Emily Deng Date: Wed Aug 22 20:18:25 2018 +0800 amdgpu: fix multi-process hang issue [ Upstream commit 2f40c6eac74a2a60921cdec9e9a8a57e88e31434 ] SWDEV-146499: hang during multi vulkan process testing cause: the second frame's PREAMBLE_IB have clear-state and LOAD actions, those actions ruin the pipeline that is still doing process in the previous frame's work-load IB. fix: need insert pipeline sync if have context switch for SRIOV (because only SRIOV will report PREEMPTION flag to UMD) Signed-off-by: Monk Liu Signed-off-by: Emily Deng Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8824ceb2580c20ac16bc235f0efe0bd461c36864 Author: Christian König Date: Tue Aug 21 15:09:39 2018 +0200 drm/amdgpu: fix preamble handling [ Upstream commit d98ff24e8e9be3329eea7c84d5e244d0c1cd0ab3 ] At this point the command submission can still be interrupted. Signed-off-by: Christian König Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8483f3b7f4243f8c871d3d93e53ec11561088c18 Author: Christian König Date: Thu Aug 16 12:01:03 2018 +0200 drm/amdgpu: fix VM clearing for the root PD [ Upstream commit 8604ffcbf04f8f4f3f55a9e46e5ff948b2ed4290 ] We need to figure out the address after validating the BO, not before. Signed-off-by: Christian König Reviewed-by: Felix Kuehling Reviewed-by: Junwei Zhang Reviewed-by: Huang Rui Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a5c7547b45b43fd1e48fb4b34ea30261043356b9 Author: John Fastabend Date: Wed Aug 22 08:37:37 2018 -0700 bpf: sockmap: write_space events need to be passed to TCP handler [ Upstream commit 9b2e0388bec8ec5427403e23faff3b58dd1c3200 ] When sockmap code is using the stream parser it also handles the write space events in order to handle the case where (a) verdict redirects skb to another socket and (b) the sockmap then sends the skb but due to memory constraints (or other EAGAIN errors) needs to do a retry. But the initial code missed a third case where the skb_send_sock_locked() triggers an sk_wait_event(). A typically case would be when sndbuf size is exceeded. If this happens because we do not pass the write_space event to the lower layers we never wake up the event and it will wait for sndtimeo. Which as noted in ktls fix may be rather large and look like a hang to the user. To reproduce the best test is to reduce the sndbuf size and send 1B data chunks to stress the memory handling. To fix this pass the event from the upper layer to the lower layer. Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9c3d97879505f51a1b0f80d9b7418bce84b11a06 Author: John Fastabend Date: Wed Aug 22 08:37:32 2018 -0700 tls: possible hang when do_tcp_sendpages hits sndbuf is full case [ Upstream commit 67db7cd249e71f64346f481b629724376d063e08 ] Currently, the lower protocols sk_write_space handler is not called if TLS is sending a scatterlist via tls_push_sg. However, normally tls_push_sg calls do_tcp_sendpage, which may be under memory pressure, that in turn may trigger a wait via sk_wait_event. Typically, this happens when the in-flight bytes exceed the sdnbuf size. In the normal case when enough ACKs are received sk_write_space() will be called and the sk_wait_event will be woken up allowing it to send more data and/or return to the user. But, in the TLS case because the sk_write_space() handler does not wake up the events the above send will wait until the sndtimeo is exceeded. By default this is MAX_SCHEDULE_TIMEOUT so it look like a hang to the user (especially this impatient user). To fix this pass the sk_write_space event to the lower layers sk_write_space event which in the TCP case will wake any pending events. I observed the above while integrating sockmap and ktls. It initially appeared as test_sockmap (modified to use ktls) occasionally hanging. To reliably reproduce this reduce the sndbuf size and stress the tls layer by sending many 1B sends. This results in every byte needing a header and each byte individually being sent to the crypto layer. Signed-off-by: John Fastabend Acked-by: Dave Watson Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a0be77d6d94081333dbe79f531f2dc2866e58d94 Author: Daniel Borkmann Date: Wed Aug 22 18:09:17 2018 +0200 bpf, sockmap: fix sock hash count in alloc_sock_hash_elem [ Upstream commit eb29429d81e31b191f3b2bd19cf820279cec6463 ] When we try to allocate a new sock hash entry and the allocation fails, then sock hash map fails to reduce the map element counter, meaning we keep accounting this element although it was never used. Fix it by dropping the element counter on error. Fixes: 81110384441a ("bpf: sockmap, add hash map support") Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit efed642bc585c8d26bdba3b4de97d78057874bcf Author: Daniel Borkmann Date: Tue Aug 21 15:55:00 2018 +0200 bpf, sockmap: fix sock_hash_alloc and reject zero-sized keys [ Upstream commit b845c898b2f1ea458d5453f0fa1da6e2dfce3bb4 ] Currently, it is possible to create a sock hash map with key size of 0 and have the kernel return a fd back to user space. This is invalid for hash maps (and kernel also hasn't been tested for zero key size support in general at this point). Thus, reject such configuration. Fixes: 81110384441a ("bpf: sockmap, add hash map support") Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Song Liu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0a9fd2a9875bd60afc0f8f9316e9ce63a1eb4e87 Author: Pavel Machek Date: Wed Aug 1 22:28:21 2018 +0200 ARM: dts: omap4-droid4: fix vibrations on Droid 4 [ Upstream commit f4efa74c09a7eddcc12cd13208f78743763f6e7a ] Vibration GPIOs don't have anything to do with wakeup. Move it to normal section; this fixes vibrations on Droid 4. Fixes: a5effd968301 ("ARM: dts: omap4-droid4: Add vibrator") Signed-off-by: Pavel Machek Reviewed-by: Sebastian Reichel Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7468a7160e1086a7960d6fea8735f49c3c3c900 Author: Tony Lindgren Date: Wed Aug 8 01:07:06 2018 -0700 bus: ti-sysc: Fix no_console_suspend handling [ Upstream commit 4f3530f4a41d49c41015020cd9a5ed5c95b5d2db ] If no_console_suspend is set, we should keep console enabled during suspend. Lets fix this by only producing a warning if we can't idle hardware during suspend. Fixes: ef55f8215a78 ("bus: ti-sysc: Improve suspend and resume handling") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b8f4b96768c08e9273b67e720be0d6287f1ac291 Author: Ludovic Desroches Date: Mon Aug 20 10:54:45 2018 +0200 mmc: android-goldfish: fix bad logic of sg_copy_{from,to}_buffer conversion [ Upstream commit 17e96d8516e31c3cb52cb8e2ee79d1d2e6948c11 ] The conversion to sg_copy_{from,to}_buffer has been done in the wrong way. sg_copy_to_buffer is a copy from an SG list to a linear buffer so it can't replace memcpy(dest, host->virt_base, data->sg->length) where dest is the virtual address of the SG. Same for sg_copy_from_buffer but in the opposite way. Signed-off-by: Ludovic Desroches Suggested-by: Douglas Gilbert Fixes: 53d7e098ba08 ("mmc: android-goldfish: use sg_copy_{from,to}_buffer") Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d02aee5cf4ea78f2343a6bdb298cba47350a05b6 Author: Ludovic Desroches Date: Mon Aug 20 10:54:44 2018 +0200 mmc: atmel-mci: fix bad logic of sg_copy_{from,to}_buffer conversion [ Upstream commit 19f5e9e015675fcdbf2c20e804b2e84e80201454 ] The conversion to sg_copy_{from,to}_buffer has been done in the wrong way. sg_copy_to_buffer is a copy from an SG list to a linear buffer so it can't replace memcpy(buf + offset, &value, remaining) where buf is the virtual address of the SG. Same for sg_copy_to_buffer but in the opposite way. Signed-off-by: Ludovic Desroches Suggested-by: Douglas Gilbert Fixes: 5b4277814e3f ("mmc: atmel-mci: use sg_copy_{from,to}_buffer") Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1a7a1ad290d4006500e798e850dfab0385a8af9c Author: Eric Sandeen Date: Thu Aug 16 21:44:02 2018 -0500 isofs: reject hardware sector size > 2048 bytes [ Upstream commit 09a4e0be5826aa66c4ce9954841f110ffe63ef4f ] The largest block size supported by isofs is ISOFS_BLOCK_SIZE (2048), but isofs_fill_super calls sb_min_blocksize and sets the blocksize to the device's logical block size if it's larger than what we ended up with after option parsing. If for some reason we try to mount a hard 4k device as an isofs filesystem, we'll set opt.blocksize to 4096, and when we try to read the superblock we found via: block = iso_blknum << (ISOFS_BLOCK_BITS - s->s_blocksize_bits) with s_blocksize_bits greater than ISOFS_BLOCK_BITS, we'll have a negative shift and the bread will fail somewhat cryptically: isofs_fill_super: bread failed, dev=sda, iso_blknum=17, block=-2147483648 It seems best to just catch and clearly reject mounts of such a device. Reported-by: Bryan Gurney Signed-off-by: Eric Sandeen Signed-off-by: Jan Kara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2da832f43da5f4b5c0ffc1d2a3f180130795730d Author: Anson Huang Date: Tue Jul 31 00:56:49 2018 +0800 thermal: of-thermal: disable passive polling when thermal zone is disabled [ Upstream commit 152395fd03d4ce1e535a75cdbf58105e50587611 ] When thermal zone is in passive mode, disabling its mode from sysfs is NOT taking effect at all, it is still polling the temperature of the disabled thermal zone and handling all thermal trips, it makes user confused. The disabling operation should disable the thermal zone behavior completely, for both active and passive mode, this patch clears the passive_delay when thermal zone is disabled and restores it when it is enabled. Signed-off-by: Anson Huang Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6a3f378b76149f668afe92aa562f795f3af56a89 Author: Tomer Tayar Date: Mon Aug 20 00:01:45 2018 +0300 qed: Avoid sending mailbox commands when MFW is not responsive [ Upstream commit b310974e041913231b6e3d5d475d4df55c312301 ] Keep sending mailbox commands to the MFW when it is not responsive ends up with a redundant amount of timeout expiries. This patch prints the MCP status on the first command which is not responded, and blocks the following commands. Since the (un)load request commands might be not responded due to other PFs, the patch also adds the option to skip the blocking upon a failure. Signed-off-by: Tomer Tayar Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c36724c6478067e0acac3d2700ad6fee55e36dea Author: Tomer Tayar Date: Mon Aug 20 00:01:44 2018 +0300 qed: Prevent a possible deadlock during driver load and unload [ Upstream commit eaa50fc59e5841910987e90b0438b2643041f508 ] The MFW manages an internal lock to prevent concurrent hardware (de)initialization of different PFs. This, together with the busy-waiting for the MFW's responses for commands, might lead to a deadlock during concurrent load or unload of PFs. This patch adds the option to sleep within the busy-waiting, and uses it for the (un)load requests (which are not sent from an interrupt context) to prevent the possible deadlock. Signed-off-by: Tomer Tayar Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1e85fc417c114e6186071fae46850c167593d152 Author: Tomer Tayar Date: Mon Aug 20 00:01:43 2018 +0300 qed: Wait for MCP halt and resume commands to take place [ Upstream commit 76271809f49056f079e202bf6513d17b0d6dd34d ] Successive iterations of halting and resuming the management chip (MCP) might fail, since currently the driver doesn't wait for these operations to actually take place. This patch prevents the driver from moving forward before the operations are reflected in the state register. Signed-off-by: Tomer Tayar Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c91ab927a8b7116967e8ed4d108ab7a44c06cfd4 Author: Tomer Tayar Date: Mon Aug 20 00:01:42 2018 +0300 qed: Wait for ready indication before rereading the shmem [ Upstream commit f00d25f3154b676fcea4502a25b94bd7f142ca74 ] The MFW might be reset and re-update its shared memory. Upon the detection of such a reset the driver rereads this memory, but it has to wait till the data is valid. This patch adds the missing wait for a data ready indication. Signed-off-by: Tomer Tayar Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 67eb28b0f832136b8af0a8f3d9831c450b4d20ae Author: Tony Lindgren Date: Wed Aug 8 01:07:05 2018 -0700 bus: ti-sysc: Fix module register ioremap for larger offsets [ Upstream commit 0ef8e3bb974af56346b34393e643d491d9141c66 ] We can have the interconnect target module control registers pretty much anywhere within the module range. The current code attempts an incomplete optimization of the ioremap size but does it wrong and it only works for registers at the beginning of the module. Let's just use the largest control register to calculate the ioremap size. The ioremapped range is for most part cached anyways so there is no need for size optimization. Let's also update the comments accordingly. Fixes: 0eecc636e5a2 ("bus: ti-sysc: Add minimal TI sysc interconnect target driver") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3609bd6105c1f41a508dad682686078d3a880662 Author: Tony Lindgren Date: Wed Aug 8 01:07:04 2018 -0700 ARM: OMAP2+: Fix module address for modules using mpu_rt_idx [ Upstream commit 1dbcb97c656eed1a244c960b8b3a469c3d20ce7b ] If we use device tree data for a module interconnect target we want to map the control registers from the module start. Legacy hwmod platform data however is using child IP offsets for cpsw module with mpu_rt_idx. In cases where we have the interconnect target module already using device tree data with legacy hwmod platform data still around, the sysc register area is not adjusted for mpu_rt_idx causing wrong registers being accessed. Let's fix the issue for mixed dts and platform data mode by ioremapping the module registers using child IP offset if mpu_rt_idx is set. For device tree only data there's no reason to use mpu_rt_idx. Fixes: 6c72b3550672 ("ARM: OMAP2+: Parse module IO range from dts for legacy "ti,hwmods" support") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1fcd5e01d26e99461d4f00b660d43632a81a3306 Author: Tony Lindgren Date: Wed Aug 8 01:07:03 2018 -0700 ARM: OMAP2+: Fix null hwmod for ti-sysc debug [ Upstream commit 4769c003e0fcff0ee001a9102e2605bdaa5880f0 ] We may call omap_hwmod_parse_module_range() with no hwmod allocated yet and may have debug enabled. Let's fix this by checking for hwmod before trying to use it's name. Fixes: 6c72b3550672 ("ARM: OMAP2+: Parse module IO range from dts for legacy Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4435064439c68cfa80a7a1ec69733db7b9030884 Author: Dave Martin Date: Thu Sep 27 16:53:21 2018 +0100 arm64: KVM: Tighten guest core register access from userspace commit d26c25a9d19b5976b319af528886f89cf455692d upstream. We currently allow userspace to access the core register file in about any possible way, including straddling multiple registers and doing unaligned accesses. This is not the expected use of the ABI, and nobody is actually using it that way. Let's tighten it by explicitly checking the size and alignment for each field of the register file. Cc: Fixes: 2f4a07c5f9fe ("arm64: KVM: guest one-reg interface") Reviewed-by: Christoffer Dall Reviewed-by: Mark Rutland Signed-off-by: Dave Martin [maz: rewrote Dave's initial patch to be more easily backported] Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 12a7e915c5069849fb0ab697a7ef9c48aedd0685 Author: Steve Wise Date: Fri Aug 31 07:16:03 2018 -0700 RDMA/uverbs: Atomically flush and mark closed the comp event queue commit 67e3816842fe6414d629c7515b955952ec40c7d7 upstream. Currently a uverbs completion event queue is flushed of events in ib_uverbs_comp_event_close() with the queue spinlock held and then released. Yet setting ev_queue->is_closed is not set until later in uverbs_hot_unplug_completion_event_file(). In between the time ib_uverbs_comp_event_close() releases the lock and uverbs_hot_unplug_completion_event_file() acquires the lock, a completion event can arrive and be inserted into the event queue by ib_uverbs_comp_handler(). This can cause a "double add" list_add warning or crash depending on the kernel configuration, or a memory leak because the event is never dequeued since the queue is already closed down. So add setting ev_queue->is_closed = 1 to ib_uverbs_comp_event_close(). Cc: stable@vger.kernel.org Fixes: 1e7710f3f656 ("IB/core: Change completion channel to use the reworked objects schema") Signed-off-by: Steve Wise Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit cbbb9f08566ef3f08e842812b93eae063133f9e2 Author: Mika Westerberg Date: Wed Sep 26 15:39:28 2018 -0500 ACPI / hotplug / PCI: Don't scan for non-hotplug bridges if slot is not bridge commit f188b99f0b2d33794b4af8a225f95d1e968c0a3f upstream. HP 6730b laptop has an ethernet NIC connected to one of the PCIe root ports. The root ports themselves are native PCIe hotplug capable. Now, during boot after PCI devices are scanned the BIOS triggers ACPI bus check directly to the NIC: ACPI: \_SB_.PCI0.RP06.NIC_: Bus check in hotplug_event() It is not clear why it is sending bus check but regardless the ACPI hotplug notify handler calls enable_slot() directly (instead of going through acpiphp_check_bridge() as there is no bridge), which ends up handling special case for non-hotplug bridges with native PCIe hotplug. This results a crash of some kind but the reporter only sees black screen so it is hard to figure out the exact spot and what actually happens. Based on a few fix proposals it was tracked to crash somewhere inside pci_assign_unassigned_bridge_resources(). In any case we should not really be in that special branch at all because the ACPI notify happened to a slot that is not a PCI bridge (it is just a regular PCI device). Fix this so that we only go to that special branch if we are calling enable_slot() for a bridge (e.g., the ACPI notification was for the bridge). Link: https://bugzilla.kernel.org/show_bug.cgi?id=201127 Fixes: 84c8b58ed3ad ("ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug") Reported-by: Peter Anemone Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki CC: stable@vger.kernel.org # v4.18+ Signed-off-by: Greg Kroah-Hartman commit 0c7898792c9a9e61b799ef37706cd29a97eb3e67 Author: Michael J. Ruhl Date: Thu Sep 20 12:59:14 2018 -0700 IB/hfi1: Fix destroy_qp hang after a link down commit b4a4957d3d1c328b733fce783b7264996f866ad2 upstream. rvt_destroy_qp() cannot complete until all in process packets have been released from the underlying hardware. If a link down event occurs, an application can hang with a kernel stack similar to: cat /proc//stack quiesce_qp+0x178/0x250 [hfi1] rvt_reset_qp+0x23d/0x400 [rdmavt] rvt_destroy_qp+0x69/0x210 [rdmavt] ib_destroy_qp+0xba/0x1c0 [ib_core] nvme_rdma_destroy_queue_ib+0x46/0x80 [nvme_rdma] nvme_rdma_free_queue+0x3c/0xd0 [nvme_rdma] nvme_rdma_destroy_io_queues+0x88/0xd0 [nvme_rdma] nvme_rdma_error_recovery_work+0x52/0xf0 [nvme_rdma] process_one_work+0x17a/0x440 worker_thread+0x126/0x3c0 kthread+0xcf/0xe0 ret_from_fork+0x58/0x90 0xffffffffffffffff quiesce_qp() waits until all outstanding packets have been freed. This wait should be momentary. During a link down event, the cleanup handling does not ensure that all packets caught by the link down are flushed properly. This is caused by the fact that the freeze path and the link down event is handled the same. This is not correct. The freeze path waits until the HFI is unfrozen and then restarts PIO. A link down is not a freeze event. The link down path cannot restart the PIO until link is restored. If the PIO path is restarted before the link comes up, the application (QP) using the PIO path will hang (until link is restored). Fix by separating the linkdown path from the freeze path and use the link down path for link down events. Close a race condition sc_disable() by acquiring both the progress and release locks. Close a race condition in sc_stop() by moving the setting of the flag bits under the alloc lock. Cc: # 4.9.x+ Fixes: 7724105686e7 ("IB/hfi1: add driver files") Reviewed-by: Mike Marciniszyn Signed-off-by: Michael J. Ruhl Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit b34ba9e024085b15ec7d7726e7180466dcf843de Author: Michael J. Ruhl Date: Thu Sep 20 12:59:05 2018 -0700 IB/hfi1: Fix context recovery when PBC has an UnsupportedVL commit d623500b3c4efd8d4e945ac9003c6b87b469a9ab upstream. If a packet stream uses an UnsupportedVL (virtual lane), the send engine will not send the packet, and it will not indicate that an error has occurred. This will cause the packet stream to block. HFI has 8 virtual lanes available for packet streams. Each lane can be enabled or disabled using the UnsupportedVL mask. If a lane is disabled, adding a packet to the send context must be disallowed. The current mask for determining unsupported VLs defaults to 0 (allow all). This is incorrect. Only the VLs that are defined should be allowed. Determine which VLs are disabled (mtu == 0), and set the appropriate unsupported bit in the mask. The correct mask will allow the send engine to error on the invalid VL, and error recovery will work correctly. Cc: # 4.9.x+ Fixes: 7724105686e7 ("IB/hfi1: add driver files") Reviewed-by: Mike Marciniszyn Reviewed-by: Lukasz Odzioba Signed-off-by: Michael J. Ruhl Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit bcc5f9f5e11ec53dddb95e2e454a8305d0ffb522 Author: Michael J. Ruhl Date: Thu Sep 20 12:58:56 2018 -0700 IB/hfi1: Invalid user input can result in crash commit 94694d18cf27a6faad91487a38ce516c2b16e7d9 upstream. If the number of packets in a user sdma request does not match the actual iovectors being sent, sdma_cleanup can be called on an uninitialized request structure, resulting in a crash similar to this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [] __sdma_txclean+0x57/0x1e0 [hfi1] PGD 8000001044f61067 PUD 1052706067 PMD 0 Oops: 0000 [#1] SMP CPU: 30 PID: 69912 Comm: upsm Kdump: loaded Tainted: G OE ------------ 3.10.0-862.el7.x86_64 #1 Hardware name: Intel Corporation S2600KPR/S2600KPR, BIOS SE5C610.86B.01.01.0019.101220160604 10/12/2016 task: ffff8b331c890000 ti: ffff8b2ed1f98000 task.ti: ffff8b2ed1f98000 RIP: 0010:[] [] __sdma_txclean+0x57/0x1e0 [hfi1] RSP: 0018:ffff8b2ed1f9bab0 EFLAGS: 00010286 RAX: 0000000000008b2b RBX: ffff8b2adf6e0000 RCX: 0000000000000000 RDX: 00000000000000a0 RSI: ffff8b2e9eedc540 RDI: ffff8b2adf6e0000 RBP: ffff8b2ed1f9bad8 R08: 0000000000000000 R09: ffffffffc0b04a06 R10: ffff8b331c890190 R11: ffffe6ed00bf1840 R12: ffff8b3315480000 R13: ffff8b33154800f0 R14: 00000000fffffff2 R15: ffff8b2e9eedc540 FS: 00007f035ac47740(0000) GS:ffff8b331e100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000c03fe6000 CR4: 00000000001607e0 Call Trace: [] user_sdma_send_pkts+0xdcd/0x1990 [hfi1] [] ? gup_pud_range+0x140/0x290 [] ? hfi1_mmu_rb_insert+0x155/0x1b0 [hfi1] [] hfi1_user_sdma_process_request+0xc5b/0x11b0 [hfi1] [] hfi1_aio_write+0xba/0x110 [hfi1] [] do_sync_readv_writev+0x7b/0xd0 [] do_readv_writev+0xce/0x260 [] ? tty_ldisc_deref+0x19/0x20 [] ? n_tty_ioctl+0xe0/0xe0 [] vfs_writev+0x35/0x60 [] SyS_writev+0x7f/0x110 [] system_call_fastpath+0x1c/0x21 Code: 06 49 c7 47 18 00 00 00 00 0f 87 89 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 66 2e 0f 1f 84 00 00 00 00 00 48 8b 4e 10 48 89 fb <48> 8b 51 08 49 89 d4 83 e2 0c 41 81 e4 00 e0 00 00 48 c1 ea 02 RIP [] __sdma_txclean+0x57/0x1e0 [hfi1] RSP CR2: 0000000000000008 There are two exit points from user_sdma_send_pkts(). One (free_tx) merely frees the slab entry and one (free_txreq) cleans the sdma_txreq prior to freeing the slab entry. The free_txreq variation can only be called after one of the sdma_init*() variations has been called. In the panic case, the slab entry had been allocated but not inited. Fix the issue by exiting through free_tx thus avoiding sdma_clean(). Cc: # 4.9.x+ Fixes: 7724105686e7 ("IB/hfi1: add driver files") Reviewed-by: Mike Marciniszyn Reviewed-by: Lukasz Odzioba Signed-off-by: Michael J. Ruhl Signed-off-by: Dennis Dalessandro Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jason Gunthorpe commit 2cced23e54834ebef19152b5246b1209329b27e0 Author: Ira Weiny Date: Thu Sep 20 12:58:46 2018 -0700 IB/hfi1: Fix SL array bounds check commit 0dbfaa9f2813787679e296eb5476e40938ab48c8 upstream. The SL specified by a user needs to be a valid SL. Add a range check to the user specified SL value which protects from running off the end of the SL to SC table. CC: stable@vger.kernel.org Fixes: 7724105686e7 ("IB/hfi1: add driver files") Signed-off-by: Ira Weiny Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit fa22f4874e9409bcb321839ceefeadb88e423b9f Author: Bart Van Assche Date: Mon Sep 17 18:10:05 2018 -0700 IB/srp: Avoid that sg_reset -d ${srp_device} triggers an infinite loop commit ee92efe41cf358f4b99e73509f2bfd4733609f26 upstream. Use different loop variables for the inner and outer loop. This avoids that an infinite loop occurs if there are more RDMA channels than target->req_ring_size. Fixes: d92c0da71a35 ("IB/srp: Add multichannel support") Cc: Signed-off-by: Bart Van Assche Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit ebc51114fa51756d627022f2fc4f202bfeef1b22 Author: Aaron Ma Date: Tue Sep 18 09:32:22 2018 -0700 Input: elantech - enable middle button of touchpad on ThinkPad P72 commit 91a97507323e1ad4bfc10f4a5922e67cdaf8b3cd upstream. Adding 2 new touchpad IDs to support middle button support. Cc: stable@vger.kernel.org Signed-off-by: Aaron Ma Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f44f3d0a9e9fbfb800a2a98c02bac5772baedf90 Author: Matthew Wilcox Date: Tue Sep 11 21:27:44 2018 -0700 filesystem-dax: Fix use of zero page commit b90ca5cc32f59bb214847c6855959702f00c6801 upstream. Use my_zero_pfn instead of ZERO_PAGE(), and pass the vaddr to it instead of zero so it works on MIPS and s390 who reference the vaddr to select a zero page. Cc: Fixes: 91d25ba8a6b0 ("dax: use common 4k zero page for dax mmap reads") Signed-off-by: Matthew Wilcox Reviewed-by: Ross Zwisler Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 7ebfc8f69a37bb28380c97819fd6437eec37dd8c Author: Toshi Kani Date: Fri Sep 14 08:51:14 2018 -0600 ext2, dax: set ext2_dax_aops for dax files commit 9e796c9db93b4840d1b00e550eea26db7cb741e2 upstream. Sync syscall to DAX file needs to flush processor cache, but it currently does not flush to existing DAX files. This is because 'ext2_da_aops' is set to address_space_operations of existing DAX files, instead of 'ext2_dax_aops', since S_DAX flag is set after ext2_set_aops() in the open path. Similar to ext4, change ext2_iget() to initialize i_flags before ext2_set_aops(). Fixes: fb094c90748f ("ext2, dax: introduce ext2_dax_aops") Signed-off-by: Toshi Kani Suggested-by: Jan Kara Cc: Jan Kara Cc: Dan Williams Cc: "Theodore Ts'o" Cc: Andreas Dilger Cc: Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 2436ce1bad9ec8756d2c6626b794ddac67cd86ef Author: Dave Jiang Date: Wed Sep 5 13:31:40 2018 -0700 uaccess: Fix is_source param for check_copy_size() in copy_to_iter_mcsafe() commit dfb06cba8c73c0704710b2e3fbe2c35ac66a01b4 upstream. copy_to_iter_mcsafe() is passing in the is_source parameter as "false" to check_copy_size(). This is different than what copy_to_iter() does. Also, the addr parameter passed to check_copy_size() is the source so therefore we should be passing in "true" instead. Fixes: 8780356ef630 ("x86/asm/memcpy_mcsafe: Define copy_to_iter_mcsafe()") Cc: Reported-by: Fan Du Signed-off-by: Dave Jiang Reviewed-by: Vishal Verma Reported-by: Wenwei Tao Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit dc38ebde8a524c88ec3d6c5e7e4906d95fa6cbac Author: Alan Stern Date: Mon Sep 10 13:58:51 2018 -0400 USB: remove LPM management from usb_driver_claim_interface() commit c183813fcee44a249339b7c46e1ad271ca1870aa upstream. usb_driver_claim_interface() disables and re-enables Link Power Management, but it shouldn't do either one, for the reasons listed below. This patch removes the two LPM-related function calls from the routine. The reason for disabling LPM in the analogous function usb_probe_interface() is so that drivers won't have to deal with unwanted LPM transitions in their probe routine. But usb_driver_claim_interface() doesn't call the driver's probe routine (or any other callbacks), so that reason doesn't apply here. Furthermore, no driver other than usbfs will ever call usb_driver_claim_interface() unless it is already bound to another interface in the same device, which means disabling LPM here would be redundant. usbfs doesn't interact with LPM at all. Lastly, the error return from usb_unlocked_disable_lpm() isn't handled properly; the code doesn't clean up its earlier actions before returning. Signed-off-by: Alan Stern Fixes: 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.") CC: Signed-off-by: Greg Kroah-Hartman commit de425c9ae7bf74f9eea429eebf96dd2f627a28a6 Author: Sebastian Andrzej Siewior Date: Tue Sep 11 10:00:44 2018 +0200 Revert "usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()" commit e871db8d78df1c411032cbb3acfdf8930509360e upstream. This reverts commit 6e22e3af7bb3a7b9dc53cb4687659f6e63fca427. The bug the patch describes to, has been already fixed in commit 2df6948428542 ("USB: cdc-wdm: don't enable interrupts in USB-giveback") so need to this, revert it. Fixes: 6e22e3af7bb3 ("usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()") Cc: stable Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman commit 8badb9b1af73c407181d44806820d494e3c3c9c3 Author: Oliver Neukum Date: Wed Sep 5 12:07:03 2018 +0200 USB: usbdevfs: restore warning for nonsensical flags commit 81e0403b26d94360abd1f6a57311337973bc82cd upstream. If we filter flags before they reach the core we need to generate our own warnings. Signed-off-by: Oliver Neukum Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow") Cc: stable Signed-off-by: Greg Kroah-Hartman commit b5376ef73d3333db5989367b3aa9c0d9e7f0e619 Author: Oliver Neukum Date: Wed Sep 5 12:07:02 2018 +0200 USB: usbdevfs: sanitize flags more commit 7a68d9fb851012829c29e770621905529bd9490b upstream. Requesting a ZERO_PACKET or not is sensible only for output. In the input direction the device decides. Likewise accepting short packets makes sense only for input. This allows operation with panic_on_warn without opening up a local DOS. Signed-off-by: Oliver Neukum Reported-by: syzbot+843efa30c8821bd69f53@syzkaller.appspotmail.com Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow") Cc: stable Signed-off-by: Greg Kroah-Hartman commit 8e2842a2e17589b1e01fc0cdb4314aecf0e2b577 Author: Bin Liu Date: Mon Sep 17 11:40:22 2018 -0500 usb: musb: dsps: do not disable CPPI41 irq in driver teardown commit 783f3b4e9ec50491c21746e7e05ec6c39c21f563 upstream. TI AM335x CPPI 4.1 module uses a single register bit for CPPI interrupts in both musb controllers. So disabling the CPPI irq in one musb driver breaks the other musb module. Since musb is already disabled before tearing down dma controller in musb_remove(), it is safe to not disable CPPI irq in musb_dma_controller_destroy(). Fixes: 255348289f71 ("usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in DSPS") Cc: stable@vger.kernel.org Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 608677656ac2c02fbab0fc569ec0629ef9a5e71c Author: Harry Pan Date: Fri Sep 14 16:58:16 2018 +0800 usb: core: safely deal with the dynamic quirk lists commit 16c4cb19fa85c648a803752eb63cac0ef69231c2 upstream. Applying dynamic usbcore quirks in early booting when the slab is not yet ready would cause kernel panic of null pointer dereference because the quirk_count has been counted as 1 while the quirk_list was failed to allocate. i.e., [ 1.044970] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1.044995] IP: [] usb_detect_quirks+0x88/0xd1 [ 1.045016] PGD 0 [ 1.045026] Oops: 0000 [#1] PREEMPT SMP [ 1.046986] gsmi: Log Shutdown Reason 0x03 [ 1.046995] Modules linked in: [ 1.047008] CPU: 0 PID: 81 Comm: kworker/0:3 Not tainted 4.4.154 #28 [ 1.047016] Hardware name: Google Coral/Coral, BIOS Google_Coral.10068.27.0 12/04/2017 [ 1.047028] Workqueue: usb_hub_wq hub_event [ 1.047037] task: ffff88017a321c80 task.stack: ffff88017a384000 [ 1.047044] RIP: 0010:[] [] usb_detect_quirks+0x88/0xd1 To tackle this odd, let's balance the quirk_count to 0 when the kcalloc call fails, and defer the quirk setting into a lower level callback which ensures that the kernel memory management has been initialized. Fixes: 027bd6cafd9a ("usb: core: Add "quirks" parameter for usbcore") Signed-off-by: Harry Pan Acked-by: Kai-Heng Feng Cc: stable Signed-off-by: Greg Kroah-Hartman commit 7b169e33a3bc9040e06988b2bc15e83d2af80358 Author: Heikki Krogerus Date: Wed Sep 19 10:58:05 2018 +0300 usb: roles: Take care of driver module reference counting commit 5c54fcac9a9de559b444ac63ec3cd82f1d157a0b upstream. This fixes potential "BUG: unable to handle kernel paging request at ..." from happening. Cc: Acked-by: Hans de Goede Tested-by: Hans de Goede Signed-off-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 95b273c4038cc3f9c2fb5e24fedd3484500c536a Author: Alan Stern Date: Mon Sep 10 14:00:53 2018 -0400 USB: handle NULL config in usb_find_alt_setting() commit c9a4cb204e9eb7fa7dfbe3f7d3a674fa530aa193 upstream. usb_find_alt_setting() takes a pointer to a struct usb_host_config as an argument; it searches for an interface with specified interface and alternate setting numbers in that config. However, it crashes if the usb_host_config pointer argument is NULL. Since this is a general-purpose routine, available for use in many places, we want to to be more robust. This patch makes it return NULL whenever the config argument is NULL. Signed-off-by: Alan Stern Reported-by: syzbot+19c3aaef85a89d451eac@syzkaller.appspotmail.com CC: Signed-off-by: Greg Kroah-Hartman commit f3a6a40b3793168f1f342aa7f2d97c82c97f24b6 Author: Alan Stern Date: Mon Sep 10 13:59:59 2018 -0400 USB: fix error handling in usb_driver_claim_interface() commit bd729f9d67aa9a303d8925bb8c4f06af25f407d1 upstream. The syzbot fuzzing project found a use-after-free bug in the USB core. The bug was caused by usbfs not unbinding from an interface when the USB device file was closed, which led another process to attempt the unbind later on, after the private data structure had been deallocated. The reason usbfs did not unbind the interface at the appropriate time was because it thought the interface had never been claimed in the first place. This was caused by the fact that usb_driver_claim_interface() does not clean up properly when device_bind_driver() returns an error. Although the error code gets passed back to the caller, the iface->dev.driver pointer remains set and iface->condition remains equal to USB_INTERFACE_BOUND. This patch adds proper error handling to usb_driver_claim_interface(). Signed-off-by: Alan Stern Reported-by: syzbot+f84aa7209ccec829536f@syzkaller.appspotmail.com CC: Signed-off-by: Greg Kroah-Hartman commit 2c2860d0e8764e07c3016742eed8cb059c78d224 Author: Marek Szyprowski Date: Mon Sep 3 16:49:37 2018 +0200 regulator: Fix 'do-nothing' value for regulators without suspend state commit 3edd79cf5a44b12dbb13bc320f5788aed6562b36 upstream. Some regulators don't have all states defined and in such cases regulator core should not assume anything. However in current implementation of of_get_regulation_constraints() DO_NOTHING_IN_SUSPEND enable value was set only for regulators which had suspend node defined, otherwise the default 0 value was used, what means DISABLE_IN_SUSPEND. This lead to broken system suspend/resume on boards, which had simple regulator constraints definition (without suspend state nodes). To avoid further mismatches between the default and uninitialized values of the suspend enabled/disabled states, change the values of the them, so default '0' means DO_NOTHING_IN_SUSPEND. Fixes: 72069f9957a1: regulator: leave one item to record whether regulator is enabled Signed-off-by: Marek Szyprowski Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ad023c0c3613e517d21ad95b6f8572503db6e3bd Author: Yu Zhao Date: Wed Sep 19 15:30:51 2018 -0600 regulator: fix crash caused by null driver data commit fb6de923ca3358a91525552b4907d4cb38730bdd upstream. dev_set_drvdata() needs to be called before device_register() exposes device to userspace. Otherwise kernel crashes after it gets null pointer from dev_get_drvdata() when userspace tries to access sysfs entries. [Removed backtrace for length -- broonie] Signed-off-by: Yu Zhao Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bc9f63756ac87d767abe3ff040e6f937a95da9d0 Author: Geert Uytterhoeven Date: Wed Sep 5 10:49:39 2018 +0200 spi: rspi: Fix interrupted DMA transfers commit 8dbbaa47b96f6ea5f09f922b4effff3c505cd8cf upstream. When interrupted, wait_event_interruptible_timeout() returns -ERESTARTSYS, and the SPI transfer in progress will fail, as expected: m25p80 spi0.0: SPI transfer failed: -512 spi_master spi0: failed to transfer one message from queue However, as the underlying DMA transfers may not have completed, all subsequent SPI transfers may start to fail: spi_master spi0: receive timeout qspi_transfer_out_in() returned -110 m25p80 spi0.0: SPI transfer failed: -110 spi_master spi0: failed to transfer one message from queue Fix this by calling dmaengine_terminate_all() not only for timeouts, but also for errors. This can be reproduced on r8a7991/koelsch, using "hd /dev/mtd0" followed by CTRL-C. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f9ca5597ab702405fee8138a9be7108017d72828 Author: Geert Uytterhoeven Date: Wed Sep 5 10:49:38 2018 +0200 spi: rspi: Fix invalid SPI use during system suspend commit c1ca59c22c56930b377a665fdd1b43351887830b upstream. If the SPI queue is running during system suspend, the system may lock up. Fix this by stopping/restarting the queue during system suspend/resume, by calling spi_master_suspend()/spi_master_resume() from the PM callbacks. In-kernel users will receive an -ESHUTDOWN error while system suspend/resume is in progress. Based on a patch for sh-msiof by Gaku Inami. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2469b01fa5143a88c632248283d9fee788ceceb2 Author: Hiromitsu Yamasaki Date: Wed Sep 5 10:49:37 2018 +0200 spi: sh-msiof: Fix handling of write value for SISTR register commit 31a5fae4c5a009898da6d177901d5328051641ff upstream. This patch changes writing to the SISTR register according to the H/W user's manual. The TDREQ bit and RDREQ bits of SISTR are read-only, and must be written their initial values of zero. Signed-off-by: Hiromitsu Yamasaki [geert: reword] Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 38274415d1180966c082c2db8cb0faabc626f8e6 Author: Gaku Inami Date: Wed Sep 5 10:49:36 2018 +0200 spi: sh-msiof: Fix invalid SPI use during system suspend commit ffa69d6a16f686efe45269342474e421f2aa58b2 upstream. If the SPI queue is running during system suspend, the system may lock up. Fix this by stopping/restarting the queue during system suspend/resume by calling spi_master_suspend()/spi_master_resume() from the PM callbacks. In-kernel users will receive an -ESHUTDOWN error while system suspend/resume is in progress. Signed-off-by: Gaku Inami Signed-off-by: Hiromitsu Yamasaki [geert: Cleanup, reword] Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a2b9280113522c7a7608c02933bc66da3e87da84 Author: Marcel Ziswiler Date: Wed Aug 29 08:47:57 2018 +0200 spi: tegra20-slink: explicitly enable/disable clock commit 7001cab1dabc0b72b2b672ef58a90ab64f5e2343 upstream. Depending on the SPI instance one may get an interrupt storm upon requesting resp. interrupt unless the clock is explicitly enabled beforehand. This has been observed trying to bring up instance 4 on T20. Signed-off-by: Marcel Ziswiler Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 825e12a2ed63cb166648a03d0a83f15e8ebc2760 Author: Alexander Shishkin Date: Tue Sep 18 16:10:48 2018 +0300 intel_th: Fix resource handling for ACPI glue layer commit ebe4582281d6e90972f057318a6edea14810ea48 upstream. The core of the driver expects the resource array from the glue layer to be indexed by even numbers, as is the case for 64-bit PCI resources. This doesn't hold true for others, ACPI in this instance, which leads to an out-of-bounds access and an ioremap() on whatever address that access fetches. This patch fixes the problem by reading resource array differently based on whether the 64-bit flag is set, which would indicate PCI glue layer. Signed-off-by: Alexander Shishkin Fixes: ebc57e399b8e ("intel_th: Add ACPI glue layer") CC: stable@vger.kernel.org # v4.17+ Signed-off-by: Greg Kroah-Hartman commit c3b92e93b23a1b6fed026acc39a8fef715bb9e4e Author: Alexander Shishkin Date: Tue Sep 18 16:10:47 2018 +0300 intel_th: Fix device removal logic commit 8801922cd94c918e4dc3a108ecaa500c4d40583f upstream. Commit a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices") brings in new subdevice addition/removal logic that's broken for "host mode": the SWITCH device has no children to begin with, which is not handled in the code. This results in a null dereference bug later down the path. This patch fixes the subdevice removal code to handle host mode correctly. Signed-off-by: Alexander Shishkin Fixes: a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices") CC: stable@vger.kernel.org # v4.14+ Signed-off-by: Greg Kroah-Hartman commit 98e1a83c338e4f3377c842ee7d60a5c36a30f0b3 Author: Christophe Leroy Date: Fri Sep 14 10:32:50 2018 +0000 serial: cpm_uart: return immediately from console poll commit be28c1e3ca29887e207f0cbcd294cefe5074bab6 upstream. kgdb expects poll function to return immediately and returning NO_POLL_CHAR when no character is available. Fixes: f5316b4aea024 ("kgdb,8250,pl011: Return immediately from console poll") Cc: Jason Wessel Cc: Signed-off-by: Christophe Leroy Signed-off-by: Greg Kroah-Hartman commit e91bf9073b44f3be71b80687a58e8fc1e8d25dd1 Author: Jan Kiszka Date: Sun Aug 26 19:49:32 2018 +0200 serial: mvebu-uart: Fix reporting of effective CSIZE to userspace commit e0bf2d4982fe7d9ddaf550dd023803ea286f47fc upstream. Apparently, this driver (or the hardware) does not support character length settings. It's apparently running in 8-bit mode, but it makes userspace believe it's in 5-bit mode. That makes tcsetattr with CS8 incorrectly fail, breaking e.g. getty from busybox, thus the login shell on ttyMVx. Fix by hard-wiring CS8 into c_cflag. Signed-off-by: Jan Kiszka Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port") Cc: stable # 4.6+ Signed-off-by: Greg Kroah-Hartman commit 5d554763aaac8009646301fd14b05607ec01d965 Author: Uwe Kleine-König Date: Thu Sep 20 14:11:17 2018 +0200 serial: imx: restore handshaking irq for imx1 commit 7e620984b62532783912312e334f3c48cdacbd5d upstream. Back in 2015 when irda was dropped from the driver imx1 was broken. This change reintroduces the support for the third interrupt of the UART. Fixes: afe9cbb1a6ad ("serial: imx: drop support for IRDA") Cc: stable Signed-off-by: Uwe Kleine-König Reviewed-by: Leonard Crestez Signed-off-by: Greg Kroah-Hartman commit 98ecfdf49ff73c87a5ab8fa7ba1f22db67da6f29 Author: Stefan Agner Date: Tue Aug 28 12:44:24 2018 +0200 tty: serial: lpuart: avoid leaking struct tty_struct commit 3216c622a24b0ebb9c159a8d1daf7f17a106b3f5 upstream. The function tty_port_tty_get() gets a reference to the tty. Since the code is not using tty_port_tty_set(), the reference is kept even after closing the tty. Avoid using tty_port_tty_get() by directly access the tty instance. Since lpuart_start_rx_dma() is called from the .startup() and .set_termios() callback, it is safe to assume the tty instance is valid. Cc: stable@vger.kernel.org # v4.9+ Fixes: 5887ad43ee02 ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx") Signed-off-by: Stefan Agner Signed-off-by: Greg Kroah-Hartman commit fdbbdfeeb699535138be3274c615233c1af42aac Author: Feng Tang Date: Thu Sep 20 10:58:28 2018 +0800 x86/mm: Expand static page table for fixmap space commit 05ab1d8a4b36ee912b7087c6da127439ed0a903e upstream. We met a kernel panic when enabling earlycon, which is due to the fixmap address of earlycon is not statically setup. Currently the static fixmap setup in head_64.S only covers 2M virtual address space, while it actually could be in 4M space with different kernel configurations, e.g. when VSYSCALL emulation is disabled. So increase the static space to 4M for now by defining FIXMAP_PMD_NUM to 2, and add a build time check to ensure that the fixmap is covered by the initial static page tables. Fixes: 1ad83c858c7d ("x86_64,vsyscall: Make vsyscall emulation configurable") Suggested-by: Thomas Gleixner Signed-off-by: Feng Tang Signed-off-by: Thomas Gleixner Tested-by: kernel test robot Reviewed-by: Juergen Gross (Xen parts) Cc: H Peter Anvin Cc: Peter Zijlstra Cc: Michal Hocko Cc: Yinghai Lu Cc: Dave Hansen Cc: Andi Kleen Cc: Andy Lutomirsky Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180920025828.23699-1-feng.tang@intel.com Signed-off-by: Greg Kroah-Hartman commit 41a770d90b88f1aec1796f931973a6a3ba368234 Author: Damien Le Moal Date: Thu Sep 27 10:55:13 2018 +0900 block: fix deadline elevator drain for zoned block devices commit 854f31ccdd7964c9c2e68da234a3a8aedb51cf6b upstream. When the deadline scheduler is used with a zoned block device, writes to a zone will be dispatched one at a time. This causes the warning message: deadline: forced dispatching is broken (nr_sorted=X), please report this to be displayed when switching to another elevator with the legacy I/O path while write requests to a zone are being retained in the scheduler queue. Prevent this message from being displayed when executing elv_drain_elevator() for a zoned block device. __blk_drain_queue() will loop until all writes are dispatched and completed, resulting in the desired elevator queue drain without extensive modifications to the deadline code itself to handle forced-dispatch calls. Signed-off-by: Damien Le Moal Fixes: 8dc8146f9c92 ("deadline-iosched: Introduce zone locking support") Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0051646c2cc2fbb9ff134a80775c0dc23baa7d35 Author: Andy Whitcroft Date: Thu Sep 20 09:09:48 2018 -0600 floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl commit 65eea8edc315589d6c993cf12dbb5d0e9ef1fe4e upstream. The final field of a floppy_struct is the field "name", which is a pointer to a string in kernel memory. The kernel pointer should not be copied to user memory. The FDGETPRM ioctl copies a floppy_struct to user memory, including this "name" field. This pointer cannot be used by the user and it will leak a kernel address to user-space, which will reveal the location of kernel code and data and undermine KASLR protection. Model this code after the compat ioctl which copies the returned data to a previously cleared temporary structure on the stack (excluding the name pointer) and copy out to userspace from there. As we already have an inparam union with an appropriate member and that memory is already cleared even for read only calls make use of that as a temporary store. Based on an initial patch by Brian Belleville. CVE-2018-7755 Signed-off-by: Andy Whitcroft Broke up long line. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit acee207b7cc92b3f057086e1df972b3020caa54a Author: Dmitry Osipenko Date: Tue Jul 17 19:10:38 2018 +0300 gpio: tegra: Fix tegra_gpio_irq_set_type() [ Upstream commit f78709a5d4114edc21a5d86586ed5e56e284f2bd ] Commit 36b312792b97 ("gpiolib: Respect error code of ->get_direction()") broke tegra_gpio_irq_set_type() because requesting of GPIO direction must be done after enabling GPIO function for a pin. This patch fixes drivers probe failure like this: gpio gpiochip0: (tegra-gpio): gpiochip_lock_as_irq: cannot get GPIO direction tegra-gpio 6000d000.gpio: unable to lock Tegra GPIO 144 as IRQ Fixes: 36b312792b97 ("gpiolib: Respect error code of ->get_direction()") Signed-off-by: Dmitry Osipenko Acked-by: Jon Hunter Tested-by: Jon Hunter Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dbb2a1e3bb371c9e757a47e68045513599409c83 Author: Sandipan Das Date: Thu Jul 26 22:47:33 2018 +0530 perf tests: Fix indexing when invoking subtests [ Upstream commit aa90f9f9554616d5738f7bedb4a8f0e5e14d1bc6 ] Recently, the subtest numbering was changed to start from 1. While it is fine for displaying results, this should not be the case when the subtests are actually invoked. Typically, the subtests are stored in zero-indexed arrays and invoked based on the index passed to the main test function. Since the index now starts from 1, the second subtest in the array (index 1) gets invoked instead of the first (index 0). This applies to all of the following subtests but for the last one, the subtest always fails because it does not meet the boundary condition of the subtest index being lesser than the number of subtests. This can be observed on powerpc64 and x86_64 systems running Fedora 28 as shown below. Before: # perf test "builtin clang support" 55: builtin clang support : 55.1: builtin clang compile C source to IR : Ok 55.2: builtin clang compile C source to ELF object : FAILED! # perf test "LLVM search and compile" 38: LLVM search and compile : 38.1: Basic BPF llvm compile : Ok 38.2: kbuild searching : Ok 38.3: Compile source for BPF prologue generation : Ok 38.4: Compile source for BPF relocation : FAILED! # perf test "BPF filter" 40: BPF filter : 40.1: Basic BPF filtering : Ok 40.2: BPF pinning : Ok 40.3: BPF prologue generation : Ok 40.4: BPF relocation checker : FAILED! After: # perf test "builtin clang support" 55: builtin clang support : 55.1: builtin clang compile C source to IR : Ok 55.2: builtin clang compile C source to ELF object : Ok # perf test "LLVM search and compile" 38: LLVM search and compile : 38.1: Basic BPF llvm compile : Ok 38.2: kbuild searching : Ok 38.3: Compile source for BPF prologue generation : Ok 38.4: Compile source for BPF relocation : Ok # perf test "BPF filter" 40: BPF filter : 40.1: Basic BPF filtering : Ok 40.2: BPF pinning : Ok 40.3: BPF prologue generation : Ok 40.4: BPF relocation checker : Ok Signed-off-by: Sandipan Das Reported-by: Arnaldo Carvalho de Melo Tested-by: Arnaldo Carvalho de Melo Cc: Heiko Carstens Cc: Hendrik Brueckner Cc: Jiri Olsa Cc: Martin Schwidefsky Cc: Naveen N. Rao Cc: Ravi Bangoria Cc: Thomas Richter Fixes: 9ef0112442bd ("perf test: Fix subtest number when showing results") Link: http://lkml.kernel.org/r/20180726171733.33208-1-sandipan@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6b07342e25961dbd483671c130cc85603462806a Author: Maxime Ripard Date: Thu May 17 15:37:59 2018 +0200 drm/vc4: plane: Expand the lower bits by repeating the higher bits [ Upstream commit 3257ec797d3a8c5232389eb1952d4451e80f3931 ] The vc4 HVS uses an internal RGB888 representation of the frames, and will by default expand formats using a lower depth using zeros. This causes an issue when we try to use other compositing software such as pixman that fill the missing bits by repeating the higher significant bits. As such, we can't check the display output in a reliable way by doing a software composition and an hardware one and compare both. To prevent this, force the same behaviour so that we can do such things. Signed-off-by: Maxime Ripard Signed-off-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20180517133759.25626-1-maxime.ripard@bootlin.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c94ce4bf1aff06fef71b83000255920018824f17 Author: Kevin Hilman Date: Mon May 21 13:08:32 2018 -0700 ARM: dts: dra7: fix DCAN node addresses [ Upstream commit 949bdcc8a97c6078f21c8d4966436b117f2e4cd3 ] Fix the DT node addresses to match the reg property addresses, which were verified to match the TRM: http://www.ti.com/lit/pdf/sprui30 Cc: Roger Quadros Signed-off-by: Kevin Hilman Acked-by: Roger Quadros Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e80225d36dca7c1897dc3b6107ee9ee87fafc9a4 Author: Eric Anholt Date: Fri Mar 16 15:04:34 2018 -0700 drm/vc4: Add missing formats to vc4_format_mod_supported(). [ Upstream commit 1e871d65e375280757833d9fce91dda71980bdf5 ] Daniel's format_mod_supported() patch predated Dave's for NV21/61, and I didn't catch that when rebasing. This is a problem since the formats are now getting validated before being passed to the driver's atomic hooks. Signed-off-by: Eric Anholt Acked-by: Daniel Stone Cc: Dave Stevenson Fixes: 423ad7b3cbd1 ("drm/vc4: Advertise supported modifiers for planes") Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-2-eric@anholt.net Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 70b914929ad741cc27c0236819ca0d36badcb1fe Author: William Breathitt Gray Date: Thu May 24 16:37:46 2018 -0400 iio: 104-quad-8: Fix off-by-one error in register selection [ Upstream commit 2873c3f0e2bd12a7612e905c920c058855f4072a ] The reset flags operation is selected by bit 2 in the "Reset and Load Signals Decoders" register, not bit 1. Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8") Signed-off-by: William Breathitt Gray Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b6b75c81c31abf2353829e1c68c9157baab60657 Author: Oleksandr Andrushchenko Date: Tue Jun 12 15:03:36 2018 -0700 Input: xen-kbdfront - fix multi-touch XenStore node's locations [ Upstream commit ce6f7d087e2b037f47349c1c36ac97678d02e394 ] kbdif protocol describes multi-touch device parameters as a part of frontend's XenBus configuration nodes while they belong to backend's configuration. Fix this by reading the parameters as defined by the protocol. Fixes: 49aac8204da5 ("Input: xen-kbdfront - add multi-touch support") Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Juergen Gross Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 31a92226a5d59a8538de9fd9a804a75a7ec1d3bd Author: Colin Ian King Date: Sun May 27 22:17:02 2018 +0100 ath10k: fix memory leak of tpc_stats [ Upstream commit 260e629bbf441585860e21d5e10d2e88437f47c8 ] Currently tpc_stats is allocated and is leaked on the return path if num_tx_chain is greater than WMI_TPC_TX_N_CHAIN. Avoid this leak by performing the check on num_tx_chain before the allocation of tpc_stats. Detected by CoverityScan, CID#1469422 ("Resource Leak") Fixes: 4b190675ad06 ("ath10k: fix kernel panic while reading tpc_stats") Signed-off-by: Colin Ian King Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f2391032c06f71ced9b6cf15226368c50b8a99c Author: Konstantin Khorenko Date: Fri Jun 8 17:27:11 2018 +0300 fs/lock: skip lock owner pid translation in case we are in init_pid_ns [ Upstream commit 826d7bc9f013d01e92997883d2fd0c25f4af1f1c ] If the flock owner process is dead and its pid has been already freed, pid translation won't work, but we still want to show flock owner pid number when expecting /proc/$PID/fdinfo/$FD in init pidns. Reproducer: process A process A1 process A2 fork()---------> exit() open() flock() fork()---------> exit() sleep() Before the patch: ================ (root@vz7)/: cat /proc/${PID_A2}/fdinfo/3 pos: 4 flags: 02100002 mnt_id: 257 lock: (root@vz7)/: After the patch: =============== (root@vz7)/:cat /proc/${PID_A2}/fdinfo/3 pos: 4 flags: 02100002 mnt_id: 295 lock: 1: FLOCK ADVISORY WRITE ${PID_A1} b6:f8a61:529946 0 EOF Fixes: 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific l_pid for remote locks") Signed-off-by: Konstantin Khorenko Acked-by: Andrey Vagin Reviewed-by: Benjamin Coddington Signed-off-by: Jeff Layton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 00b438869cbe414d9a92419dcf702a0a74b679c5 Author: Brian Norris Date: Mon Jun 11 14:09:43 2018 -0700 ath10k: snoc: use correct bus-specific pointer in RX retry [ Upstream commit 426a0f0b5a2fe1df3496ba299ee3521159dba302 ] We're 'ath10k_snoc', not 'ath10k_pci'. This probably means we're accessing junk data in ath10k_snoc_rx_replenish_retry(), unless 'ath10k_snoc' and 'ath10k_pci' happen to have very similar struct layouts. Noticed by inspection. Fixes: d915105231ca ("ath10k: add hif rx methods for wcn3990") Signed-off-by: Brian Norris Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 06c21f7423e7eabbe85dd18d4de8e9f6bc69400d Author: YueHaibing Date: Fri Jun 1 19:25:48 2018 +0800 ath10k: fix incorrect size of dma_free_coherent in ath10k_ce_alloc_src_ring_64 [ Upstream commit 5a211627004e2cddd0ab8b9df19e5fb0bbe97634 ] sizeof(struct ce_desc) should be a copy-paste mistake just use sizeof(struct ce_desc_64) to avoid mem leak Fixes: b7ba83f7c414 ("ath10k: add support for shadow register for WNC3990") Signed-off-by: YueHaibing Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10db0e22fb8c50db736e5294af33fae43e950fe6 Author: Hugo Lefeuvre Date: Wed Jun 13 21:04:38 2018 -0400 staging: pi433: fix race condition in pi433_ioctl [ Upstream commit 6de4ef65a8c6f53ce7eef06666410bc3b6e4b624 ] In the PI433_IOC_WR_TX_CFG case in pi433_ioctl, instance->tx_cfg is modified via copy_from_user(&instance->tx_cfg, argp, sizeof(struct pi433_tx_cfg))) without any kind of synchronization. In the case where two threads would execute this same command concurrently the tx_cfg field might enter in an inconsistent state. Additionally: if ioctl(PI433_IOC_WR_TX_CFG) and write() execute concurrently the tx config might be modified while it is being copied to the fifo, resulting in potential data corruption. Fix: Get instance->tx_cfg_lock before modifying tx config in the PI433_IOC_WR_TX_CFG case in pi433_ioctl. Also, do not copy data directly from user space to instance->tx_cfg. Instead use a temporary buffer allowing future checks for correctness of copied data and simpler code. Signed-off-by: Hugo Lefeuvre Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fff64d9fb3817fee88ce211bd4fef94558d877be Author: Christophe JAILLET Date: Sun Jun 10 19:45:32 2018 +0200 EDAC, altera: Fix an error handling path in altr_s10_sdram_probe() [ Upstream commit 9d72fe1ce81bc757ecb6d57b58e5fd95b9ad1b26 ] If regmap_write() fails, we should release some resources as done in all the other error handling paths of the function. Signed-off-by: Christophe JAILLET Reviewed-by: Thor Thayer Cc: linux-edac Link: http://lkml.kernel.org/r/20180610174532.22071-1-christophe.jaillet@wanadoo.fr Fixes: e9918d7fafae ("EDAC, altera: Handle SDRAM Uncorrectable Errors on Stratix10") Signed-off-by: Borislav Petkov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0855e6e1ac14f7e7f742e70bf9bbc6a1cdf0769e Author: Johan Hovold Date: Tue Jun 12 14:43:34 2018 +0200 EDAC: Fix memleak in module init error path [ Upstream commit 4708aa85d50cc6e962dfa8acf5ad4e0d290a21db ] Make sure to use put_device() to free the initialised struct device so that resources managed by driver core also gets released in the event of a registration failure. Signed-off-by: Johan Hovold Cc: Denis Kirjanov Cc: Mauro Carvalho Chehab Cc: linux-edac Fixes: 2d56b109e3a5 ("EDAC: Handle error path in edac_mc_sysfs_init() properly") Link: http://lkml.kernel.org/r/20180612124335.6420-1-johan@kernel.org Signed-off-by: Borislav Petkov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6e67b33dbe432215868bbfb57dfff90d18347409 Author: J. Bruce Fields Date: Wed Jun 13 15:21:35 2018 -0400 nfsd: fix corrupted reply to badly ordered compound [ Upstream commit 5b7b15aee641904ae269be9846610a3950cbd64c ] We're encoding a single op in the reply but leaving the number of ops zero, so the reply makes no sense. Somewhat academic as this isn't a case any real client will hit, though in theory perhaps that could change in a future protocol extension. Reviewed-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af4b12c54b3be0d46bffdba1debb811270784110 Author: Nadav Amit Date: Mon Jun 4 06:58:14 2018 -0700 gpio: Fix wrong rounding in gpio-menz127 [ Upstream commit 7279d9917560bbd0d82813d6bf00490a82c06783 ] men_z127_debounce() tries to round up and down, but uses functions which are only suitable when the divider is a power of two, which is not the case. Use the appropriate ones. Found by static check. Compile tested. Fixes: f436bc2726c64 ("gpio: add driver for MEN 16Z127 GPIO controller") Signed-off-by: Nadav Amit Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8463cd689be0bf1d27a34ef00a8ffe63c1d89c02 Author: Jessica Yu Date: Tue Jun 5 10:22:52 2018 +0200 module: exclude SHN_UNDEF symbols from kallsyms api [ Upstream commit 9f2d1e68cf4d641def734adaccfc3823d3575e6c ] Livepatch modules are special in that we preserve their entire symbol tables in order to be able to apply relocations after module load. The unwanted side effect of this is that undefined (SHN_UNDEF) symbols of livepatch modules are accessible via the kallsyms api and this can confuse symbol resolution in livepatch (klp_find_object_symbol()) and cause subtle bugs in livepatch. Have the module kallsyms api skip over SHN_UNDEF symbols. These symbols are usually not available for normal modules anyway as we cut down their symbol tables to just the core (non-undefined) symbols, so this should really just affect livepatch modules. Note that this patch doesn't affect the display of undefined symbols in /proc/kallsyms. Reported-by: Josh Poimboeuf Tested-by: Josh Poimboeuf Reviewed-by: Josh Poimboeuf Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 163ac07ff0b29ba45e1e0dd39fe520adee472118 Author: Liam Girdwood Date: Thu Jun 14 20:26:42 2018 +0100 ASoC: dapm: Fix potential DAI widget pointer deref when linking DAIs [ Upstream commit e01b4f624278d5efe5fb5da585ca371947b16680 ] Sometime a component or topology may configure a DAI widget with no private data leading to a dev_dbg() dereferencne of this data. Fix this to check for non NULL private data and let users know if widget is missing DAI. Signed-off-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2edaabf0e58dda612c5096bf925749dd10681e4a Author: Johan Hovold Date: Tue Jun 12 14:43:35 2018 +0200 EDAC, i7core: Fix memleaks and use-after-free on probe and remove [ Upstream commit 6c974d4dfafe5e9ee754f2a6fba0eb1864f1649e ] Make sure to free and deregister the addrmatch and chancounts devices allocated during probe in all error paths. Also fix use-after-free in a probe error path and in the remove success path where the devices were being put before before deregistration. Signed-off-by: Johan Hovold Cc: Mauro Carvalho Chehab Cc: linux-edac Fixes: 356f0a30860d ("i7core_edac: change the mem allocation scheme to make Documentation/kobject.txt happy") Link: http://lkml.kernel.org/r/20180612124335.6420-2-johan@kernel.org Signed-off-by: Borislav Petkov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1e4b176959fb817a3bbf6bc74310ba4a13ef39ae Author: Kuninori Morimoto Date: Tue Jun 12 05:52:17 2018 +0000 ASoC: rsnd: SSI parent cares SWSP bit [ Upstream commit 203cdf51f28820bee7893b4be392847418e6f4ec ] SSICR has SWSP bit (= Serial WS Polarity) which decides WS pin 1st channel polarity (low or hi). This bit shouldn't exchange after running. Current SSI "parent" doesn't care SSICR, just controls clock only. Because of this behavior, if platform uses SSI0 as playback, SSI1 as capture, and if user starts capture -> playback order, SSI0 SSICR::SWSP bit exchanged 0 -> 1 during captureing, and it makes capture noise. This patch cares SSICR on SSI parent, too. Special thanks to Yokoyama-san Reported-by: Hiroyuki Yokoyama Signed-off-by: Kuninori Morimoto Tested-by: Hiroyuki Yokoyama Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d07efbdf84f47b935c8bb4e5998050375295764 Author: Geert Uytterhoeven Date: Thu Jun 7 15:50:48 2018 +0200 ASoC: rt1305: Use ULL suffixes for 64-bit constants [ Upstream commit 4f29b663c08d369fe320a148179996c94cf7d01b ] With gcc 4.1.2: sound/soc/codecs/rt1305.c: In function ‘rt1305_calibrate’: sound/soc/codecs/rt1305.c:1069: warning: integer constant is too large for ‘long’ type sound/soc/codecs/rt1305.c:1086: warning: integer constant is too large for ‘long’ type Add the missing "ULL" suffixes to fix this. Fixes: 29bc643ddd7efb74 ("ASoC: rt1305: Add RT1305/RT1306 amplifier driver") Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3e28a96b87f64bc4cbb3a254793fa609df7f2bcc Author: Hans de Goede Date: Sun Jun 3 15:42:32 2018 +0200 ASoC: Intel: bytcr_rt5640: Fix Acer Iconia 8 over-current detect threshold [ Upstream commit f12a0a3c4cc6f594d7c2ea361f2396ae5c518d2c ] Change the over-current detect threshold on the Acer Iconia 8 from 2000ua to 1500uA, this fixes headset button presses not being detected. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ebce61bb2c864c0c16bd86502e1259be385b0139 Author: Shivasharan S Date: Mon Jun 4 03:45:10 2018 -0700 scsi: megaraid_sas: Update controller info during resume [ Upstream commit c3b10a55abc943a526aaecd7e860b15671beb906 ] There is a possibility that firmware on the controller was upgraded before system was suspended. During resume, driver needs to read updated controller properties. Signed-off-by: Shivasharan S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b38977a366258758245d2e335ddc4735bbfb445c Author: Jan Kundrát Date: Mon Jun 4 16:34:25 2018 +0200 spi: orion: fix CS GPIO handling again [ Upstream commit fb9acf5f1f21f1de193523ff780bda375b4c2e21 ] The code did not de-assert any CS GPIOs before probing slaves. This means that several CS signals could be active at once, garbling the communication. Whether this was actually a problem depended on the type of the SPI device attached (so my "spidev" for userspace access worked correctly because its probe was effectively a no-op), and on the state of the GPIO pins at SoC's boot. The code was already iterating through all DT children of the SPI controller, so this change re-uses that loop for CS GPIO setup as well. This means that this might change the number of the HW CS signal which is picked for all GPIO CS devices. Previously, the lowest one was used, but we now use the first one from the DT. With this move of the code, we can also finally initialize each GPIO CS lane before registering the SPI controller (which in turn probes for slaves). I tried to fix this in 544248623b95 already, but that only did it half way by registering the GPIOs properly. That patch failed to set their logic signals early enough, though. Signed-off-by: Jan Kundrát Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d731684c4496963824fecff6f1227738bff7b165 Author: Xiaofei Tan Date: Thu May 31 20:50:44 2018 +0800 scsi: hisi_sas: Fix the conflict between dev gone and host reset [ Upstream commit d2fc401e47529d9ffd2673a5395d56002e31ad98 ] There is a possible conflict when a device is removed and host reset occurs concurrently. The reason is that then the device is notified as gone, we try to clear the ITCT, which is notified via an interrupt. The dev gone function pends on this event with a completion, which is completed when the ITCT interrupt occurs. But host reset will disable all interrupts, the wait_for_completion() may wait indefinitely. This patch adds an semaphore to synchronise this two processes. The semaphore is taken by the host reset as the basis of synchronising. Signed-off-by: Xiaofei Tan Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2f7b94ebaa193a08544809c2eef011137e5700c3 Author: Andreas Gruenbacher Date: Tue Jun 19 15:10:55 2018 -0700 iomap: complete partial direct I/O writes synchronously [ Upstream commit ebf00be37de35788cad72f4f20b4a39e30c0be4a ] According to xfstest generic/240, applications seem to expect direct I/O writes to either complete as a whole or to fail; short direct I/O writes are apparently not appreciated. This means that when only part of an asynchronous direct I/O write succeeds, we can either fail the entire write, or we can wait for the partial write to complete and retry the remaining write as buffered I/O. The old __blockdev_direct_IO helper has code for waiting for partial writes to complete; the new iomap_dio_rw iomap helper does not. The above mentioned fallback mode is needed for gfs2, which doesn't allow block allocations under direct I/O to avoid taking cluster-wide exclusive locks. As a consequence, an asynchronous direct I/O write to a file range that contains a hole will result in a short write. In that case, wait for the short write to complete to allow gfs2 to recover. Signed-off-by: Andreas Gruenbacher Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 939dd916dc25cb110c798fd427d39ade5b40b1ca Author: Zhouyang Jia Date: Tue Jun 12 11:13:00 2018 +0800 scsi: bnx2i: add error handling for ioremap_nocache [ Upstream commit aa154ea885eb0c2407457ce9c1538d78c95456fa ] When ioremap_nocache fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling ioremap_nocache. Signed-off-by: Zhouyang Jia Reviewed-by: Johannes Thumshirn Acked-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 074e4687846ed41ec2c9d0b34ebb0632961f75d2 Author: Kan Liang Date: Tue Jun 5 08:38:45 2018 -0700 perf/x86/intel/lbr: Fix incomplete LBR call stack [ Upstream commit 0592e57b24e7e05ec1f4c50b9666c013abff7017 ] LBR has a limited stack size. If a task has a deeper call stack than LBR's stack size, only the overflowed part is reported. A complete call stack may not be reconstructed by perf tool. Current code doesn't access all LBR registers. It only read the ones below the TOS. The LBR registers above the TOS will be discarded unconditionally. When a CALL is captured, the TOS is incremented by 1 , modulo max LBR stack size. The LBR HW only records the call stack information to the register which the TOS points to. It will not touch other LBR registers. So the registers above the TOS probably still store the valid call stack information for an overflowed call stack, which need to be reported. To retrieve complete call stack information, we need to start from TOS, read all LBR registers until an invalid entry is detected. 0s can be used to detect the invalid entry, because: - When a RET is captured, the HW zeros the LBR register which TOS points to, then decreases the TOS. - The LBR registers are reset to 0 when adding a new LBR event or scheduling an existing LBR event. - A taken branch at IP 0 is not expected The context switch code is also modified to save/restore all valid LBR registers. Furthermore, the LBR registers, which don't have valid call stack information, need to be reset in restore, because they may be polluted while swapped out. Here is a small test program, tchain_deep. Its call stack is deeper than 32. noinline void f33(void) { int i; for (i = 0; i < 10000000;) { if (i%2) i++; else i++; } } noinline void f32(void) { f33(); } noinline void f31(void) { f32(); } ... ... noinline void f1(void) { f2(); } int main() { f1(); } Here is the test result on SKX. The max stack size of SKX is 32. Without the patch: $ perf record -e cycles --call-graph lbr -- ./tchain_deep $ perf report --stdio # # Children Self Command Shared Object Symbol # ........ ........ ........... ................ ................. # 100.00% 99.99% tchain_deep tchain_deep [.] f33 | --99.99%--f30 f31 f32 f33 With the patch: $ perf record -e cycles --call-graph lbr -- ./tchain_deep $ perf report --stdio # Children Self Command Shared Object Symbol # ........ ........ ........... ................ .................. # 99.99% 0.00% tchain_deep tchain_deep [.] f1 | ---f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 f13 f14 f15 f16 f17 f18 f19 f20 f21 f22 f23 f24 f25 f26 f27 f28 f29 f30 f31 f32 f33 Signed-off-by: Kan Liang Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Stephane Eranian Cc: Vince Weaver Cc: Alexander Shishkin Cc: Thomas Gleixner Cc: acme@kernel.org Cc: eranian@google.com Link: https://lore.kernel.org/lkml/1528213126-4312-1-git-send-email-kan.liang@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09468e65ec7db8d002102143ea0d94bc4e7f3786 Author: Eric Anholt Date: Wed Jun 6 10:48:51 2018 -0700 drm/v3d: Take a lock across GPU scheduler job creation and queuing. [ Upstream commit 7122b68b8a9692dcc3acf89595f04c492872115f ] Between creation and queueing of a job, you need to prevent any other job from being created and queued. Otherwise the scheduler's fences may be signaled out of seqno order. v2: move mutex unlock to the error label. Signed-off-by: Eric Anholt Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Link: https://patchwork.freedesktop.org/patch/msgid/20180606174851.12433-1-eric@anholt.net Reviewed-by: Lucas Stach Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dbdef3dff35bcdef02521d6ab1c9ace112f0417b Author: Laurent Pinchart Date: Fri Jun 8 15:21:15 2018 +0300 arm64: dts: renesas: Fix VSPD registers range [ Upstream commit e21adc781bb45e810f1c396c4bc2c1624a4c25b9 ] The VSPD and FCPVD nodes have overlapping register ranges, as the FCPVD devices are mapped in the memory range usually used by the VSP LUT and CLU, which are not present in the VSPD. Fix this by shortening the VSPD registers range to 0x5000. Fixes: 9f8573e38a0b ("arm64: dts: renesas: r8a7795: Add VSP instances") Fixes: 291e0c4994d0 ("arm64: dts: r8a7795: Add support for R-Car H3 ES2.0") Fixes: f06ffdfbdd90 ("arm64: dts: r8a7796: Add VSP instances") Fixes: b4f92030d5d3 ("arm64: dts: renesas: r8a77970: add VSPD support") Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances") Fixes: 85cb3229218a ("arm64: dts: renesas: r8a77965: Add VSP instances") Reported-by: Simon Horman Reported-by: Geert Uytterhoeven Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven Signed-off-by: Simon Horman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 56984081650a02cc326f9abecad027fc28279f00 Author: Masahiro Yamada Date: Mon Apr 16 23:47:43 2018 +0900 MIPS: boot: fix build rule of vmlinux.its.S [ Upstream commit 67e09db507db3e1642ddce512a4313d20addd6e5 ] As Documentation/kbuild/makefile.txt says, it is a typical mistake to forget the FORCE prerequisite for the rule invoked by if_changed. Add the FORCE to the prerequisite, but it must be filtered-out from the files passed to the 'cat' command. Because this rule generates .vmlinux.its.S.cmd, vmlinux.its.S must be specified as targets so that the .cmd file is included. Signed-off-by: Masahiro Yamada Patchwork: https://patchwork.linux-mips.org/patch/19097/ Signed-off-by: Paul Burton Cc: Kees Cook Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d0f7fbdb1cf98e37b3c61b503d41578517cede1c Author: Stephen Boyd Date: Thu Jun 21 19:27:16 2018 -0700 HID: i2c-hid: Use devm to allocate i2c_hid struct [ Upstream commit d6f83894110de247a81392ab7ef89e5498df7e80 ] Use devm here to save some lines and prepare for bulk regulator usage in this driver. Otherwise, when we devm bulk get regulators we'll free the containing i2c_hid structure and try to put regulator pointers from freed memory. Cc: Benjamin Tissoires Cc: Hans de Goede Cc: Andy Shevchenko Cc: Dmitry Torokhov Cc: Doug Anderson Signed-off-by: Stephen Boyd Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 46066a10dd7acaedfb681c878ed483e5d641fb72 Author: Zhouyang Jia Date: Thu Jun 14 21:37:17 2018 +0800 HID: hid-ntrig: add error handling for sysfs_create_group [ Upstream commit 44d4d51de9a3534a2b63d69efda02a10e66541e4 ] When sysfs_create_group fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling sysfs_create_group. Signed-off-by: Zhouyang Jia Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d79cdff5728575d95f6cbdcda62fc5936abc8698 Author: Viresh Kumar Date: Fri May 25 16:01:49 2018 +0530 arm: dts: mediatek: Add missing cooling device properties for CPUs [ Upstream commit 0c7f7a5150023f3c6f0b27c4d4940ce3dfaf62cc ] The cooling device properties, like "#cooling-cells" and "dynamic-power-coefficient", should either be present for all the CPUs of a cluster or none. If these are present only for a subset of CPUs of a cluster then things will start falling apart as soon as the CPUs are brought online in a different order. For example, this will happen because the operating system looks for such properties in the CPU node it is trying to bring up, so that it can register a cooling device. Add such missing properties. Signed-off-by: Viresh Kumar Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 65470af8b10d9522aa4045cb2f587ede860bb1b0 Author: Frederic Weisbecker Date: Tue Jun 26 04:58:48 2018 +0200 perf/hw_breakpoint: Split attribute parse and commit [ Upstream commit 9a4903dde2c8633c5fcf887b98c4e047a6154a54 ] arch_validate_hwbkpt_settings() mixes up attribute check and commit into a single code entity. Therefore the validation may return an error due to incorrect atributes while still leaving halfway modified architecture breakpoint data. This is harmless when we deal with a new breakpoint but it becomes a problem when we modify an existing breakpoint. Split attribute parse and commit to fix that. The architecture is passed a "struct arch_hw_breakpoint" to fill on top of the new attr and the core takes care about copying the backend data once it's fully validated. The architectures then need to implement the new API. Original-patch-by: Andy Lutomirski Reported-by: Linus Torvalds Signed-off-by: Frederic Weisbecker Cc: Alexander Shishkin Cc: Andy Lutomirski Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Benjamin Herrenschmidt Cc: Catalin Marinas Cc: Chris Zankel Cc: Jiri Olsa Cc: Joel Fernandes Cc: Mark Rutland Cc: Max Filippov Cc: Michael Ellerman Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Rich Felker Cc: Thomas Gleixner Cc: Will Deacon Cc: Yoshinori Sato Link: http://lkml.kernel.org/r/1529981939-8231-2-git-send-email-frederic@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7f22023170f77dedd8b622c279ccaf62377c330a Author: Randy Dunlap Date: Sat Jun 16 19:02:03 2018 -0700 Documentation/process: fix reST table border error [ Upstream commit cccd289f12d0e827070c847b1ff96ba02eb20eaf ] Fix reST error in Documentation/process/: Documentation/process/2.Process.rst:131: ERROR: Malformed table. Bottom/header table border does not match top border. Fixes: 8962e40c1993 ("docs: update kernel versions and dates in tables") Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: Tim Bird Signed-off-by: Jonathan Corbet Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 53b56e401d930d9d0ae148975c5c34f46df27b11 Author: Leon Romanovsky Date: Sun Jun 24 11:23:47 2018 +0300 RDMA/uverbs: Don't overwrite NULL pointer with ZERO_SIZE_PTR [ Upstream commit a5cc9831af05e658543593abaee45a29d061bac4 ] Number of specs is provided by user and in valid case can be equal to zero. Such argument causes to call to kcalloc() with zero-length request and in return the ZERO_SIZE_PTR is assigned. This pointer is different from NULL and makes various if (..) checks to success. Fixes: b6ba4a9aa59f ("IB/uverbs: Add support for flow counters") Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1da59841eea9bd521e1b42cb7b7eece12247019e Author: Ethan Tuttle Date: Tue Jun 19 21:31:08 2018 -0700 ARM: mvebu: declare asm symbols as character arrays in pmsu.c [ Upstream commit d0d378ff451a66e486488eec842e507d28145813 ] With CONFIG_FORTIFY_SOURCE, memcpy uses the declared size of operands to detect buffer overflows. If src or dest is declared as a char, attempts to copy more than byte will result in a fortify_panic(). Address this problem in mvebu_setup_boot_addr_wa() by declaring mvebu_boot_wa_start and mvebu_boot_wa_end as character arrays. Also remove a couple addressof operators to avoid "arithmetic on pointer to an incomplete type" compiler error. See commit 54a7d50b9205 ("x86: mark kprobe templates as character arrays, not single characters") for a similar fix. Fixes "detected buffer overflow in memcpy" error during init on some mvebu systems (armada-370-xp, armada-375): (fortify_panic) from (mvebu_setup_boot_addr_wa+0xb0/0xb4) (mvebu_setup_boot_addr_wa) from (mvebu_v7_cpu_pm_init+0x154/0x204) (mvebu_v7_cpu_pm_init) from (do_one_initcall+0x7c/0x1a8) (do_one_initcall) from (kernel_init_freeable+0x1bc/0x254) (kernel_init_freeable) from (kernel_init+0x8/0x114) (kernel_init) from (ret_from_fork+0x14/0x2c) Signed-off-by: Ethan Tuttle Tested-by: Ethan Tuttle Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3fc862c26744005261ee430450d3571d07d86458 Author: Daniel Vetter Date: Fri May 25 19:39:24 2018 +0300 drm/omap: gem: Fix mm_list locking [ Upstream commit 5117bd898e8c0a31e8ab3a9b8523aecf0706e997 ] - None of the list walkings where protected. - Switch to a mutex since the list walking at device resume time can sleep when pinning buffers through the tiler. Only thing we need to be careful with here is that while we walk the list we can't unreference any gem objects, since the final unref would result in a recursive deadlock. But the only functions that walk the list is the device resume and debugfs dumping, so all safe. Signed-off-by: Daniel Vetter Reviewed-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7867f358bfec376bd4c423b97a00580856171ad Author: Tony Lindgren Date: Tue Jun 19 02:43:35 2018 -0700 wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout() [ Upstream commit 4ec7cece87b3ed21ffcd407c62fb2f151a366bc1 ] Otherwise we can get: WARNING: CPU: 0 PID: 55 at drivers/net/wireless/ti/wlcore/io.h:84 I've only seen this few times with the runtime PM patches enabled so this one is probably not needed before that. This seems to work currently based on the current PM implementation timer. Let's apply this separately though in case others are hitting this issue. Signed-off-by: Tony Lindgren Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 13c4f14d8cf264f889186ec991533923c11993ac Author: Johannes Berg Date: Wed Jun 20 08:58:28 2018 +0200 bitfield: fix *_encode_bits() [ Upstream commit e7d4a95da86e0b048702765bbdcdc968aaf312e7 ] There's a bug in *_encode_bits() in using ~field_multiplier() for the check whether or not the constant value fits into the field, this is wrong and clearly ~field_mask() was intended. This was triggering for me for both constant and non-constant values. Additionally, make this case actually into an compile error. Declaring the extern function that will never exist with just a warning is pointless as then later we'll just get a link error. While at it, also fix the indentation in those lines I'm touching. Finally, as suggested by Andy Shevchenko, add some tests and for that introduce also u8 helpers. The tests don't compile without the fix, showing that it's necessary. Fixes: 00b0c9b82663 ("Add primitives for manipulating bitfields both in host- and fixed-endian.") Reviewed-by: Andy Shevchenko Signed-off-by: Johannes Berg Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1ae0268dc54e6657605216669eefab4268165237 Author: Stefan Agner Date: Sun Jun 17 12:33:50 2018 +0200 brcmsmac: fix wrap around in conversion from constant to s16 [ Upstream commit c9a61469fc97672a08b2f798830a55ea6e03dc4a ] The last value in the log_table wraps around to a negative value since s16 has a value range of -32768 to 32767. This is not what the table intends to represent. Use the closest positive value 32767. This fixes a warning seen with clang: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c:216:2: warning: implicit conversion from 'int' to 's16' (aka 'short') changes value from 32768 to -32768 [-Wconstant-conversion] 32768 ^~~~~ 1 warning generated. Fixes: 4c0bfeaae9f9 ("brcmsmac: fix array out-of-bounds access in qm_log10") Cc: Tobias Regnery Signed-off-by: Stefan Agner Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af1c6a743c9891585625114d2ccd91eb794c999f Author: Dan Carpenter Date: Tue Jun 5 14:31:39 2018 +0300 rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication() [ Upstream commit ae636fb1554833ee5133ca47bf4b2791b6739c52 ] This is a static checker fix, not something I have tested. The issue is that on the second iteration through the loop, we jump forward by le32_to_cpu(auth_req->length) bytes. The problem is that if the length is more than "buflen" then we end up with a negative "buflen". A negative buflen is type promoted to a high positive value and the loop continues but it's accessing beyond the end of the buffer. I believe the "auth_req->length" comes from the firmware and if the firmware is malicious or buggy, you're already toasted so the impact of this bug is probably not very severe. Fixes: 030645aceb3d ("rndis_wlan: handle 802.11 indications from device") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 35ba785489480a7ac54d3287ef15374c574c03a7 Author: Lorenzo Bianconi Date: Mon Jun 4 11:19:41 2018 +0200 mt76x2: fix mrr idx/count estimation in mt76x2_mac_fill_tx_status() [ Upstream commit 2d1e9be0016230f3707812243561fbd16f1aea4b ] Fix mcs and attempt count estimation in mt76x2_mac_fill_tx_status routine if the number of tx retries reported by the hw is grater than IEEE80211_TX_MAX_RATES Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e") Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 882791abd11d3020694baa72b2782ad5a98da2e1 Author: Niklas Cassel Date: Mon Jun 18 17:00:49 2018 +0300 ath10k: transmit queued frames after processing rx packets [ Upstream commit 3f04950f32d5d592ab4fcaecac2178558a6f7437 ] When running iperf on ath10k SDIO, TX can stop working: iperf -c 192.168.1.1 -i 1 -t 20 -w 10K [ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec [ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec [ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec [ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec [ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 0.0-10.3 sec 9.01 MBytes 7.32 Mbits/sec There are frames in the ieee80211_txq and there are frames that have been removed from from this queue, but haven't yet been sent on the wire (num_pending_tx). When num_pending_tx reaches max_num_pending_tx, we will stop the queues by calling ieee80211_stop_queues(). As frames that have previously been sent for transmission (num_pending_tx) are completed, we will decrease num_pending_tx and wake the queues by calling ieee80211_wake_queue(). ieee80211_wake_queue() does not call wake_tx_queue, so we might still have frames in the queue at this point. While the queues were stopped, the socket buffer might have filled up, and in order for user space to write more, we need to free the frames in the queue, since they are accounted to the socket. In order to free them, we first need to transmit them. This problem cannot be reproduced on low-latency devices, e.g. pci, since they call ath10k_mac_tx_push_pending() from ath10k_htt_txrx_compl_task(). ath10k_htt_txrx_compl_task() is not called on high-latency devices. Fix the problem by calling ath10k_mac_tx_push_pending(), after processing rx packets, just like for low-latency devices, also in the SDIO case. Since we are calling ath10k_mac_tx_push_pending() directly, we also need to export it. Signed-off-by: Niklas Cassel Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9f81b08ad8eaa4dad0a9ea70d13e60d5c04853cc Author: Jernej Skrabec Date: Mon Jun 25 14:02:46 2018 +0200 drm/sun4i: Fix releasing node when enumerating enpoints [ Upstream commit 367c359aa8637b15ee8df6335c5a29b7623966ec ] sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put() when remote is equal to NULL and does nothing when remote has a valid pointer. Invert the logic to fix memory leak. Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20180625120304.7543-7-jernej.skrabec@siol.net Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 900812a0d318954400d20b0190c7d788b4ff2cc2 Author: Brandon Maier Date: Tue Jun 26 12:50:48 2018 -0500 net: phy: xgmiitorgmii: Check phy_driver ready before accessing [ Upstream commit ab4e6ee578e88a659938db8fbf33720bc048d29c ] Since a phy_device is added to the global mdio_bus list during phy_device_register(), but a phy_device's phy_driver doesn't get attached until phy_probe(). It's possible of_phy_find_device() in xgmiitorgmii will return a valid phy with a NULL phy_driver. Leading to a NULL pointer access during the memcpy(). Fixes this Oops: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.40 #1 Hardware name: Xilinx Zynq Platform task: ce4c8d00 task.stack: ce4ca000 PC is at memcpy+0x48/0x330 LR is at xgmiitorgmii_probe+0x90/0xe8 pc : [] lr : [] psr: 20000013 sp : ce4cbb54 ip : 00000000 fp : ce4cbb8c r10: 00000000 r9 : 00000000 r8 : c0c49178 r7 : 00000000 r6 : cdc14718 r5 : ce762800 r4 : cdc14710 r3 : 00000000 r2 : 00000054 r1 : 00000000 r0 : cdc14718 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 18c5387d Table: 0000404a DAC: 00000051 Process swapper/0 (pid: 1, stack limit = 0xce4ca210) ... [] (memcpy) from [] (xgmiitorgmii_probe+0x90/0xe8) [] (xgmiitorgmii_probe) from [] (mdio_probe+0x28/0x34) [] (mdio_probe) from [] (driver_probe_device+0x254/0x414) [] (driver_probe_device) from [] (__device_attach_driver+0xac/0x10c) [] (__device_attach_driver) from [] (bus_for_each_drv+0x84/0xc8) [] (bus_for_each_drv) from [] (__device_attach+0xd0/0x134) [] (__device_attach) from [] (device_initial_probe+0x1c/0x20) [] (device_initial_probe) from [] (bus_probe_device+0x98/0xa0) [] (bus_probe_device) from [] (device_add+0x43c/0x5d0) [] (device_add) from [] (mdio_device_register+0x34/0x80) [] (mdio_device_register) from [] (of_mdiobus_register+0x170/0x30c) [] (of_mdiobus_register) from [] (macb_probe+0x710/0xc00) [] (macb_probe) from [] (platform_drv_probe+0x44/0x80) [] (platform_drv_probe) from [] (driver_probe_device+0x254/0x414) [] (driver_probe_device) from [] (__driver_attach+0x10c/0x118) [] (__driver_attach) from [] (bus_for_each_dev+0x8c/0xd0) [] (bus_for_each_dev) from [] (driver_attach+0x2c/0x30) [] (driver_attach) from [] (bus_add_driver+0x50/0x260) [] (bus_add_driver) from [] (driver_register+0x88/0x108) [] (driver_register) from [] (__platform_driver_register+0x50/0x58) [] (__platform_driver_register) from [] (macb_driver_init+0x24/0x28) [] (macb_driver_init) from [] (do_one_initcall+0x60/0x1a4) [] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1f8) [] (kernel_init_freeable) from [] (kernel_init+0x18/0x124) [] (kernel_init) from [] (ret_from_fork+0x14/0x20) Code: ba000002 f5d1f03c f5d1f05c f5d1f07c (e8b151f8) ---[ end trace 3e4ec21905820a1f ]--- Signed-off-by: Brandon Maier Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d0a4b7b3792f7650c57aedb6ac514fd608d64859 Author: Jernej Skrabec Date: Mon Jun 25 14:02:56 2018 +0200 drm/sun4i: Enable DW HDMI PHY clock [ Upstream commit 09773c532d30187f86a142901c27c93e629ce6ba ] Current DW HDMI PHY code never prepares and enables PHY clock after it is created. It's just used as it is. This may work in some cases, but it's clearly wrong. Fix it by adding proper calls to enable/disable PHY clock. Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant") Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20180625120304.7543-17-jernej.skrabec@siol.net Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c247a4bf53b6d70830f1a7190d404425fe8a806c Author: Ben Greear Date: Mon Jun 18 17:00:56 2018 +0300 ath10k: protect ath10k_htt_rx_ring_free with rx_ring.lock [ Upstream commit 168f75f11fe68455e0d058a818ebccfc329d8685 ] While debugging driver crashes related to a buggy firmware crashing under load, I noticed that ath10k_htt_rx_ring_free could be called without being under lock. I'm not sure if this is the root cause of the crash or not, but it seems prudent to protect it. Originally tested on 4.16+ kernel with ath10k-ct 10.4 firmware running on 9984 NIC. Signed-off-by: Ben Greear Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fcd12823cd576544556e4ba852204bc34be3e257 Author: Brandon Maier Date: Tue Jun 26 12:50:50 2018 -0500 net: phy: xgmiitorgmii: Check read_status results [ Upstream commit 8d0752d11312be830c33e84dfd1016e6a47c2938 ] We're ignoring the result of the attached phy device's read_status(). Return it so we can detect errors. Signed-off-by: Brandon Maier Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6cdfe3ed6c9d75db5d028f285c57890faa000c80 Author: Kai-Heng Feng Date: Thu Jun 28 15:28:24 2018 +0800 ALSA: hda: Add AZX_DCAPS_PM_RUNTIME for AMD Raven Ridge [ Upstream commit 1adca4b0cd65c14cb8b8c9c257720385869c3d5f ] This patch can make audio controller in AMD Raven Ridge gets runtime suspended to D3, to save ~1W power when it's not in use. Cc: Vijendar Mukunda Signed-off-by: Kai-Heng Feng Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3dc220c5253ebc8bc454d14c604816738d4bc2a5 Author: Dan Carpenter Date: Wed Jun 27 11:56:53 2018 +0300 ASoC: qdsp6: qdafe: fix some off by one bugs [ Upstream commit c54c1c5ee8e73b7cb752834e52e2129b1dab00bd ] The > should be >= or we could read one element beyond the end of the port_maps[] array. Fixes: 7fa2d70f9766 ("ASoC: qdsp6: q6afe: Add q6afe driver") Signed-off-by: Dan Carpenter Acked-by: Srinivas Kandagatla Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 49fc6188cdb6a1aad28e57058b2a07c4b8a03889 Author: Zhouyang Jia Date: Mon Jun 11 00:39:20 2018 -0400 media: tm6000: add error handling for dvb_register_adapter [ Upstream commit e95d7c6eb94c634852eaa5ff4caf3db05b5d2e86 ] When dvb_register_adapter fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling dvb_register_adapter. Signed-off-by: Zhouyang Jia [hans.verkuil@cisco.com: use pr_err and fix typo: adater -> adapter] Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6c695a374b0b21a7bb42c53aa0c4238577c2280d Author: Rosen Penev Date: Sat Jun 16 19:17:50 2018 -0700 staging: mt7621-dts: Fix remaining pcie warnings [ Upstream commit d0233204fbc10f003d1ef077f57341c2feca4002 ] This currently fixes the remaining dtb warnings: Node /pcie@1e140000/pcie0 has a reg or ranges property, but no unit name Node /pcie@1e140000/pcie1 has a reg or ranges property, but no unit name Node /pcie@1e140000/pcie2 has a reg or ranges property, but no unit name Node /pcie@1e140000/pcie0 node name is not "pci" or "pcie" Node /pcie@1e140000/pcie0 missing ranges for PCI bridge (or not a bridge) Node /pcie@1e140000/pcie0 missing bus-range for PCI bridge Node /pcie@1e140000/pcie1 node name is not "pci" or "pcie" Node /pcie@1e140000/pcie1 missing ranges for PCI bridge (or not a bridge) Node /pcie@1e140000/pcie1 missing bus-range for PCI bridge Node /pcie@1e140000/pcie2 node name is not "pci" or "pcie" Node /pcie@1e140000/pcie2 missing ranges for PCI bridge (or not a bridge) Node /pcie@1e140000/pcie2 missing bus-range for PCI bridge Warning (unit_address_format): Failed prerequisite 'pci_bridge' Warning (pci_device_reg): Failed prerequisite 'pci_bridge' Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge' device_type was removed since according to documentation, it's deprecated for pci(e) devices. Signed-off-by: Rosen Penev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7a887d2a1f91b8a0856735ddc8bf6d38b06e2b5a Author: Christophe JAILLET Date: Mon Jun 11 19:30:35 2018 +0200 serial: pxa: Fix an error handling path in 'serial_pxa_probe()' [ Upstream commit 95a0e656580fab3128c7bee5f660c50784f53651 ] If port.line is out of range, we still need to release some resources, or we will leak them. Fixes: afc7851fab83 ("serial: pxa: Fix out-of-bounds access through serial port index") Signed-off-by: Christophe JAILLET Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e8db58e3d80bf4c739450a3f0791022bde391cb4 Author: Geert Uytterhoeven Date: Thu Jun 14 15:48:08 2018 +0200 arm64: dts: renesas: salvator-common: Fix adv7482 decimal unit addresses [ Upstream commit c5a884838ce34681200b5a45b2330177036affd0 ] With recent dtc and W=1: ...salvator-x.dtb: Warning (graph_port): /soc/i2c@e66d8000/video-receiver@70/port@10: graph node unit address error, expected "a" ...salvator-x.dtb: Warning (graph_port): /soc/i2c@e66d8000/video-receiver@70/port@11: graph node unit address error, expected "b" Unit addresses are always hexadecimal (without prefix), while the bases of reg property values depend on their prefixes. Fixes: 908001d778eba06e ("arm64: dts: renesas: salvator-common: Add ADV7482 support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Acked-by: Kieran Bingham Signed-off-by: Simon Horman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e65f712ea9369fcb7c1824d3eaa6dd19caa22482 Author: Zhouyang Jia Date: Tue Jun 12 12:36:25 2018 +0800 drivers/tty: add error handling for pcmcia_loop_config [ Upstream commit 85c634e919bd6ef17427f26a52920aeba12e16ee ] When pcmcia_loop_config fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling pcmcia_loop_config. Signed-off-by: Zhouyang Jia Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5208cebb4ca394b9809d37035c6e3c66c3ef2f9c Author: Kamal Heib Date: Tue Jun 19 20:04:08 2018 +0300 staging: mt7621-eth: Fix memory leak in mtk_add_mac() error path [ Upstream commit 85e1d42663a0c163002961d2685be952067b0dc2 ] Fix memory leak in error path of mtk_add_mac() by make sure to free the allocated netdev. Fixes: e3cbf478f846 ('staging: mt7621-eth: add the drivers core files') Signed-off-by: Kamal Heib Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6cbaed5c50ac046fdad63fef1463201750407e44 Author: Akinobu Mita Date: Sun May 6 10:19:18 2018 -0400 media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING [ Upstream commit 0b964d183cbf3f95a062ad9f3eec87ffa2790558 ] The ov772x driver only works when the i2c controller have I2C_FUNC_PROTOCOL_MANGLING. However, many i2c controller drivers don't support it. The reason that the ov772x requires I2C_FUNC_PROTOCOL_MANGLING is that it doesn't support repeated starts. This changes the reading ov772x register method so that it doesn't require I2C_FUNC_PROTOCOL_MANGLING by calling two separated i2c messages. Cc: Laurent Pinchart Cc: Hans Verkuil Cc: Wolfram Sang Reviewed-by: Jacopo Mondi Signed-off-by: Akinobu Mita Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 47da213433ae898f92a1f5c2e66196fdbcbc2a18 Author: Alistair Strachan Date: Tue Jun 19 17:57:35 2018 -0700 staging: android: ashmem: Fix mmap size validation [ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ] The ashmem driver did not check that the size/offset of the vma passed to its .mmap() function was not larger than the ashmem object being mapped. This could cause mmap() to succeed, even though accessing parts of the mapping would later fail with a segmentation fault. Ensure an error is returned by the ashmem_mmap() function if the vma size is larger than the ashmem object size. This enables safer handling of the problem in userspace. Cc: Todd Kjos Cc: devel@driverdev.osuosl.org Cc: linux-kernel@vger.kernel.org Cc: kernel-team@android.com Cc: Joel Fernandes Signed-off-by: Alistair Strachan Acked-by: Joel Fernandes (Google) Reviewed-by: Martijn Coenen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 20d705e92eb785f1ad0e3260825d627f6633629c Author: Akinobu Mita Date: Sun May 6 10:19:19 2018 -0400 media: ov772x: add checks for register read errors [ Upstream commit 30f3b17eaf4913e9e56be15915ce57aae69db701 ] This change adds checks for register read errors and returns correct error code. Cc: Laurent Pinchart Cc: Hans Verkuil Reviewed-by: Jacopo Mondi Signed-off-by: Akinobu Mita Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit eab10433598a6003eea8e7c05ee5ea3d8efda4b7 Author: Javier Martinez Canillas Date: Sat Jun 9 08:22:45 2018 -0400 media: omap3isp: zero-initialize the isp cam_xclk{a,b} initial data [ Upstream commit 2ec7debd44b49927a6e2861521994cc075a389ed ] The struct clk_init_data init variable is declared in the isp_xclk_init() function so is an automatic variable allocated in the stack. But it's not explicitly zero-initialized, so some init fields are left uninitialized. This causes the data structure to have undefined values that may confuse the common clock framework when the clock is registered. For example, the uninitialized .flags field could have the CLK_IS_CRITICAL bit set, causing the framework to wrongly prepare the clk on registration. This leads to the isp_xclk_prepare() callback being called, which in turn calls to the omap3isp_get() function that increments the isp dev refcount. Since this omap3isp_get() call is unexpected, this leads to an unbalanced omap3isp_get() call that prevents the requested IRQ to be later enabled, due the refcount not being 0 when the correct omap3isp_get() call happens. Fixes: 9b28ee3c9122 ("[media] omap3isp: Use the common clock framework") Signed-off-by: Javier Martinez Canillas Reviewed-by: Sebastian Reichel Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 870878d2c9419c4d45a898502b06bd8f8f7d18d4 Author: Akinobu Mita Date: Sun Jun 10 11:42:26 2018 -0400 media: soc_camera: ov772x: correct setting of banding filter [ Upstream commit 22216ec41e919682c15345e95928f266e8ba6f9e ] The banding filter ON/OFF is controlled via bit 5 of COM8 register. It is attempted to be enabled in ov772x_set_params() by the following line. ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, 1); But this unexpectedly results disabling the banding filter, because the mask and set bits are exclusive. On the other hand, ov772x_s_ctrl() correctly sets the bit by: ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, BNDF_ON_OFF); The same fix was already applied to non-soc_camera version of ov772x driver in the commit commit a024ee14cd36 ("media: ov772x: correct setting of banding filter") Cc: Jacopo Mondi Cc: Laurent Pinchart Cc: Hans Verkuil Signed-off-by: Akinobu Mita Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 39a372355b5af5aaea17861662dd6118d87363f5 Author: Akinobu Mita Date: Sun Jun 10 11:42:01 2018 -0400 media: s3c-camif: ignore -ENOIOCTLCMD from v4l2_subdev_call for s_power [ Upstream commit 30ed2b83343bd1e07884ca7355dac70d25ffc158 ] When the subdevice doesn't provide s_power core ops callback, the v4l2_subdev_call for s_power returns -ENOIOCTLCMD. If the subdevice doesn't have the special handling for its power saving mode, the s_power isn't required. So -ENOIOCTLCMD from the v4l2_subdev_call should be ignored. Cc: Hans Verkuil Signed-off-by: Akinobu Mita Acked-by: Sylwester Nawrocki Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8086828bed84415f9e1caf5eef123c3cca8122a6 Author: Bob Copeland Date: Thu Jun 21 08:25:48 2018 -0400 ath10k: use locked skb_dequeue for rx completions [ Upstream commit 62652555c616cad23a572f76cb5e870ab5395191 ] In our environment we are occasionally seeing the following stack trace in ath10k: Unable to handle kernel paging request at virtual address 0000a800 pgd = c0204000 [0000a800] *pgd=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: dwc3 dwc3_of_simple phy_qcom_dwc3 nf_nat xt_connmark CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.31 #2 Hardware name: Generic DT based system task: c09f4f40 task.stack: c09ee000 PC is at kfree_skb_list+0x1c/0x2c LR is at skb_release_data+0x6c/0x108 pc : [] lr : [] psr: 200f0113 sp : c09efb68 ip : c09efb80 fp : c09efb7c r10: 00000000 r9 : 00000000 r8 : 043fddd1 r7 : bf15d160 r6 : 00000000 r5 : d4ca2f00 r4 : ca7c6480 r3 : 000000a0 r2 : 01000000 r1 : c0a57470 r0 : 0000a800 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5787d Table: 56e6006a DAC: 00000051 Process swapper/0 (pid: 0, stack limit = 0xc09ee210) Stack: (0xc09efb68 to 0xc09f0000) fb60: ca7c6480 d4ca2f00 c09efb9c c09efb80 c065da5c c065dcb4 fb80: d4ca2f00 00000000 dcbf8400 bf15d160 c09efbb4 c09efba0 c065db28 c065d9fc fba0: d4ca2f00 00000000 c09efbcc c09efbb8 c065db48 c065db04 d4ca2f00 00000000 fbc0: c09efbe4 c09efbd0 c065ddd0 c065db38 d4ca2f00 00000000 c09efc64 c09efbe8 fbe0: bf09bd00 c065dd10 00000003 7fffffff c09efc24 dcbfc9c0 01200000 00000000 fc00: 00000000 00000000 ddb7e440 c09e9440 c09efc48 1d195000 c09efc7c c09efc28 fc20: c027bb68 c028aa00 ddb7e4f8 bf13231c ddb7e454 0004091f bf154571 d4ca2f00 fc40: dcbf8d00 ca7c5df6 bf154538 01200000 00000000 bf154538 c09efd1c c09efc68 fc60: bf132458 bf09bbbc ca7c5dec 00000041 bf154538 bf154539 000007bf bf154545 fc80: bf154538 bf154538 bf154538 bf154538 bf154538 00000000 00000000 000016c1 fca0: 00000001 c09efcb0 01200000 00000000 00000000 00000000 00000000 00000001 fcc0: bf154539 00000041 00000000 00000007 00000000 000000d0 ffffffff 3160ffff fce0: 9ad93e97 3e973160 7bf09ad9 0004091f d4ca2f00 c09efdb0 dcbf94e8 00000000 fd00: dcbf8d00 01200000 00000000 dcbf8d00 c09efd44 c09efd20 bf132544 bf132130 fd20: dcbf8d00 00000000 d4ca2f00 c09efdb0 00000001 d4ca2f00 c09efdec c09efd48 fd40: bf133630 bf1324d0 ca7c5cc0 000007c0 c09efd88 c09efd70 c0764230 c02277d8 fd60: 200f0113 ffffffff dcbf94c8 bf000000 dcbf93b0 dcbf8d00 00000040 dcbf945c fd80: dcbf94e8 00000000 c09efdcc 00000000 c09efd90 c09efd90 00000000 00000024 fda0: dcbf8d00 00000000 00000005 dcbf8d00 c09efdb0 c09efdb0 00000000 00000040 fdc0: c09efdec dcbf8d00 dcbfc9c0 c09ed140 00000040 00000000 00000100 00000040 fde0: c09efe14 c09efdf0 bf1739b4 bf132840 dcbfc9c0 ddb82140 c09ed140 1d195000 fe00: 00000001 00000100 c09efe64 c09efe18 c067136c bf173958 ddb7fac8 c09f0d00 fe20: 001df678 0000012c c09efe28 c09efe28 c09efe30 c09efe30 c0a7fb28 ffffe000 fe40: c09f008c 00000003 00000008 c0a598c0 00000100 c09f0080 c09efeb4 c09efe68 fe60: c02096e0 c0671278 c0494584 00000080 dd5c3300 c09f0d00 00000004 001df677 fe80: 0000000a 00200100 dd5c3300 00000000 00000000 c09eaa70 00000060 dd410800 fea0: c09ee000 00000000 c09efecc c09efeb8 c0227944 c02094c4 00000000 00000000 fec0: c09efef4 c09efed0 c0268b64 c02278ac de802000 c09f1b1c c09eff20 c0a16cc0 fee0: de803000 c09ee000 c09eff1c c09efef8 c020947c c0268ae0 c02103dc 600f0013 ff00: ffffffff c09eff54 ffffe000 c09ee000 c09eff7c c09eff20 c021448c c0209424 ff20: 00000001 00000000 00000000 c021ddc0 00000000 00000000 c09f1024 00000001 ff40: ffffe000 c09f1078 00000000 c09eff7c c09eff80 c09eff70 c02103ec c02103dc ff60: 600f0013 ffffffff 00000051 00000000 c09eff8c c09eff80 c0763cc4 c02103bc ff80: c09effa4 c09eff90 c025f0e4 c0763c98 c0a59040 c09f1000 c09effb4 c09effa8 ffa0: c075efe0 c025efd4 c09efff4 c09effb8 c097dcac c075ef7c ffffffff ffffffff ffc0: 00000000 c097d6c4 00000000 c09c1a28 c0a59294 c09f101c c09c1a24 c09f61c0 ffe0: 4220406a 512f04d0 00000000 c09efff8 4220807c c097d95c 00000000 00000000 [] (kfree_skb_list) from [] (skb_release_data+0x6c/0x108) [] (skb_release_data) from [] (skb_release_all+0x30/0x34) [] (skb_release_all) from [] (__kfree_skb+0x1c/0x9c) [] (__kfree_skb) from [] (consume_skb+0xcc/0xd8) [] (consume_skb) from [] (ieee80211_rx_napi+0x150/0x82c [mac80211]) [] (ieee80211_rx_napi [mac80211]) from [] (ath10k_htt_t2h_msg_handler+0x15e8/0x19c4 [ath10k_core]) [] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [] (ath10k_htt_t2h_msg_handler+0x16d4/0x19c4 [ath10k_core]) [] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [] (ath10k_htt_txrx_compl_task+0xdfc/0x12cc [ath10k_core]) [] (ath10k_htt_txrx_compl_task [ath10k_core]) from [] (ath10k_pci_napi_poll+0x68/0xf4 [ath10k_pci]) [] (ath10k_pci_napi_poll [ath10k_pci]) from [] (net_rx_action+0x100/0x33c) [] (net_rx_action) from [] (__do_softirq+0x228/0x31c) [] (__do_softirq) from [] (irq_exit+0xa4/0x114) The trace points to a corrupt skb inside kfree_skb(), seemingly because one of the shared skb queues is getting corrupted. Most of the skb queues ath10k uses are local to a single call stack, but three are shared among multiple codepaths: - rx_msdus_q, - rx_in_ord_compl_q, and - tx_fetch_ind_q Of the three, the first two are manipulated using the unlocked skb_queue functions without any additional lock protecting them. Use the locked variants of skb_queue_* functions to protect these manipulations. Signed-off-by: Bob Copeland Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 11750fe66e26f0c3757486b4a54d97a9a61d539e Author: Petr Machata Date: Thu Jun 28 18:56:33 2018 +0200 selftests: forwarding: Tweak tc filters for mirror-to-gretap tests [ Upstream commit ec9fdc99f5a6a2cfe4061e807fcb0cc1129f0a2d ] When running mirror_gre_bridge_1d_vlan tests on veth, several issues cause spurious failures: - vlan_ethtype should be ip, not ipv6 even in mirror-to-ip6gretap case, because the overlay packet is still IPv4. - Similarly ip_proto matches the innermost IP protocol, so can't be used to filter out GRE packet. Drop the corresponding condition. - Because the above fixes the filters to match in slow path as well, they need to be made skip_hw so as not to double-count packets. Signed-off-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a4c7557bc547c2e0f43c41bd48d040a8386b2c0a Author: Nicholas Mc Guire Date: Fri Jun 29 19:07:42 2018 +0200 ALSA: snd-aoa: add of_node_put() in error path [ Upstream commit 222bce5eb88d1af656419db04bcd84b2419fb900 ] Both calls to of_find_node_by_name() and of_get_next_child() return a node pointer with refcount incremented thus it must be explicidly decremented here after the last usage. As we are assured to have a refcounted np either from the initial of_find_node_by_name(NULL, name); or from the of_get_next_child(gpio, np) in the while loop if we reached the error code path below, an x of_node_put(np) is needed. Signed-off-by: Nicholas Mc Guire Fixes: commit f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f6b9cd5c5f22603363b181adb5671f6d17e7a4e Author: Thomas Gleixner Date: Tue Jun 26 15:21:32 2018 +0200 posix-timers: Sanitize overrun handling [ Upstream commit 78c9c4dfbf8c04883941445a195276bb4bb92c76 ] The posix timer overrun handling is broken because the forwarding functions can return a huge number of overruns which does not fit in an int. As a consequence timer_getoverrun(2) and siginfo::si_overrun can turn into random number generators. The k_clock::timer_forward() callbacks return a 64 bit value now. Make k_itimer::ti_overrun[_last] 64bit as well, so the kernel internal accounting is correct. 3Remove the temporary (int) casts. Add a helper function which clamps the overrun value returned to user space via timer_getoverrun(2) or siginfo::si_overrun limited to a positive value between 0 and INT_MAX. INT_MAX is an indicator for user space that the overrun value has been clamped. Reported-by: Team OWL337 Signed-off-by: Thomas Gleixner Acked-by: John Stultz Cc: Peter Zijlstra Cc: Michael Kerrisk Link: https://lkml.kernel.org/r/20180626132705.018623573@linutronix.de Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c0d08296a291d9998dc63cabd795aa56fd511375 Author: Thomas Gleixner Date: Tue Jun 26 15:21:31 2018 +0200 posix-timers: Make forward callback return s64 [ Upstream commit 6fec64e1c92d5c715c6d0f50786daa7708266bde ] The posix timer ti_overrun handling is broken because the forwarding functions can return a huge number of overruns which does not fit in an int. As a consequence timer_getoverrun(2) and siginfo::si_overrun can turn into random number generators. As a first step to address that let the timer_forward() callbacks return the full 64 bit value. Cast it to (int) temporarily until k_itimer::ti_overrun is converted to 64bit and the conversion to user space visible values is sanitized. Reported-by: Team OWL337 Signed-off-by: Thomas Gleixner Acked-by: John Stultz Cc: Peter Zijlstra Cc: Michael Kerrisk Link: https://lkml.kernel.org/r/20180626132704.922098090@linutronix.de Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 90f955af43fe7d7c975abce7bed8966ff12aa3ab Author: Akinobu Mita Date: Tue Jun 26 00:22:41 2018 +0900 iio: accel: adxl345: convert address field usage in iio_chan_spec [ Upstream commit 9048f1f18a70a01eaa3c8e7166fdb2538929d780 ] Currently the address field in iio_chan_spec is filled with an accel data register address for the corresponding axis. In preparation for adding calibration offset support, this sets the address field to the index of accel data registers instead of the actual register address. This change makes it easier to access both accel registers and calibration offset registers with fewer lines of code as these are located in X-axis, Y-axis, Z-axis order. Cc: Eva Rachel Retuya Cc: Andy Shevchenko Cc: Jonathan Cameron Signed-off-by: Akinobu Mita Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f1915d5162a92d5d5e24aec054417eefea075184 Author: Peter Rosin Date: Thu Mar 29 15:10:54 2018 +0200 mtd: rawnand: atmel: add module param to avoid using dma [ Upstream commit efc6362c6f8c1e74b340e2611f1b35e7d557ce7b ] On a sama5d31 with a Full-HD dual LVDS panel (132MHz pixel clock) NAND flash accesses have a tendency to cause display disturbances. Add a module param to disable DMA from the NAND controller, since that fixes the display problem for me. Signed-off-by: Peter Rosin Reviewed-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ff9ac7d9bddaf104ede4578d4d1783fbee7841da Author: Vasily Gorbik Date: Sun Jun 17 00:30:43 2018 +0200 s390/extmem: fix gcc 8 stringop-overflow warning [ Upstream commit 6b2ddf33baec23dace85bd647e3fc4ac070963e8 ] arch/s390/mm/extmem.c: In function '__segment_load': arch/s390/mm/extmem.c:436:2: warning: 'strncat' specified bound 7 equals source length [-Wstringop-overflow=] strncat(seg->res_name, " (DCSS)", 7); What gcc complains about here is the misuse of strncat function, which in this case does not limit a number of bytes taken from "src", so it is in the end the same as strcat(seg->res_name, " (DCSS)"); Keeping in mind that a res_name is 15 bytes, strncat in this case would overflow the buffer and write 0 into alignment byte between the fields in the struct. To avoid that increasing res_name size to 16, and reusing strlcat. Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6143a4525c3e97bb56b6e5ccd09c7b89f648873a Author: Vasily Gorbik Date: Mon Jun 25 14:30:42 2018 +0200 s390/scm_blk: correct numa_node in scm_blk_dev_setup [ Upstream commit d642d6262f4fcfa5d200ec6e218c17f0c15b3390 ] The numa_node field of the tag_set struct has to be explicitly initialized, otherwise it stays as 0, which is a valid numa node id and cause memory allocation failure if node 0 is offline. Acked-by: Sebastian Ott Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0c6df6d17ab43cdb5c889d49149aeb9160e6cb45 Author: Vasily Gorbik Date: Sun Jun 24 09:21:59 2018 +0200 s390/dasd: correct numa_node in dasd_alloc_queue [ Upstream commit b17e3abb0af404cb62ad4ef1a5962f58b06e2b78 ] The numa_node field of the tag_set struct has to be explicitly initialized, otherwise it stays as 0, which is a valid numa node id and cause memory allocation failure if node 0 is offline. Acked-by: Stefan Haberland Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 04937aaaf8c795481580c323d91ee40a74cc66af Author: Thomas Gleixner Date: Mon Jul 2 09:34:29 2018 +0200 alarmtimer: Prevent overflow for relative nanosleep [ Upstream commit 5f936e19cc0ef97dbe3a56e9498922ad5ba1edef ] Air Icy reported: UBSAN: Undefined behaviour in kernel/time/alarmtimer.c:811:7 signed integer overflow: 1529859276030040771 + 9223372036854775807 cannot be represented in type 'long long int' Call Trace: alarm_timer_nsleep+0x44c/0x510 kernel/time/alarmtimer.c:811 __do_sys_clock_nanosleep kernel/time/posix-timers.c:1235 [inline] __se_sys_clock_nanosleep kernel/time/posix-timers.c:1213 [inline] __x64_sys_clock_nanosleep+0x326/0x4e0 kernel/time/posix-timers.c:1213 do_syscall_64+0xb8/0x3a0 arch/x86/entry/common.c:290 alarm_timer_nsleep() uses ktime_add() to add the current time and the relative expiry value. ktime_add() has no sanity checks so the addition can overflow when the relative timeout is large enough. Use ktime_add_safe() which has the necessary sanity checks in place and limits the result to the valid range. Fixes: 9a7adcf5c6de ("timers: Posix interface for alarm-timers") Reported-by: Team OWL337 Signed-off-by: Thomas Gleixner Cc: John Stultz Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1807020926360.1595@nanos.tec.linutronix.de Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4add6942e51ec39a3f9f183700b6bcc3669629d1 Author: Heiko Carstens Date: Mon Jul 2 10:54:02 2018 +0200 s390/sysinfo: add missing #ifdef CONFIG_PROC_FS [ Upstream commit 9f35b818a2f90fb6cb291aa0c9f835d4f0974a9a ] Get rid of this compile warning for !PROC_FS: CC arch/s390/kernel/sysinfo.o arch/s390/kernel/sysinfo.c:275:12: warning: 'sysinfo_show' defined but not used [-Wunused-function] static int sysinfo_show(struct seq_file *m, void *v) Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ab0fd80d87471c34912c3691ccfb6d1741f330f3 Author: Ravi Chandra Sadineni Date: Wed Jun 27 10:55:02 2018 -0700 ACPI / button: increment wakeup count only when notified [ Upstream commit 7c058c7c74b3dbeb7d157c273959f87faf710350 ] Because acpi_lid_initialize_state() is called on every system resume and it triggers acpi_lid_notify_state() which invokes acpi_pm_wakeup_event() for the lid device, the lid's wakeup count is incremented even if the lid was not the source of the event that woke up the system. That behavior confuses user space deamons using wakeup_count to identify the potential system wakeup source. To avoid the confusion, only trigger acpi_pm_wakeup_event() in the acpi_button_notify() path and don't do that in the acpi_lid_initialize_state() path. Signed-off-by: Ravi Chandra Sadineni Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f2514c04f556215cda3a4be98ea0215f72187988 Author: João Paulo Rechi Vita Date: Fri Jun 29 15:12:46 2018 -0700 platform/x86: asus-wireless: Fix uninitialized symbol usage [ Upstream commit eca4c4e47eb0658ad251f0bff465e23c055377da ] 'ret' will not be initialized if acpi_evaluate_integer() returns through an error path, so it should not be used in this case. This fixes the following Smatch static analyser error: drivers/platform/x86/asus-wireless.c:76 asus_wireless_method() error: uninitialized symbol 'ret'. Reported-by: Dan Carpenter Signed-off-by: João Paulo Rechi Vita Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 677b34aa38ed7ba6bd1a10883917e5d0b373ff3f Author: Alexey Kardashevskiy Date: Fri Jun 1 18:06:16 2018 +1000 powerpc/powernv/ioda2: Reduce upper limit for DMA window size [ Upstream commit d3d4ffaae439981e1e441ebb125aa3588627c5d8 ] We use PHB in mode1 which uses bit 59 to select a correct DMA window. However there is mode2 which uses bits 59:55 and allows up to 32 DMA windows per a PE. Even though documentation does not clearly specify that, it seems that the actual hardware does not support bits 59:55 even in mode1, in other words we can create a window as big as 1<<58 but DMA simply won't work. This reduces the upper limit from 59 to 55 bits to let the userspace know about the hardware limits. Fixes: 7aafac11e3 "powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested" Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ee1df10ae020bfa35589722ace79cc565991919a Author: Alagu Sankar Date: Fri Jun 29 16:28:00 2018 +0300 ath10k: sdio: set skb len for all rx packets [ Upstream commit 8530b4e7b22bc3bd8240579f3844c73947cd5f71 ] Without this, packets larger than 1500 will silently be dropped. Easily reproduced by sending a ping packet with a size larger than 1500. Co-Developed-by: Niklas Cassel Signed-off-by: Alagu Sankar Signed-off-by: Niklas Cassel Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd9b4e60690281a2e2f555d7d6e7dc9afcaa3f44 Author: Alagu Sankar Date: Fri Jun 29 16:27:56 2018 +0300 ath10k: sdio: use same endpoint id for all packets in a bundle [ Upstream commit 679e1f07c86221b7183dd69df7068fd42d0041f6 ] All packets in a bundle should use the same endpoint id as the first lookahead. This matches how things are done is ath6kl, however, this patch can theoretically handle several bundles in ath10k_sdio_mbox_rx_process_packets(). Without this patch we get lots of errors about invalid endpoint id: ath10k_sdio mmc2:0001:1: invalid endpoint in look-ahead: 224 ath10k_sdio mmc2:0001:1: failed to get pending recv messages: -12 ath10k_sdio mmc2:0001:1: failed to process pending SDIO interrupts: -12 Co-Developed-by: Niklas Cassel Signed-off-by: Alagu Sankar Signed-off-by: Niklas Cassel Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 420c37a784a77244b5e22e10209f86903537d6fe Author: Julia Lawall Date: Sun Jul 1 19:32:04 2018 +0200 usb: wusbcore: security: cast sizeof to int for comparison [ Upstream commit d3ac5598c5010a8999978ebbcca3b1c6188ca36b ] Comparing an int to a size, which is unsigned, causes the int to become unsigned, giving the wrong result. usb_get_descriptor can return a negative error code. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ int x; expression e,e1; identifier f; @@ *x = f(...); ... when != x = e1 when != if (x < 0 || ...) { ... return ...; } *x < sizeof(e) // Signed-off-by: Julia Lawall Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 90c00dd1798d4e1cddc312fc6fbd0c2f204f332f Author: Bart Van Assche Date: Thu Jun 28 13:48:57 2018 -0500 scsi: target: Avoid that EXTENDED COPY commands trigger lock inversion [ Upstream commit 36d4cb460bcbe2a1323732a6e4bb9dd783284368 ] The approach for adding a device to the devices_idr data structure and for removing it is as follows: * &dev->dev_group.cg_item is initialized before a device is added to devices_idr. * If the reference count of a device drops to zero then target_free_device() removes the device from devices_idr. * All devices_idr manipulations are protected by device_mutex. This means that increasing the reference count of a device is sufficient to prevent removal from devices_idr and also that it is safe access dev_group.cg_item for any device that is referenced by devices_idr. Use this to modify target_find_device() and target_for_each_device() such that these functions no longer introduce a dependency between device_mutex and the configfs root inode mutex. Note: it is safe to pass a NULL pointer to config_item_put() and also to config_item_get_unless_zero(). This patch prevents that lockdep reports the following complaint: ====================================================== WARNING: possible circular locking dependency detected 4.12.0-rc1-dbg+ #1 Not tainted ------------------------------------------------------ rmdir/12053 is trying to acquire lock: (device_mutex#2){+.+.+.}, at: [] target_free_device+0xae/0xf0 [target_core_mod] but task is already holding lock: (&sb->s_type->i_mutex_key#14){++++++}, at: [] vfs_rmdir+0x50/0x140 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sb->s_type->i_mutex_key#14){++++++}: lock_acquire+0x59/0x80 down_write+0x36/0x70 configfs_depend_item+0x3a/0xb0 [configfs] target_depend_item+0x13/0x20 [target_core_mod] target_xcopy_locate_se_dev_e4_iter+0x87/0x100 [target_core_mod] target_devices_idr_iter+0x16/0x20 [target_core_mod] idr_for_each+0x39/0xc0 target_for_each_device+0x36/0x50 [target_core_mod] target_xcopy_locate_se_dev_e4+0x28/0x80 [target_core_mod] target_xcopy_do_work+0x2e9/0xdd0 [target_core_mod] process_one_work+0x1ca/0x3f0 worker_thread+0x49/0x3b0 kthread+0x109/0x140 ret_from_fork+0x31/0x40 -> #0 (device_mutex#2){+.+.+.}: __lock_acquire+0x101f/0x11d0 lock_acquire+0x59/0x80 __mutex_lock+0x7e/0x950 mutex_lock_nested+0x16/0x20 target_free_device+0xae/0xf0 [target_core_mod] target_core_dev_release+0x10/0x20 [target_core_mod] config_item_put+0x6e/0xb0 [configfs] configfs_rmdir+0x1a6/0x300 [configfs] vfs_rmdir+0xb7/0x140 do_rmdir+0x1f4/0x200 SyS_rmdir+0x11/0x20 entry_SYSCALL_64_fastpath+0x23/0xc2 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sb->s_type->i_mutex_key#14); lock(device_mutex#2); lock(&sb->s_type->i_mutex_key#14); lock(device_mutex#2); *** DEADLOCK *** 3 locks held by rmdir/12053: #0: (sb_writers#10){.+.+.+}, at: [] mnt_want_write+0x1f/0x50 #1: (&sb->s_type->i_mutex_key#14/1){+.+.+.}, at: [] do_rmdir+0x15e/0x200 #2: (&sb->s_type->i_mutex_key#14){++++++}, at: [] vfs_rmdir+0x50/0x140 stack backtrace: CPU: 3 PID: 12053 Comm: rmdir Not tainted 4.12.0-rc1-dbg+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0x86/0xcf print_circular_bug+0x1c7/0x220 __lock_acquire+0x101f/0x11d0 lock_acquire+0x59/0x80 __mutex_lock+0x7e/0x950 mutex_lock_nested+0x16/0x20 target_free_device+0xae/0xf0 [target_core_mod] target_core_dev_release+0x10/0x20 [target_core_mod] config_item_put+0x6e/0xb0 [configfs] configfs_rmdir+0x1a6/0x300 [configfs] vfs_rmdir+0xb7/0x140 do_rmdir+0x1f4/0x200 SyS_rmdir+0x11/0x20 entry_SYSCALL_64_fastpath+0x23/0xc2 Signed-off-by: Bart Van Assche [Rebased to handle conflict withe target_find_device removal] Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d08b7218cea00dded98edc96f52d8822901498aa Author: Breno Leitao Date: Tue Jun 26 17:35:16 2018 -0300 scsi: ibmvscsi: Improve strings handling [ Upstream commit 1262dc09dc9ae7bf4ad00b6a2c5ed6a6936bcd10 ] Currently an open firmware property is copied into partition_name variable without keeping a room for \0. Later one, this variable (partition_name), which is 97 bytes long, is strncpyed into ibmvcsci_host_data->madapter_info->partition_name, which is 96 bytes long, possibly truncating it 'again' and removing the \0. This patch simply decreases the partition name to 96 and just copy using strlcpy() which guarantees that the string is \0 terminated. I think there is no issue if this there is a truncation in this very first copy, i.e, when the open firmware property is read and copied into the driver for the very first time; This issue also causes the following warning on GCC 8: drivers/scsi/ibmvscsi/ibmvscsi.c:281:2: warning: strncpy output may be truncated copying 96 bytes from a string of length 96 [-Wstringop-truncation] ... inlined from ibmvscsi_probe at drivers/scsi/ibmvscsi/ibmvscsi.c:2221:7: drivers/scsi/ibmvscsi/ibmvscsi.c:265:3: warning: strncpy specified bound 97 equals destination size [-Wstringop-truncation] CC: Bart Van Assche CC: Tyrel Datwyler Signed-off-by: Breno Leitao Acked-by: Tyrel Datwyler Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7369c88b59a9b4ecddad2e14d82ba4ce6c7aa160 Author: Bart Van Assche Date: Fri Jun 22 14:54:49 2018 -0700 scsi: klist: Make it safe to use klists in atomic context [ Upstream commit 624fa7790f80575a4ec28fbdb2034097dc18d051 ] In the scsi_transport_srp implementation it cannot be avoided to iterate over a klist from atomic context when using the legacy block layer instead of blk-mq. Hence this patch that makes it safe to use klists in atomic context. This patch avoids that lockdep reports the following: WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&k->k_lock)->rlock); local_irq_disable(); lock(&(&q->__queue_lock)->rlock); lock(&(&k->k_lock)->rlock); lock(&(&q->__queue_lock)->rlock); stack backtrace: Workqueue: kblockd blk_timeout_work Call Trace: dump_stack+0xa4/0xf5 check_usage+0x6e6/0x700 __lock_acquire+0x185d/0x1b50 lock_acquire+0xd2/0x260 _raw_spin_lock+0x32/0x50 klist_next+0x47/0x190 device_for_each_child+0x8e/0x100 srp_timed_out+0xaf/0x1d0 [scsi_transport_srp] scsi_times_out+0xd4/0x410 [scsi_mod] blk_rq_timed_out+0x36/0x70 blk_timeout_work+0x1b5/0x220 process_one_work+0x4fe/0xad0 worker_thread+0x63/0x5a0 kthread+0x1c1/0x1e0 ret_from_fork+0x24/0x30 See also commit c9ddf73476ff ("scsi: scsi_transport_srp: Fix shost to rport translation"). Signed-off-by: Bart Van Assche Cc: Martin K. Petersen Cc: James Bottomley Acked-by: Greg Kroah-Hartman Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d6b653c050973971b1ab8791d445b692871ab0c Author: Jean-Christophe Dubois Date: Sun Jul 1 00:10:50 2018 +0200 thermal: i.MX: Allow thermal probe to fail gracefully in case of bad calibration. [ Upstream commit be926ceeb4efc3bf44cb9b56f5c71aac9b1f8bbe ] Without this fix, the thermal probe on i.MX6 might trigger a division by zero exception later in the probe if the calibration does fail. Note: This linux behavior (Division by zero in kernel) has been triggered on a Qemu i.MX6 emulation where parameters in nvmem were not set. With this fix the division by zero is not triggeed anymore as the thermal probe does fail early. Signed-off-by: Jean-Christophe Dubois Reviewed-by: Fabio Estevam Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 92e96ad168ea8772b32bd6fe0d36d989b65feb58 Author: Bart Van Assche Date: Fri Jun 22 14:53:01 2018 -0700 scsi: target/iscsi: Make iscsit_ta_authentication() respect the output buffer size [ Upstream commit 35bea5c84fd13c643cce63f0b5cd4b148f8c901d ] Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Signed-off-by: Bart Van Assche Reviewed-by: Mike Christie Cc: Mike Christie Cc: Christoph Hellwig Cc: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6cf7be0267f7f5943fc038f47d314e66407a60f5 Author: Viresh Kumar Date: Fri May 25 16:01:48 2018 +0530 ARM: dts: ls1021a: Add missing cooling device properties for CPUs [ Upstream commit 47768f372eae030db6fab5225f9504a820d2c07f ] The cooling device properties, like "#cooling-cells" and "dynamic-power-coefficient", should either be present for all the CPUs of a cluster or none. If these are present only for a subset of CPUs of a cluster then things will start falling apart as soon as the CPUs are brought online in a different order. For example, this will happen because the operating system looks for such properties in the CPU node it is trying to bring up, so that it can register a cooling device. Add such missing properties. Signed-off-by: Viresh Kumar Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f0c6c6ec02a133bacfe5ef93f3e40d8a612c9df8 Author: Jan Beulich Date: Mon Jul 2 04:47:57 2018 -0600 x86/entry/64: Add two more instruction suffixes [ Upstream commit 6709812f094d96543b443645c68daaa32d3d3e77 ] Sadly, other than claimed in: a368d7fd2a ("x86/entry/64: Add instruction suffix") ... there are two more instances which want to be adjusted. As said there, omitting suffixes from instructions in AT&T mode is bad practice when operand size cannot be determined by the assembler from register operands, and is likely going to be warned about by upstream gas in the future (mine does already). Add the other missing suffixes here as well. Signed-off-by: Jan Beulich Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/5B3A02DD02000078001CFB78@prv1-mh.provo.novell.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 06f91031931aa727e1479878de487e303648c5a2 Author: Dave Gerlach Date: Thu Jun 21 14:43:08 2018 +0530 ARM: hwmod: RTC: Don't assume lock/unlock will be called with irq enabled [ Upstream commit 6d609b35c815ba20132b7b64bcca04516bb17c56 ] When the RTC lock and unlock functions were introduced it was likely assumed that they would always be called from irq enabled context, hence the use of local_irq_disable/enable. This is no longer true as the RTC+DDR path makes a late call during the suspend path after irqs have been disabled to enable the RTC hwmod which calls both unlock and lock, leading to IRQs being reenabled through the local_irq_enable call in omap_hwmod_rtc_lock call. To avoid this change the local_irq_disable/enable to local_irq_save/restore to ensure that from whatever context this is called the proper IRQ configuration is maintained. Signed-off-by: Dave Gerlach Signed-off-by: Keerthy Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 11a88b9218e7b41a2d773593cca2c6fe557d118c Author: Andy Shevchenko Date: Fri Jun 29 22:31:10 2018 +0300 x86/tsc: Add missing header to tsc_msr.c [ Upstream commit dbd0fbc76c77daac08ddd245afdcbade0d506e19 ] Add a missing header otherwise compiler warns about missed prototype: CC arch/x86/kernel/tsc_msr.o arch/x86/kernel/tsc_msr.c:73:15: warning: no previous prototype for ‘cpu_khz_from_msr’ [-Wmissing-prototypes] unsigned long cpu_khz_from_msr(void) ^~~~~~~~~~~~~~~~ Signed-off-by: Andy Shevchenko Signed-off-by: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Pavel Tatashin Link: https://lkml.kernel.org/r/20180629193113.84425-4-andriy.shevchenko@linux.intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2bffdc28ee6029df705996f6b5566ccd049673c6 Author: Bart Van Assche Date: Mon Jul 2 10:06:51 2018 -0700 include/rdma/opa_addr.h: Fix an endianness issue [ Upstream commit 4eefd62c17a9a5e7576207e84f3d2b4f73aba750 ] IB_MULTICAST_LID_BASE is defined as follows: #define IB_MULTICAST_LID_BASE cpu_to_be16(0xC000) Hence use be16_to_cpu() to convert it to CPU endianness. Compile-tested only. Fixes: af808ece5ce9 ("IB/SA: Check dlid before SA agent queries for ClassPortInfo") Signed-off-by: Bart Van Assche Cc: Venkata Sandeep Dhanalakota Cc: Mike Marciniszyn Cc: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b40f2ec52bf5647c4a1e71d73cd5a37a650f2944 Author: Maor Gottlieb Date: Sun Jul 1 15:50:17 2018 +0300 IB/mlx5: Fix GRE flow specification [ Upstream commit a93b632c4531ff50c43d658447a45cbc11f488fd ] Currently the driver sets the mask of the gre_protocol to 0xffff without consideration in the user request. Fix it by copy the mask from the verbs spec. Fixes: da2f22ae7707 ("IB/mlx5: Add support for GRE flow specification") Signed-off-by: Maor Gottlieb Reviewed-by: Ariel Levkovich Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c26fc717b13ba97901add97c7ef91c6b8a5921f5 Author: Peter Seiderer Date: Thu Mar 15 15:13:22 2018 -0400 media: staging/imx: fill vb2_v4l2_buffer field entry [ Upstream commit a38d4b71cb7a12b65317f4e3d59883a918957719 ] - fixes gstreamer v4l2src warning: 0:00:00.716640334 349 0x164f720 WARN v4l2bufferpool gstv4l2bufferpool.c:1195:gst_v4l2_buffer_pool_dqbuf: Driver should never set v4l2_buffer.field to ANY - fixes v4l2-compliance test failure: Streaming ioctls: test read/write: OK (Not Supported) Video Capture: Buffer: 0 Sequence: 0 Field: Any Timestamp: 58.383658s fail: v4l2-test-buffers.cpp(297): g_field() == V4L2_FIELD_ANY Signed-off-by: Peter Seiderer Reviewed-by: Steve Longerbeam Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0bd77cd5c2dac5a21bfe16eb61c9e449f8ab24e3 Author: Toshiaki Makita Date: Tue Jul 3 16:31:32 2018 +0900 vhost_net: Avoid tx vring kicks during busyloop [ Upstream commit 027b17603b030f1334ade079b7a3e986569c956b ] Under heavy load vhost busypoll may run without suppressing notification. For example tx zerocopy callback can push tx work while handle_tx() is running, then busyloop exits due to vhost_has_work() condition and enables notification but immediately reenters handle_tx() because the pushed work was tx. In this case handle_tx() tries to disable notification again, but when using event_idx it by design cannot. Then busyloop will run without suppressing notification. Another example is the case where handle_tx() tries to enable notification but avail idx is advanced so disables it again. This case also leads to the same situation with event_idx. The problem is that once we enter this situation busyloop does not work under heavy load for considerable amount of time, because notification is likely to happen during busyloop and handle_tx() immediately enables notification after notification happens. Specifically busyloop detects notification by vhost_has_work() and then handle_tx() calls vhost_enable_notify(). Because the detected work was the tx work, it enters handle_tx(), and enters busyloop without suppression again. This is likely to be repeated, so with event_idx we are almost not able to suppress notification in this case. To fix this, poll the work instead of enabling notification when busypoll is interrupted by something. IMHO vhost_has_work() is kind of interruption rather than a signal to completely cancel the busypoll, so let's run busypoll after the necessary work is done. Signed-off-by: Toshiaki Makita Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af58a41db9cc506bb323982a3d2e56a21fad9934 Author: Alexey Khoroshilov Date: Fri Jun 29 17:49:22 2018 -0400 media: fsl-viu: fix error handling in viu_of_probe() [ Upstream commit 662a99e145661c2b35155cf375044deae9b79896 ] viu_of_probe() ignores fails in i2c_get_adapter(), tries to unlock uninitialized mutex on error path. The patch streamlining the error handling in viu_of_probe(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ec0e373a62147960a4ab8692e33e0658ccccc9b1 Author: Hari Bathini Date: Thu Jun 28 10:49:56 2018 +0530 powerpc/kdump: Handle crashkernel memory reservation failure [ Upstream commit 8950329c4a64c6d3ca0bc34711a1afbd9ce05657 ] Memory reservation for crashkernel could fail if there are holes around kdump kernel offset (128M). Fail gracefully in such cases and print an error message. Signed-off-by: Hari Bathini Tested-by: David Gibson Reviewed-by: Dave Young Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fd56423854c4a811a671762fbd3f5505ec1ff45 Author: Tarick Bedeir Date: Mon Jul 2 14:02:34 2018 -0700 IB/mlx4: Test port number before querying type. [ Upstream commit f1228867adaf8890826f2b59e4caddb1c5cc2df7 ] rdma_ah_find_type() can reach into ib_device->port_immutable with a potentially out-of-bounds port number, so check that the port number is valid first. Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types") Signed-off-by: Tarick Bedeir Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 76e2bf1d322a899d1d5a5e855dc5072922ec860e Author: Sylwester Nawrocki Date: Tue May 15 05:21:45 2018 -0400 media: exynos4-is: Prevent NULL pointer dereference in __isp_video_try_fmt() [ Upstream commit 7c1b9a5aeed91bef98988ac0fcf38c8c1f4f9a3a ] This patch fixes potential NULL pointer dereference as indicated by the following static checker warning: drivers/media/platform/exynos4-is/fimc-isp-video.c:408 isp_video_try_fmt_mplane() error: NULL dereference inside function '__isp_video_try_fmt(isp, &f->fmt.pix_mp, (0))()'. Fixes: 34947b8aebe3: ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver") Reported-by: Dan Carpenter Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 203ae10a4713a8ee70775182b3cf0dc4052ca124 Author: Dan Carpenter Date: Wed Jul 4 12:32:12 2018 +0300 IB/core: type promotion bug in rdma_rw_init_one_mr() [ Upstream commit c2d7c8ff89b22ddefb1ac2986c0d48444a667689 ] "nents" is an unsigned int, so if ib_map_mr_sg() returns a negative error code then it's type promoted to a high unsigned int which is treated as success. Fixes: a060b5629ab0 ("IB/core: generic RDMA READ/WRITE API") Signed-off-by: Dan Carpenter Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 16fc25226707f4ac91844fe5117c16956f37908f Author: Dan Carpenter Date: Wed Jul 4 12:58:02 2018 +0300 RDMA/bnxt_re: Fix a bunch of off by one bugs in qplib_fp.c [ Upstream commit c1dfc0114c901b4f46c85ceff0491debf2b2a2ec ] The srq->swq[] is allocated in bnxt_qplib_create_srq(). It has srq->hwq.max_elements elements so these tests should be > instead of >= or we might go beyond the end of the array. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Signed-off-by: Dan Carpenter Acked-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6a4d21a7664b3b2a62b7bf9fbd0b89b52c30acef Author: Leon Romanovsky Date: Sun Jul 1 19:36:24 2018 +0300 RDMA/i40w: Hold read semaphore while looking after VMA [ Upstream commit 5d9a2b0e28759e319a623da33940dbb3ce952b7d ] VMA lookup is supposed to be performed while mmap_sem is held. Fixes: f26c7c83395b ("i40iw: Add 2MB page support") Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5ae7031fea6aca491cdc15dd28b2b93f8c7c4b11 Author: Dan Carpenter Date: Wed Jul 4 12:57:11 2018 +0300 RDMA/bnxt_re: Fix a couple off by one bugs [ Upstream commit 474e5a86067e5f12c97d1db8b170c7f45b53097a ] The sgid_tbl->tbl[] array is allocated in bnxt_qplib_alloc_sgid_tbl(). It has sgid_tbl->max elements. So the > should be >= to prevent accessing one element beyond the end of the array. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Signed-off-by: Dan Carpenter Acked-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit be853349a4a9784eac564fec0467ad68595e617f Author: Ganesh Goudar Date: Wed Jul 4 17:49:33 2018 +0530 cxgb4: Fix the condition to check if the card is T5 [ Upstream commit dfecc759e64b0ea581468fe2359836f1998deac9 ] Use 'chip_ver' rather than 'chip' to check if the card is T5. Fixes: e8d452923ae6 ("cxgb4: clean up init_one") Signed-off-by: Ganesh Goudar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 69b921bdab4be3885582b3badc4f992c78677b83 Author: Guoqing Jiang Date: Mon Jul 2 16:26:24 2018 +0800 md-cluster: clear another node's suspend_area after the copy is finished [ Upstream commit 010228e4a932ca1e8365e3b58c8e1e44c16ff793 ] When one node leaves cluster or stops the resyncing (resync or recovery) array, then other nodes need to call recover_bitmaps to continue the unfinished task. But we need to clear suspend_area later after other nodes copy the resync information to their bitmap (by call bitmap_copy_from_slot). Otherwise, all nodes could write to the suspend_area even the suspend_area is not handled by any node, because area_resyncing returns 0 at the beginning of raid1_write_request. Which means one node could write suspend_area while another node is resyncing the same area, then data could be inconsistent. So let's clear suspend_area later to avoid above issue with the protection of bm lock. Also it is straightforward to clear suspend_area after nodes have copied the resync info to bitmap. Signed-off-by: Guoqing Jiang Reviewed-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dd5ac3dcb22eb0f30cfa3137542fdec260bca0ef Author: Wesley Chalmers Date: Tue May 29 17:45:05 2018 -0400 drm/amd/display: fix use of uninitialized memory [ Upstream commit f3e077d95ca0a016fdf3d6b1e97a9910dfdaff17 ] DML does not calculate chroma values for RQ when surface is not YUV, but DC will unconditionally use the uninitialized values for HW programming. This does not cause visual corruption since HW will ignore garbage chroma values when surface is not YUV, but causes presubmission tests to fail golden value comparison. Signed-off-by: Wesley Chalmers Signed-off-by: Eryk Brol Reviewed-by: Wenjing Liu Acked-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e21238f1be65530a0d747e9f91202820fe73ce32 Author: Gustavo A. R. Silva Date: Wed Jul 4 08:22:11 2018 -0500 drm/amd/display/dc/dce: Fix multiple potential integer overflows [ Upstream commit 6f3472a993e7cb63cde5d818dcabc8e42fc03744 ] Add suffix ULL to constant 5 and cast variables target_pix_clk_khz and feedback_divider to uint64_t in order to avoid multiple potential integer overflows and give the compiler complete information about the proper arithmetic to use. Notice that such constant and variables are used in contexts that expect expressions of type uint64_t (64 bits, unsigned). The current casts to uint64_t effectively apply to each expression as a whole, but they do not prevent them from being evaluated using 32-bit arithmetic instead of 64-bit arithmetic. Also, once the expressions are properly evaluated using 64-bit arithmentic, there is no need for the parentheses that enclose them. Addresses-Coverity-ID: 1460245 ("Unintentional integer overflow") Addresses-Coverity-ID: 1460286 ("Unintentional integer overflow") Addresses-Coverity-ID: 1460401 ("Unintentional integer overflow") Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Gustavo A. R. Silva Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9fa1c8f4b9b2e919330840a98fac32ae2817fae9 Author: Benjamin Tissoires Date: Mon Jun 25 09:51:48 2018 +0200 power: remove possible deadlock when unregistering power_supply [ Upstream commit 3ffa6583e24e1ad1abab836d24bfc9d2308074e5 ] If a device gets removed right after having registered a power_supply node, we might enter in a deadlock between the remove call (that has a lock on the parent device) and the deferred register work. Allow the deferred register work to exit without taking the lock when we are in the remove state. Stack trace on a Ubuntu 16.04: [16072.109121] INFO: task kworker/u16:2:1180 blocked for more than 120 seconds. [16072.109127] Not tainted 4.13.0-41-generic #46~16.04.1-Ubuntu [16072.109129] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16072.109132] kworker/u16:2 D 0 1180 2 0x80000000 [16072.109142] Workqueue: events_power_efficient power_supply_deferred_register_work [16072.109144] Call Trace: [16072.109152] __schedule+0x3d6/0x8b0 [16072.109155] schedule+0x36/0x80 [16072.109158] schedule_preempt_disabled+0xe/0x10 [16072.109161] __mutex_lock.isra.2+0x2ab/0x4e0 [16072.109166] __mutex_lock_slowpath+0x13/0x20 [16072.109168] ? __mutex_lock_slowpath+0x13/0x20 [16072.109171] mutex_lock+0x2f/0x40 [16072.109174] power_supply_deferred_register_work+0x2b/0x50 [16072.109179] process_one_work+0x15b/0x410 [16072.109182] worker_thread+0x4b/0x460 [16072.109186] kthread+0x10c/0x140 [16072.109189] ? process_one_work+0x410/0x410 [16072.109191] ? kthread_create_on_node+0x70/0x70 [16072.109194] ret_from_fork+0x35/0x40 [16072.109199] INFO: task test:2257 blocked for more than 120 seconds. [16072.109202] Not tainted 4.13.0-41-generic #46~16.04.1-Ubuntu [16072.109204] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16072.109206] test D 0 2257 2256 0x00000004 [16072.109208] Call Trace: [16072.109211] __schedule+0x3d6/0x8b0 [16072.109215] schedule+0x36/0x80 [16072.109218] schedule_timeout+0x1f3/0x360 [16072.109221] ? check_preempt_curr+0x5a/0xa0 [16072.109224] ? ttwu_do_wakeup+0x1e/0x150 [16072.109227] wait_for_completion+0xb4/0x140 [16072.109230] ? wait_for_completion+0xb4/0x140 [16072.109233] ? wake_up_q+0x70/0x70 [16072.109236] flush_work+0x129/0x1e0 [16072.109240] ? worker_detach_from_pool+0xb0/0xb0 [16072.109243] __cancel_work_timer+0x10f/0x190 [16072.109247] ? device_del+0x264/0x310 [16072.109250] ? __wake_up+0x44/0x50 [16072.109253] cancel_delayed_work_sync+0x13/0x20 [16072.109257] power_supply_unregister+0x37/0xb0 [16072.109260] devm_power_supply_release+0x11/0x20 [16072.109263] release_nodes+0x110/0x200 [16072.109266] devres_release_group+0x7c/0xb0 [16072.109274] wacom_remove+0xc2/0x110 [wacom] [16072.109279] hid_device_remove+0x6e/0xd0 [hid] [16072.109284] device_release_driver_internal+0x158/0x210 [16072.109288] device_release_driver+0x12/0x20 [16072.109291] bus_remove_device+0xec/0x160 [16072.109293] device_del+0x1de/0x310 [16072.109298] hid_destroy_device+0x27/0x60 [hid] [16072.109303] usbhid_disconnect+0x51/0x70 [usbhid] [16072.109308] usb_unbind_interface+0x77/0x270 [16072.109311] device_release_driver_internal+0x158/0x210 [16072.109315] device_release_driver+0x12/0x20 [16072.109318] usb_driver_release_interface+0x77/0x80 [16072.109321] proc_ioctl+0x20f/0x250 [16072.109325] usbdev_do_ioctl+0x57f/0x1140 [16072.109327] ? __wake_up+0x44/0x50 [16072.109331] usbdev_ioctl+0xe/0x20 [16072.109336] do_vfs_ioctl+0xa4/0x600 [16072.109339] ? vfs_write+0x15a/0x1b0 [16072.109343] SyS_ioctl+0x79/0x90 [16072.109347] entry_SYSCALL_64_fastpath+0x24/0xab [16072.109349] RIP: 0033:0x7f20da807f47 [16072.109351] RSP: 002b:00007ffc422ae398 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [16072.109353] RAX: ffffffffffffffda RBX: 00000000010b8560 RCX: 00007f20da807f47 [16072.109355] RDX: 00007ffc422ae3a0 RSI: 00000000c0105512 RDI: 0000000000000009 [16072.109356] RBP: 0000000000000000 R08: 00007ffc422ae3e0 R09: 0000000000000010 [16072.109357] R10: 00000000000000a6 R11: 0000000000000246 R12: 0000000000000000 [16072.109359] R13: 00000000010b8560 R14: 00007ffc422ae2e0 R15: 0000000000000000 Reported-and-tested-by: Richard Hughes Tested-by: Aaron Skomra Signed-off-by: Benjamin Tissoires Fixes: 7f1a57fdd6cb ("power_supply: Fix possible NULL pointer dereference on early uevent") Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ff8aa171ef8c6fde8305ee3de843f2c08b24f966 Author: Vasily Gorbik Date: Sun Jun 24 12:17:43 2018 +0200 s390/mm: correct allocate_pgste proc_handler callback [ Upstream commit 5bedf8aa03c28cb8dc98bdd32a41b66d8f7d3eaa ] Since proc_dointvec does not perform value range control, proc_dointvec_minmax should be used to limit value range, which is clearly intended here, as the internal representation of the value: unsigned int alloc_pgste:1; In fact it currently works, since we have mm->context.alloc_pgste = page_table_allocate_pgste || ... ... since commit 23fefe119ceb5 ("s390/kvm: avoid global config of vm.alloc_pgste=1") Before that it was mm->context.alloc_pgste = page_table_allocate_pgste; which was broken. That was introduced with commit 0b46e0a3ec0d7 ("s390/kvm: remove delayed reallocation of page tables for KVM"). Fixes: 0b46e0a3ec0d7 ("s390/kvm: remove delayed reallocation of page tables for KVM") Acked-by: Christian Borntraeger Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 596ee3e366eb6d26c3c27fe852e847efac817d85 Author: Niklas Cassel Date: Tue Jun 12 16:06:10 2018 +0200 iommu/msm: Don't call iommu_device_{,un}link from atomic context [ Upstream commit 379521462e4add27f3514da8e4ab1fd7a54fe1c7 ] Fixes the following splat during boot: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747 in_atomic(): 1, irqs_disabled(): 128, pid: 77, name: kworker/2:1 4 locks held by kworker/2:1/77: #0: (ptrval) ((wq_completion)"events"){+.+.}, at: process_one_work+0x1fc/0x8fc #1: (ptrval) (deferred_probe_work){+.+.}, at: process_one_work+0x1fc/0x8fc #2: (ptrval) (&dev->mutex){....}, at: __device_attach+0x40/0x178 #3: (ptrval) (msm_iommu_lock){....}, at: msm_iommu_add_device+0x28/0xcc irq event stamp: 348 hardirqs last enabled at (347): [] kfree+0xe0/0x3c0 hardirqs last disabled at (348): [] _raw_spin_lock_irqsave+0x2c/0x68 softirqs last enabled at (0): [] copy_process.part.5+0x280/0x1a68 softirqs last disabled at (0): [<00000000>] (null) Preemption disabled at: [<00000000>] (null) CPU: 2 PID: 77 Comm: kworker/2:1 Not tainted 4.17.0-rc5-wt-ath-01075-gaca0516bb4cf #239 Hardware name: Generic DT based system Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0xa0/0xcc) [] (dump_stack) from [] (___might_sleep+0x1f8/0x2d4) ath10k_sdio mmc2:0001:1: Direct firmware load for ath10k/QCA9377/hw1.0/board-2.bin failed with error -2 [] (___might_sleep) from [] (__might_sleep+0x70/0xa8) [] (__might_sleep) from [] (__mutex_lock+0x50/0xb28) [] (__mutex_lock) from [] (mutex_lock_nested+0x2c/0x34) ath10k_sdio mmc2:0001:1: board_file api 1 bmi_id N/A crc32 544289f7 [] (mutex_lock_nested) from [] (kernfs_find_and_get_ns+0x30/0x5c) [] (kernfs_find_and_get_ns) from [] (sysfs_add_link_to_group+0x28/0x58) [] (sysfs_add_link_to_group) from [] (iommu_device_link+0x50/0xb4) [] (iommu_device_link) from [] (msm_iommu_add_device+0xa0/0xcc) [] (msm_iommu_add_device) from [] (add_iommu_group+0x3c/0x64) [] (add_iommu_group) from [] (bus_for_each_dev+0x84/0xc4) [] (bus_for_each_dev) from [] (bus_set_iommu+0xd0/0x10c) [] (bus_set_iommu) from [] (msm_iommu_probe+0x5b8/0x66c) [] (msm_iommu_probe) from [] (platform_drv_probe+0x60/0xbc) [] (platform_drv_probe) from [] (driver_probe_device+0x30c/0x4cc) [] (driver_probe_device) from [] (__device_attach_driver+0xac/0x14c) [] (__device_attach_driver) from [] (bus_for_each_drv+0x68/0xc8) [] (bus_for_each_drv) from [] (__device_attach+0xe4/0x178) [] (__device_attach) from [] (device_initial_probe+0x1c/0x20) [] (device_initial_probe) from [] (bus_probe_device+0x98/0xa0) [] (bus_probe_device) from [] (deferred_probe_work_func+0x74/0x198) [] (deferred_probe_work_func) from [] (process_one_work+0x2c4/0x8fc) [] (process_one_work) from [] (worker_thread+0x2c4/0x5cc) [] (worker_thread) from [] (kthread+0x180/0x188) [] (kthread) from [] (ret_from_fork+0x14/0x20) Fixes: 42df43b36163 ("iommu/msm: Make use of iommu_device_register interface") Signed-off-by: Niklas Cassel Reviewed-by: Vivek Gautam Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c4ea4d6928bd47cc5c4a3e5676c776cad453efc3 Author: Michael Scott Date: Tue Jun 19 16:44:06 2018 -0700 6lowpan: iphc: reset mac_header after decompress to fix panic [ Upstream commit 03bc05e1a4972f73b4eb8907aa373369e825c252 ] After decompression of 6lowpan socket data, an IPv6 header is inserted before the existing socket payload. After this, we reset the network_header value of the skb to account for the difference in payload size from prior to decompression + the addition of the IPv6 header. However, we fail to reset the mac_header value. Leaving the mac_header value untouched here, can cause a calculation error in net/packet/af_packet.c packet_rcv() function when an AF_PACKET socket is opened in SOCK_RAW mode for use on a 6lowpan interface. On line 2088, the data pointer is moved backward by the value returned from skb_mac_header(). If skb->data is adjusted so that it is before the skb->head pointer (which can happen when an old value of mac_header is left in place) the kernel generates a panic in net/core/skbuff.c line 1717. This panic can be generated by BLE 6lowpan interfaces (such as bt0) and 802.15.4 interfaces (such as lowpan0) as they both use the same 6lowpan sources for compression and decompression. Signed-off-by: Michael Scott Acked-by: Alexander Aring Acked-by: Jukka Rissanen Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d3f86dceb54c6915ac2c5741264c68a3223fc2cb Author: Johan Hovold Date: Wed Jul 4 17:02:18 2018 +0200 USB: serial: kobil_sct: fix modem-status error handling [ Upstream commit a420b5d939ee58f1d950f0ea782834056520aeaa ] Make sure to return -EIO in case of a short modem-status read request. While at it, split the debug message to not include the (zeroed) transfer-buffer content in case of errors. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 41086956a32b8e70e606e95c194b68051e3af0a6 Author: Jian-Hong Pan Date: Fri May 25 17:54:52 2018 +0800 Bluetooth: Add a new Realtek 8723DE ID 0bda:b009 [ Upstream commit 45ae68b8cfc25bdbffc11248001c47ab1b76ff6e ] Without this patch we cannot turn on the Bluethooth adapter on HP 14-bs007la. T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=b009 Rev= 2.00 S: Manufacturer=Realtek S: Product=802.11n WLAN Adapter 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: Jian-Hong Pan Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9032c7d6d57f3accf8b9546f668d5ec9412f7d17 Author: Zhen Lei Date: Wed Jun 6 10:18:46 2018 +0800 iommu/amd: make sure TLB to be flushed before IOVA freed [ Upstream commit 3c120143f584360a13614787e23ae2cdcb5e5ccd ] Although the mapping has already been removed in the page table, it maybe still exist in TLB. Suppose the freed IOVAs is reused by others before the flush operation completed, the new user can not correctly access to its meomory. Signed-off-by: Zhen Lei Fixes: b1516a14657a ('iommu/amd: Implement flush queue') Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8ae46971d69e888a0fd3569d3adae0aeef7d9c4a Author: Sudeep Holla Date: Mon Jun 18 16:54:32 2018 +0100 power: vexpress: fix corruption in notifier registration [ Upstream commit 09bebb1adb21ecd04adf7ccb3b06f73e3a851e93 ] Vexpress platforms provide two different restart handlers: SYS_REBOOT that restart the entire system, while DB_RESET only restarts the daughter board containing the CPU. DB_RESET is overridden by SYS_REBOOT if it exists. notifier_chain_register used in register_restart_handler by design relies on notifiers to be registered once only, however vexpress restart notifier can get registered twice. When this happen it corrupts list of notifiers, as result some notifiers can be not called on proper event, traverse on list can be cycled forever, and second unregister can access already freed memory. So far, since this was the only restart handler in the system, no issue was observed even if the same notifier was registered twice. However commit 6c5c0d48b686 ("watchdog: sp805: add restart handler") added support for SP805 restart handlers and since the system under test contains two vexpress restart and two SP805 watchdog instances, it was observed that during the boot traversing the restart handler list looped forever as there's a cycle in that list resulting in boot hang. This patch fixes the issues by ensuring that the notifier is installed only once. Cc: Sebastian Reichel Signed-off-by: Sudeep Holla Fixes: 46c99ac66222 ("power/reset: vexpress: Register with kernel restart handler") Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c8527e5a6e42c12c2afcf03d224ca67efcf9dc5 Author: Anton Vasilyev Date: Fri Jul 6 15:32:53 2018 +0300 uwb: hwa-rc: fix memory leak at probe [ Upstream commit 11b71782c1d10d9bccc31825cf84291cd7588a1e ] hwarc_probe() allocates memory for hwarc, but does not free it if uwb_rc_add() or hwarc_get_version() fail. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Anton Vasilyev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cb39b07bf5f961eb1c5d29bf5d392b9f3461f7e2 Author: Geert Uytterhoeven Date: Fri Jul 6 11:08:36 2018 +0200 serial: sh-sci: Stop RX FIFO timer during port shutdown [ Upstream commit c5a9262fa8bfed0dddc7466ef10fcd292e2af61b ] The RX FIFO timer may be armed when the port is shut down, hence the timer function may still be called afterwards. Fix this race condition by deleting the timer during port shutdown. Fixes: 039403765e5da3c6 ("serial: sh-sci: SCIFA/B RX FIFO software timeout") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 741b2c3b62cf8033587b24d0c44231054dbc1e4e Author: Johan Hovold Date: Tue Jul 3 12:05:48 2018 +0200 misc: sram: enable clock before registering regions [ Upstream commit d5b9653dd2bb7a2b1c8cc783c5d3b607bbb6b271 ] Make sure to enable the clock before registering regions and exporting partitions to user space at which point we must be prepared for I/O. Fixes: ee895ccdf776 ("misc: sram: fix enabled clock leak on error path") Signed-off-by: Johan Hovold Reviewed-by: Vladimir Zapolskiy Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 919618d2323473a43865384fecfd5113cc62b0dc Author: Hans de Goede Date: Wed May 23 15:33:21 2018 +0200 power: supply: axp288_charger: Fix initial constant_charge_current value [ Upstream commit f2a42595f0865886a2d40524b0e9d15600848670 ] We should look at val which contains the value read from the register, not ret which is always 0 on a successful read. Signed-off-by: Hans de Goede Fixes: eac53b3664f59 ("power: supply: axp288_charger: Drop platform_data dependency") Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df09a796560af5a8954993d1fca30f44a033c4df Author: Colin Ian King Date: Mon Jul 2 14:27:35 2018 +0100 staging: rts5208: fix missing error check on call to rtsx_write_register [ Upstream commit c5fae4f4fd28189b1062fb8ef7b21fec37cb8b17 ] Currently the check on error return from the call to rtsx_write_register is checking the error status from the previous call. Fix this by adding in the missing assignment of retval. Detected by CoverityScan, CID#709877 Fixes: fa590c222fba ("staging: rts5208: add support for rts5208 and rts5288") Signed-off-by: Colin Ian King Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e3deb9b3c252ecca24ef274bd1f178e5f4d5c7c1 Author: Dan Williams Date: Fri Jul 6 09:08:01 2018 -0700 x86/numa_emulation: Fix emulated-to-physical node mapping [ Upstream commit 3b6c62f363a19ce82bf378187ab97c9dc01e3927 ] Without this change the distance table calculation for emulated nodes may use the wrong numa node and report an incorrect distance. Signed-off-by: Dan Williams Cc: David Rientjes Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Wei Yang Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/153089328103.27680.14778434392225818887.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb2ca3d777d94c3851b380cfd8918425458a3c86 Author: Yunsheng Lin Date: Fri Jul 6 11:28:02 2018 +0100 net: hns3: Fix get_vector ops in hclgevf_main module [ Upstream commit 03718db97bfb57535f3aa8110f0cbe0c616a67c0 ] The hclgevf_free_vector function expects the caller to pass the vector_id to it, and hclgevf_put_vector pass vector to it now, which will cause vector allocation problem. This patch fixes it by converting vector into vector_id before calling hclgevf_free_vector. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Yunsheng Lin Signed-off-by: Peng Li Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6739fc895c8090916c5518030625b2d01ac03379 Author: Yunsheng Lin Date: Fri Jul 6 11:28:01 2018 +0100 net: hns3: Fix warning bug when doing lp selftest [ Upstream commit d7099d15478e89edb9bc6c6e3ab4cd341884a367 ] The napi_alloc_skb is excepted to be called under the non-preemptible code path when it is called by hns3_clean_rx_ring during loopback selftest, otherwise the below warning will be logged: [ 92.420780] BUG: using smp_processor_id() in preemptible [00000000] code: ethtool/1873 [ 92.463202] check_preemption_disabled+0xf8/0x100 [ 92.467893] debug_smp_processor_id+0x1c/0x28 [ 92.472239] __napi_alloc_skb+0x30/0x130 [ 92.476158] hns3_clean_rx_ring+0x118/0x5f0 [hns3] [ 92.480941] hns3_self_test+0x32c/0x4d0 [hns3] [ 92.485375] ethtool_self_test+0xdc/0x1e8 [ 92.489372] dev_ethtool+0x1020/0x1da8 [ 92.493109] dev_ioctl+0x188/0x3a0 [ 92.496499] sock_do_ioctl+0xf4/0x208 [ 92.500148] sock_ioctl+0x228/0x3e8 [ 92.503626] do_vfs_ioctl+0xc4/0x880 [ 92.507189] SyS_ioctl+0x94/0xa8 [ 92.510404] el0_svc_naked+0x30/0x34 This patch fix it by disabling preemption when calling hns3_clean_rx_ring during loopback selftest. Fixes: c39c4d98dc65 ("net: hns3: Add mac loopback selftest support in hns3 driver") Signed-off-by: Yunsheng Lin Signed-off-by: Peng Li Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 87dbcb1ce9c2cc7def3c8f96733bcea2bd32af43 Author: Yunsheng Lin Date: Fri Jul 6 11:27:56 2018 +0100 net: hns3: Fix for mac pause not disable in pfc mode [ Upstream commit 6d0ec65cb5810f9bf08671be008785bb8c84d39f ] When pfc pause mode is enable, the mac pause mode need to be disabled, otherwise the pfc pause packet will not be sent when congestion happens. This patch fixes by disabling the mac pause when pfc pause is enabled. Fixes: 848440544b41 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver") Signed-off-by: Yunsheng Lin Signed-off-by: Peng Li Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a659cb2f0fd7a1d8ddebc687e922cc10bff719b Author: Fuyun Liang Date: Fri Jul 6 11:27:59 2018 +0100 net: hns3: Fix for mailbox message truncated problem [ Upstream commit ead5bd4d35c0a14d5ce1474177718c678dff5205 ] The payload of mailbox message is 16 byte and the value of HCLGE_MBX_MAX_ARQ_MSG_SIZE is 8. A message truncated problem will happen when mailbox message is converted to ARQ message. This patch replaces HCLGE_MBX_MAX_ARQ_MSG_SIZE with the size of ARQ message in hclgevf_mbx_handler to fix this problem. Fixes: b11a0bb231f3 ("net: hns3: Add mailbox support to VF driver") Signed-off-by: Fuyun Liang Signed-off-by: Peng Li Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1bb1252b4e788fd8bcab9a2b4aebcffa2f49c30a Author: Uwe Kleine-König Date: Thu Jun 28 09:57:42 2018 +0200 siox: don't create a thread without starting it [ Upstream commit e890591413819eeb604207ad3261ba617b2ec0bb ] When a siox master device is registered a kthread is created that is only started when triggered by userspace. So this thread might be in TASK_UNINTERRUPTIBLE state for long and trigger a warning [ 241.130465] INFO: task siox-0:626 blocked for more than 120 seconds. with the respective debug settings enabled. It might be right to put an unstarted thread to TASK_IDLE (in kernel/kthread.c:kthread()) instead, but independant of this discussion it is cleaner for siox_master_register() to start the thread immediately. The effect is that it enters its own waiting state and then stays in state TASK_IDLE which doesn't trigger the above warning. As siox_poll_thread() uses some variables of the device the initialisation of these is moved before thread creation. Acked-by: Peter Zijlstra (Intel) Signed-off-by: Uwe Kleine-König Acked-by: Gavin Schenk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e83bd606a14e2e423db7b161907eae6fb4b80976 Author: Dan Carpenter Date: Wed Jul 4 12:33:34 2018 +0300 vmci: type promotion bug in qp_host_get_user_memory() [ Upstream commit 7fb2fd4e25fc1fb10dcb30b5519de257cfeae84c ] The problem is that if get_user_pages_fast() fails and returns a negative error code, it gets type promoted to a high positive value and treated as a success. Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 46ba8d1156e78b4d05c3f05d8d902832bfb33965 Author: Wei Yongjun Date: Sat May 26 09:45:59 2018 +0000 misc: ibmvmc: Use GFP_ATOMIC under spin lock [ Upstream commit 97b715b62e5b4c6edb75d023f556fd09a46cb4e1 ] The function alloc_dma_buffer() is called from ibmvmc_add_buffer(), in which a spin lock be held here, so we should use GFP_ATOMIC when a lock is held. Fixes: 0eca353e7ae7 ("misc: IBM Virtual Management Channel Driver (VMC)") Signed-off-by: Wei Yongjun Reviewed-by: Bryant G. Ly Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1d3de3d5e2749c6345daf4f05afc2134be5fe31b Author: Matt Ranostay Date: Fri Jun 8 23:58:15 2018 -0700 tsl2550: fix lux1_input error in low light [ Upstream commit ce054546cc2c26891cefa2f284d90d93b52205de ] ADC channel 0 photodiode detects both infrared + visible light, but ADC channel 1 just detects infrared. However, the latter is a bit more sensitive in that range so complete darkness or low light causes a error condition in which the chan0 - chan1 is negative that results in a -EAGAIN. This patch changes the resulting lux1_input sysfs attribute message from "Resource temporarily unavailable" to a user-grokable lux value of 0. Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Signed-off-by: Matt Ranostay Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c9bcfbebca4074dfb6db597f00747d1106cb08d2 Author: Akinobu Mita Date: Mon Jun 25 00:05:21 2018 +0900 iio: adc: ina2xx: avoid kthread_stop() with stale task_struct [ Upstream commit 7d6cd21d82bacab2d1786fe5e989e4815b75d9a3 ] When the buffer is enabled for ina2xx driver, a dedicated kthread is invoked to capture mesurement data. When the buffer is disabled, the kthread is stopped. However if the kthread gets register access errors, it immediately exits and when the malfunctional buffer is disabled, the stale task_struct pointer is accessed as there is no kthread to be stopped. A similar issue in the usbip driver is prevented by kthread_get_run and kthread_stop_put helpers by increasing usage count of the task_struct. This change applies the same solution. Cc: Stefan Brüns Cc: Jonathan Cameron Signed-off-by: Akinobu Mita Fixes: c43a102e67db ("iio: ina2xx: add support for TI INA2xx Power Monitors") Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d08aa810ddd189e2e8e84b1a0ce09621dfd35cd1 Author: Stafford Horne Date: Mon Jun 25 21:45:37 2018 +0900 crypto: skcipher - Fix -Wstringop-truncation warnings [ Upstream commit cefd769fd0192c84d638f66da202459ed8ad63ba ] As of GCC 9.0.0 the build is reporting warnings like: crypto/ablkcipher.c: In function ‘crypto_ablkcipher_report’: crypto/ablkcipher.c:374:2: warning: ‘strncpy’ specified bound 64 equals destination size [-Wstringop-truncation] strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(rblkcipher.geniv)); ~~~~~~~~~~~~~~~~~~~~~~~~~ This means the strnycpy might create a non null terminated string. Fix this by explicitly performing '\0' termination. Cc: Greg Kroah-Hartman Cc: Arnd Bergmann Cc: Max Filippov Cc: Eric Biggers Cc: Nick Desaulniers Signed-off-by: Stafford Horne Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2f411a0873a9daa20ae16cf5879d11bbea267582 Author: Greg Kroah-Hartman Date: Sat Sep 29 02:56:03 2018 -0700 Linux 4.18.11 commit e5bd6aca70efa763752aadc033027018a2aa8670 Author: Geert Uytterhoeven Date: Tue Aug 21 11:53:03 2018 +0200 spi: Fix double IDR allocation with DT aliases commit 04b2d03a75652bda989de1595048f0501dc0c0a0 upstream. If the SPI bus number is provided by a DT alias, idr_alloc() is called twice, leading to: WARNING: CPU: 1 PID: 1 at drivers/spi/spi.c:2179 spi_register_controller+0x11c/0x5d8 couldn't get idr Fix this by moving the handling of fixed SPI bus numbers up, before the DT handling code fills in ctlr->bus_num. Fixes: 1a4327fbf4554d5b ("spi: fix IDR collision on systems with both fixed and dynamic SPI bus numbers") Signed-off-by: Geert Uytterhoeven Tested-by: Fabio Estevam Signed-off-by: Mark Brown Cc: Sudip Mukherjee Cc: Kirill Kapranov Signed-off-by: Greg Kroah-Hartman commit 4fda8face67c15d9e9a016e552963bf72e7fde84 Author: Steve Wise Date: Fri Aug 31 07:15:56 2018 -0700 iw_cxgb4: only allow 1 flush on user qps commit 308aa2b8f7b7db3332a7d41099fd37851fb793b2 upstream. Once the qp has been flushed, it cannot be flushed again. The user qp flush logic wasn't enforcing it however. The bug can cause touch-after-free crashes like: Unable to handle kernel paging request for data at address 0x000001ec Faulting instruction address: 0xc008000016069100 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000016069100] flush_qp+0x80/0x480 [iw_cxgb4] LR [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4] Call Trace: [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4] [c00800001606e868] c4iw_ib_modify_qp+0x118/0x200 [iw_cxgb4] [c0080000119eae80] ib_security_modify_qp+0xd0/0x3d0 [ib_core] [c0080000119c4e24] ib_modify_qp+0xc4/0x2c0 [ib_core] [c008000011df0284] iwcm_modify_qp_err+0x44/0x70 [iw_cm] [c008000011df0fec] destroy_cm_id+0xcc/0x370 [iw_cm] [c008000011ed4358] rdma_destroy_id+0x3c8/0x520 [rdma_cm] [c0080000134b0540] ucma_close+0x90/0x1b0 [rdma_ucm] [c000000000444da4] __fput+0xe4/0x2f0 So fix flush_qp() to only flush the wq once. Cc: stable@vger.kernel.org Signed-off-by: Steve Wise Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 61b5194808f405fbf901f7c8280333cad0ec9768 Author: Nadav Amit Date: Thu Sep 13 13:18:52 2018 -0700 vmw_balloon: include asm/io.h commit a3b92ee6fc171d7c9d9b6b829b7fef169210440c upstream. Fix a build error due to missing virt_to_phys() Reported-by: kbuild test robot Fixes: f0a1bf29d821b ("vmw_balloon: fix inflation with batching") Cc: stable@vger.kernel.org Cc: Xavier Deguillard Signed-off-by: Nadav Amit Signed-off-by: Greg Kroah-Hartman commit ac586a2ffe31d77d3b6325708e5b4bfac6976f1b Author: Steve Muckle Date: Fri Aug 31 15:42:17 2018 -0700 sched/fair: Fix vruntime_normalized() for remote non-migration wakeup commit d0cdb3ce8834332d918fc9c8ff74f8a169ec9abe upstream. When a task which previously ran on a given CPU is remotely queued to wake up on that same CPU, there is a period where the task's state is TASK_WAKING and its vruntime is not normalized. This is not accounted for in vruntime_normalized() which will cause an error in the task's vruntime if it is switched from the fair class during this time. For example if it is boosted to RT priority via rt_mutex_setprio(), rq->min_vruntime will not be subtracted from the task's vruntime but it will be added again when the task returns to the fair class. The task's vruntime will have been erroneously doubled and the effective priority of the task will be reduced. Note this will also lead to inflation of all vruntimes since the doubled vruntime value will become the rq's min_vruntime when other tasks leave the rq. This leads to repeated doubling of the vruntime and priority penalty. Fix this by recognizing a WAKING task's vruntime as normalized only if sched_remote_wakeup is true. This indicates a migration, in which case the vruntime would have been normalized in migrate_task_rq_fair(). Based on a similar patch from John Dias . Suggested-by: Peter Zijlstra Tested-by: Dietmar Eggemann Signed-off-by: Steve Muckle Signed-off-by: Peter Zijlstra (Intel) Cc: Chris Redpath Cc: John Dias Cc: Linus Torvalds Cc: Miguel de Dios Cc: Morten Rasmussen Cc: Patrick Bellasi Cc: Paul Turner Cc: Quentin Perret Cc: Thomas Gleixner Cc: Todd Kjos Cc: kernel-team@android.com Fixes: b5179ac70de8 ("sched/fair: Prepare to fix fairness problems on migration") Link: http://lkml.kernel.org/r/20180831224217.169476-1-smuckle@google.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ec215095ac28e564e1eddf333fd85394b6908be4 Author: Toshi Kani Date: Sat Sep 15 21:37:59 2018 -0400 ext4, dax: set ext4_dax_aops for dax files commit cce6c9f7e6029caee45c459db5b3e78fec6973cb upstream. Sync syscall to DAX file needs to flush processor cache, but it currently does not flush to existing DAX files. This is because 'ext4_da_aops' is set to address_space_operations of existing DAX files, instead of 'ext4_dax_aops', since S_DAX flag is set after ext4_set_aops() in the open path. New file -------- lookup_open ext4_create __ext4_new_inode ext4_set_inode_flags // Set S_DAX flag ext4_set_aops // Set aops to ext4_dax_aops Existing file ------------- lookup_open ext4_lookup ext4_iget ext4_set_aops // Set aops to ext4_da_aops ext4_set_inode_flags // Set S_DAX flag Change ext4_iget() to initialize i_flags before ext4_set_aops(). Fixes: 5f0663bb4a64 ("ext4, dax: introduce ext4_dax_aops") Signed-off-by: Toshi Kani Signed-off-by: Theodore Ts'o Suggested-by: Jan Kara Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e2dd3371bfd1bb30163d0cac205aa212be4bdf36 Author: Toshi Kani Date: Sat Sep 15 21:23:41 2018 -0400 ext4, dax: add ext4_bmap to ext4_dax_aops commit 94dbb63117e82253c9592816aa4465f0a9c94850 upstream. Ext4 mount path calls .bmap to the journal inode. This currently works for the DAX mount case because ext4_iget() always set 'ext4_da_aops' to any regular files. In preparation to fix ext4_iget() to set 'ext4_dax_aops' for ext4 DAX files, add ext4_bmap() to 'ext4_dax_aops', since bmap works for DAX inodes. Fixes: 5f0663bb4a64 ("ext4, dax: introduce ext4_dax_aops") Signed-off-by: Toshi Kani Signed-off-by: Theodore Ts'o Suggested-by: Jan Kara Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d60e0a56ac37edda1a62a0a38e9c93dbf7752b1a Author: Eric Biggers Date: Sat Sep 15 14:28:26 2018 -0400 ext4: show test_dummy_encryption mount option in /proc/mounts commit 338affb548c243d2af25b1ca628e67819350de6b upstream. When in effect, add "test_dummy_encryption" to _ext4_show_options() so that it is shown in /proc/mounts and other relevant procfs files. Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit da7a6e25fe8e8376b0848500494c645a5f12ce4b Author: Li Dongyang Date: Sat Sep 15 17:11:25 2018 -0400 ext4: don't mark mmp buffer head dirty commit fe18d649891d813964d3aaeebad873f281627fbc upstream. Marking mmp bh dirty before writing it will make writeback pick up mmp block later and submit a write, we don't want the duplicate write as kmmpd thread should have full control of reading and writing the mmp block. Another reason is we will also have random I/O error on the writeback request when blk integrity is enabled, because kmmpd could modify the content of the mmp block(e.g. setting new seq and time) while the mmp block is under I/O requested by writeback. Signed-off-by: Li Dongyang Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 705bcb551648b0f93e6bd196888972df8a043040 Author: Theodore Ts'o Date: Mon Sep 3 22:25:01 2018 -0400 ext4: fix online resizing for bigalloc file systems with a 1k block size commit 5f8c10936fab2b69a487400f2872902e597dd320 upstream. An online resize of a file system with the bigalloc feature enabled and a 1k block size would be refused since ext4_resize_begin() did not understand s_first_data_block is 0 for all bigalloc file systems, even when the block size is 1k. Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d47e119158ec3b7c5033f7c5d96576cdd682fdbe Author: Theodore Ts'o Date: Mon Sep 3 22:19:43 2018 -0400 ext4: fix online resize's handling of a too-small final block group commit f0a459dec5495a3580f8d784555e6f8f3bf7f263 upstream. Avoid growing the file system to an extent so that the last block group is too small to hold all of the metadata that must be stored in the block group. This problem can be triggered with the following reproducer: umount /mnt mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \ -E resize=1073741824 /tmp/foo.img 128M mount /tmp/foo.img /mnt truncate --size 1708M /tmp/foo.img resize2fs /dev/loop0 295400 umount /mnt e2fsck -fy /tmp/foo.img Reported-by: Torsten Hilbrich Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2d0cd272e096cf41abae5ab22640836d00307edc Author: Theodore Ts'o Date: Sat Sep 1 14:42:14 2018 -0400 ext4: recalucate superblock checksum after updating free blocks/inodes commit 4274f516d4bc50648a4d97e4f67ecbd7b65cde4a upstream. When mounting the superblock, ext4_fill_super() calculates the free blocks and free inodes and stores them in the superblock. It's not strictly necessary, since we don't use them any more, but it's nice to keep them roughly aligned to reality. Since it's not critical for file system correctness, the code doesn't call ext4_commit_super(). The problem is that it's in ext4_commit_super() that we recalculate the superblock checksum. So if we're not going to call ext4_commit_super(), we need to call ext4_superblock_csum_set() to make sure the superblock checksum is consistent. Most of the time, this doesn't matter, since we end up calling ext4_commit_super() very soon thereafter, and definitely by the time the file system is unmounted. However, it doesn't work in this sequence: mke2fs -Fq -t ext4 /dev/vdc 128M mount /dev/vdc /vdc cp xfstests/git-versions /vdc godown /vdc umount /vdc mount /dev/vdc tune2fs -l /dev/vdc With this commit, the "tune2fs -l" no longer fails. Reported-by: Chengguang Xu Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a4cb1bf267a6db789655f05810dfb328e130a14c Author: Theodore Ts'o Date: Sat Sep 1 12:45:04 2018 -0400 ext4: avoid arithemetic overflow that can trigger a BUG commit bcd8e91f98c156f4b1ebcfacae675f9cfd962441 upstream. A maliciously crafted file system can cause an overflow when the results of a 64-bit calculation is stored into a 32-bit length parameter. https://bugzilla.kernel.org/show_bug.cgi?id=200623 Signed-off-by: Theodore Ts'o Reported-by: Wen Xu Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 976eeff67a3ad52c8337e3e10d10ae0a93e7f1ec Author: Theodore Ts'o Date: Mon Aug 27 09:22:45 2018 -0400 ext4: avoid divide by zero fault when deleting corrupted inline directories commit 4d982e25d0bdc83d8c64e66fdeca0b89240b3b85 upstream. A specially crafted file system can trick empty_inline_dir() into reading past the last valid entry in a inline directory, and then run into the end of xattr marker. This will trigger a divide by zero fault. Fix this by using the size of the inline directory instead of dir->i_size. Also clean up error reporting in __ext4_check_dir_entry so that the message is clearer and more understandable --- and avoids the division by zero trap if the size passed in is zero. (I'm not sure why we coded it that way in the first place; printing offset % size is actually more confusing and less useful.) https://bugzilla.kernel.org/show_bug.cgi?id=200933 Signed-off-by: Theodore Ts'o Reported-by: Wen Xu Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fdad4e17dc61310f9099d868ac6e528313b1ca9d Author: Theodore Ts'o Date: Mon Aug 27 01:47:09 2018 -0400 ext4: check to make sure the rename(2)'s destination is not freed commit b50282f3241acee880514212d88b6049fb5039c8 upstream. If the destination of the rename(2) system call exists, the inode's link count (i_nlinks) must be non-zero. If it is, the inode can end up on the orphan list prematurely, leading to all sorts of hilarity, including a use-after-free. https://bugzilla.kernel.org/show_bug.cgi?id=200931 Signed-off-by: Theodore Ts'o Reported-by: Wen Xu Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 52ef74c21c277e50de771fc722d814a830b3036b Author: Gustavo A. R. Silva Date: Thu Aug 16 15:30:38 2018 -0500 tty: vt_ioctl: fix potential Spectre v1 commit e97267cb4d1ee01ca0929638ec0fcbb0904f903d upstream. vsa.console is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue 'vc_cons' [r] Fix this by sanitizing vsa.console before using it to index vc_cons Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Reviewed-by: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 5a5338e45009de6834778c34a026f735d5caba04 Author: Alex Deucher Date: Tue Sep 18 15:28:24 2018 -0500 drm/amdgpu: add new polaris pci id commit 30f3984ede683b98a4e8096e200df78bf0609b4f upstream. Add new pci id. Reviewed-by: Rex Zhu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4cd5d680d8154ee3a061f6b36f1a4df6efa2da6c Author: Emil Lundmark Date: Mon May 28 16:27:11 2018 +0200 drm: udl: Destroy framebuffer only if it was initialized commit fcb74da1eb8edd3a4ef9b9724f88ed709d684227 upstream. This fixes a NULL pointer dereference that can happen if the UDL driver is unloaded before the framebuffer is initialized. This can happen e.g. if the USB device is unplugged right after it was plugged in. As explained by Stéphane Marchesin: It happens when fbdev is disabled (which is the case for Chrome OS). Even though intialization of the fbdev part is optional (it's done in udlfb_create which is the callback for fb_probe()), the teardown isn't optional (udl_driver_unload -> udl_fbdev_cleanup -> udl_fbdev_destroy). Note that udl_fbdev_cleanup *tries* to be conditional (you can see it does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is always set during udl_fbdev_init. Cc: stable@vger.kernel.org Suggested-by: Sean Paul Reviewed-by: Sean Paul Acked-by: Daniel Vetter Signed-off-by: Emil Lundmark Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180528142711.142466-1-lndmrk@chromium.org Signed-off-by: Sean Paul Signed-off-by: Greg Kroah-Hartman commit 934df3d13fc60d8987f0b3e4920785355edf53fa Author: Boris Brezillon Date: Wed Jul 25 14:29:07 2018 +0200 drm/vc4: Fix the "no scaling" case on multi-planar YUV formats commit 658d8cbd07dae22ccecf49399e18c609c4e85c53 upstream. When there's no scaling requested ->is_unity should be true no matter the format. Also, when no scaling is requested and we have a multi-planar YUV format, we should leave ->y_scaling[0] to VC4_SCALING_NONE and only set ->x_scaling[0] to VC4_SCALING_PPF. Doing this fixes an hardly visible artifact (seen when using modetest and a rather big overlay plane in YUV420). Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20180725122907.13702-1-boris.brezillon@bootlin.com Signed-off-by: Sean Paul Signed-off-by: Greg Kroah-Hartman commit 21fb862e0e3c3125dabbee740c3f0e9f95d669b9 Author: Lyude Paul Date: Thu Aug 16 16:13:13 2018 -0400 drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early commit 79e765ad665da4b8aa7e9c878bd2fef837f6fea5 upstream. On most systems with ACPI hotplugging support, it seems that we always receive a hotplug event once we re-enable EC interrupts even if the GPU hasn't even been resumed yet. This can cause problems since even though we schedule hpd_work to handle connector reprobing for us, hpd_work synchronizes on pm_runtime_get_sync() to wait until the device is ready to perform reprobing. Since runtime suspend/resume callbacks are disabled before the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during this period will grab a runtime PM ref and return immediately with -EACCES. Because we schedule hpd_work from our ACPI HPD handler, and hpd_work synchronizes on pm_runtime_get_sync(), this causes us to launch a connector reprobe immediately even if the GPU isn't actually resumed just yet. This causes various warnings in dmesg and occasionally, also prevents some displays connected to the dedicated GPU from coming back up after suspend. Example: usb 1-4: USB disconnect, device number 14 usb 1-4.1: USB disconnect, device number 15 WARNING: CPU: 0 PID: 838 at drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nouveau_dp_detect+0x17e/0x370 [nouveau] CPU: 0 PID: 838 Comm: kworker/0:6 Not tainted 4.17.14-201.Lyude.bz1477182.V3.fc28.x86_64 #1 Hardware name: LENOVO 20EQS64N00/20EQS64N00, BIOS N1EET77W (1.50 ) 03/28/2018 Workqueue: events nouveau_display_hpd_work [nouveau] RIP: 0010:nouveau_dp_detect+0x17e/0x370 [nouveau] RSP: 0018:ffffa15143933cf0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8cb4f656c400 RCX: 0000000000000000 RDX: ffffa1514500e4e4 RSI: ffffa1514500e4e4 RDI: 0000000001009002 RBP: ffff8cb4f4a8a800 R08: ffffa15143933cfd R09: ffffa15143933cfc R10: 0000000000000000 R11: 0000000000000000 R12: ffff8cb4fb57a000 R13: ffff8cb4fb57a000 R14: ffff8cb4f4a8f800 R15: ffff8cb4f656c418 FS: 0000000000000000(0000) GS:ffff8cb51f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f78ec938000 CR3: 000000073720a003 CR4: 00000000003606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? _cond_resched+0x15/0x30 nouveau_connector_detect+0x2ce/0x520 [nouveau] ? _cond_resched+0x15/0x30 ? ww_mutex_lock+0x12/0x40 drm_helper_probe_detect_ctx+0x8b/0xe0 [drm_kms_helper] drm_helper_hpd_irq_event+0xa8/0x120 [drm_kms_helper] nouveau_display_hpd_work+0x2a/0x60 [nouveau] process_one_work+0x187/0x340 worker_thread+0x2e/0x380 ? pwq_unbound_release_workfn+0xd0/0xd0 kthread+0x112/0x130 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x35/0x40 Code: 4c 8d 44 24 0d b9 00 05 00 00 48 89 ef ba 09 00 00 00 be 01 00 00 00 e8 e1 09 f8 ff 85 c0 0f 85 b2 01 00 00 80 7c 24 0c 03 74 02 <0f> 0b 48 89 ef e8 b8 07 f8 ff f6 05 51 1b c8 ff 02 0f 84 72 ff ---[ end trace 55d811b38fc8e71a ]--- So, to fix this we attempt to grab a runtime PM reference in the ACPI handler itself asynchronously. If the GPU is already awake (it will have normal hotplugging at this point) or runtime PM callbacks are currently disabled on the device, we drop our reference without updating the autosuspend delay. We only schedule connector reprobes when we successfully managed to queue up a resume request with our asynchronous PM ref. This also has the added benefit of preventing redundant connector reprobes from ACPI while the GPU is runtime resumed! Signed-off-by: Lyude Paul Cc: stable@vger.kernel.org Cc: Karol Herbst Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1477182#c41 Signed-off-by: Lyude Paul Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 99aa61fb35ed40f5ae023549e50c3279e219de61 Author: Lyude Paul Date: Wed Aug 15 15:00:14 2018 -0400 drm/nouveau/drm/nouveau: Use pm_runtime_get_noresume() in connector_detect() commit 6833fb1ec120bf078e1a527c573a09d4de286224 upstream. It's true we can't resume the device from poll workers in nouveau_connector_detect(). We can however, prevent the autosuspend timer from elapsing immediately if it hasn't already without risking any sort of deadlock with the runtime suspend/resume operations. So do that instead of entirely avoiding grabbing a power reference. Signed-off-by: Lyude Paul Reviewed-by: Karol Herbst Acked-by: Daniel Vetter Cc: stable@vger.kernel.org Cc: Lukas Wunner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 9c7443a7aa646327acbaa02d16e7f7858e4e886c Author: Lyude Paul Date: Wed Aug 15 15:00:13 2018 -0400 drm/nouveau/drm/nouveau: Fix deadlock with fb_helper with async RPM requests commit 7fec8f5379fb6eddabc0aaef6d2304c366808f97 upstream. Currently, nouveau uses the generic drm_fb_helper_output_poll_changed() function provided by DRM as it's output_poll_changed callback. Unfortunately however, this function doesn't grab runtime PM references early enough and even if it did-we can't block waiting for the device to resume in output_poll_changed() since it's very likely that we'll need to grab the fb_helper lock at some point during the runtime resume process. This currently results in deadlocking like so: [ 246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds. [ 246.673398] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.676527] kworker/4:0 D 0 37 2 0x80000000 [ 246.677580] Workqueue: events output_poll_execute [drm_kms_helper] [ 246.678704] Call Trace: [ 246.679753] __schedule+0x322/0xaf0 [ 246.680916] schedule+0x33/0x90 [ 246.681924] schedule_preempt_disabled+0x15/0x20 [ 246.683023] __mutex_lock+0x569/0x9a0 [ 246.684035] ? kobject_uevent_env+0x117/0x7b0 [ 246.685132] ? drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.686179] mutex_lock_nested+0x1b/0x20 [ 246.687278] ? mutex_lock_nested+0x1b/0x20 [ 246.688307] drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.689420] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper] [ 246.690462] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper] [ 246.691570] output_poll_execute+0x198/0x1c0 [drm_kms_helper] [ 246.692611] process_one_work+0x231/0x620 [ 246.693725] worker_thread+0x214/0x3a0 [ 246.694756] kthread+0x12b/0x150 [ 246.695856] ? wq_pool_ids_show+0x140/0x140 [ 246.696888] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.697998] ret_from_fork+0x3a/0x50 [ 246.699034] INFO: task kworker/0:1:60 blocked for more than 120 seconds. [ 246.700153] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.701182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.702278] kworker/0:1 D 0 60 2 0x80000000 [ 246.703293] Workqueue: pm pm_runtime_work [ 246.704393] Call Trace: [ 246.705403] __schedule+0x322/0xaf0 [ 246.706439] ? wait_for_completion+0x104/0x190 [ 246.707393] schedule+0x33/0x90 [ 246.708375] schedule_timeout+0x3a5/0x590 [ 246.709289] ? mark_held_locks+0x58/0x80 [ 246.710208] ? _raw_spin_unlock_irq+0x2c/0x40 [ 246.711222] ? wait_for_completion+0x104/0x190 [ 246.712134] ? trace_hardirqs_on_caller+0xf4/0x190 [ 246.713094] ? wait_for_completion+0x104/0x190 [ 246.713964] wait_for_completion+0x12c/0x190 [ 246.714895] ? wake_up_q+0x80/0x80 [ 246.715727] ? get_work_pool+0x90/0x90 [ 246.716649] flush_work+0x1c9/0x280 [ 246.717483] ? flush_workqueue_prep_pwqs+0x1b0/0x1b0 [ 246.718442] __cancel_work_timer+0x146/0x1d0 [ 246.719247] cancel_delayed_work_sync+0x13/0x20 [ 246.720043] drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper] [ 246.721123] nouveau_pmops_runtime_suspend+0x3d/0xb0 [nouveau] [ 246.721897] pci_pm_runtime_suspend+0x6b/0x190 [ 246.722825] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.723737] __rpm_callback+0x7a/0x1d0 [ 246.724721] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.725607] rpm_callback+0x24/0x80 [ 246.726553] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.727376] rpm_suspend+0x142/0x6b0 [ 246.728185] pm_runtime_work+0x97/0xc0 [ 246.728938] process_one_work+0x231/0x620 [ 246.729796] worker_thread+0x44/0x3a0 [ 246.730614] kthread+0x12b/0x150 [ 246.731395] ? wq_pool_ids_show+0x140/0x140 [ 246.732202] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.732878] ret_from_fork+0x3a/0x50 [ 246.733768] INFO: task kworker/4:2:422 blocked for more than 120 seconds. [ 246.734587] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.735393] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.736113] kworker/4:2 D 0 422 2 0x80000080 [ 246.736789] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] [ 246.737665] Call Trace: [ 246.738490] __schedule+0x322/0xaf0 [ 246.739250] schedule+0x33/0x90 [ 246.739908] rpm_resume+0x19c/0x850 [ 246.740750] ? finish_wait+0x90/0x90 [ 246.741541] __pm_runtime_resume+0x4e/0x90 [ 246.742370] nv50_disp_atomic_commit+0x31/0x210 [nouveau] [ 246.743124] drm_atomic_commit+0x4a/0x50 [drm] [ 246.743775] restore_fbdev_mode_atomic+0x1c8/0x240 [drm_kms_helper] [ 246.744603] restore_fbdev_mode+0x31/0x140 [drm_kms_helper] [ 246.745373] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 [drm_kms_helper] [ 246.746220] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] [ 246.746884] drm_fb_helper_hotplug_event.part.28+0x96/0xb0 [drm_kms_helper] [ 246.747675] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper] [ 246.748544] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper] [ 246.749439] nv50_mstm_hotplug+0x15/0x20 [nouveau] [ 246.750111] drm_dp_send_link_address+0x177/0x1c0 [drm_kms_helper] [ 246.750764] drm_dp_check_and_send_link_address+0xa8/0xd0 [drm_kms_helper] [ 246.751602] drm_dp_mst_link_probe_work+0x51/0x90 [drm_kms_helper] [ 246.752314] process_one_work+0x231/0x620 [ 246.752979] worker_thread+0x44/0x3a0 [ 246.753838] kthread+0x12b/0x150 [ 246.754619] ? wq_pool_ids_show+0x140/0x140 [ 246.755386] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.756162] ret_from_fork+0x3a/0x50 [ 246.756847] Showing all locks held in the system: [ 246.758261] 3 locks held by kworker/4:0/37: [ 246.759016] #0: 00000000f8df4d2d ((wq_completion)"events"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.759856] #1: 00000000e6065461 ((work_completion)(&(&dev->mode_config.output_poll_work)->work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.760670] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.761516] 2 locks held by kworker/0:1/60: [ 246.762274] #0: 00000000fff6be0f ((wq_completion)"pm"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.762982] #1: 000000005ab44fb4 ((work_completion)(&dev->power.work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.763890] 1 lock held by khungtaskd/64: [ 246.764664] #0: 000000008cb8b5c3 (rcu_read_lock){....}, at: debug_show_all_locks+0x23/0x185 [ 246.765588] 5 locks held by kworker/4:2/422: [ 246.766440] #0: 00000000232f0959 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.767390] #1: 00000000bb59b134 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.768154] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0xb0 [drm_kms_helper] [ 246.768966] #3: 000000004c8f0b6b (crtc_ww_class_acquire){+.+.}, at: restore_fbdev_mode_atomic+0x4b/0x240 [drm_kms_helper] [ 246.769921] #4: 000000004c34a296 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8a/0x1b0 [drm] [ 246.770839] 1 lock held by dmesg/1038: [ 246.771739] 2 locks held by zsh/1172: [ 246.772650] #0: 00000000836d0438 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40 [ 246.773680] #1: 000000001f4f4d48 (&ldata->atomic_read_lock){+.+.}, at: n_tty_read+0xc1/0x870 [ 246.775522] ============================================= After trying dozens of different solutions, I found one very simple one that should also have the benefit of preventing us from having to fight locking for the rest of our lives. So, we work around these deadlocks by deferring all fbcon hotplug events that happen after the runtime suspend process starts until after the device is resumed again. Changes since v7: - Fixup commit message - Daniel Vetter Changes since v6: - Remove unused nouveau_fbcon_hotplugged_in_suspend() - Ilia Changes since v5: - Come up with the (hopefully final) solution for solving this dumb problem, one that is a lot less likely to cause issues with locking in the future. This should work around all deadlock conditions with fbcon brought up thus far. Changes since v4: - Add nouveau_fbcon_hotplugged_in_suspend() to workaround deadlock condition that Lukas described - Just move all of this out of drm_fb_helper. It seems that other DRM drivers have already figured out other workarounds for this. If other drivers do end up needing this in the future, we can just move this back into drm_fb_helper again. Changes since v3: - Actually check if fb_helper is NULL in both new helpers - Actually check drm_fbdev_emulation in both new helpers - Don't fire off a fb_helper hotplug unconditionally; only do it if the following conditions are true (as otherwise, calling this in the wrong spot will cause Bad Things to happen): - fb_helper hotplug handling was actually inhibited previously - fb_helper actually has a delayed hotplug pending - fb_helper is actually bound - fb_helper is actually initialized - Add __must_check to drm_fb_helper_suspend_hotplug(). There's no situation where a driver would actually want to use this without checking the return value, so enforce that - Rewrite and clarify the documentation for both helpers. - Make sure to return true in the drm_fb_helper_suspend_hotplug() stub that's provided in drm_fb_helper.h when CONFIG_DRM_FBDEV_EMULATION isn't enabled - Actually grab the toplevel fb_helper lock in drm_fb_helper_resume_hotplug(), since it's possible other activity (such as a hotplug) could be going on at the same time the driver calls drm_fb_helper_resume_hotplug(). We need this to check whether or not drm_fb_helper_hotplug_event() needs to be called anyway Signed-off-by: Lyude Paul Reviewed-by: Karol Herbst Acked-by: Daniel Vetter Cc: stable@vger.kernel.org Cc: Lukas Wunner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 563f482029d43706850ebc54a39cc31f1ed8fc19 Author: Lyude Paul Date: Wed Aug 15 15:00:11 2018 -0400 drm/nouveau/drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement commit d77ef138ff572409ab93d492e5e6c826ee6fb21d upstream. Turns out this part is my fault for not noticing when reviewing 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work(). This makes basically no sense however, because that means we're calling drm_kms_helper_poll_enable() every time we schedule the hotplug detection work. This is also against the advice mentioned in drm_kms_helper_poll_enable()'s documentation: Note that calls to enable and disable polling must be strictly ordered, which is automatically the case when they're only call from suspend/resume callbacks. Of course, hotplugs can't really be ordered. They could even happen immediately after we called drm_kms_helper_poll_disable() in nouveau_display_fini(), which can lead to all sorts of issues. Additionally; enabling polling /after/ we call drm_helper_hpd_irq_event() could also mean that we'd miss a hotplug event anyway, since drm_helper_hpd_irq_event() wouldn't bother trying to probe connectors so long as polling is disabled. So; simply move this back into nouveau_display_init() again. The race condition that both of these patches attempted to work around has already been fixed properly in d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend") Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling") Signed-off-by: Lyude Paul Acked-by: Karol Herbst Acked-by: Daniel Vetter Cc: Lukas Wunner Cc: Peter Ujfalusi Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 0f756495557cbbaac0a392f3c160204f8b8f8131 Author: Lyude Paul Date: Tue Aug 7 17:32:48 2018 -0400 drm/nouveau/drm/nouveau: Don't forget to cancel hpd_work on suspend/unload commit 2f7ca781fd382cf8dde73ed36dfdd93fd05b3332 upstream. Currently, there's nothing in nouveau that actually cancels this work struct. So, cancel it on suspend/unload. Otherwise, if we're unlucky enough hpd_work might try to keep running up until the system is suspended. Signed-off-by: Lyude Paul Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 86393a7e3315aa0a57e66857880a8536bab070c8 Author: Lyude Paul Date: Wed Aug 15 15:00:15 2018 -0400 drm/nouveau: Fix deadlocks in nouveau_connector_detect() commit 3e1a12754d4df5804bfca5dedf09d2ba291bdc2a upstream. When we disable hotplugging on the GPU, we need to be able to synchronize with each connector's hotplug interrupt handler before the interrupt is finally disabled. This can be a problem however, since nouveau_connector_detect() currently grabs a runtime power reference when handling connector probing. This will deadlock the runtime suspend handler like so: [ 861.480896] INFO: task kworker/0:2:61 blocked for more than 120 seconds. [ 861.483290] Tainted: G O 4.18.0-rc6Lyude-Test+ #1 [ 861.485158] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 861.486332] kworker/0:2 D 0 61 2 0x80000000 [ 861.487044] Workqueue: events nouveau_display_hpd_work [nouveau] [ 861.487737] Call Trace: [ 861.488394] __schedule+0x322/0xaf0 [ 861.489070] schedule+0x33/0x90 [ 861.489744] rpm_resume+0x19c/0x850 [ 861.490392] ? finish_wait+0x90/0x90 [ 861.491068] __pm_runtime_resume+0x4e/0x90 [ 861.491753] nouveau_display_hpd_work+0x22/0x60 [nouveau] [ 861.492416] process_one_work+0x231/0x620 [ 861.493068] worker_thread+0x44/0x3a0 [ 861.493722] kthread+0x12b/0x150 [ 861.494342] ? wq_pool_ids_show+0x140/0x140 [ 861.494991] ? kthread_create_worker_on_cpu+0x70/0x70 [ 861.495648] ret_from_fork+0x3a/0x50 [ 861.496304] INFO: task kworker/6:2:320 blocked for more than 120 seconds. [ 861.496968] Tainted: G O 4.18.0-rc6Lyude-Test+ #1 [ 861.497654] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 861.498341] kworker/6:2 D 0 320 2 0x80000080 [ 861.499045] Workqueue: pm pm_runtime_work [ 861.499739] Call Trace: [ 861.500428] __schedule+0x322/0xaf0 [ 861.501134] ? wait_for_completion+0x104/0x190 [ 861.501851] schedule+0x33/0x90 [ 861.502564] schedule_timeout+0x3a5/0x590 [ 861.503284] ? mark_held_locks+0x58/0x80 [ 861.503988] ? _raw_spin_unlock_irq+0x2c/0x40 [ 861.504710] ? wait_for_completion+0x104/0x190 [ 861.505417] ? trace_hardirqs_on_caller+0xf4/0x190 [ 861.506136] ? wait_for_completion+0x104/0x190 [ 861.506845] wait_for_completion+0x12c/0x190 [ 861.507555] ? wake_up_q+0x80/0x80 [ 861.508268] flush_work+0x1c9/0x280 [ 861.508990] ? flush_workqueue_prep_pwqs+0x1b0/0x1b0 [ 861.509735] nvif_notify_put+0xb1/0xc0 [nouveau] [ 861.510482] nouveau_display_fini+0xbd/0x170 [nouveau] [ 861.511241] nouveau_display_suspend+0x67/0x120 [nouveau] [ 861.511969] nouveau_do_suspend+0x5e/0x2d0 [nouveau] [ 861.512715] nouveau_pmops_runtime_suspend+0x47/0xb0 [nouveau] [ 861.513435] pci_pm_runtime_suspend+0x6b/0x180 [ 861.514165] ? pci_has_legacy_pm_support+0x70/0x70 [ 861.514897] __rpm_callback+0x7a/0x1d0 [ 861.515618] ? pci_has_legacy_pm_support+0x70/0x70 [ 861.516313] rpm_callback+0x24/0x80 [ 861.517027] ? pci_has_legacy_pm_support+0x70/0x70 [ 861.517741] rpm_suspend+0x142/0x6b0 [ 861.518449] pm_runtime_work+0x97/0xc0 [ 861.519144] process_one_work+0x231/0x620 [ 861.519831] worker_thread+0x44/0x3a0 [ 861.520522] kthread+0x12b/0x150 [ 861.521220] ? wq_pool_ids_show+0x140/0x140 [ 861.521925] ? kthread_create_worker_on_cpu+0x70/0x70 [ 861.522622] ret_from_fork+0x3a/0x50 [ 861.523299] INFO: task kworker/6:0:1329 blocked for more than 120 seconds. [ 861.523977] Tainted: G O 4.18.0-rc6Lyude-Test+ #1 [ 861.524644] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 861.525349] kworker/6:0 D 0 1329 2 0x80000000 [ 861.526073] Workqueue: events nvif_notify_work [nouveau] [ 861.526751] Call Trace: [ 861.527411] __schedule+0x322/0xaf0 [ 861.528089] schedule+0x33/0x90 [ 861.528758] rpm_resume+0x19c/0x850 [ 861.529399] ? finish_wait+0x90/0x90 [ 861.530073] __pm_runtime_resume+0x4e/0x90 [ 861.530798] nouveau_connector_detect+0x7e/0x510 [nouveau] [ 861.531459] ? ww_mutex_lock+0x47/0x80 [ 861.532097] ? ww_mutex_lock+0x47/0x80 [ 861.532819] ? drm_modeset_lock+0x88/0x130 [drm] [ 861.533481] drm_helper_probe_detect_ctx+0xa0/0x100 [drm_kms_helper] [ 861.534127] drm_helper_hpd_irq_event+0xa4/0x120 [drm_kms_helper] [ 861.534940] nouveau_connector_hotplug+0x98/0x120 [nouveau] [ 861.535556] nvif_notify_work+0x2d/0xb0 [nouveau] [ 861.536221] process_one_work+0x231/0x620 [ 861.536994] worker_thread+0x44/0x3a0 [ 861.537757] kthread+0x12b/0x150 [ 861.538463] ? wq_pool_ids_show+0x140/0x140 [ 861.539102] ? kthread_create_worker_on_cpu+0x70/0x70 [ 861.539815] ret_from_fork+0x3a/0x50 [ 861.540521] Showing all locks held in the system: [ 861.541696] 2 locks held by kworker/0:2/61: [ 861.542406] #0: 000000002dbf8af5 ((wq_completion)"events"){+.+.}, at: process_one_work+0x1b3/0x620 [ 861.543071] #1: 0000000076868126 ((work_completion)(&drm->hpd_work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 861.543814] 1 lock held by khungtaskd/64: [ 861.544535] #0: 0000000059db4b53 (rcu_read_lock){....}, at: debug_show_all_locks+0x23/0x185 [ 861.545160] 3 locks held by kworker/6:2/320: [ 861.545896] #0: 00000000d9e1bc59 ((wq_completion)"pm"){+.+.}, at: process_one_work+0x1b3/0x620 [ 861.546702] #1: 00000000c9f92d84 ((work_completion)(&dev->power.work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 861.547443] #2: 000000004afc5de1 (drm_connector_list_iter){.+.+}, at: nouveau_display_fini+0x96/0x170 [nouveau] [ 861.548146] 1 lock held by dmesg/983: [ 861.548889] 2 locks held by zsh/1250: [ 861.549605] #0: 00000000348e3cf6 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40 [ 861.550393] #1: 000000007009a7a8 (&ldata->atomic_read_lock){+.+.}, at: n_tty_read+0xc1/0x870 [ 861.551122] 6 locks held by kworker/6:0/1329: [ 861.551957] #0: 000000002dbf8af5 ((wq_completion)"events"){+.+.}, at: process_one_work+0x1b3/0x620 [ 861.552765] #1: 00000000ddb499ad ((work_completion)(¬ify->work)#2){+.+.}, at: process_one_work+0x1b3/0x620 [ 861.553582] #2: 000000006e013cbe (&dev->mode_config.mutex){+.+.}, at: drm_helper_hpd_irq_event+0x6c/0x120 [drm_kms_helper] [ 861.554357] #3: 000000004afc5de1 (drm_connector_list_iter){.+.+}, at: drm_helper_hpd_irq_event+0x78/0x120 [drm_kms_helper] [ 861.555227] #4: 0000000044f294d9 (crtc_ww_class_acquire){+.+.}, at: drm_helper_probe_detect_ctx+0x3d/0x100 [drm_kms_helper] [ 861.556133] #5: 00000000db193642 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_lock+0x4b/0x130 [drm] [ 861.557864] ============================================= [ 861.559507] NMI backtrace for cpu 2 [ 861.560363] CPU: 2 PID: 64 Comm: khungtaskd Tainted: G O 4.18.0-rc6Lyude-Test+ #1 [ 861.561197] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET78W (1.51 ) 05/18/2018 [ 861.561948] Call Trace: [ 861.562757] dump_stack+0x8e/0xd3 [ 861.563516] nmi_cpu_backtrace.cold.3+0x14/0x5a [ 861.564269] ? lapic_can_unplug_cpu.cold.27+0x42/0x42 [ 861.565029] nmi_trigger_cpumask_backtrace+0xa1/0xae [ 861.565789] arch_trigger_cpumask_backtrace+0x19/0x20 [ 861.566558] watchdog+0x316/0x580 [ 861.567355] kthread+0x12b/0x150 [ 861.568114] ? reset_hung_task_detector+0x20/0x20 [ 861.568863] ? kthread_create_worker_on_cpu+0x70/0x70 [ 861.569598] ret_from_fork+0x3a/0x50 [ 861.570370] Sending NMI from CPU 2 to CPUs 0-1,3-7: [ 861.571426] NMI backtrace for cpu 6 skipped: idling at intel_idle+0x7f/0x120 [ 861.571429] NMI backtrace for cpu 7 skipped: idling at intel_idle+0x7f/0x120 [ 861.571432] NMI backtrace for cpu 3 skipped: idling at intel_idle+0x7f/0x120 [ 861.571464] NMI backtrace for cpu 5 skipped: idling at intel_idle+0x7f/0x120 [ 861.571467] NMI backtrace for cpu 0 skipped: idling at intel_idle+0x7f/0x120 [ 861.571469] NMI backtrace for cpu 4 skipped: idling at intel_idle+0x7f/0x120 [ 861.571472] NMI backtrace for cpu 1 skipped: idling at intel_idle+0x7f/0x120 [ 861.572428] Kernel panic - not syncing: hung_task: blocked tasks So: fix this by making it so that normal hotplug handling /only/ happens so long as the GPU is currently awake without any pending runtime PM requests. In the event that a hotplug occurs while the device is suspending or resuming, we can simply defer our response until the GPU is fully runtime resumed again. Changes since v4: - Use a new trick I came up with using pm_runtime_get() instead of the hackish junk we had before Signed-off-by: Lyude Paul Reviewed-by: Karol Herbst Acked-by: Daniel Vetter Cc: stable@vger.kernel.org Cc: Lukas Wunner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 573eeddd45386418c70adc5d501353e38a53bd75 Author: Lyude Paul Date: Wed Aug 15 15:00:12 2018 -0400 drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend() commit 611ce855420a6e8b9ff47af5f47431d52c7709f8 upstream. Since actual hotplug notifications don't get disabled until nouveau_display_fini() is called, all this will do is cause any hotplugs that happen between this drm_kms_helper_poll_disable() call and the actual hotplug disablement to potentially be dropped if ACPI isn't around to help us. Signed-off-by: Lyude Paul Acked-by: Karol Herbst Acked-by: Daniel Vetter Cc: stable@vger.kernel.org Cc: Lukas Wunner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit aed4ca2690c2e80d86f53883ba331f4b50fffb5c Author: Lyude Paul Date: Thu Aug 9 18:22:05 2018 -0400 drm/nouveau: Only write DP_MSTM_CTRL when needed commit b26b4590dd53e012526342e749c423e6c0e73437 upstream. Currently, nouveau will re-write the DP_MSTM_CTRL register for an MST hub every time it receives a long HPD pulse on DP. This isn't actually necessary and additionally, has some unintended side effects. With the P50 I've got here, rewriting DP_MSTM_CTRL constantly seems to make it rather likely (1 out of 5 times usually) that bringing up MST with it's ThinkPad dock will fail and result in sideband messages timing out in the middle. Afterwards, successive probes don't manage to get the dock to communicate properly over MST sideband properly. Many times sideband message timeouts from MST hubs are indicative of either the source or the sink dropping an ESI event, which can cause DRM's perspective of the topology's current state to go out of sync with reality. While it's tough to really know for sure what's happening to the dock, using userspace tools to write to DP_MSTM_CTRL in the middle of the MST link probing process does appear to make things flaky. It's possible that when we write to DP_MSTM_CTRL, the function that gets triggered to respond in the dock's firmware temporarily puts it in a state where it might end up not reporting an ESI to the source, or ends up dropping a sideband message we sent it. So, to fix this we make it so that when probing an MST topology, we respect it's current state. If the dock's already enabled, we simply read DP_MSTM_CTRL and disable the topology if it's value is not what we expected. Otherwise, we perform the normal MST probing dance. We avoid taking any action except if the state of the MST topology actually changes. This fixes MST sideband message timeouts and detection failures on my P50 with its ThinkPad dock. Signed-off-by: Lyude Paul Cc: stable@vger.kernel.org Cc: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 04393d25720708f809dd877a69391c715a45d4f7 Author: Lyude Paul Date: Thu Aug 9 18:22:06 2018 -0400 drm/nouveau: Reset MST branching unit before enabling commit fa3cdf8d0b092c4561f9f017dfac409eb7644737 upstream. When probing a new MST device, it's not safe to make any assumptions about it's current state. While most well mannered MST hubs will just disable the branching unit on hotplug disconnects, this isn't enough to save us from various other scenarios that might have resulted in something writing to the MST branching unit before we got control of it. This could happen if a previous probe we tried failed, if we're booting in kexec context and the hub is still in the state the last kernel put it in, etc. Luckily; there is no reason we can't just reset the branching unit every time we enable a new topology. So, fix this by resetting it on enabling new topologies to ensure that we always start off with a clean, unmodified topology state on MST sinks. This fixes occasional hard-lockups on my P50's laptop dock (e.g. AUX times out all DPCD trasactions) observed after multiple docks, undocks, and module reloads. Signed-off-by: Lyude Paul Cc: stable@vger.kernel.org Cc: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 1f4401ece98b6492996f67d8645b255ec37a50c5 Author: Imre Deak Date: Wed Sep 5 13:00:05 2018 +0300 drm/i915/bdw: Increase IPS disable timeout to 100ms commit 92a6803149465e2339f8f7f8f6415d75be80073d upstream. During IPS disabling the current 42ms timeout value leads to occasional timeouts, increase it to 100ms which seems to get rid of the problem. References: https://bugs.freedesktop.org/show_bug.cgi?id=107494 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107562 Reported-by: Diego Viola Tested-by: Diego Viola Cc: Diego Viola Cc: Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180905100005.7663-1-imre.deak@intel.com (cherry picked from commit acb3ef0ee40ea657280a4a11d9f60eb2937c0dca) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 1e0be23859b9098593d72c210efbacab5ec5c3b9 Author: Junxiao Bi Date: Thu Sep 20 12:22:51 2018 -0700 ocfs2: fix ocfs2 read block panic commit 234b69e3e089d850a98e7b3145bd00e9b52b1111 upstream. While reading block, it is possible that io error return due to underlying storage issue, in this case, BH_NeedsValidate was left in the buffer head. Then when reading the very block next time, if it was already linked into journal, that will trigger the following panic. [203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342! [203748.702533] invalid opcode: 0000 [#1] SMP [203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod [203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2 [203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015 [203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000 [203748.703088] RIP: 0010:[] [] ocfs2_read_blocks+0x669/0x7f0 [ocfs2] [203748.703130] RSP: 0018:ffff88006ff4b818 EFLAGS: 00010206 [203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000 [203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe [203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0 [203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000 [203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000 [203748.705871] FS: 00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000 [203748.706370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670 [203748.707124] Stack: [203748.707371] ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001 [203748.707885] 0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00 [203748.708399] 00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000 [203748.708915] Call Trace: [203748.709175] [] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2] [203748.709680] [] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2] [203748.710185] [] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2] [203748.710691] [] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2] [203748.711204] [] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2] [203748.711716] [] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2] [203748.712227] [] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2] [203748.712737] [] ocfs2_mknod+0x4b2/0x1370 [ocfs2] [203748.713003] [] ocfs2_create+0x65/0x170 [ocfs2] [203748.713263] [] vfs_create+0xdb/0x150 [203748.713518] [] do_last+0x815/0x1210 [203748.713772] [] ? path_init+0xb9/0x450 [203748.714123] [] path_openat+0x80/0x600 [203748.714378] [] ? handle_pte_fault+0xd15/0x1620 [203748.714634] [] do_filp_open+0x3a/0xb0 [203748.714888] [] ? __alloc_fd+0xa7/0x130 [203748.715143] [] do_sys_open+0x12c/0x220 [203748.715403] [] ? syscall_trace_enter_phase1+0x11b/0x180 [203748.715668] [] ? system_call_after_swapgs+0xe9/0x190 [203748.715928] [] SyS_open+0x1e/0x20 [203748.716184] [] system_call_fastpath+0x18/0xd7 [203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10 [203748.717505] RIP [] ocfs2_read_blocks+0x669/0x7f0 [ocfs2] [203748.717775] RSP Joesph ever reported a similar panic. Link: https://oss.oracle.com/pipermail/ocfs2-devel/2013-May/008931.html Link: http://lkml.kernel.org/r/20180912063207.29484-1-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Cc: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Changwei Ge Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 23fe9688228c87a3bfc693ba1993b7b951b591aa Author: Jens Axboe Date: Thu Sep 20 08:30:55 2018 -0600 libata: mask swap internal and hardware tag commit 7ce5c8cd753f9afa8e79e9ec40351998e354f239 upstream. hen we're comparing the hardware completion mask passed in from the driver with the internal tag pending mask, we need to account for the fact that the internal tag is different from the hardware tag. If not, then we can end up either prematurely completing the internal tag (since it's not set in the hw mask), or simply flag an error: ata2: illegal qc_active transition (100000000->00000001) If the internal tag is set, then swap that with the hardware tag in this case before comparing with what the hardware reports. Fixes: 28361c403683 ("libata: add extra internal command") Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=201151 Cc: stable@vger.kernel.org Reported-by: Paul Sbarra Tested-by: Paul Sbarra Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f8b35f82a252999845289c5e313f841c97314851 Author: Richard Weinberger Date: Sun Sep 16 23:57:35 2018 +0200 Revert "ubifs: xattr: Don't operate on deleted inodes" commit f061c1cc404a618858a77aea233fde0aeaad2f2d upstream. This reverts commit 11a6fc3dc743e22fb50f2196ec55bee5140d3c52. UBIFS wants to assert that xattr operations are only issued on files with positive link count. The said patch made this operations return -ENOENT for unlinked files such that the asserts will no longer trigger. This was wrong since xattr operations are perfectly fine on unlinked files. Instead the assertions need to be fixed/removed. Cc: Fixes: 11a6fc3dc743 ("ubifs: xattr: Don't operate on deleted inodes") Reported-by: Koen Vandeputte Tested-by: Joel Stanley Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 94403d71bb9e515f713749de09f9dcc43f70ab40 Author: Vincent Pelletier Date: Sun Sep 9 04:09:27 2018 +0000 scsi: target: iscsi: Use bin2hex instead of a re-implementation commit 8c39e2699f8acb2e29782a834e56306da24937fe upstream. Signed-off-by: Vincent Pelletier Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 8e31c95fe08501af201f4e8470af1f68d52d6e7e Author: Vincent Pelletier Date: Sun Sep 9 04:09:26 2018 +0000 scsi: target: iscsi: Use hex2bin instead of a re-implementation commit 1816494330a83f2a064499d8ed2797045641f92c upstream. This change has the following effects, in order of descreasing importance: 1) Prevent a stack buffer overflow 2) Do not append an unnecessary NULL to an anyway binary buffer, which is writing one byte past client_digest when caller is: chap_string_to_hex(client_digest, chap_r, strlen(chap_r)); The latter was found by KASAN (see below) when input value hes expected size (32 hex chars), and further analysis revealed a stack buffer overflow can happen when network-received value is longer, allowing an unauthenticated remote attacker to smash up to 17 bytes after destination buffer (16 bytes attacker-controlled and one null). As switching to hex2bin requires specifying destination buffer length, and does not internally append any null, it solves both issues. This addresses CVE-2018-14633. Beyond this: - Validate received value length and check hex2bin accepted the input, to log this rejection reason instead of just failing authentication. - Only log received CHAP_R and CHAP_C values once they passed sanity checks. ================================================================== BUG: KASAN: stack-out-of-bounds in chap_string_to_hex+0x32/0x60 [iscsi_target_mod] Write of size 1 at addr ffff8801090ef7c8 by task kworker/0:0/1021 CPU: 0 PID: 1021 Comm: kworker/0:0 Tainted: G O 4.17.8kasan.sess.connops+ #2 Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 05/19/2014 Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod] Call Trace: dump_stack+0x71/0xac print_address_description+0x65/0x22e ? chap_string_to_hex+0x32/0x60 [iscsi_target_mod] kasan_report.cold.6+0x241/0x2fd chap_string_to_hex+0x32/0x60 [iscsi_target_mod] chap_server_compute_md5.isra.2+0x2cb/0x860 [iscsi_target_mod] ? chap_binaryhex_to_asciihex.constprop.5+0x50/0x50 [iscsi_target_mod] ? ftrace_caller_op_ptr+0xe/0xe ? __orc_find+0x6f/0xc0 ? unwind_next_frame+0x231/0x850 ? kthread+0x1a0/0x1c0 ? ret_from_fork+0x35/0x40 ? ret_from_fork+0x35/0x40 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod] ? deref_stack_reg+0xd0/0xd0 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod] ? is_module_text_address+0xa/0x11 ? kernel_text_address+0x4c/0x110 ? __save_stack_trace+0x82/0x100 ? ret_from_fork+0x35/0x40 ? save_stack+0x8c/0xb0 ? 0xffffffffc1660000 ? iscsi_target_do_login+0x155/0x8d0 [iscsi_target_mod] ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod] ? process_one_work+0x35c/0x640 ? worker_thread+0x66/0x5d0 ? kthread+0x1a0/0x1c0 ? ret_from_fork+0x35/0x40 ? iscsi_update_param_value+0x80/0x80 [iscsi_target_mod] ? iscsit_release_cmd+0x170/0x170 [iscsi_target_mod] chap_main_loop+0x172/0x570 [iscsi_target_mod] ? chap_server_compute_md5.isra.2+0x860/0x860 [iscsi_target_mod] ? rx_data+0xd6/0x120 [iscsi_target_mod] ? iscsit_print_session_params+0xd0/0xd0 [iscsi_target_mod] ? cyc2ns_read_begin.part.2+0x90/0x90 ? _raw_spin_lock_irqsave+0x25/0x50 ? memcmp+0x45/0x70 iscsi_target_do_login+0x875/0x8d0 [iscsi_target_mod] ? iscsi_target_check_first_request.isra.5+0x1a0/0x1a0 [iscsi_target_mod] ? del_timer+0xe0/0xe0 ? memset+0x1f/0x40 ? flush_sigqueue+0x29/0xd0 iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod] ? iscsi_target_nego_release+0x80/0x80 [iscsi_target_mod] ? iscsi_target_restore_sock_callbacks+0x130/0x130 [iscsi_target_mod] process_one_work+0x35c/0x640 worker_thread+0x66/0x5d0 ? flush_rcu_work+0x40/0x40 kthread+0x1a0/0x1c0 ? kthread_bind+0x30/0x30 ret_from_fork+0x35/0x40 The buggy address belongs to the page: page:ffffea0004243bc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0 flags: 0x17fffc000000000() raw: 017fffc000000000 0000000000000000 0000000000000000 00000000ffffffff raw: ffffea0004243c20 ffffea0004243ba0 0000000000000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8801090ef680: f2 f2 f2 f2 f2 f2 f2 01 f2 f2 f2 f2 f2 f2 f2 00 ffff8801090ef700: f2 f2 f2 f2 f2 f2 f2 00 02 f2 f2 f2 f2 f2 f2 00 >ffff8801090ef780: 00 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2 f2 00 ^ ffff8801090ef800: 00 f2 f2 f2 f2 f2 f2 00 00 00 00 02 f2 f2 f2 f2 ffff8801090ef880: f2 f2 f2 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 ================================================================== Signed-off-by: Vincent Pelletier Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 31426b50594c12802e77bcba69f5f5169cdf0dd5 Author: Lubomir Rintel Date: Mon Sep 24 13:18:34 2018 +0100 Revert "uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name" commit 8c0f9f5b309d627182d5da72a69246f58bde1026 upstream. This changes UAPI, breaking iwd and libell: ell/key.c: In function 'kernel_dh_compute': ell/key.c:205:38: error: 'struct keyctl_dh_params' has no member named 'private'; did you mean 'dh_private'? struct keyctl_dh_params params = { .private = private, ^~~~~~~ dh_private This reverts commit 8a2336e549d385bb0b46880435b411df8d8200e8. Fixes: 8a2336e549d3 ("uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name") Signed-off-by: Lubomir Rintel Signed-off-by: David Howells cc: Randy Dunlap cc: Mat Martineau cc: Stephan Mueller cc: James Morris cc: "Serge E. Hallyn" cc: Mat Martineau cc: Andrew Morton cc: Linus Torvalds cc: Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit bc35488686c34703e5f0909c7a6cb0b942bfcf58 Author: Alexei Starovoitov Date: Wed Sep 12 14:06:10 2018 -0700 bpf/verifier: disallow pointer subtraction commit dd066823db2ac4e22f721ec85190817b58059a54 upstream. Subtraction of pointers was accidentally allowed for unpriv programs by commit 82abbf8d2fc4. Revert that part of commit. Fixes: 82abbf8d2fc4 ("bpf: do not allow root to mangle valid pointers") Reported-by: Jann Horn Acked-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman commit 909828a2920bb029f847c8d96385cba941e9790d Author: Greg Kroah-Hartman Date: Wed Sep 26 13:53:39 2018 +0200 Revert "rpmsg: core: add support to power domains for devices" This reverts commit e5d9ae0077a5cf336d298002959dc0c8dcfe7b89 which is commit fe782affd0f440a4e60e2cc81b8f2eccb2923113 upstream Rafael reports that this patch causes problems: > -rc2 looks good. There is a problem on dragonboard during boot that was > introduced in v4.14.71 that I didn't notice last week. We'll bisect it > and report back later this week. dragonboard on the other branches (4.9, > 4.18, mainline) looks fine. As Dan pointed out, during validation, we have bisected this issue on a dragonboard 410c (can't find root device) to the following commit for v4.14: [1ed3a9307230] rpmsg: core: add support to power domains for devices There is an on-going discussion on "[PATCH] rpmsg: core: add support to power domains for devices" about this patch having other dependencies and breaking something else on v4.14 as well. so drop it. Reported-by: Rafael Tinoco Cc: Srinivas Kandagatla Cc: Bjorn Andersson Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 946f8052f7eeb19aa07bb8249ac97fd752495317 Author: Joel Fernandes (Google) Date: Thu Sep 20 12:22:39 2018 -0700 mm: shmem.c: Correctly annotate new inodes for lockdep commit b45d71fb89ab8adfe727b9d0ee188ed58582a647 upstream. Directories and inodes don't necessarily need to be in the same lockdep class. For ex, hugetlbfs splits them out too to prevent false positives in lockdep. Annotate correctly after new inode creation. If its a directory inode, it will be put into a different class. This should fix a lockdep splat reported by syzbot: > ====================================================== > WARNING: possible circular locking dependency detected > 4.18.0-rc8-next-20180810+ #36 Not tainted > ------------------------------------------------------ > syz-executor900/4483 is trying to acquire lock: > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock > include/linux/fs.h:765 [inline] > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > > but task is already holding lock: > 0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630 > drivers/staging/android/ashmem.c:448 > > which lock already depends on the new lock. > > -> #2 (ashmem_mutex){+.+.}: > __mutex_lock_common kernel/locking/mutex.c:925 [inline] > __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073 > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088 > ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361 > call_mmap include/linux/fs.h:1844 [inline] > mmap_region+0xf27/0x1c50 mm/mmap.c:1762 > do_mmap+0xa10/0x1220 mm/mmap.c:1535 > do_mmap_pgoff include/linux/mm.h:2298 [inline] > vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357 > ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585 > __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline] > __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline] > __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #1 (&mm->mmap_sem){++++}: > __might_fault+0x155/0x1e0 mm/memory.c:4568 > _copy_to_user+0x30/0x110 lib/usercopy.c:25 > copy_to_user include/linux/uaccess.h:155 [inline] > filldir+0x1ea/0x3a0 fs/readdir.c:196 > dir_emit_dot include/linux/fs.h:3464 [inline] > dir_emit_dots include/linux/fs.h:3475 [inline] > dcache_readdir+0x13a/0x620 fs/libfs.c:193 > iterate_dir+0x48b/0x5d0 fs/readdir.c:51 > __do_sys_getdents fs/readdir.c:231 [inline] > __se_sys_getdents fs/readdir.c:212 [inline] > __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #0 (&sb->s_type->i_mutex_key#9){++++}: > lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924 > down_write+0x8f/0x130 kernel/locking/rwsem.c:70 > inode_lock include/linux/fs.h:765 [inline] > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455 > ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:501 [inline] > do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 > __do_sys_ioctl fs/ioctl.c:709 [inline] > __se_sys_ioctl fs/ioctl.c:707 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > other info that might help us debug this: > > Chain exists of: > &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex > > Possible unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(ashmem_mutex); > lock(&mm->mmap_sem); > lock(ashmem_mutex); > lock(&sb->s_type->i_mutex_key#9); > > *** DEADLOCK *** > > 1 lock held by syz-executor900/4483: > #0: 0000000025208078 (ashmem_mutex){+.+.}, at: > ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448 Link: http://lkml.kernel.org/r/20180821231835.166639-1-joel@joelfernandes.org Signed-off-by: Joel Fernandes (Google) Reported-by: syzbot Reviewed-by: NeilBrown Suggested-by: NeilBrown Cc: Matthew Wilcox Cc: Peter Zijlstra Cc: Hugh Dickins Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4cdb6f01e9e5bf507a391a8cf826833d41053771 Author: Pasha Tatashin Date: Thu Sep 20 12:22:30 2018 -0700 mm: disable deferred struct page for 32-bit arches commit 889c695d419f19e5db52592dafbaf26143c36d1f upstream. Deferred struct page init is needed only on systems with large amount of physical memory to improve boot performance. 32-bit systems do not benefit from this feature. Jiri reported a problem where deferred struct pages do not work well with x86-32: [ 0.035162] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.035725] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.036269] Initializing CPU#0 [ 0.036513] Initializing HighMem for node 0 (00036ffe:0007ffe0) [ 0.038459] page:f6780000 is uninitialized and poisoned [ 0.038460] raw: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff [ 0.039509] page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page)) [ 0.040038] ------------[ cut here ]------------ [ 0.040399] kernel BUG at include/linux/page-flags.h:293! [ 0.040823] invalid opcode: 0000 [#1] SMP PTI [ 0.041166] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc1_pt_jiri #9 [ 0.041694] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 [ 0.042496] EIP: free_highmem_page+0x64/0x80 [ 0.042839] Code: 13 46 d8 c1 e8 18 5d 83 e0 03 8d 04 c0 c1 e0 06 ff 80 ec 5f 44 d8 c3 8d b4 26 00 00 00 00 ba 08 65 28 d8 89 d8 e8 fc 71 02 00 <0f> 0b 8d 76 00 8d bc 27 00 00 00 00 ba d0 b1 26 d8 89 d8 e8 e4 71 [ 0.044338] EAX: 0000003c EBX: f6780000 ECX: 00000000 EDX: d856cbe8 [ 0.044868] ESI: 0007ffe0 EDI: d838df20 EBP: d838df00 ESP: d838defc [ 0.045372] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210086 [ 0.045913] CR0: 80050033 CR2: 00000000 CR3: 18556000 CR4: 00040690 [ 0.046413] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 0.046913] DR6: fffe0ff0 DR7: 00000400 [ 0.047220] Call Trace: [ 0.047419] add_highpages_with_active_regions+0xbd/0x10d [ 0.047854] set_highmem_pages_init+0x5b/0x71 [ 0.048202] mem_init+0x2b/0x1e8 [ 0.048460] start_kernel+0x1d2/0x425 [ 0.048757] i386_start_kernel+0x93/0x97 [ 0.049073] startup_32_smp+0x164/0x168 [ 0.049379] Modules linked in: [ 0.049626] ---[ end trace 337949378db0abbb ]--- We free highmem pages before their struct pages are initialized: mem_init() set_highmem_pages_init() add_highpages_with_active_regions() free_highmem_page() .. Access uninitialized struct page here.. Because there is no reason to have this feature on 32-bit systems, just disable it. Link: http://lkml.kernel.org/r/20180831150506.31246-1-pavel.tatashin@microsoft.com Fixes: 2e3ca40f03bb ("mm: relax deferred struct page requirements") Signed-off-by: Pavel Tatashin Reported-by: Jiri Slaby Acked-by: Michal Hocko Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3299a0eead685bd92955e94001a519accc0ca3bd Author: KJ Tsanaktsidis Date: Thu Sep 20 12:22:25 2018 -0700 fork: report pid exhaustion correctly commit f83606f5eb007adc33bc8541ede00590f477bdeb upstream. Make the clone and fork syscalls return EAGAIN when the limit on the number of pids /proc/sys/kernel/pid_max is exceeded. Currently, when the pid_max limit is exceeded, the kernel will return ENOSPC from the fork and clone syscalls. This is contrary to the documented behaviour, which explicitly calls out the pid_max case as one where EAGAIN should be returned. It also leads to really confusing error messages in userspace programs which will complain about a lack of disk space when they fail to create processes/threads for this reason. This error is being returned because alloc_pid() uses the idr api to find a new pid; when there are none available, idr_alloc_cyclic() returns -ENOSPC, and this is being propagated back to userspace. This behaviour has been broken before, and was explicitly fixed in commit 35f71bc0a09a ("fork: report pid reservation failure properly"), so I think -EAGAIN is definitely the right thing to return in this case. The current behaviour change dates from commit 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP") and was I believe unintentional. This patch has no impact on the case where allocating a pid fails because the child reaper for the namespace is dead; that case will still return -ENOMEM. Link: http://lkml.kernel.org/r/20180903111016.46461-1-ktsanaktsidis@zendesk.com Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP") Signed-off-by: KJ Tsanaktsidis Reviewed-by: Andrew Morton Acked-by: Michal Hocko Cc: Gargi Sharma Cc: Rik van Riel Cc: Oleg Nesterov Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 30938d20eb1a6e4cb62ae747f37bc9e2645c9f58 Author: Ondrej Mosnacek Date: Wed Sep 5 09:26:41 2018 +0200 crypto: x86/aegis,morus - Do not require OSXSAVE for SSE2 commit 24568b47d48ec8c906fd0f589489a08b17e1edca upstream. It turns out OSXSAVE needs to be checked only for AVX, not for SSE. Without this patch the affected modules refuse to load on CPUs with SSE2 but without AVX support. Fixes: 877ccce7cbe8 ("crypto: x86/aegis,morus - Fix and simplify CPUID checks") Cc: # 4.18 Reported-by: Zdenek Kaspar Signed-off-by: Ondrej Mosnacek Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d73ccd8bb7323b09ae4b2ef750a82262720e94cf Author: Vaibhav Nagarnaik Date: Fri Sep 7 15:31:29 2018 -0700 ring-buffer: Allow for rescheduling when removing pages commit 83f365554e47997ec68dc4eca3f5dce525cd15c3 upstream. When reducing ring buffer size, pages are removed by scheduling a work item on each CPU for the corresponding CPU ring buffer. After the pages are removed from ring buffer linked list, the pages are free()d in a tight loop. The loop does not give up CPU until all pages are removed. In a worst case behavior, when lot of pages are to be freed, it can cause system stall. After the pages are removed from the list, the free() can happen while the work is rescheduled. Call cond_resched() in the loop to prevent the system hangup. Link: http://lkml.kernel.org/r/20180907223129.71994-1-vnagarnaik@google.com Cc: stable@vger.kernel.org Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic") Reported-by: Jason Behmer Signed-off-by: Vaibhav Nagarnaik Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 6bed4f10277b0e97922326b2ab4fa251d15482c0 Author: Mika Westerberg Date: Wed Sep 5 14:09:54 2018 +0300 Revert "PCI: Add ACS quirk for Intel 300 series" commit 50ca031b51106b1b46162d4e9ecccb7edc95682f upstream. This reverts f154a718e6cc ("PCI: Add ACS quirk for Intel 300 series"). It turns out that erratum "PCH PCIe* Controller Root Port (ACSCTLR) Appear As Read Only" has been fixed in 300 series chipsets, even though the datasheet [1] claims otherwise. To make ACS work properly on 300 series root ports, revert the faulty commit. [1] https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/300-series-c240-series-chipset-pch-spec-update.pdf Fixes: f154a718e6cc ("PCI: Add ACS quirk for Intel 300 series") Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Greg Kroah-Hartman commit 6d8911403d991dfda859f5059af6f7c3071a2600 Author: Kirill Kapranov Date: Mon Aug 13 19:48:10 2018 +0300 spi: fix IDR collision on systems with both fixed and dynamic SPI bus numbers commit 1a4327fbf4554d5b78d75b19a13d40d6de220159 upstream. On systems where some controllers get a dynamic ID assigned and some have a fixed number (e.g. from ACPI tables), the current implementation might run into an IDR collision: in case of a fixed bus number is gotten by a driver (but not marked busy in IDR tree) and a driver with dynamic bus number gets the same ID and predictably fails. Fix this by means of checking-in fixed IDsin IDR as far as dynamic ones at the moment of the controller registration. Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) Signed-off-by: Kirill Kapranov Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1318b2c26b783f94045678c5056720a86b20a418 Author: Boris Ostrovsky Date: Thu Jul 12 13:27:00 2018 -0400 xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code commit 70513d58751d7c6c1a0133557b13089b9f2e3e66 upstream. Otherwise we may leak kernel stack for events that sample user registers. Reported-by: Mark Rutland Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b73a161e9beff24bf1803ba393dff95a255268f9 Author: Juergen Gross Date: Tue Sep 11 09:04:48 2018 +0200 xen/netfront: don't bug in case of too many frags commit ad4f15dc2c70b1de5e0a64d27335962fbc9cf71c upstream. Commit 57f230ab04d291 ("xen/netfront: raise max number of slots in xennet_get_responses()") raised the max number of allowed slots by one. This seems to be problematic in some configurations with netback using a larger MAX_SKB_FRAGS value (e.g. old Linux kernel with MAX_SKB_FRAGS defined as 18 instead of nowadays 17). Instead of BUG_ON() in this case just fall back to retransmission. Fixes: 57f230ab04d291 ("xen/netfront: raise max number of slots in xennet_get_responses()") Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5e17a1ecc44be1b9ed4bc94838749c99c9dff86b Author: Mario Limonciello Date: Mon Sep 10 13:01:53 2018 -0500 platform/x86: alienware-wmi: Correct a memory leak commit ff0e9f26288d2daee4950f42b37a3d3d30d36ec1 upstream. An ACPI buffer that was allocated was not being freed after use. Signed-off-by: Mario Limonciello Cc: stable@vger.kernel.org Signed-off-by: Darren Hart (VMware) Signed-off-by: Greg Kroah-Hartman commit 8879342a67a4c0986dd48f8d4381b94999ada174 Author: Mario Limonciello Date: Mon Sep 10 13:01:52 2018 -0500 platform/x86: dell-smbios-wmi: Correct a memory leak commit affab51082174f60ef71ced8ab5fbe71f00e9ae3 upstream. ACPI buffers were being allocated but never freed. Reported-by: Pinzhen Xu Signed-off-by: Mario Limonciello Cc: stable@vger.kernel.org Signed-off-by: Darren Hart (VMware) Signed-off-by: Greg Kroah-Hartman commit 0639ddca2c8cfdfe9b443712914de9a824908d19 Author: Masahiro Yamada Date: Thu Sep 13 14:58:49 2018 +0900 mtd: rawnand: denali: fix a race condition when DMA is kicked commit cf51e4b9c34407bf0c3d9b582b7837e047e1df47 upstream. I thought the read-back of the DMA_ENABLE register was unnecessary (at least it is working on my boards), then deleted it in commit 586a2c52909d ("mtd: nand: denali: squash denali_enable_dma() helper into caller"). Sorry, I was wrong - it caused a timing issue on Cyclone5 SoCFPGAs. Revive the register read-back, commenting why this is necessary. Fixes: 586a2c52909d ("mtd: nand: denali: squash denali_enable_dma() helper into caller") Cc: Reported-by: Steffen Trumtrar Signed-off-by: Masahiro Yamada Reviewed-by: Miquel Raynal Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit f11b8aad34fa7b0ec1ca2a45d2d2a826ebf41c32 Author: Boris Brezillon Date: Mon Sep 17 16:31:30 2018 +0200 mtd: devices: m25p80: Make sure the buffer passed in op is DMA-able commit 4a3e85f2674cbfb81052059107d0165269778e2f upstream. As documented in spi-mem.h, spi_mem_op->data.buf.{in,out} must be DMA-able, and commit 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx() API") failed to follow this rule as buffers passed to ->{read,write}_reg() are usually placed on the stack. Fix that by allocating a scratch buffer and copying the data around. Fixes: 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx() API") Reported-by: Jarkko Nikula Cc: Signed-off-by: Boris Brezillon Tested-by: Jarkko Nikula Reviewed-by: Jarkko Nikula Signed-off-by: Greg Kroah-Hartman commit 1501a0f2e14ea7fc0028fe17eaa4a28231af7887 Author: Takashi Sakamoto Date: Thu Sep 13 21:31:18 2018 +0900 ALSA: oxfw: fix memory leak of private data commit 498fe23aad8e3b5a9554f55719c537603b4476ea upstream. Although private data of sound card instance is usually allocated in the tail of the instance, drivers in ALSA firewire stack allocate the private data before allocating the instance. In this case, the private data should be released explicitly at .private_free callback of the instance. This commit fixes memory leak following to the above design. Fixes: 6c29230e2a5f ('ALSA: oxfw: delayed registration of sound card') Cc: # v4.7+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9d07f491db952d1ae98c430f7c4ef62482ec11ea Author: Takashi Sakamoto Date: Mon Sep 17 17:26:20 2018 +0900 ALSA: oxfw: fix memory leak of discovered stream formats at error path commit 1064bc685d359f549f91c2d5f111965a9284f328 upstream. After finishing discover of stream formats, ALSA OXFW driver has memory leak of allocated memory object at error path. This commit releases the memory object at the error path. Fixes: 6c29230e2a5f ('ALSA: oxfw: delayed registration of sound card') Cc: # v4.7+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 82567fb0984625e5e11b89ecbfbbb4654a2a313b Author: Takashi Sakamoto Date: Mon Sep 17 17:26:08 2018 +0900 ALSA: oxfw: fix memory leak for model-dependent data at error path commit ce925f088b979537f22f9e05eb923ef9822ca139 upstream. After allocating model-dependent data, ALSA OXFW driver has memory leak of the data at error path. This commit releases the data at the error path. Fixes: 6c29230e2a5f ('ALSA: oxfw: delayed registration of sound card') Cc: # v4.7+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8e54fc8910f3d131be47d434fcde15d409ae62f1 Author: Takashi Sakamoto Date: Mon Sep 17 17:26:41 2018 +0900 ALSA: fireworks: fix memory leak of response buffer at error path commit c3b55e2ec9c76e7a0de2a0b1dc851fdc9440385b upstream. After allocating memory object for response buffer, ALSA fireworks driver has leak of the memory object at error path. This commit releases the object at the error path. Fixes: 7d3c1d5901aa('ALSA: fireworks: delayed registration of sound card') Cc: # v4.7+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e5301d45d01c27a8f214bedb2a93fd4ec41c1186 Author: Takashi Sakamoto Date: Thu Sep 13 21:31:05 2018 +0900 ALSA: firewire-tascam: fix memory leak of private data commit 8d28277c065a974873c6781d44b7bcdcd8fb4e8a upstream. Although private data of sound card instance is usually allocated in the tail of the instance, drivers in ALSA firewire stack allocate the private data before allocating the instance. In this case, the private data should be released explicitly at .private_free callback of the instance. This commit fixes memory leak following to the above design. Fixes: b610386c8afb ('ALSA: firewire-tascam: deleyed registration of sound card') Cc: # v4.7+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7c57a806be787c080854e93cfbf643b9f5c18eae Author: Takashi Sakamoto Date: Thu Sep 13 21:30:34 2018 +0900 ALSA: firewire-digi00x: fix memory leak of private data commit a49a83ab05e34edd6c71a4fbd062c9a7ba6d18aa upstream. Although private data of sound card instance is usually allocated in the tail of the instance, drivers in ALSA firewire stack allocate the private data before allocating the instance. In this case, the private data should be released explicitly at .private_free callback of the instance. This commit fixes memory leak following to the above design. Fixes: 86c8dd7f4da3 ('ALSA: firewire-digi00x: delayed registration of sound card') Cc: # v4.7+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e9355495975d8a6b07470aaff25073564e765e86 Author: Takashi Sakamoto Date: Sun Sep 9 22:25:52 2018 +0900 ALSA: fireface: fix memory leak in ff400_switch_fetching_mode() commit 36f3a6e02c143a7e9e4e143e416371f67bc1fae6 upstream. An allocated memory forgets to be released. Fixes: 76fdb3a9e13 ('ALSA: fireface: add support for Fireface 400') Cc: # 4.12+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cedfb9f8a588ea7f72d7c232fa09beadc338d9ed Author: Willy Tarreau Date: Sat Sep 8 08:12:21 2018 +0200 ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO commit 49434c6c575d2008c0abbc93e615019f39e01252 upstream. snd_emu10k1_fx8010_ioctl(SNDRV_EMU10K1_IOCTL_INFO) allocates memory using kmalloc() and partially fills it by calling snd_emu10k1_fx8010_info() before returning the resulting structure to userspace, leaving uninitialized holes. Let's just use kzalloc() here. BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html Signed-off-by: Willy Tarreau Cc: Jann Horn Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c143935a34a50e1a6dfba3da2da8809ebe90f2d1 Author: Takashi Sakamoto Date: Sun Sep 9 22:25:12 2018 +0900 ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping commit 493626f2d87a74e6dbea1686499ed6e7e600484e upstream. When executing 'fw_run_transaction()' with 'TCODE_WRITE_BLOCK_REQUEST', an address of 'payload' argument is used for streaming DMA mapping by 'firewire_ohci' module if 'size' argument is larger than 8 byte. Although in this case the address should not be on kernel stack, current implementation of ALSA bebob driver uses data in kernel stack for a cue to boot M-Audio devices. This often brings unexpected result, especially for a case of CONFIG_VMAP_STACK=y. This commit fixes the bug. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=201021 Reference: https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165 Fixes: a2b2a7798fb6('ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series') Cc: # v3.16+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 28114caeb0ab2edb0181866a040965cd74169571 Author: Takashi Sakamoto Date: Mon Sep 17 17:25:24 2018 +0900 ALSA: bebob: fix memory leak for M-Audio FW1814 and ProjectMix I/O at error path commit b1fbebd4164b3d170ad916dcd692cf843c9c065d upstream. After allocating model-dependent data for M-Audio FW1814 and ProjectMix I/O, ALSA bebob driver has memory leak at error path. This commit releases the allocated data at the error path. Fixes: 04a2c73c97eb('ALSA: bebob: delayed registration of sound card') Cc: # v4.7+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 30100a47516788e46f8063ad2b0bdf1ef224ef1e Author: Dmitry V. Levin Date: Mon Aug 13 18:50:02 2018 +0300 ASoC: uapi: fix sound/skl-tplg-interface.h userspace compilation errors commit fb504caae7ef85be159743bd4b08ecde269ba55f upstream. Include and consistently use types it provides to fix the following sound/skl-tplg-interface.h userspace compilation errors: /usr/include/sound/skl-tplg-interface.h:146:2: error: unknown type name 'u32' u32 set_params:2; /usr/include/sound/skl-tplg-interface.h:147:2: error: unknown type name 'u32' u32 rsvd:30; /usr/include/sound/skl-tplg-interface.h:148:2: error: unknown type name 'u32' u32 param_id; /usr/include/sound/skl-tplg-interface.h:149:2: error: unknown type name 'u32' u32 max; /usr/include/sound/skl-tplg-interface.h:166:2: error: unknown type name 'u16' u16 module_id; /usr/include/sound/skl-tplg-interface.h:167:2: error: unknown type name 'u16' u16 instance_id; /usr/include/sound/skl-tplg-interface.h:171:2: error: unknown type name 'u32' u32 channels; /usr/include/sound/skl-tplg-interface.h:172:2: error: unknown type name 'u32' u32 freq; /usr/include/sound/skl-tplg-interface.h:173:2: error: unknown type name 'u32' u32 bit_depth; /usr/include/sound/skl-tplg-interface.h:174:2: error: unknown type name 'u32' u32 valid_bit_depth; /usr/include/sound/skl-tplg-interface.h:175:2: error: unknown type name 'u32' u32 ch_cfg; /usr/include/sound/skl-tplg-interface.h:176:2: error: unknown type name 'u32' u32 interleaving_style; /usr/include/sound/skl-tplg-interface.h:177:2: error: unknown type name 'u32' u32 sample_type; /usr/include/sound/skl-tplg-interface.h:178:2: error: unknown type name 'u32' u32 ch_map; /usr/include/sound/skl-tplg-interface.h:182:2: error: unknown type name 'u32' u32 set_params:2; /usr/include/sound/skl-tplg-interface.h:183:2: error: unknown type name 'u32' u32 rsvd:30; /usr/include/sound/skl-tplg-interface.h:184:2: error: unknown type name 'u32' u32 param_id; /usr/include/sound/skl-tplg-interface.h:185:2: error: unknown type name 'u32' u32 caps_size; /usr/include/sound/skl-tplg-interface.h:186:2: error: unknown type name 'u32' u32 caps[HDA_SST_CFG_MAX]; /usr/include/sound/skl-tplg-interface.h:190:2: error: unknown type name 'u8' u8 pipe_id; /usr/include/sound/skl-tplg-interface.h:191:2: error: unknown type name 'u8' u8 pipe_priority; /usr/include/sound/skl-tplg-interface.h:192:2: error: unknown type name 'u16' u16 conn_type:4; /usr/include/sound/skl-tplg-interface.h:193:2: error: unknown type name 'u16' u16 rsvd:4; /usr/include/sound/skl-tplg-interface.h:194:2: error: unknown type name 'u16' u16 memory_pages:8; /usr/include/sound/skl-tplg-interface.h:200:2: error: unknown type name 'u16' u16 module_id; /usr/include/sound/skl-tplg-interface.h:201:2: error: unknown type name 'u16' u16 instance_id; /usr/include/sound/skl-tplg-interface.h:202:2: error: unknown type name 'u32' u32 max_mcps; /usr/include/sound/skl-tplg-interface.h:203:2: error: unknown type name 'u32' u32 mem_pages; /usr/include/sound/skl-tplg-interface.h:204:2: error: unknown type name 'u32' u32 obs; /usr/include/sound/skl-tplg-interface.h:205:2: error: unknown type name 'u32' u32 ibs; /usr/include/sound/skl-tplg-interface.h:206:2: error: unknown type name 'u32' u32 vbus_id; /usr/include/sound/skl-tplg-interface.h:208:2: error: unknown type name 'u32' u32 max_in_queue:8; /usr/include/sound/skl-tplg-interface.h:209:2: error: unknown type name 'u32' u32 max_out_queue:8; /usr/include/sound/skl-tplg-interface.h:210:2: error: unknown type name 'u32' u32 time_slot:8; /usr/include/sound/skl-tplg-interface.h:211:2: error: unknown type name 'u32' u32 core_id:4; /usr/include/sound/skl-tplg-interface.h:212:2: error: unknown type name 'u32' u32 rsvd1:4; /usr/include/sound/skl-tplg-interface.h:214:2: error: unknown type name 'u32' u32 module_type:8; /usr/include/sound/skl-tplg-interface.h:215:2: error: unknown type name 'u32' u32 conn_type:4; /usr/include/sound/skl-tplg-interface.h:216:2: error: unknown type name 'u32' u32 dev_type:4; /usr/include/sound/skl-tplg-interface.h:217:2: error: unknown type name 'u32' u32 hw_conn_type:4; /usr/include/sound/skl-tplg-interface.h:218:2: error: unknown type name 'u32' u32 rsvd2:12; /usr/include/sound/skl-tplg-interface.h:220:2: error: unknown type name 'u32' u32 params_fixup:8; /usr/include/sound/skl-tplg-interface.h:221:2: error: unknown type name 'u32' u32 converter:8; /usr/include/sound/skl-tplg-interface.h:222:2: error: unknown type name 'u32' u32 input_pin_type:1; /usr/include/sound/skl-tplg-interface.h:223:2: error: unknown type name 'u32' u32 output_pin_type:1; /usr/include/sound/skl-tplg-interface.h:224:2: error: unknown type name 'u32' u32 is_dynamic_in_pin:1; /usr/include/sound/skl-tplg-interface.h:225:2: error: unknown type name 'u32' u32 is_dynamic_out_pin:1; /usr/include/sound/skl-tplg-interface.h:226:2: error: unknown type name 'u32' u32 is_loadable:1; /usr/include/sound/skl-tplg-interface.h:227:2: error: unknown type name 'u32' u32 rsvd3:11; Fixes: 0c24fdc00244 ("ASoC: topology: Move skl-tplg-interface.h to uapi") Signed-off-by: Dmitry V. Levin Reviewed-by: Guenter Roeck Signed-off-by: Mark Brown Cc: # v4.18 Signed-off-by: Greg Kroah-Hartman commit 341ff629a2e9bfe1ed786cd06186bc727f0cce21 Author: Jiada Wang Date: Mon Sep 3 07:08:58 2018 +0000 ASoC: rsnd: fixup not to call clk_get/set under non-atomic commit 4d230d12710646788af581ba0155d83ab48b955c upstream. Clocking operations clk_get/set_rate, are non-atomic, they shouldn't be called in soc_pcm_trigger() which is atomic. Following issue was found due to execution of clk_get_rate() causes sleep in soc_pcm_trigger(), which shouldn't be blocked. We can reproduce this issue by following > enable CONFIG_DEBUG_ATOMIC_SLEEP=y > compile, and boot > mount -t debugfs none /sys/kernel/debug > while true; do cat /sys/kernel/debug/clk/clk_summary > /dev/null; done & > while true; do aplay xxx; done This patch adds support to .prepare callback, and moves non-atomic clocking operations to it. As .prepare is non-atomic, it is always called before trigger_start/trigger_stop. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620 in_atomic(): 1, irqs_disabled(): 128, pid: 2242, name: aplay INFO: lockdep is turned off. irq event stamp: 5964 hardirqs last enabled at (5963): [] mutex_lock_nested+0x6e8/0x6f0 hardirqs last disabled at (5964): [] _raw_spin_lock_irqsave+0x24/0x68 softirqs last enabled at (5502): [] __do_softirq+0x560/0x10c0 softirqs last disabled at (5495): [] irq_exit+0x160/0x25c Preemption disabled at:[ 62.904063] [] snd_pcm_stream_lock+0xb4/0xc0 CPU: 2 PID: 2242 Comm: aplay Tainted: G B C 4.9.54+ #186 Hardware name: Renesas Salvator-X board based on r8a7795 (DT) Call trace: [] dump_backtrace+0x0/0x37c [] show_stack+0x14/0x1c [] dump_stack+0xfc/0x154 [] ___might_sleep+0x57c/0x58c [] __might_sleep+0x208/0x21c [] mutex_lock_nested+0xb4/0x6f0 [] clk_prepare_lock+0xb0/0x184 [] clk_core_get_rate+0x14/0x54 [] clk_get_rate+0x20/0x34 [] rsnd_adg_ssi_clk_try_start+0x158/0x4f8 [snd_soc_rcar] [] rsnd_ssi_init+0x668/0x7a0 [snd_soc_rcar] [] rsnd_soc_dai_trigger+0x4bc/0xcf8 [snd_soc_rcar] [] soc_pcm_trigger+0x2a4/0x2d4 Fixes: e7d850dd10f4 ("ASoC: rsnd: use mod base common method on SSI-parent") Signed-off-by: Jiada Wang Signed-off-by: Timo Wischer [Kuninori: tidyup for upstream] Signed-off-by: Kuninori Morimoto Tested-by: Hiroyuki Yokoyama Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9e6a69b065758615c0b631e5675403e086f88c7c Author: Andrew F. Davis Date: Fri Aug 31 10:14:05 2018 -0500 ASoC: tas6424: Save last fault register even when clear commit d40e3e9e44db4b3c8777f3b515ba6097ba26e3b2 upstream. When there is no fault bit set in a fault register we skip the fault reporting section for that register. This also skips over saving that registers value. We save the value so we will not double report an error, but if an error clears then returns we will also not report it as we did not save the all cleared register value. Fix this by saving the fault register value in the all clear path. Signed-off-by: Andrew F. Davis Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit df231dbe93ebefdc2bd959550fe4856472113251 Author: Sébastien Szymanski Date: Thu Sep 6 11:16:00 2018 +0200 ASoC: cs4265: fix MMTLR Data switch control commit 90a3b7f8aba3011badacd6d8121e03aa24ac79d1 upstream. The MMTLR bit is in the CS4265_SPDIF_CTL2 register at address 0x12 bit 0 and not at address 0x0 bit 1. Fix this. Signed-off-by: Sébastien Szymanski Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 401e975e5950ad9f64f6348c21f6c05e65e0de91 Author: Marcel Ziswiler Date: Tue Aug 14 00:35:56 2018 +0200 ASoC: wm9712: fix replace codec to component commit 5e4cfadaf5b73a0801b2fa7fb007f98400ebfe6e upstream. Since commit 143b44845d87 ("ASoC: wm9712: replace codec to component") "wm9712-codec" got renamed to "wm9712-component", however, this change never got propagated down to the actual board/platform drivers. E.g. on Colibri T20 this lead to the following spew upon boot with sound/touch being broken: [ 2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 14.970443] ALSA device list: [ 14.996628] No soundcards found. This commit finally fixes this again. Signed-off-by: Marcel Ziswiler Acked-by: Charles Keepax Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 58be75ff08789de700a75a12a092f4a2b778296b Author: Suren Baghdasaryan Date: Mon Sep 17 15:51:41 2018 +0200 NFC: Fix the number of pipes commit e285d5bfb7e9785d289663baef252dd315e171f8 upstream. According to ETSI TS 102 622 specification chapter 4.4 pipe identifier is 7 bits long which allows for 128 unique pipe IDs. Because NFC_HCI_MAX_PIPES is used as the number of pipes supported and not as the max pipe ID, its value should be 128 instead of 127. nfc_hci_recv_from_llc extracts pipe ID from packet header using NFC_HCI_FRAGMENT(0x7F) mask which allows for pipe ID value of 127. Same happens when NCI_HCP_MSG_GET_PIPE() is being used. With pipes array having only 127 elements and pipe ID of 127 the OOB memory access will result. Cc: Samuel Ortiz Cc: Allen Pais Cc: "David S. Miller" Suggested-by: Dan Carpenter Signed-off-by: Suren Baghdasaryan Reviewed-by: Kees Cook Cc: stable Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0ad778eeee6d42b61bbf4494c7de22e387a2a05e Author: Suren Baghdasaryan Date: Mon Sep 17 15:51:40 2018 +0200 NFC: Fix possible memory corruption when handling SHDLC I-Frame commands commit 674d9de02aa7d521ebdf66c3958758bdd9c64e11 upstream. When handling SHDLC I-Frame commands "pipe" field used for indexing into an array should be checked before usage. If left unchecked it might access memory outside of the array of size NFC_HCI_MAX_PIPES(127). Malformed NFC HCI frames could be injected by a malicious NFC device communicating with the device being attacked (remote attack vector), or even by an attacker with physical access to the I2C bus such that they could influence the data transfers on that bus (local attack vector). skb->data is controlled by the attacker and has only been sanitized in the most trivial ways (CRC check), therefore we can consider the create_info struct and all of its members to tainted. 'create_info->pipe' with max value of 255 (uint8) is used to take an offset of the hdev->pipes array of 127 elements which can lead to OOB write. Cc: Samuel Ortiz Cc: Allen Pais Cc: "David S. Miller" Suggested-by: Kevin Deus Signed-off-by: Suren Baghdasaryan Acked-by: Kees Cook Cc: stable Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 18b8a9c5dab35c3f39402e12664da6d8b2d52c43 Author: Roopa Prabhu Date: Wed Sep 12 13:21:48 2018 -0700 net: rtnl_configure_link: fix dev flags changes arg to __dev_notify_flags [ Upstream commit 56a49d7048703f5ffdb84d3a0ee034108fba6850 ] This fix addresses https://bugzilla.kernel.org/show_bug.cgi?id=201071 Commit 5025f7f7d506 wrongly relied on __dev_change_flags to notify users of dev flag changes in the case when dev->rtnl_link_state = RTNL_LINK_INITIALIZED. Fix it by indicating flag changes explicitly to __dev_notify_flags. Fixes: 5025f7f7d506 ("rtnetlink: add rtnl_link_state check in rtnl_configure_link") Reported-By: Liam mcbirnie Signed-off-by: Roopa Prabhu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1b46979978c0105988c1607a6dda4b2a7f740f7f Author: Antoine Tenart Date: Fri Sep 14 16:56:35 2018 +0200 net: mvpp2: let phylink manage the carrier state [ Upstream commit 41948ccb4a856dddacfbd4d789d4fa8663fe41bb ] Net drivers using phylink shouldn't mess with the link carrier themselves and should let phylink manage it. The mvpp2 driver wasn't following this best practice as the mac_config() function made calls to change the link carrier state. This led to wrongly reported carrier link state which then triggered other issues. This patch fixes this behaviour. But the PPv2 driver relied on this misbehaviour in two cases: for fixed links and when not using phylink (ACPI mode). The later was fixed by adding an explicit call to link_up(), which when the ACPI mode will use phylink should be removed. The fixed link case was relying on the mac_config() function to set the link up, as we found an issue in phylink_start() which assumes the carrier is off. If not, the link_up() function is never called. To fix this, a call to netif_carrier_off() is added just before phylink_start() so that we do not introduce a regression in the driver. Fixes: 4bb043262878 ("net: mvpp2: phylink support") Reported-by: Russell King Signed-off-by: Antoine Tenart Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 001e4e5537d83d5b5814a642a47d7691de80a66f Author: Peter Oskolkov Date: Mon Sep 17 10:20:53 2018 -0700 net/ipv6: do not copy dst flags on rt init [ Upstream commit 30bfd93062814d6767e452a8f5ddcd97f7e38c7e ] DST_NOCOUNT in dst_entry::flags tracks whether the entry counts toward route cache size (net->ipv6.sysctl.ip6_rt_max_size). If the flag is NOT set, dst_ops::pcpuc_entries counter is incremented in dist_init() and decremented in dst_destroy(). This flag is tied to allocation/deallocation of dst_entry and should not be copied from another dst/route. Otherwise it can happen that dst_ops::pcpuc_entries counter grows until no new routes can be allocated because the counter reached ip6_rt_max_size due to DST_NOCOUNT not set and thus no counter decrements on gc-ed routes. Fixes: 3b6761d18bc1 ("net/ipv6: Move dst flags to booleans in fib entries") Cc: David Ahern Acked-by: Wei Wang Signed-off-by: Peter Oskolkov Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1328a5a40fdef0cd1c82698074b40b490558c6b6 Author: Xin Long Date: Tue Sep 11 14:33:58 2018 +0800 ipv6: use rt6_info members when dst is set in rt6_fill_node [ Upstream commit 22d0bd82cc7cec7d9ed4bd5913f3ab65643364be ] In inet6_rtm_getroute, since Commit 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes"), it has used rt->from to dump route info instead of rt. However for some route like cache, some of its information like flags or gateway is not the same as that of the 'from' one. It caused 'ip route get' to dump the wrong route information. In Jianlin's testing, the output information even lost the expiration time for a pmtu route cache due to the wrong fib6_flags. So change to use rt6_info members for dst addr, src addr, flags and gateway when it tries to dump a route entry without fibmatch set. v1->v2: - not use rt6i_prefsrc. - also fix the gw dump issue. Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes") Reported-by: Jianlin Shi Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b5fc7f300cdbc7d8bee3a0b77bb1a37bfa367b18 Author: Michael Chan Date: Fri Sep 14 15:41:29 2018 -0400 bnxt_en: Fix VF mac address regression. [ Upstream commit 28ea334bd1657f3c43485b4a8592672fc6835fac ] The recent commit to always forward the VF MAC address to the PF for approval may not work if the PF driver or the firmware is older. This will cause the VF driver to fail during probe: bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): hwrm req_type 0xf seq id 0x5 error 0xffff bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): VF MAC address 00:00:17:02:05:d0 not approved by the PF bnxt_en 0000:00:03.0: Unable to initialize mac address. bnxt_en: probe of 0000:00:03.0 failed with error -99 We fix it by treating the error as fatal only if the VF MAC address is locally generated by the VF. Fixes: 707e7e966026 ("bnxt_en: Always forward VF MAC address to the PF.") Reported-by: Seth Forshee Reported-by: Siwei Liu Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8ac22b327cc28dba60d350e341e96657d30ac4b5 Author: Daniel Borkmann Date: Fri Sep 14 23:00:55 2018 +0200 tls: fix currently broken MSG_PEEK behavior [ Upstream commit 50c6b58a814d86a93c0f6964570f839632854044 ] In kTLS MSG_PEEK behavior is currently failing, strace example: [pid 2430] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 [pid 2430] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4 [pid 2430] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 [pid 2430] listen(4, 10) = 0 [pid 2430] getsockname(4, {sa_family=AF_INET, sin_port=htons(38855), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 [pid 2430] connect(3, {sa_family=AF_INET, sin_port=htons(38855), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 [pid 2430] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0 [pid 2430] setsockopt(3, 0x11a /* SOL_?? */, 1, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0 [pid 2430] accept(4, {sa_family=AF_INET, sin_port=htons(49636), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5 [pid 2430] setsockopt(5, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0 [pid 2430] setsockopt(5, 0x11a /* SOL_?? */, 2, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0 [pid 2430] close(4) = 0 [pid 2430] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14 [pid 2430] sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11 [pid 2430] recvfrom(5, "test_read_peektest_read_peektest"..., 64, MSG_PEEK, NULL, NULL) = 64 As can be seen from strace, there are two TLS records sent, i) 'test_read_peek' and ii) '_mult_recs\0' where we end up peeking 'test_read_peektest_read_peektest'. This is clearly wrong, and what happens is that given peek cannot call into tls_sw_advance_skb() to unpause strparser and proceed with the next skb, we end up looping over the current one, copying the 'test_read_peek' over and over into the user provided buffer. Here, we can only peek into the currently held skb (current, full TLS record) as otherwise we would end up having to hold all the original skb(s) (depending on the peek depth) in a separate queue when unpausing strparser to process next records, minimally intrusive is to return only up to the current record's size (which likely was what c46234ebb4d1 ("tls: RX path for ktls") originally intended as well). Thus, after patch we properly peek the first record: [pid 2046] wait4(2075, [pid 2075] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 [pid 2075] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4 [pid 2075] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 [pid 2075] listen(4, 10) = 0 [pid 2075] getsockname(4, {sa_family=AF_INET, sin_port=htons(55115), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 [pid 2075] connect(3, {sa_family=AF_INET, sin_port=htons(55115), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 [pid 2075] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0 [pid 2075] setsockopt(3, 0x11a /* SOL_?? */, 1, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0 [pid 2075] accept(4, {sa_family=AF_INET, sin_port=htons(45732), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5 [pid 2075] setsockopt(5, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0 [pid 2075] setsockopt(5, 0x11a /* SOL_?? */, 2, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0 [pid 2075] close(4) = 0 [pid 2075] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14 [pid 2075] sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11 [pid 2075] recvfrom(5, "test_read_peek", 64, MSG_PEEK, NULL, NULL) = 14 Fixes: c46234ebb4d1 ("tls: RX path for ktls") Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 17eef150f66b502b4d7a27ecc7fc5b18fd5ab117 Author: Johannes Berg Date: Thu Sep 13 14:40:55 2018 +0200 socket: fix struct ifreq size in compat ioctl [ Upstream commit 1cebf8f143c21eb422cd0f4e27ab2ae366eb4d04 ] As reported by Reobert O'Callahan, since Viro's commit to kill dev_ifsioc() we attempt to copy too much data in compat mode, which may lead to EFAULT when the 32-bit version of struct ifreq sits at/near the end of a page boundary, and the next page isn't mapped. Fix this by passing the approprate compat/non-compat size to copy and using that, as before the dev_ifsioc() removal. This works because only the embedded "struct ifmap" has different size, and this is only used in SIOCGIFMAP/SIOCSIFMAP which has a different handler. All other parts of the union are naturally compatible. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=199469. Fixes: bf4405737f9f ("kill dev_ifsioc()") Reported-by: Robert O'Callahan Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 263baf63bdfbe69a4d9e21b73ab94d97a848c99f Author: Andrew Lunn Date: Fri Sep 14 23:46:12 2018 +0200 net: dsa: mv88e6xxx: Fix ATU Miss Violation [ Upstream commit ddca24dfcf1bec608668dd44c45d49397b70f520 ] Fix a cut/paste error and a typo which results in ATU miss violations not being reported. Fixes: 0977644c5005 ("net: dsa: mv88e6xxx: Decode ATU problem interrupt") Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4188aa04910796865e608212fbb3654fcdd68836 Author: Stephen Hemminger Date: Thu Sep 13 08:03:43 2018 -0700 hv_netvsc: fix schedule in RCU context [ Upstream commit 018349d70f28a78d5343b3660cb66e1667005f8a ] When netvsc device is removed it can call reschedule in RCU context. This happens because canceling the subchannel setup work could (in theory) cause a reschedule when manipulating the timer. To reproduce, run with lockdep enabled kernel and unbind a network device from hv_netvsc (via sysfs). [ 160.682011] WARNING: suspicious RCU usage [ 160.707466] 4.19.0-rc3-uio+ #2 Not tainted [ 160.709937] ----------------------------- [ 160.712352] ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section! [ 160.723691] [ 160.723691] other info that might help us debug this: [ 160.723691] [ 160.730955] [ 160.730955] rcu_scheduler_active = 2, debug_locks = 1 [ 160.762813] 5 locks held by rebind-eth.sh/1812: [ 160.766851] #0: 000000008befa37a (sb_writers#6){.+.+}, at: vfs_write+0x184/0x1b0 [ 160.773416] #1: 00000000b097f236 (&of->mutex){+.+.}, at: kernfs_fop_write+0xe2/0x1a0 [ 160.783766] #2: 0000000041ee6889 (kn->count#3){++++}, at: kernfs_fop_write+0xeb/0x1a0 [ 160.787465] #3: 0000000056d92a74 (&dev->mutex){....}, at: device_release_driver_internal+0x39/0x250 [ 160.816987] #4: 0000000030f6031e (rcu_read_lock){....}, at: netvsc_remove+0x1e/0x250 [hv_netvsc] [ 160.828629] [ 160.828629] stack backtrace: [ 160.831966] CPU: 1 PID: 1812 Comm: rebind-eth.sh Not tainted 4.19.0-rc3-uio+ #2 [ 160.832952] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012 [ 160.832952] Call Trace: [ 160.832952] dump_stack+0x85/0xcb [ 160.832952] ___might_sleep+0x1a3/0x240 [ 160.832952] __flush_work+0x57/0x2e0 [ 160.832952] ? __mutex_lock+0x83/0x990 [ 160.832952] ? __kernfs_remove+0x24f/0x2e0 [ 160.832952] ? __kernfs_remove+0x1b2/0x2e0 [ 160.832952] ? mark_held_locks+0x50/0x80 [ 160.832952] ? get_work_pool+0x90/0x90 [ 160.832952] __cancel_work_timer+0x13c/0x1e0 [ 160.832952] ? netvsc_remove+0x1e/0x250 [hv_netvsc] [ 160.832952] ? __lock_is_held+0x55/0x90 [ 160.832952] netvsc_remove+0x9a/0x250 [hv_netvsc] [ 160.832952] vmbus_remove+0x26/0x30 [ 160.832952] device_release_driver_internal+0x18a/0x250 [ 160.832952] unbind_store+0xb4/0x180 [ 160.832952] kernfs_fop_write+0x113/0x1a0 [ 160.832952] __vfs_write+0x36/0x1a0 [ 160.832952] ? rcu_read_lock_sched_held+0x6b/0x80 [ 160.832952] ? rcu_sync_lockdep_assert+0x2e/0x60 [ 160.832952] ? __sb_start_write+0x141/0x1a0 [ 160.832952] ? vfs_write+0x184/0x1b0 [ 160.832952] vfs_write+0xbe/0x1b0 [ 160.832952] ksys_write+0x55/0xc0 [ 160.832952] do_syscall_64+0x60/0x1b0 [ 160.832952] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 160.832952] RIP: 0033:0x7fe48f4c8154 Resolve this by getting RTNL earlier. This is safe because the subchannel work queue does trylock on RTNL and will detect the race. Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic") Signed-off-by: Stephen Hemminger Reviewed-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9f2489640a57d2a8287bbb86edadd539a638b9f3 Author: Davide Caratti Date: Fri Sep 14 12:03:18 2018 +0200 net/sched: act_sample: fix NULL dereference in the data path [ Upstream commit 34043d250f51368f214aed7f54c2dc29c819a8c7 ] Matteo reported the following splat, testing the datapath of TC 'sample': BUG: KASAN: null-ptr-deref in tcf_sample_act+0xc4/0x310 Read of size 8 at addr 0000000000000000 by task nc/433 CPU: 0 PID: 433 Comm: nc Not tainted 4.19.0-rc3-kvm #17 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS ?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 04/01/2014 Call Trace: kasan_report.cold.6+0x6c/0x2fa tcf_sample_act+0xc4/0x310 ? dev_hard_start_xmit+0x117/0x180 tcf_action_exec+0xa3/0x160 tcf_classify+0xdd/0x1d0 htb_enqueue+0x18e/0x6b0 ? deref_stack_reg+0x7a/0xb0 ? htb_delete+0x4b0/0x4b0 ? unwind_next_frame+0x819/0x8f0 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 __dev_queue_xmit+0x722/0xca0 ? unwind_get_return_address_ptr+0x50/0x50 ? netdev_pick_tx+0xe0/0xe0 ? save_stack+0x8c/0xb0 ? kasan_kmalloc+0xbe/0xd0 ? __kmalloc_track_caller+0xe4/0x1c0 ? __kmalloc_reserve.isra.45+0x24/0x70 ? __alloc_skb+0xdd/0x2e0 ? sk_stream_alloc_skb+0x91/0x3b0 ? tcp_sendmsg_locked+0x71b/0x15a0 ? tcp_sendmsg+0x22/0x40 ? __sys_sendto+0x1b0/0x250 ? __x64_sys_sendto+0x6f/0x80 ? do_syscall_64+0x5d/0x150 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 ? __sys_sendto+0x1b0/0x250 ? __x64_sys_sendto+0x6f/0x80 ? do_syscall_64+0x5d/0x150 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 ip_finish_output2+0x495/0x590 ? ip_copy_metadata+0x2e0/0x2e0 ? skb_gso_validate_network_len+0x6f/0x110 ? ip_finish_output+0x174/0x280 __tcp_transmit_skb+0xb17/0x12b0 ? __tcp_select_window+0x380/0x380 tcp_write_xmit+0x913/0x1de0 ? __sk_mem_schedule+0x50/0x80 tcp_sendmsg_locked+0x49d/0x15a0 ? tcp_rcv_established+0x8da/0xa30 ? tcp_set_state+0x220/0x220 ? clear_user+0x1f/0x50 ? iov_iter_zero+0x1ae/0x590 ? __fget_light+0xa0/0xe0 tcp_sendmsg+0x22/0x40 __sys_sendto+0x1b0/0x250 ? __ia32_sys_getpeername+0x40/0x40 ? _copy_to_user+0x58/0x70 ? poll_select_copy_remaining+0x176/0x200 ? __pollwait+0x1c0/0x1c0 ? ktime_get_ts64+0x11f/0x140 ? kern_select+0x108/0x150 ? core_sys_select+0x360/0x360 ? vfs_read+0x127/0x150 ? kernel_write+0x90/0x90 __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x5d/0x150 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fefef2b129d Code: ff ff ff ff eb b6 0f 1f 80 00 00 00 00 48 8d 05 51 37 0c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41 RSP: 002b:00007fff2f5350c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000056118d60c120 RCX: 00007fefef2b129d RDX: 0000000000002000 RSI: 000056118d629320 RDI: 0000000000000003 RBP: 000056118d530370 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000002000 R13: 000056118d5c2a10 R14: 000056118d5c2a10 R15: 000056118d5303b8 tcf_sample_act() tried to update its per-cpu stats, but tcf_sample_init() forgot to allocate them, because tcf_idr_create() was called with a wrong value of 'cpustats'. Setting it to true proved to fix the reported crash. Reported-by: Matteo Croce Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR") Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action") Tested-by: Matteo Croce Signed-off-by: Davide Caratti Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1708cc7ed059ec42e789bb1cc2551fbe2ece555d Author: Paolo Abeni Date: Thu Sep 13 16:27:21 2018 +0200 udp6: add missing checks on edumux packet processing [ Upstream commit eb63f2964dbe36f26deac77d3016791675821ded ] Currently the UDPv6 early demux rx code path lacks some mandatory checks, already implemented into the normal RX code path - namely the checksum conversion and no_check6_rx check. Similar to the previous commit, we move the common processing to an UDPv6 specific helper and call it from both edemux code path and normal code path. In respect to the UDPv4, we need to add an explicit check for non zero csum according to no_check6_rx value. Reported-by: Jianlin Shi Suggested-by: Xin Long Fixes: c9f2c1ae123a ("udp6: fix socket leak on early demux") Fixes: 2abb7cdc0dc8 ("udp: Add support for doing checksum unnecessary conversion") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c0d10c5d5d715355923b7577939870672b7bc03a Author: Vasily Khoruzhick Date: Thu Sep 13 11:12:03 2018 -0700 neighbour: confirm neigh entries when ARP packet is received [ Upstream commit f0e0d04413fcce9bc76388839099aee93cd0d33b ] Update 'confirmed' timestamp when ARP packet is received. It shouldn't affect locktime logic and anyway entry can be confirmed by any higher-layer protocol. Thus it makes sense to confirm it when ARP packet is received. Fixes: 77d7123342dc ("neighbour: update neigh timestamps iff update is effective") Signed-off-by: Vasily Khoruzhick Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 77971ea816ba7eee08f1c98474ef3fe05c78a4ea Author: Sabrina Dubroca Date: Wed Sep 12 17:44:43 2018 +0200 tls: clear key material from kernel memory when do_tls_setsockopt_conf fails [ Upstream commit c844eb46b7d43c2cf760169df5ae1d5b033af338 ] Fixes: 3c4d7559159b ("tls: kernel TLS support") Signed-off-by: Sabrina Dubroca Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 13d1bdc70bc25de0f5a31988776bdbe90745a4cd Author: Sabrina Dubroca Date: Wed Sep 12 17:44:42 2018 +0200 tls: zero the crypto information from tls_context before freeing [ Upstream commit 86029d10af18381814881d6cce2dd6872163b59f ] This contains key material in crypto_send_aes_gcm_128 and crypto_recv_aes_gcm_128. Introduce union tls_crypto_context, and replace the two identical unions directly embedded in struct tls_context with it. We can then use this union to clean up the memory in the new tls_ctx_free() function. Fixes: 3c4d7559159b ("tls: kernel TLS support") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d8e6fc73d2ebec80de775cf77e80f777e6334bdb Author: Sabrina Dubroca Date: Wed Sep 12 17:44:41 2018 +0200 tls: don't copy the key out of tls12_crypto_info_aes_gcm_128 [ Upstream commit 7cba09c6d5bc73ebbd25a353742d9ddb7a713b95 ] There's no need to copy the key to an on-stack buffer before calling crypto_aead_setkey(). Fixes: 3c4d7559159b ("tls: kernel TLS support") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6d7a3fd5cfaed3172b7dc4c2abf443fbf89650b0 Author: Paolo Abeni Date: Thu Sep 13 16:27:20 2018 +0200 udp4: fix IP_CMSG_CHECKSUM for connected sockets [ Upstream commit 2b5a921740a55c00223a797d075b9c77c42cb171 ] commit 2abb7cdc0dc8 ("udp: Add support for doing checksum unnecessary conversion") left out the early demux path for connected sockets. As a result IP_CMSG_CHECKSUM gives wrong values for such socket when GRO is not enabled/available. This change addresses the issue by moving the csum conversion to a common helper and using such helper in both the default and the early demux rx path. Fixes: 2abb7cdc0dc8 ("udp: Add support for doing checksum unnecessary conversion") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a02ff7df6a3b4caf7cf9dfb7814a70c62642af9b Author: Bjørn Mork Date: Mon Sep 17 22:00:24 2018 +0200 qmi_wwan: set DTR for modems in forced USB2 mode [ Upstream commit 922005c7f50e7f4b2a6dbc182e9c575b4f92396b ] Recent firmware revisions have added the ability to force these modems to USB2 mode, hiding their SuperSpeed capabilities from the host. The driver has been using the SuperSpeed capability, as shown by the bcdUSB field of the device descriptor, to detect the need to enable the DTR quirk. This method fails when the modems are forced to USB2 mode by the modem firmware. Fix by unconditionally enabling the DTR quirk for the affected device IDs. Reported-by: Fred Veldini Reported-by: Deshu Wen Signed-off-by: Bjørn Mork Reported-by: Fred Veldini Reported-by: Deshu Wen Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 89721b836972c366dbe670d7867c8b838d7039e7 Author: Guillaume Nault Date: Fri Sep 14 16:28:05 2018 +0200 pppoe: fix reception of frames with no mac header [ Upstream commit 8540827ebac6b654ab2f69c8fbce9e4fbd6304a0 ] pppoe_rcv() needs to look back at the Ethernet header in order to lookup the PPPoE session. Therefore we need to ensure that the mac header is big enough to contain an Ethernet header. Otherwise eth_hdr(skb)->h_source might access invalid data. ================================================================== BUG: KMSAN: uninit-value in __get_item drivers/net/ppp/pppoe.c:172 [inline] BUG: KMSAN: uninit-value in get_item drivers/net/ppp/pppoe.c:236 [inline] BUG: KMSAN: uninit-value in pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450 CPU: 0 PID: 4543 Comm: syz-executor355 Not tainted 4.16.0+ #87 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x185/0x1d0 lib/dump_stack.c:53 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683 __get_item drivers/net/ppp/pppoe.c:172 [inline] get_item drivers/net/ppp/pppoe.c:236 [inline] pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450 __netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4562 __netif_receive_skb net/core/dev.c:4627 [inline] netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701 netif_receive_skb+0x230/0x240 net/core/dev.c:4725 tun_rx_batched drivers/net/tun.c:1555 [inline] tun_get_user+0x740f/0x7c60 drivers/net/tun.c:1962 tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990 call_write_iter include/linux/fs.h:1782 [inline] new_sync_write fs/read_write.c:469 [inline] __vfs_write+0x7fb/0x9f0 fs/read_write.c:482 vfs_write+0x463/0x8d0 fs/read_write.c:544 SYSC_write+0x172/0x360 fs/read_write.c:589 SyS_write+0x55/0x80 fs/read_write.c:581 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x4447c9 RSP: 002b:00007fff64c8fc28 EFLAGS: 00000297 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004447c9 RDX: 000000000000fd87 RSI: 0000000020000600 RDI: 0000000000000004 RBP: 00000000006cf018 R08: 00007fff64c8fda8 R09: 00007fff00006bda R10: 0000000000005fe7 R11: 0000000000000297 R12: 00000000004020d0 R13: 0000000000402160 R14: 0000000000000000 R15: 0000000000000000 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline] kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314 kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2737 [inline] __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369 __kmalloc_reserve net/core/skbuff.c:138 [inline] __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206 alloc_skb include/linux/skbuff.h:984 [inline] alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234 sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085 tun_alloc_skb drivers/net/tun.c:1532 [inline] tun_get_user+0x2242/0x7c60 drivers/net/tun.c:1829 tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990 call_write_iter include/linux/fs.h:1782 [inline] new_sync_write fs/read_write.c:469 [inline] __vfs_write+0x7fb/0x9f0 fs/read_write.c:482 vfs_write+0x463/0x8d0 fs/read_write.c:544 SYSC_write+0x172/0x360 fs/read_write.c:589 SyS_write+0x55/0x80 fs/read_write.c:581 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 ================================================================== Fixes: 224cf5ad14c0 ("ppp: Move the PPP drivers") Reported-by: syzbot+f5f6080811c849739212@syzkaller.appspotmail.com Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b411479d52680db884ae55bfce5a78303fdf4449 Author: Colin Ian King Date: Fri Sep 14 17:39:53 2018 +0100 net: hp100: fix always-true check for link up state [ Upstream commit a7f38002fb69b44f8fc622ecb838665d0b8666af ] The operation ~(p100_inb(VG_LAN_CFG_1) & HP100_LINK_UP) returns a value that is always non-zero and hence the wait for the link to drop always terminates prematurely. Fix this by using a logical not operator instead of a bitwise complement. This issue has been in the driver since pre-2.6.12-rc2. Detected by CoverityScan, CID#114157 ("Logical vs. bitwise operator") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6a9c934f04e6e6351742eb68a6899b964e1d01b5 Author: Willy Tarreau Date: Wed Sep 12 07:36:35 2018 +0200 net/appletalk: fix minor pointer leak to userspace in SIOCFINDIPDDPRT [ Upstream commit 9824dfae5741275473a23a7ed5756c7b6efacc9d ] Fields ->dev and ->next of struct ipddp_route may be copied to userspace on the SIOCFINDIPDDPRT ioctl. This is only accessible to CAP_NET_ADMIN though. Let's manually copy the relevant fields instead of using memcpy(). BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html Cc: Jann Horn Signed-off-by: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6b4d14c57381cc142bb5ff0072c4ecf338513bf1 Author: Eric Dumazet Date: Fri Sep 14 12:02:31 2018 -0700 ipv6: fix possible use-after-free in ip6_xmit() [ Upstream commit bbd6528d28c1b8e80832b3b018ec402b6f5c3215 ] In the unlikely case ip6_xmit() has to call skb_realloc_headroom(), we need to call skb_set_owner_w() before consuming original skb, otherwise we risk a use-after-free. Bring IPv6 in line with what we do in IPv4 to fix this. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 288942f4a669c9121d4afd6ec6784a53a484feb1 Author: Toke Høiland-Jørgensen Date: Thu Sep 13 16:43:07 2018 +0200 gso_segment: Reset skb->mac_len after modifying network header [ Upstream commit c56cae23c6b167acc68043c683c4573b80cbcc2c ] When splitting a GSO segment that consists of encapsulated packets, the skb->mac_len of the segments can end up being set wrong, causing packet drops in particular when using act_mirred and ifb interfaces in combination with a qdisc that splits GSO packets. This happens because at the time skb_segment() is called, network_header will point to the inner header, throwing off the calculation in skb_reset_mac_len(). The network_header is subsequently adjust by the outer IP gso_segment handlers, but they don't set the mac_len. Fix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6 gso_segment handlers, after they modify the network_header. Many thanks to Eric Dumazet for his help in identifying the cause of the bug. Acked-by: Dave Taht Reviewed-by: Eric Dumazet Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman