commit 239cc2c5a3c8555efd2330cc5b09affd5b503669 Author: Greg Kroah-Hartman Date: Sat Mar 23 20:11:41 2019 +0100 Linux 5.0.4 commit 87e728e85559749608073c447141dab26663d0bb Author: Trond Myklebust Date: Thu Mar 7 14:10:32 2019 -0500 SUNRPC: Respect RPC call timeouts when retrying transmission commit 7b3fef8e4157ed424bcde039a60a730aa0dfb0eb upstream. Fix a regression where soft and softconn requests are not timing out as expected. Fixes: 89f90fe1ad8b ("SUNRPC: Allow calls to xprt_transmit() to drain...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit f6716abfd12b90c10a6e234edd41bfab4387c3b8 Author: Trond Myklebust Date: Tue Mar 5 07:30:48 2019 -0500 SUNRPC: Fix up RPC back channel transmission commit 477687e1116ad16180caf8633dd830b296a5ce73 upstream. Now that transmissions happen through a queue, we require the RPC tasks to handle error conditions that may have been set while they were sleeping. The back channel does not currently do this, but assumes that any error condition happens during its own call to xprt_transmit(). The solution is to ensure that the back channel splits out the error handling just like the forward channel does. Fixes: 89f90fe1ad8b ("SUNRPC: Allow calls to xprt_transmit() to drain...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit aed54941cf9e67876456513b490fdf72e0367aed Author: Trond Myklebust Date: Mon Mar 4 14:19:31 2019 -0500 SUNRPC: Prevent thundering herd when the socket is not connected commit ed7dc973bd91da234d93aff6d033a5206a6c9885 upstream. If the socket is not connected, then we want to initiate a reconnect rather that trying to transmit requests. If there is a large number of requests queued and waiting for the lock in call_transmit(), then it can take a while for one of the to loop back and retake the lock in call_connect. Fixes: 89f90fe1ad8b ("SUNRPC: Allow calls to xprt_transmit() to drain...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 1b2f5d715bbc21c548c834647084c4ad7952696f Author: Martin Schwidefsky Date: Mon Feb 18 18:10:08 2019 +0100 s390/setup: fix boot crash for machine without EDAT-1 commit 86a86804e4f18fc3880541b3d5a07f4df0fe29cb upstream. The fix to make WARN work in the early boot code created a problem on older machines without EDAT-1. The setup_lowcore_dat_on function uses the pointer from lowcore_ptr[0] to set the DAT bit in the new PSWs. That does not work if the kernel page table is set up with 4K pages as the prefix address maps to absolute zero. To make this work the PSWs need to be changed with via address 0 in form of the S390_lowcore definition. Reported-by: Guenter Roeck Tested-by: Cornelia Huck Fixes: 94f85ed3e2f8 ("s390/setup: fix early warning messages") Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 09bfb45ed842f4b53683c3bc28a386997e47c719 Author: Johan Hovold Date: Wed Jan 16 11:23:34 2019 +0100 net: dsa: lantiq_gswip: fix OF child-node lookups commit c8cbcb0d8bd72d44fad1a5ddc348ac10e0fb1b37 upstream. Use the new of_get_compatible_child() helper to look up child nodes to avoid ever matching non-child nodes elsewhere in the tree. Also fix up the related struct device_node leaks. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Cc: stable # 4.20 Cc: Hauke Mehrtens Signed-off-by: Johan Hovold Reviewed-by: Andrew Lunn Acked-by: Hauke Mehrtens Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8d244127d25f403d285ab69ff16c194dc44327be Author: Johan Hovold Date: Wed Jan 16 11:23:33 2019 +0100 net: dsa: lantiq_gswip: fix use-after-free on failed probe commit aed13f2e00ce278f039b76e7ac84d419aff48ef6 upstream. Make sure to disable and deregister the switch on late probe errors to avoid use-after-free when the device-resource-managed switch is freed. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Cc: stable # 4.20 Cc: Hauke Mehrtens Signed-off-by: Johan Hovold Reviewed-by: Andrew Lunn Acked-by: Hauke Mehrtens Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4e126cbd4f0613a1975056b9f2978151b25ecd39 Author: Sean Christopherson Date: Fri Jan 25 07:40:49 2019 -0800 KVM: nVMX: Check a single byte for VMCS "launched" in nested early checks commit 1ce072cbfd8dba46f117804850398e0b3040a541 upstream. Nested early checks does a manual comparison of a VMCS' launched status in its asm blob to execute the correct VM-Enter instruction, i.e. VMLAUNCH vs. VMRESUME. The launched flag is a bool, which is a typedef of _Bool. C99 does not define an exact size for _Bool, stating only that is must be large enough to hold '0' and '1'. Most, if not all, compilers use a single byte for _Bool, including gcc[1]. The use of 'cmpl' instead of 'cmpb' was not deliberate, but rather the result of a copy-paste as the asm blob was directly derived from the asm blob for vCPU-run. This has not caused any known problems, likely due to compilers aligning variables to 4-byte or 8-byte boundaries and KVM zeroing out struct vcpu_vmx during allocation. I.e. vCPU-run accesses "junk" data, it just happens to always be zero and so doesn't affect the result. [1] https://gcc.gnu.org/ml/gcc-patches/2000-10/msg01127.html Fixes: 52017608da33 ("KVM: nVMX: add option to perform early consistency checks via H/W") Cc: Reviewed-by: Jim Mattson Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5de7f6cd6aebe0a6b58cd975c22f9472ec30ef33 Author: Sean Christopherson Date: Wed Jan 23 14:39:25 2019 -0800 KVM: nVMX: Ignore limit checks on VMX instructions using flat segments commit 34333cc6c2cb021662fd32e24e618d1b86de95bf upstream. Regarding segments with a limit==0xffffffff, the SDM officially states: When the effective limit is FFFFFFFFH (4 GBytes), these accesses may or may not cause the indicated exceptions. Behavior is implementation-specific and may vary from one execution to another. In practice, all CPUs that support VMX ignore limit checks for "flat segments", i.e. an expand-up data or code segment with base=0 and limit=0xffffffff. This is subtly different than wrapping the effective address calculation based on the address size, as the flat segment behavior also applies to accesses that would wrap the 4g boundary, e.g. a 4-byte access starting at 0xffffffff will access linear addresses 0xffffffff, 0x0, 0x1 and 0x2. Fixes: f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f88f29f81d5921b03f60bb9d707b2a377e0875c4 Author: Sean Christopherson Date: Wed Jan 23 14:39:24 2019 -0800 KVM: nVMX: Apply addr size mask to effective address for VMX instructions commit 8570f9e881e3fde98801bb3a47eef84dd934d405 upstream. The address size of an instruction affects the effective address, not the virtual/linear address. The final address may still be truncated, e.g. to 32-bits outside of long mode, but that happens irrespective of the address size, e.g. a 32-bit address size can yield a 64-bit virtual address when using FS/GS with a non-zero base. Fixes: 064aea774768 ("KVM: nVMX: Decoding memory operands of VMX instructions") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 64d259a7064214e8b6cc4f807a71987ee73235d2 Author: Sean Christopherson Date: Wed Jan 23 14:39:23 2019 -0800 KVM: nVMX: Sign extend displacements of VMX instr's mem operands commit 946c522b603f281195af1df91837a1d4d1eb3bc9 upstream. The VMCS.EXIT_QUALIFCATION field reports the displacements of memory operands for various instructions, including VMX instructions, as a naturally sized unsigned value, but masks the value by the addr size, e.g. given a ModRM encoded as -0x28(%ebp), the -0x28 displacement is reported as 0xffffffd8 for a 32-bit address size. Despite some weird wording regarding sign extension, the SDM explicitly states that bits beyond the instructions address size are undefined: In all cases, bits of this field beyond the instruction’s address size are undefined. Failure to sign extend the displacement results in KVM incorrectly treating a negative displacement as a large positive displacement when the address size of the VMX instruction is smaller than KVM's native size, e.g. a 32-bit address size on a 64-bit KVM. The very original decoding, added by commit 064aea774768 ("KVM: nVMX: Decoding memory operands of VMX instructions"), sort of modeled sign extension by truncating the final virtual/linear address for a 32-bit address size. I.e. it messed up the effective address but made it work by adjusting the final address. When segmentation checks were added, the truncation logic was kept as-is and no sign extension logic was introduced. In other words, it kept calculating the wrong effective address while mostly generating the correct virtual/linear address. As the effective address is what's used in the segment limit checks, this results in KVM incorreclty injecting #GP/#SS faults due to non-existent segment violations when a nested VMM uses negative displacements with an address size smaller than KVM's native address size. Using the -0x28(%ebp) example, an EBP value of 0x1000 will result in KVM using 0x100000fd8 as the effective address when checking for a segment limit violation. This causes a 100% failure rate when running a 32-bit KVM build as L1 on top of a 64-bit KVM L0. Fixes: f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1e42327adb8da50e3a0fb68848a6a07d18c158ec Author: Sean Christopherson Date: Tue Feb 5 13:01:13 2019 -0800 KVM: x86/mmu: Do not cache MMIO accesses while memslots are in flux commit ddfd1730fd829743e41213e32ccc8b4aa6dc8325 upstream. When installing new memslots, KVM sets bit 0 of the generation number to indicate that an update is in-progress. Until the update is complete, there are no guarantees as to whether a vCPU will see the old or the new memslots. Explicity prevent caching MMIO accesses so as to avoid using an access cached from the old memslots after the new memslots have been installed. Note that it is unclear whether or not disabling caching during the update window is strictly necessary as there is no definitive documentation as to what ordering guarantees KVM provides with respect to updating memslots. That being said, the MMIO spte code does not allow reusing sptes created while an update is in-progress, and the associated documentation explicitly states: We do not want to use an MMIO sptes created with an odd generation number, ... If KVM is unlucky and creates an MMIO spte while the low bit is 1, the next access to the spte will always be a cache miss. At the very least, disabling the per-vCPU MMIO cache during updates will make its behavior consistent with the MMIO spte behavior and documentation. Fixes: 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug") Cc: Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c173d5417a11248961b4da79adeb6a70b5b44df3 Author: Sean Christopherson Date: Tue Feb 5 13:01:12 2019 -0800 KVM: x86/mmu: Detect MMIO generation wrap in any address space commit e1359e2beb8b0a1188abc997273acbaedc8ee791 upstream. The check to detect a wrap of the MMIO generation explicitly looks for a generation number of zero. Now that unique memslots generation numbers are assigned to each address space, only address space 0 will get a generation number of exactly zero when wrapping. E.g. when address space 1 goes from 0x7fffe to 0x80002, the MMIO generation number will wrap to 0x2. Adjust the MMIO generation to strip the address space modifier prior to checking for a wrap. Fixes: 4bd518f1598d ("KVM: use separate generations for each address space") Cc: Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5221117cd414d6365b921ea85d5c14c55c3dfb76 Author: Sean Christopherson Date: Fri Jan 25 07:40:50 2019 -0800 KVM: VMX: Zero out *all* general purpose registers after VM-Exit commit 0e0ab73c9a0243736bcd779b30b717e23ba9a56d upstream. ...except RSP, which is restored by hardware as part of VM-Exit. Paolo theorized that restoring registers from the stack after a VM-Exit in lieu of zeroing them could lead to speculative execution with the guest's values, e.g. if the stack accesses miss the L1 cache[1]. Zeroing XORs are dirt cheap, so just be ultra-paranoid. Note that the scratch register (currently RCX) used to save/restore the guest state is also zeroed as its host-defined value is loaded via the stack, just with a MOV instead of a POP. [1] https://patchwork.kernel.org/patch/10771539/#22441255 Fixes: 0cb5b30698fd ("kvm: vmx: Scrub hardware GPRs at VM-exit") Cc: Cc: Jim Mattson Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit cf8d03a4fe59ae40a6a8e5b0925425ef975a5597 Author: Sean Christopherson Date: Fri Jan 25 07:40:48 2019 -0800 KVM: VMX: Compare only a single byte for VMCS' "launched" in vCPU-run commit 61c08aa9606d4e48a8a50639c956448a720174c3 upstream. The vCPU-run asm blob does a manual comparison of a VMCS' launched status to execute the correct VM-Enter instruction, i.e. VMLAUNCH vs. VMRESUME. The launched flag is a bool, which is a typedef of _Bool. C99 does not define an exact size for _Bool, stating only that is must be large enough to hold '0' and '1'. Most, if not all, compilers use a single byte for _Bool, including gcc[1]. Originally, 'launched' was of type 'int' and so the asm blob used 'cmpl' to check the launch status. When 'launched' was moved to be stored on a per-VMCS basis, struct vcpu_vmx's "temporary" __launched flag was added in order to avoid having to pass the current VMCS into the asm blob. The new '__launched' was defined as a 'bool' and not an 'int', but the 'cmp' instruction was not updated. This has not caused any known problems, likely due to compilers aligning variables to 4-byte or 8-byte boundaries and KVM zeroing out struct vcpu_vmx during allocation. I.e. vCPU-run accesses "junk" data, it just happens to always be zero and so doesn't affect the result. [1] https://gcc.gnu.org/ml/gcc-patches/2000-10/msg01127.html Fixes: d462b8192368 ("KVM: VMX: Keep list of loaded VMCSs, instead of vcpus") Cc: Reviewed-by: Jim Mattson Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit e1bdcf061b48dafc0755dd2f68fb0e31ed6f2597 Author: Sean Christopherson Date: Tue Feb 5 12:54:17 2019 -0800 KVM: Call kvm_arch_memslots_updated() before updating memslots commit 152482580a1b0accb60676063a1ac57b2d12daf6 upstream. kvm_arch_memslots_updated() is at this point in time an x86-specific hook for handling MMIO generation wraparound. x86 stashes 19 bits of the memslots generation number in its MMIO sptes in order to avoid full page fault walks for repeat faults on emulated MMIO addresses. Because only 19 bits are used, wrapping the MMIO generation number is possible, if unlikely. kvm_arch_memslots_updated() alerts x86 that the generation has changed so that it can invalidate all MMIO sptes in case the effective MMIO generation has wrapped so as to avoid using a stale spte, e.g. a (very) old spte that was created with generation==0. Given that the purpose of kvm_arch_memslots_updated() is to prevent consuming stale entries, it needs to be called before the new generation is propagated to memslots. Invalidating the MMIO sptes after updating memslots means that there is a window where a vCPU could dereference the new memslots generation, e.g. 0, and incorrectly reuse an old MMIO spte that was created with (pre-wrap) generation==0. Fixes: e59dbe09f8e6 ("KVM: Introduce kvm_arch_memslots_updated()") Cc: Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c61d88f39491cb9105a83b770b195cbd1b836c4a Author: Harry Wentland Date: Wed Jan 30 15:45:18 2019 -0500 drm/amd/display: don't call dm_pp_ function from an fpu block commit 59d3191f14dc18881fec1172c7096b7863622803 upstream. Powerplay functions called from dm_pp_* functions tend to do a mutex_lock which isn't safe to do inside a kernel_fpu_begin/end block as those will disable/enable preemption. Rearrange the dm_pp_get_clock_levels_by_type_with_voltage calls to make sure they happen outside of kernel_fpu_begin/end. Cc: stable@vger.kernel.org Acked-by: Alex Deucher Signed-off-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ea7da9ef23a08f21ccd194d8e86f07f164788820 Author: Evan Quan Date: Mon Feb 25 16:44:36 2019 +0800 drm/amd/powerplay: correct power reading on fiji commit f5742ec36422a39b57f0256e4847f61b3c432f8c upstream. Set sampling period as 500ms to provide a smooth power reading output. Also, correct the register for power reading. Signed-off-by: Evan Quan Reviewed-by: Feifei Xu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3bc65d729765659a7959d4fb99ee53811ecc9cb0 Author: Gustavo A. R. Silva Date: Fri Feb 15 14:29:26 2019 -0600 drm/radeon/evergreen_cs: fix missing break in switch statement commit cc5034a5d293dd620484d1d836aa16c6764a1c8c upstream. Add missing break statement in order to prevent the code from falling through to case CB_TARGET_MASK. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: dd220a00e8bd ("drm/radeon/kms: add support for streamout v7") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b78ee0965f86be90e514258b60dbf71908e071ee Author: Noralf Trønnes Date: Fri Jan 25 16:03:00 2019 +0100 drm/fb-helper: generic: Fix drm_fbdev_client_restore() commit 78de14c23e031420aa5f61973583635eccd6cd2a upstream. If fbdev setup has failed, lastclose will give a NULL pointer deref: [ 77.794295] [drm:drm_lastclose] [ 77.794414] [drm:drm_lastclose] driver lastclose completed [ 77.794660] Unable to handle kernel NULL pointer dereference at virtual address 00000014 [ 77.809460] pgd = b376b71b [ 77.818275] [00000014] *pgd=175ba831, *pte=00000000, *ppte=00000000 [ 77.830813] Internal error: Oops: 17 [#1] ARM [ 77.840963] Modules linked in: mi0283qt mipi_dbi tinydrm raspberrypi_hwmon gpio_backlight backlight snd_bcm2835(C) bcm2835_rng rng_core [ 77.865203] CPU: 0 PID: 527 Comm: lt-modetest Tainted: G C 5.0.0-rc1+ #1 [ 77.879525] Hardware name: BCM2835 [ 77.889185] PC is at restore_fbdev_mode+0x20/0x164 [ 77.900261] LR is at drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c [ 78.002446] Process lt-modetest (pid: 527, stack limit = 0x7a3d5c14) [ 78.291030] Backtrace: [ 78.300815] [] (restore_fbdev_mode) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c) [ 78.319095] r9:d8a8a288 r8:d891acf0 r7:d7697910 r6:00000000 r5:d891ac00 r4:d891ac00 [ 78.334432] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fbdev_client_restore+0x18/0x20) [ 78.353296] r8:d76978c0 r7:d7697910 r6:d7697950 r5:d7697800 r4:d891ac00 r3:c04f47d0 [ 78.368689] [] (drm_fbdev_client_restore) from [] (drm_client_dev_restore+0x7c/0xc0) [ 78.385982] [] (drm_client_dev_restore) from [] (drm_lastclose+0xc4/0xd4) [ 78.402332] r8:d76978c0 r7:d7471080 r6:c0e0c088 r5:d8a85e00 r4:d7697800 [ 78.416688] [] (drm_lastclose) from [] (drm_release+0xa8/0x10c) [ 78.431929] r5:d8a85e00 r4:d7697800 [ 78.442989] [] (drm_release) from [] (__fput+0x104/0x1c8) [ 78.457740] r8:d5ccea10 r7:d96cfb10 r6:00000008 r5:d74c1b90 r4:d8a8a280 [ 78.472043] [] (__fput) from [] (____fput+0x18/0x1c) [ 78.486363] r10:00000006 r9:d7722000 r8:c01011c4 r7:00000000 r6:c0ebac6c r5:d892a340 [ 78.501869] r4:d8a8a280 [ 78.512002] [] (____fput) from [] (task_work_run+0x98/0xac) [ 78.527186] [] (task_work_run) from [] (do_work_pending+0x4f8/0x570) [ 78.543238] r7:d7722030 r6:00000004 r5:d7723fb0 r4:00000000 [ 78.556825] [] (do_work_pending) from [] (slow_work_pending+0xc/0x20) [ 78.674256] ---[ end trace 70d3a60cf739be3b ]--- Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use. Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation") Cc: stable@vger.kernel.org Signed-off-by: Noralf Trønnes Reviewed-by: Gerd Hoffmann Link: https://patchwork.freedesktop.org/patch/msgid/20190125150300.33268-1-noralf@tronnes.org Signed-off-by: Greg Kroah-Hartman commit c7a35a9877b89bca4856fcd06d191335b2d6bf5c Author: Steve Longerbeam Date: Mon Jan 21 21:35:51 2019 -0200 media: imx: csi: Stop upstream before disabling IDMA channel commit 4bc1ab41eee9d02ad2483bf8f51a7b72e3504eba upstream. Move upstream stream off to just after receiving the last EOF completion and disabling the CSI (and thus before disabling the IDMA channel) in csi_stop(). For symmetry also move upstream stream on to beginning of csi_start(). Doing this makes csi_s_stream() more symmetric with prp_s_stream() which will require the same change to fix a hard lockup. Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org # for 4.13 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 145cab144d758292570cd2e6a9ad765234debedc Author: Steve Longerbeam Date: Mon Jan 21 21:35:50 2019 -0200 media: imx: csi: Disable CSI immediately after last EOF commit 2e0fe66e0a136252f4d89dbbccdcb26deb867eb8 upstream. Disable the CSI immediately after receiving the last EOF before stream off (and thus before disabling the IDMA channel). Do this by moving the wait for EOF completion into a new function csi_idmac_wait_last_eof(). This fixes a complete system hard lockup on the SabreAuto when streaming from the ADV7180, by repeatedly sending a stream off immediately followed by stream on: while true; do v4l2-ctl -d4 --stream-mmap --stream-count=3; done Eventually this either causes the system lockup or EOF timeouts at all subsequent stream on, until a system reset. The lockup occurs when disabling the IDMA channel at stream off. Disabling the CSI before disabling the IDMA channel appears to be a reliable fix for the hard lockup. Fixes: 4a34ec8e470cb ("[media] media: imx: Add CSI subdev driver") Reported-by: Gaël PORTAY Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org # for 4.13 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e7a06193c52cab30335d58cde7dc7e0e6a67045b Author: Steve Longerbeam Date: Thu Jan 17 18:58:37 2019 -0200 media: imx-csi: Input connections to CSI should be optional commit 337e90ed028643c7acdfd0d31e3224d05ca03d66 upstream. Some imx platforms do not have fwnode connections to all CSI input ports, and should not be treated as an error. This includes the imx6q SabreAuto, which has no connections to ipu1_csi1 and ipu2_csi0. Return -ENOTCONN in imx_csi_parse_endpoint() so that v4l2-fwnode endpoint parsing will not treat an unconnected CSI input port as an error. Fixes: c893500a16baf ("media: imx: csi: Register a subdev notifier") Signed-off-by: Steve Longerbeam Reviewed-by: Philipp Zabel Acked-by: Tim Harvey Cc: stable@vger.kernel.org Tested-by: Fabio Estevam Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e7ae48ae47227c0302b9f4b15a5bf45934a55673 Author: Lucas A. M. Magalhães Date: Mon Jan 21 20:05:01 2019 -0500 media: vimc: Add vimc-streamer for stream control commit adc589d2a20808fb99d46a78175cd023f2040338 upstream. Add a linear pipeline logic for the stream control. It's created by walking backwards on the entity graph. When the stream starts it will simply loop through the pipeline calling the respective process_frame function of each entity. Fixes: f2fe89061d797 ("vimc: Virtual Media Controller core, capture and sensor") Cc: stable@vger.kernel.org # for v4.20 Signed-off-by: Lucas A. M. Magalhães Acked-by: Helen Koike Signed-off-by: Hans Verkuil [hverkuil-cisco@xs4all.nl: fixed small space-after-tab issue in the patch] Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 6932b9b4e677f6b29fa1f7f54b259ed9b3b6ba8e Author: Sakari Ailus Date: Wed Jan 30 05:09:41 2019 -0500 media: uvcvideo: Avoid NULL pointer dereference at the end of streaming commit 9dd0627d8d62a7ddb001a75f63942d92b5336561 upstream. The UVC video driver converts the timestamp from hardware specific unit to one known by the kernel at the time when the buffer is dequeued. This is fine in general, but the streamoff operation consists of the following steps (among other things): 1. uvc_video_clock_cleanup --- the hardware clock sample array is released and the pointer to the array is set to NULL, 2. buffers in active state are returned to the user and 3. buf_finish callback is called on buffers that are prepared. buf_finish includes calling uvc_video_clock_update that accesses the hardware clock sample array. The above is serialised by a queue specific mutex. Address the problem by skipping the clock conversion if the hardware clock sample array is already released. Fixes: 9c0863b1cc48 ("[media] vb2: call buf_finish from __queue_cancel") Reported-by: Chiranjeevi Rapolu Tested-by: Chiranjeevi Rapolu Signed-off-by: Sakari Ailus Cc: stable@vger.kernel.org Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 202ed62dea70ce1b87db2007384b6ef2cfc13d47 Author: Chen-Yu Tsai Date: Sun Feb 3 11:03:56 2019 -0500 media: sun6i: Fix CSI regmap's max_register commit d31b282e2c0de9c7fb113516820340251f03a625 upstream. max_register is currently set to 0x1000. This is beyond the mapped address range of the hardware, so attempts to dump the regmap from debugfs would trigger a kernel exception. Furthermore, the useful registers only occupy a small section at the beginning of the full range. Change the value to 0x9c, the last known register on the V3s and H3. On the A31, the register range is extended to support additional capture channels. Since this is not yet supported, ignore it for now. Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s") Cc: Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1d433d48516e387de7c3cf043b56744606f07c17 Author: French, Nicholas A Date: Sun Dec 9 02:11:18 2018 -0500 media: lgdt330x: fix lock status reporting commit 1b4fd9de6ec7f3722c2b3e08cc5ad171c11f93be upstream. A typo in code cleanup commit db9c1007bc07 ("media: lgdt330x: do some cleanups at status logic") broke the FE_HAS_LOCK reporting for 3303 chips by inadvertently modifying the register mask. The broken lock status is critial as it prevents video capture cards from reporting signal strength, scanning for channels, and capturing video. Fix regression by reverting mask change. Cc: stable@vger.kernel.org # Kernel 4.17+ Fixes: db9c1007bc07 ("media: lgdt330x: do some cleanups at status logic") Signed-off-by: Nick French Reviewed-by: Laurent Pinchart Tested-by: Adam Stylinski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f55d0cb10f5b54fdd586b738fcd36da0576781a3 Author: Steve Longerbeam Date: Mon Jan 21 21:35:52 2019 -0200 media: imx: prpencvf: Stop upstream before disabling IDMA channel commit a19c22677377b87e4354f7306f46ad99bc982a9f upstream. Upstream must be stopped immediately after receiving the last EOF and before disabling the IDMA channel. This can be accomplished by moving upstream stream off to just after receiving the last EOF completion in prp_stop(). For symmetry also move upstream stream on to end of prp_start(). This fixes a complete system hard lockup on the SabreAuto when streaming from the ADV7180, by repeatedly sending a stream off immediately followed by stream on: while true; do v4l2-ctl -d1 --stream-mmap --stream-count=3; done Eventually this either causes the system lockup or EOF timeouts at all subsequent stream on, until a system reset. The lockup occurs when disabling the IDMA channel at stream off. Stopping the video data stream entering the IDMA channel before disabling the channel itself appears to be a reliable fix for the hard lockup. Fixes: f0d9c8924e2c3 ("[media] media: imx: Add IC subdev drivers") Reported-by: Gaël PORTAY Tested-by: Gaël PORTAY Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org # for 4.13 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 9d032911a36cb7a3903cae3f96138609fae1bd8d Author: Zhang, Jun Date: Tue Dec 18 06:55:01 2018 -0800 rcu: Do RCU GP kthread self-wakeup from softirq and interrupt commit 1d1f898df6586c5ea9aeaf349f13089c6fa37903 upstream. The rcu_gp_kthread_wake() function is invoked when it might be necessary to wake the RCU grace-period kthread. Because self-wakeups are normally a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from this kthread, it naturally refuses to do the wakeup. Unfortunately, natural though it might be, this heuristic fails when rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler that interrupted the grace-period kthread just after the final check of the wait-event condition but just before the schedule() call. In this case, a wakeup is required, even though the call to rcu_gp_kthread_wake() is within the RCU grace-period kthread's context. Failing to provide this wakeup can result in grace periods failing to start, which in turn results in out-of-memory conditions. This race window is quite narrow, but it actually did happen during real testing. It would of course need to be fixed even if it was strictly theoretical in nature. This patch does not Cc stable because it does not apply cleanly to earlier kernel versions. Fixes: 48a7639ce80c ("rcu: Make callers awaken grace-period kthread") Reported-by: "He, Bo" Co-developed-by: "Zhang, Jun" Co-developed-by: "He, Bo" Co-developed-by: "xiao, jin" Co-developed-by: Bai, Jie A Signed-off: "Zhang, Jun" Signed-off: "He, Bo" Signed-off: "xiao, jin" Signed-off: Bai, Jie A Signed-off-by: "Zhang, Jun" [ paulmck: Switch from !in_softirq() to "!in_interrupt() && !in_serving_softirq() to avoid redundant wakeups and to also handle the interrupt-handler scenario as well as the softirq-handler scenario that actually occurred in testing. ] Signed-off-by: Paul E. McKenney Link: https://lkml.kernel.org/r/CD6925E8781EFD4D8E11882D20FC406D52A11F61@SHSMSX104.ccr.corp.intel.com Signed-off-by: Greg Kroah-Hartman commit 5d6f031fa78241c72efecf1c99ff70fa34de0453 Author: Jarkko Sakkinen Date: Fri Feb 8 18:30:58 2019 +0200 tpm: Unify the send callback behaviour commit f5595f5baa30e009bf54d0d7653a9a0cc465be60 upstream. The send() callback should never return length as it does not in every driver except tpm_crb in the success case. The reason is that the main transmit functionality only cares about whether the transmit was successful or not and ignores the count completely. Suggested-by: Stefan Berger Cc: stable@vger.kernel.org Signed-off-by: Jarkko Sakkinen Reviewed-by: Stefan Berger Reviewed-by: Jerry Snitselaar Tested-by: Alexander Steffen Signed-off-by: Greg Kroah-Hartman commit 65a2af7599c6f3b9afa4e6b479fcbfa5bb1ec456 Author: Jarkko Sakkinen Date: Mon Feb 4 15:59:43 2019 +0200 tpm/tpm_crb: Avoid unaligned reads in crb_recv() commit 3d7a850fdc1a2e4d2adbc95cc0fc962974725e88 upstream. The current approach to read first 6 bytes from the response and then tail of the response, can cause the 2nd memcpy_fromio() to do an unaligned read (e.g. read 32-bit word from address aligned to a 16-bits), depending on how memcpy_fromio() is implemented. If this happens, the read will fail and the memory controller will fill the read with 1's. This was triggered by 170d13ca3a2f, which should be probably refined to check and react to the address alignment. Before that commit, on x86 memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right thing (from tpm_crb's perspective) for us so far, but we should not rely on that. Thus, it makes sense to fix this also in tpm_crb, not least because the fix can be then backported to stable kernels and make them more robust when compiled in differing environments. Cc: stable@vger.kernel.org Cc: James Morris Cc: Tomas Winkler Cc: Jerry Snitselaar Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface") Signed-off-by: Jarkko Sakkinen Reviewed-by: Jerry Snitselaar Acked-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit f484e220df1530bed07d0b1e56a127e57f85cd3c Author: Steven Rostedt (VMware) Date: Mon Mar 4 16:35:22 2019 -0500 x86/ftrace: Fix warning and considate ftrace_jmp_replace() and ftrace_call_replace() commit 745cfeaac09ce359130a5451d90cb0bd4094c290 upstream. Arnd reported the following compiler warning: arch/x86/kernel/ftrace.c:669:23: error: 'ftrace_jmp_replace' defined but not used [-Werror=unused-function] The ftrace_jmp_replace() function now only has a single user and should be simply moved by that user. But looking at the code, it shows that ftrace_jmp_replace() is similar to ftrace_call_replace() except that instead of using the opcode of 0xe8 it uses 0xe9. It makes more sense to consolidate that function into one implementation that both ftrace_jmp_replace() and ftrace_call_replace() use by passing in the op code separate. The structure in ftrace_code_union is also modified to replace the "e8" field with the more appropriate name "op". Cc: stable@vger.kernel.org Reported-by: Arnd Bergmann Acked-by: Arnd Bergmann Link: http://lkml.kernel.org/r/20190304200748.1418790-1-arnd@arndb.de Fixes: d2a68c4effd8 ("x86/ftrace: Do not call function graph from dynamic trampolines") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 384dada74d3710d74b673ce5f96294b1375d6963 Author: Pavel Tatashin Date: Sat Jan 26 12:49:56 2019 -0500 x86/kvmclock: set offset for kvm unstable clock commit b5179ec4187251a751832193693d6e474d3445ac upstream. VMs may show incorrect uptime and dmesg printk offsets on hypervisors with unstable clock. The problem is produced when VM is rebooted without exiting from qemu. The fix is to calculate clock offset not only for stable clock but for unstable clock as well, and use kvm_sched_clock_read() which substracts the offset for both clocks. This is safe, because pvclock_clocksource_read() does the right thing and makes sure that clock always goes forward, so once offset is calculated with unstable clock, we won't get new reads that are smaller than offset, and thus won't get negative results. Thank you Jon DeVree for helping to reproduce this issue. Fixes: 857baa87b642 ("sched/clock: Enable sched clock early") Cc: stable@vger.kernel.org Reported-by: Dominique Martinet Signed-off-by: Pavel Tatashin Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 9b236e3f79d9c26009162d331daa5770320f225d Author: Aditya Pakki Date: Mon Mar 4 16:48:54 2019 -0600 md: Fix failed allocation of md_register_thread commit e406f12dde1a8375d77ea02d91f313fb1a9c6aec upstream. mddev->sync_thread can be set to NULL on kzalloc failure downstream. The patch checks for such a scenario and frees allocated resources. Committer node: Added similar fix to raid5.c, as suggested by Guoqing. Cc: stable@vger.kernel.org # v3.16+ Acked-by: Guoqing Jiang Signed-off-by: Aditya Pakki Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 99e5abb7b8958c4bfaa9a155cfa4e3600d336854 Author: Adrian Hunter Date: Fri Mar 1 12:35:36 2019 +0200 perf intel-pt: Fix divide by zero when TSC is not available commit 076333870c2f5bdd9b6d31e7ca1909cf0c84cbfa upstream. When TSC is not available, "timeless" decoding is used but a divide by zero occurs if perf_time_to_tsc() is called. Ensure the divisor is not zero. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org # v4.9+ Link: https://lkml.kernel.org/n/tip-1i4j0wqoc8vlbkcizqqxpsf4@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 85c9f1fb8a81ddd2bbd1c7259b8454b09d51ee09 Author: Kan Liang Date: Wed Feb 27 08:57:29 2019 -0800 perf/x86/intel/uncore: Fix client IMC events return huge result commit 8041ffd36f42d8521d66dd1e236feb58cecd68bc upstream. The client IMC bandwidth events currently return very large values: $ perf stat -e uncore_imc/data_reads/ -e uncore_imc/data_writes/ -I 10000 -a 10.000117222 34,788.76 MiB uncore_imc/data_reads/ 10.000117222 8.26 MiB uncore_imc/data_writes/ 20.000374584 34,842.89 MiB uncore_imc/data_reads/ 20.000374584 10.45 MiB uncore_imc/data_writes/ 30.000633299 37,965.29 MiB uncore_imc/data_reads/ 30.000633299 323.62 MiB uncore_imc/data_writes/ 40.000891548 41,012.88 MiB uncore_imc/data_reads/ 40.000891548 6.98 MiB uncore_imc/data_writes/ 50.001142480 1,125,899,906,621,494.75 MiB uncore_imc/data_reads/ 50.001142480 6.97 MiB uncore_imc/data_writes/ The client IMC events are freerunning counters. They still use the old event encoding format (0x1 for data_read and 0x2 for data write). The counter bit width is calculated by common code, which assume that the standard encoding format is used for the freerunning counters. Error bit width information is calculated. The patch intends to convert the old client IMC event encoding to the standard encoding format. Current common code uses event->attr.config which directly copy from user space. We should not implicitly modify it for a converted event. The event->hw.config is used to replace the event->attr.config in common code. For client IMC events, the event->attr.config is used to calculate a converted event with standard encoding format in the custom event_init(). The converted event is stored in event->hw.config. For other events of freerunning counters, they already use the standard encoding format. The same value as event->attr.config is assigned to event->hw.config in common event_init(). Reported-by: Jin Yao Tested-by: Jin Yao Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Andy Lutomirski Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Dave Hansen Cc: H. Peter Anvin Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Rik van Riel Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: stable@kernel.org # v4.18+ Fixes: 9aae1780e7e8 ("perf/x86/intel/uncore: Clean up client IMC uncore") Link: https://lkml.kernel.org/r/20190227165729.1861-1-kan.liang@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6228a6e3516f9fcada4c2eeb45d56eb1638eee3c Author: Adrian Hunter Date: Wed Feb 6 12:39:44 2019 +0200 perf intel-pt: Fix overlap calculation for padding commit 5a99d99e3310a565b0cf63f785b347be9ee0da45 upstream. Auxtrace records might have up to 7 bytes of padding appended. Adjust the overlap accordingly. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20190206103947.15750-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 2354deae355bd77162676e9e7a23c3c0e9720b4c Author: Adrian Hunter Date: Wed Feb 6 12:39:43 2019 +0200 perf auxtrace: Define auxtrace record alignment commit c3fcadf0bb765faf45d6d562246e1d08885466df upstream. Define auxtrace record alignment so that it can be referenced elsewhere. Note this is preparation for patch "perf intel-pt: Fix overlap calculation for padding" Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20190206103947.15750-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 0f43fd4bdb74714f0ad8b0ee5bd26603b0390adb Author: Adrian Hunter Date: Wed Jan 9 11:18:30 2019 +0200 perf tools: Fix split_kallsyms_for_kcore() for trampoline symbols commit d6d457451eb94fa747dc202765592eb8885a7352 upstream. Kallsyms symbols do not have a size, so the size becomes the distance to the next symbol. Consequently the recently added trampoline symbols end up with large sizes because the trampolines are some distance from one another and the main kernel map. However, symbols that end outside their map can disrupt the symbol tree because, after mapping, it can appear incorrectly that they overlap other symbols. Add logic to truncate symbol size to the end of the corresponding map. Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa Cc: stable@vger.kernel.org Fixes: d83212d5dd67 ("kallsyms, x86: Export addresses of PTI entry trampolines") Link: http://lkml.kernel.org/r/20190109091835.5570-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 99c7a8ec438752b6a29c0449eb3298233d7243cd Author: Adrian Hunter Date: Wed Feb 6 12:39:45 2019 +0200 perf intel-pt: Fix CYC timestamp calculation after OVF commit 03997612904866abe7cdcc992784ef65cb3a4b81 upstream. CYC packet timestamp calculation depends upon CBR which was being cleared upon overflow (OVF). That can cause errors due to failing to synchronize with sideband events. Even if a CBR change has been lost, the old CBR is still a better estimate than zero. So remove the clearing of CBR. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20190206103947.15750-4-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit a0203d4e717ec9939f70a4cc27c5259f5ec31e67 Author: Josh Poimboeuf Date: Wed Mar 6 11:07:24 2019 -0600 x86/unwind/orc: Fix ORC unwind table alignment commit f76a16adc485699f95bb71fce114f97c832fe664 upstream. The .orc_unwind section is a packed array of 6-byte structs. It's currently aligned to 6 bytes, which is causing warnings in the LLD linker. Six isn't a power of two, so it's not a valid alignment value. The actual alignment doesn't matter much because it's an array of packed structs. An alignment of two is sufficient. In reality it always gets aligned to four bytes because it comes immediately after the 4-byte-aligned .orc_unwind_ip section. Fixes: ee9f8fce9964 ("x86/unwind: Add the ORC unwinder") Reported-by: Nick Desaulniers Reported-by: Dmitry Golovin Reported-by: Sedat Dilek Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Tested-by: Sedat Dilek Cc: Peter Zijlstra Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/218 Link: https://lkml.kernel.org/r/d55027ee95fe73e952dcd8be90aebd31b0095c45.1551892041.git.jpoimboe@redhat.com Signed-off-by: Greg Kroah-Hartman commit 194f1ecd4906396a8638a8e9294bd9255209a439 Author: Nicolas Pitre Date: Mon Feb 11 19:36:41 2019 -0500 vt: perform safe console erase in the right order commit a6dbe442755999960ca54a9b8ecfd9606be0ea75 upstream. Commit 4b4ecd9cb853 ("vt: Perform safe console erase only once") removed what appeared to be an extra call to scr_memsetw(). This missed the fact that set_origin() must be called before clearing the screen otherwise old screen content gets restored on the screen when using vgacon. Let's fix that by moving all the scrollback handling to flush_scrollback() where it logically belongs, and invoking it before the actual screen clearing in csi_J(), making the code simpler in the end. Reported-by: Matthew Whitehead Signed-off-by: Nicolas Pitre Tested-by: Matthew Whitehead Fixes: 4b4ecd9cb853 ("vt: Perform safe console erase only once") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c8d3a581742f36da4047eab4b3ed9c27201aa781 Author: Greg Kroah-Hartman Date: Tue Jan 22 19:46:32 2019 +0100 stable-kernel-rules.rst: add link to networking patch queue commit a41e8f25fa8f8f67360d88eb0eebbabe95a64bdf upstream. The networking maintainer keeps a public list of the patches being queued up for the next round of stable releases. Be sure to check there before asking for a patch to be applied so that you do not waste people's time. Signed-off-by: Greg Kroah-Hartman Acked-by: David S. Miller Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit 0b60b354b33a6d7740e0da6174594716cf4356a2 Author: Coly Li Date: Sat Feb 9 12:53:11 2019 +0800 bcache: use (REQ_META|REQ_PRIO) to indicate bio for metadata commit dc7292a5bcb4c878b076fca2ac3fc22f81b8f8df upstream. In 'commit 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for metadata")' REQ_META is replaced by REQ_PRIO to indicate metadata bio. This assumption is not always correct, e.g. XFS uses REQ_META to mark metadata bio other than REQ_PRIO. This is why Nix noticed that bcache does not cache metadata for XFS after the above commit. Thanks to Dave Chinner, he explains the difference between REQ_META and REQ_PRIO from view of file system developer. Here I quote part of his explanation from mailing list, REQ_META is used for metadata. REQ_PRIO is used to communicate to the lower layers that the submitter considers this IO to be more important that non REQ_PRIO IO and so dispatch should be expedited. IOWs, if the filesystem considers metadata IO to be more important that user data IO, then it will use REQ_PRIO | REQ_META rather than just REQ_META. Then it seems bios with REQ_META or REQ_PRIO should both be cached for performance optimation, because they are all probably low I/O latency demand by upper layer (e.g. file system). So in this patch, when we want to decide whether to bypass the cache, REQ_META and REQ_PRIO are both checked. Then both metadata and high priority I/O requests will be handled properly. Reported-by: Nix Signed-off-by: Coly Li Reviewed-by: Andre Noll Tested-by: Nix Cc: stable@vger.kernel.org Cc: Dave Chinner Cc: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dddd539dc3257c8a1bfc66b7c7f4f47ea7f10605 Author: Tang Junhui Date: Sat Feb 9 12:52:58 2019 +0800 bcache: treat stale && dirty keys as bad keys commit 58ac323084ebf44f8470eeb8b82660f9d0ee3689 upstream. Stale && dirty keys can be produced in the follow way: After writeback in write_dirty_finish(), dirty keys k1 will replace by clean keys k2 ==>ret = bch_btree_insert(dc->disk.c, &keys, NULL, &w->key); ==>btree_insert_fn(struct btree_op *b_op, struct btree *b) ==>static int bch_btree_insert_node(struct btree *b, struct btree_op *op, struct keylist *insert_keys, atomic_t *journal_ref, Then two steps: A) update k1 to k2 in btree node memory; bch_btree_insert_keys(b, op, insert_keys, replace_key) B) Write the bset(contains k2) to cache disk by a 30s delay work bch_btree_leaf_dirty(b, journal_ref). But before the 30s delay work write the bset to cache device, these things happened: A) GC works, and reclaim the bucket k2 point to; B) Allocator works, and invalidate the bucket k2 point to, and increase the gen of the bucket, and place it into free_inc fifo; C) Until now, the 30s delay work still does not finish work, so in the disk, the key still is k1, it is dirty and stale (its gen is smaller than the gen of the bucket). and then the machine power off suddenly happens; D) When the machine power on again, after the btree reconstruction, the stale dirty key appear. In bch_extent_bad(), when expensive_debug_checks is off, it would treat the dirty key as good even it is stale keys, and it would cause bellow probelms: A) In read_dirty() it would cause machine crash: BUG_ON(ptr_stale(dc->disk.c, &w->key, 0)); B) It could be worse when reads hits stale dirty keys, it would read old incorrect data. This patch tolerate the existence of these stale && dirty keys, and treat them as bad key in bch_extent_bad(). (Coly Li: fix indent which was modified by sender's email client) Signed-off-by: Tang Junhui Cc: stable@vger.kernel.org Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 97cf758e172c9ae8b3a1561d1dbb247e2eaf6dca Author: Daniel Axtens Date: Sat Feb 9 12:52:53 2019 +0800 bcache: never writeback a discard operation commit 9951379b0ca88c95876ad9778b9099e19a95d566 upstream. Some users see panics like the following when performing fstrim on a bcached volume: [ 529.803060] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 530.183928] #PF error: [normal kernel read fault] [ 530.412392] PGD 8000001f42163067 P4D 8000001f42163067 PUD 1f42168067 PMD 0 [ 530.750887] Oops: 0000 [#1] SMP PTI [ 530.920869] CPU: 10 PID: 4167 Comm: fstrim Kdump: loaded Not tainted 5.0.0-rc1+ #3 [ 531.290204] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 12/27/2015 [ 531.693137] RIP: 0010:blk_queue_split+0x148/0x620 [ 531.922205] Code: 60 38 89 55 a0 45 31 db 45 31 f6 45 31 c9 31 ff 89 4d 98 85 db 0f 84 7f 04 00 00 44 8b 6d 98 4c 89 ee 48 c1 e6 04 49 03 70 78 <8b> 46 08 44 8b 56 0c 48 8b 16 44 29 e0 39 d8 48 89 55 a8 0f 47 c3 [ 532.838634] RSP: 0018:ffffb9b708df39b0 EFLAGS: 00010246 [ 533.093571] RAX: 00000000ffffffff RBX: 0000000000046000 RCX: 0000000000000000 [ 533.441865] RDX: 0000000000000200 RSI: 0000000000000000 RDI: 0000000000000000 [ 533.789922] RBP: ffffb9b708df3a48 R08: ffff940d3b3fdd20 R09: 0000000000000000 [ 534.137512] R10: ffffb9b708df3958 R11: 0000000000000000 R12: 0000000000000000 [ 534.485329] R13: 0000000000000000 R14: 0000000000000000 R15: ffff940d39212020 [ 534.833319] FS: 00007efec26e3840(0000) GS:ffff940d1f480000(0000) knlGS:0000000000000000 [ 535.224098] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 535.504318] CR2: 0000000000000008 CR3: 0000001f4e256004 CR4: 00000000001606e0 [ 535.851759] Call Trace: [ 535.970308] ? mempool_alloc_slab+0x15/0x20 [ 536.174152] ? bch_data_insert+0x42/0xd0 [bcache] [ 536.403399] blk_mq_make_request+0x97/0x4f0 [ 536.607036] generic_make_request+0x1e2/0x410 [ 536.819164] submit_bio+0x73/0x150 [ 536.980168] ? submit_bio+0x73/0x150 [ 537.149731] ? bio_associate_blkg_from_css+0x3b/0x60 [ 537.391595] ? _cond_resched+0x1a/0x50 [ 537.573774] submit_bio_wait+0x59/0x90 [ 537.756105] blkdev_issue_discard+0x80/0xd0 [ 537.959590] ext4_trim_fs+0x4a9/0x9e0 [ 538.137636] ? ext4_trim_fs+0x4a9/0x9e0 [ 538.324087] ext4_ioctl+0xea4/0x1530 [ 538.497712] ? _copy_to_user+0x2a/0x40 [ 538.679632] do_vfs_ioctl+0xa6/0x600 [ 538.853127] ? __do_sys_newfstat+0x44/0x70 [ 539.051951] ksys_ioctl+0x6d/0x80 [ 539.212785] __x64_sys_ioctl+0x1a/0x20 [ 539.394918] do_syscall_64+0x5a/0x110 [ 539.568674] entry_SYSCALL_64_after_hwframe+0x44/0xa9 We have observed it where both: 1) LVM/devmapper is involved (bcache backing device is LVM volume) and 2) writeback cache is involved (bcache cache_mode is writeback) On one machine, we can reliably reproduce it with: # echo writeback > /sys/block/bcache0/bcache/cache_mode (not sure whether above line is required) # mount /dev/bcache0 /test # for i in {0..10}; do file="$(mktemp /test/zero.XXX)" dd if=/dev/zero of="$file" bs=1M count=256 sync rm $file done # fstrim -v /test Observing this with tracepoints on, we see the following writes: fstrim-18019 [022] .... 91107.302026: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4260112 + 196352 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302050: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4456464 + 262144 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302075: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4718608 + 81920 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302094: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5324816 + 180224 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302121: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5505040 + 262144 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302145: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5767184 + 81920 hit 0 bypass 1 fstrim-18019 [022] .... 91107.308777: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 6373392 + 180224 hit 1 bypass 0 Note the final one has different hit/bypass flags. This is because in should_writeback(), we were hitting a case where the partial stripe condition was returning true and so should_writeback() was returning true early. If that hadn't been the case, it would have hit the would_skip test, and as would_skip == s->iop.bypass == true, should_writeback() would have returned false. Looking at the git history from 'commit 72c270612bd3 ("bcache: Write out full stripes")', it looks like the idea was to optimise for raid5/6: * If a stripe is already dirty, force writes to that stripe to writeback mode - to help build up full stripes of dirty data To fix this issue, make sure that should_writeback() on a discard op never returns true. More details of debugging: https://www.spinics.net/lists/linux-bcache/msg06996.html Previous reports: - https://bugzilla.kernel.org/show_bug.cgi?id=201051 - https://bugzilla.kernel.org/show_bug.cgi?id=196103 - https://www.spinics.net/lists/linux-bcache/msg06885.html (Coly Li: minor modification to follow maximum 75 chars per line rule) Cc: Kent Overstreet Cc: stable@vger.kernel.org Fixes: 72c270612bd3 ("bcache: Write out full stripes") Signed-off-by: Daniel Axtens Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a8ce88427a9b3932e469e3eeb4853926b8a91b34 Author: Viresh Kumar Date: Tue Mar 12 10:27:18 2019 +0530 PM / OPP: Update performance state when freq == old_freq commit faef080f6db5320011862f7baf1aa66d0851559f upstream. At boot up, CPUFreq core performs a sanity check to see if the system is running at a frequency defined in the frequency table of the CPU. If so, we try to find a valid frequency (lowest frequency greater than the currently programmed frequency) from the table and set it. When the call reaches dev_pm_opp_set_rate(), it calls _find_freq_ceil(opp_table, &old_freq) to find the previously configured OPP and this call also updates the old_freq. This eventually sets the old_freq == freq (new target requested by cpufreq core) and we skip updating the performance state in this case. Fix this by also updating the performance state when the old_freq == freq. Fixes: ca1b5d77b1c6 ("OPP: Configure all required OPPs") Cc: v5.0 # v5.0 Reported-by: Niklas Cassel Tested-by: Jorge Ramirez-Ortiz Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c9c0e5f01245d6bf6779401a32f9f194e19deb87 Author: Viresh Kumar Date: Fri Mar 8 15:23:11 2019 +0530 PM / wakeup: Rework wakeup source timer cancellation commit 1fad17fb1bbcd73159c2b992668a6957ecc5af8a upstream. If wakeup_source_add() is called right after wakeup_source_remove() for the same wakeup source, timer_setup() may be called for a potentially scheduled timer which is incorrect. To avoid that, move the wakeup source timer cancellation from wakeup_source_drop() to wakeup_source_remove(). Moreover, make wakeup_source_remove() clear the timer function after canceling the timer to let wakeup_source_not_registered() treat unregistered wakeup sources in the same way as the ones that have never been registered. Signed-off-by: Viresh Kumar Cc: 4.4+ # 4.4+ [ rjw: Subject, changelog, merged two patches together ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f03f5295caf0106820d1dac1fe0e019ee00f05dc Author: J. Bruce Fields Date: Wed Feb 20 12:54:50 2019 -0500 svcrpc: fix UDP on servers with lots of threads commit b7e5034cbecf5a65b7bfdc2b20a8378039577706 upstream. James Pearson found that an NFS server stopped responding to UDP requests if started with more than 1017 threads. sv_max_mesg is about 2^20, so that is probably where the calculation performed by svc_sock_setbufsize(svsk->sk_sock, (serv->sv_nrthreads+3) * serv->sv_max_mesg, (serv->sv_nrthreads+3) * serv->sv_max_mesg); starts to overflow an int. Reported-by: James Pearson Tested-by: James Pearson Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 1363f37fbd241c8341816513dfd07b3d9ed3a4ba Author: Trond Myklebust Date: Fri Mar 1 12:13:34 2019 -0500 NFSv4.1: Reinitialise sequence results before retransmitting a request commit c1dffe0bf7f9c3d57d9f237a7cb2a81e62babd2b upstream. If we have to retransmit a request, we should ensure that we reinitialise the sequence results structure, since in the event of a signal we need to treat the request as if it had not been sent. Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 867ae74fb190082a12863a4719c1f6fead35c50a Author: Yihao Wu Date: Wed Mar 6 21:03:50 2019 +0800 nfsd: fix wrong check in write_v4_end_grace() commit dd838821f0a29781b185cd8fb8e48d5c177bd838 upstream. Commit 62a063b8e7d1 "nfsd4: fix crash on writing v4_end_grace before nfsd startup" is trying to fix a NULL dereference issue, but it mistakenly checks if the nfsd server is started. So fix it. Fixes: 62a063b8e7d1 "nfsd4: fix crash on writing v4_end_grace before nfsd startup" Cc: stable@vger.kernel.org Reviewed-by: Joseph Qi Signed-off-by: Yihao Wu Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit f5bed084b482498852a5e6caf4fa2f83c6e55040 Author: NeilBrown Date: Mon Mar 4 14:08:22 2019 +1100 nfsd: fix memory corruption caused by readdir commit b602345da6cbb135ba68cf042df8ec9a73da7981 upstream. If the result of an NFSv3 readdir{,plus} request results in the "offset" on one entry having to be split across 2 pages, and is sized so that the next directory entry doesn't fit in the requested size, then memory corruption can happen. When encode_entry() is called after encoding the last entry that fits, it notices that ->offset and ->offset1 are set, and so stores the offset value in the two pages as required. It clears ->offset1 but *does not* clear ->offset. Normally this omission doesn't matter as encode_entry_baggage() will be called, and will set ->offset to a suitable value (not on a page boundary). But in the case where cd->buflen < elen and nfserr_toosmall is returned, ->offset is not reset. This means that nfsd3proc_readdirplus will see ->offset with a value 4 bytes before the end of a page, and ->offset1 set to NULL. It will try to write 8bytes to ->offset. If we are lucky, the next page will be read-only, and the system will BUG: unable to handle kernel paging request at... If we are unlucky, some innocent page will have the first 4 bytes corrupted. nfsd3proc_readdir() doesn't even check for ->offset1, it just blindly writes 8 bytes to the offset wherever it is. Fix this by clearing ->offset after it is used, and copying the ->offset handling code from nfsd3_proc_readdirplus into nfsd3_proc_readdir. (Note that the commit hash in the Fixes tag is from the 'history' tree - this bug predates git). Fixes: 0b1d57cf7654 ("[PATCH] kNFSd: Fix nfs3 dentry encoding") Fixes-URL: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=0b1d57cf7654 Cc: stable@vger.kernel.org (v2.6.12+) Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 2ececa64d67ad8efe1704ec9ecdecb1451ee32a1 Author: J. Bruce Fields Date: Thu Feb 21 10:47:00 2019 -0500 nfsd: fix performance-limiting session calculation commit c54f24e338ed2a35218f117a4a1afb5f9e2b4e64 upstream. We're unintentionally limiting the number of slots per nfsv4.1 session to 10. Often more than 10 simultaneous RPCs are needed for the best performance. This calculation was meant to prevent any one client from using up more than a third of the limit we set for total memory use across all clients and sessions. Instead, it's limiting the client to a third of the maximum for a single session. Fix this. Reported-by: Chris Tracy Cc: stable@vger.kernel.org Fixes: de766e570413 "nfsd: give out fewer session slots as limit approaches" Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 88f786a8e78a091e10a58cb794fb5637feaa82d0 Author: Trond Myklebust Date: Fri Feb 15 16:08:25 2019 -0500 NFS: Don't recoalesce on error in nfs_pageio_complete_mirror() commit 8127d82705998568b52ac724e28e00941538083d upstream. If the I/O completion failed with a fatal error, then we should just exit nfs_pageio_complete_mirror() rather than try to recoalesce. Fixes: a7d42ddb3099 ("nfs: add mirroring support to pgio layer") Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: Greg Kroah-Hartman commit 4fe2a7fda78a7275cd695e0219260d3a5572bc24 Author: Trond Myklebust Date: Fri Feb 15 14:59:52 2019 -0500 NFS: Fix an I/O request leakage in nfs_do_recoalesce commit 4d91969ed4dbcefd0e78f77494f0cb8fada9048a upstream. Whether we need to exit early, or just reprocess the list, we must not lost track of the request which failed to get recoalesced. Fixes: 03d5eb65b538 ("NFS: Fix a memory leak in nfs_do_recoalesce") Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: Greg Kroah-Hartman commit e83b6ac7deed44e09f45bf13e837cd9e3ce23256 Author: Trond Myklebust Date: Wed Feb 13 09:21:38 2019 -0500 NFS: Fix I/O request leakages commit f57dcf4c72113c745d83f1c65f7291299f65c14f upstream. When we fail to add the request to the I/O queue, we currently leave it to the caller to free the failed request. However since some of the requests that fail are actually created by nfs_pageio_add_request() itself, and are not passed back the caller, this leads to a leakage issue, which can again cause page locks to leak. This commit addresses the leakage by freeing the created requests on error, using desc->pg_completion_ops->error_cleanup() Signed-off-by: Trond Myklebust Fixes: a7d42ddb30997 ("nfs: add mirroring support to pgio layer") Cc: stable@vger.kernel.org # v4.0: c18b96a1b862: nfs: clean up rest of reqs Cc: stable@vger.kernel.org # v4.0: d600ad1f2bdb: NFS41: pop some layoutget Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: Greg Kroah-Hartman commit b41991d86722d6557ca9e4509313d894c9fdc46b Author: Rafael J. Wysocki Date: Tue Mar 12 19:13:13 2019 +0100 cpuidle: governor: Add new governors to cpuidle_governors again commit 22782b3f9bb8ae21c710e2880db21bc729771e92 upstream. After commit 61cb5758d3c4 ("cpuidle: Add cpuidle.governor= command line parameter") new cpuidle governors are not added to the list of available governors, so governor selection via sysfs doesn't work as expected (even though it is rarely used anyway). Fix that by making cpuidle_register_governor() add new governors to cpuidle_governors again. Fixes: 61cb5758d3c4 ("cpuidle: Add cpuidle.governor= command line parameter") Reported-by: Kees Cook Cc: 5.0+ # 5.0+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6eea03f8c368b79f8b8ca0fbe4cbe23ce51cb843 Author: Pavel Machek Date: Thu Dec 27 20:52:21 2018 +0100 cpcap-charger: generate events for userspace commit fd10606f93a149a9f3d37574e5385b083b4a7b32 upstream. The driver doesn't generate uevents on charger connect/disconnect. This leads to UPower not detecting when AC is on or off... and that is bad. Reported by Arthur D. on github ( https://github.com/maemo-leste/bugtracker/issues/206 ), thanks to Merlijn Wajer for suggesting a fix. Cc: stable@kernel.org Signed-off-by: Pavel Machek Acked-by: Tony Lindgren Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 9cc42d068f57ed5bf15ec626f20d256cfffc5d1c Author: Gustavo A. R. Silva Date: Tue Jan 22 10:56:36 2019 -0600 mfd: sm501: Fix potential NULL pointer dereference commit ae7b8eda27b33b1f688dfdebe4d46f690a8f9162 upstream. There is a potential NULL pointer dereference in case devm_kzalloc() fails and returns NULL. Fix this by adding a NULL check on *lookup* This bug was detected with the help of Coccinelle. Fixes: b2e63555592f ("i2c: gpio: Convert to use descriptors") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 83df21c731e632254232ffa980f9244ca10dcfb0 Author: Cody P Schafer Date: Mon Jan 14 19:14:24 2019 -0500 media: cx25840: mark pad sig_types to fix cx231xx init commit 46c039d06b6ecabb94bd16c3a999b28dc83b79ce upstream. Without this, we get failures like this when the kernel attempts to initialize a cx231xx device: [16046.153653] cx231xx 3-1.2:1.1: New device Hauppauge Hauppauge Device @ 480 Mbps (2040:c200) with 6 interfaces [16046.153900] cx231xx 3-1.2:1.1: can't change interface 3 alt no. to 3: Max. Pkt size = 0 [16046.153907] cx231xx 3-1.2:1.1: Identified as Hauppauge USB Live 2 (card=9) [16046.154350] i2c i2c-11: Added multiplexed i2c bus 13 [16046.154379] i2c i2c-11: Added multiplexed i2c bus 14 [16046.267194] cx25840 10-0044: cx23102 A/V decoder found @ 0x88 (cx231xx #0-0) [16048.424551] cx25840 10-0044: loaded v4l-cx231xx-avcore-01.fw firmware (16382 bytes) [16048.463224] cx231xx 3-1.2:1.1: v4l2 driver version 0.0.3 [16048.567878] cx231xx 3-1.2:1.1: Registered video device video2 [v4l2] [16048.568001] cx231xx 3-1.2:1.1: Registered VBI device vbi0 [16048.568419] cx231xx 3-1.2:1.1: audio EndPoint Addr 0x83, Alternate settings: 3 [16048.568425] cx231xx 3-1.2:1.1: video EndPoint Addr 0x84, Alternate settings: 5 [16048.568431] cx231xx 3-1.2:1.1: VBI EndPoint Addr 0x85, Alternate settings: 2 [16048.568436] cx231xx 3-1.2:1.1: sliced CC EndPoint Addr 0x86, Alternate settings: 2 [16048.568448] usb 3-1.2: couldn't get decoder output pad for V4L I/O [16048.568453] cx231xx 3-1.2:1.1: V4L2 device vbi0 deregistered [16048.568579] cx231xx 3-1.2:1.1: V4L2 device video2 deregistered [16048.569001] cx231xx: probe of 3-1.2:1.1 failed with error -22 Likely a regession since Commit 9d6d20e652c0 ("media: v4l2-mc: switch it to use the new approach to setup pipelines") (v4.19-rc1-100-g9d6d20e652c0), which introduced the use of PAD_SIGNAL_DV within v4l2_mc_create_media_graph(). This also modifies cx25840 to remove the VBI pad, matching the action taken in Commit 092a37875a22 ("media: v4l2: remove VBI output pad"). Fixes: 9d6d20e652c0 ("media: v4l2-mc: switch it to use the new approach to setup pipelines") Cc: stable@vger.kernel.org Signed-off-by: Cody P Schafer Tested-by: Hans Verkuil Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b6246ffae5a0e05878afd0079ff6a9c76df865ec Author: Mikulas Patocka Date: Wed Mar 6 08:29:34 2019 -0500 dm integrity: limit the rate of error messages commit 225557446856448039a9e495da37b72c20071ef2 upstream. When using dm-integrity underneath md-raid, some tests with raid auto-correction trigger large amounts of integrity failures - and all these failures print an error message. These messages can bring the system to a halt if the system is using serial console. Fix this by limiting the rate of error messages - it improves the speed of raid recovery and avoids the hang. Fixes: 7eada909bfd7a ("dm: add integrity target") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit dca22c59e47e2af32943c471aa879fa9ba20baf0 Author: NeilBrown Date: Sun Jan 6 21:06:25 2019 +1100 dm: fix to_sector() for 32bit commit 0bdb50c531f7377a9da80d3ce2d61f389c84cb30 upstream. A dm-raid array with devices larger than 4GB won't assemble on a 32 bit host since _check_data_dev_sectors() was added in 4.16. This is because to_sector() treats its argument as an "unsigned long" which is 32bits (4GB) on a 32bit host. Using "unsigned long long" is more correct. Kernels as early as 4.2 can have other problems due to to_sector() being used on the size of a device. Fixes: 0cf4503174c1 ("dm raid: add support for the MD RAID0 personality") cc: stable@vger.kernel.org (v4.2+) Reported-and-tested-by: Guillaume Perréal Signed-off-by: NeilBrown Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit a8964a63780ce3ea4ada492cfe8edef9c1336022 Author: Yang Yingliang Date: Mon Jan 28 11:08:54 2019 +0800 ipmi_si: fix use-after-free of resource->name commit 401e7e88d4ef80188ffa07095ac00456f901b8c4 upstream. When we excute the following commands, we got oops rmmod ipmi_si cat /proc/ioports [ 1623.482380] Unable to handle kernel paging request at virtual address ffff00000901d478 [ 1623.482382] Mem abort info: [ 1623.482383] ESR = 0x96000007 [ 1623.482385] Exception class = DABT (current EL), IL = 32 bits [ 1623.482386] SET = 0, FnV = 0 [ 1623.482387] EA = 0, S1PTW = 0 [ 1623.482388] Data abort info: [ 1623.482389] ISV = 0, ISS = 0x00000007 [ 1623.482390] CM = 0, WnR = 0 [ 1623.482393] swapper pgtable: 4k pages, 48-bit VAs, pgdp = 00000000d7d94a66 [ 1623.482395] [ffff00000901d478] pgd=000000dffbfff003, pud=000000dffbffe003, pmd=0000003f5d06e003, pte=0000000000000000 [ 1623.482399] Internal error: Oops: 96000007 [#1] SMP [ 1623.487407] Modules linked in: ipmi_si(E) nls_utf8 isofs rpcrdma ib_iser ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_umad rdma_cm ib_cm dm_mirror dm_region_hash dm_log iw_cm dm_mod aes_ce_blk crypto_simd cryptd aes_ce_cipher ses ghash_ce sha2_ce enclosure sha256_arm64 sg sha1_ce hisi_sas_v2_hw hibmc_drm sbsa_gwdt hisi_sas_main ip_tables mlx5_ib ib_uverbs marvell ib_core mlx5_core ixgbe mdio hns_dsaf ipmi_devintf hns_enet_drv ipmi_msghandler hns_mdio [last unloaded: ipmi_si] [ 1623.532410] CPU: 30 PID: 11438 Comm: cat Kdump: loaded Tainted: G E 5.0.0-rc3+ #168 [ 1623.541498] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.37 11/21/2017 [ 1623.548822] pstate: a0000005 (NzCv daif -PAN -UAO) [ 1623.553684] pc : string+0x28/0x98 [ 1623.557040] lr : vsnprintf+0x368/0x5e8 [ 1623.560837] sp : ffff000013213a80 [ 1623.564191] x29: ffff000013213a80 x28: ffff00001138abb5 [ 1623.569577] x27: ffff000013213c18 x26: ffff805f67d06049 [ 1623.574963] x25: 0000000000000000 x24: ffff00001138abb5 [ 1623.580349] x23: 0000000000000fb7 x22: ffff0000117ed000 [ 1623.585734] x21: ffff000011188fd8 x20: ffff805f67d07000 [ 1623.591119] x19: ffff805f67d06061 x18: ffffffffffffffff [ 1623.596505] x17: 0000000000000200 x16: 0000000000000000 [ 1623.601890] x15: ffff0000117ed748 x14: ffff805f67d07000 [ 1623.607276] x13: ffff805f67d0605e x12: 0000000000000000 [ 1623.612661] x11: 0000000000000000 x10: 0000000000000000 [ 1623.618046] x9 : 0000000000000000 x8 : 000000000000000f [ 1623.623432] x7 : ffff805f67d06061 x6 : fffffffffffffffe [ 1623.628817] x5 : 0000000000000012 x4 : ffff00000901d478 [ 1623.634203] x3 : ffff0a00ffffff04 x2 : ffff805f67d07000 [ 1623.639588] x1 : ffff805f67d07000 x0 : ffffffffffffffff [ 1623.644974] Process cat (pid: 11438, stack limit = 0x000000008d4cbc10) [ 1623.651592] Call trace: [ 1623.654068] string+0x28/0x98 [ 1623.657071] vsnprintf+0x368/0x5e8 [ 1623.660517] seq_vprintf+0x70/0x98 [ 1623.668009] seq_printf+0x7c/0xa0 [ 1623.675530] r_show+0xc8/0xf8 [ 1623.682558] seq_read+0x330/0x440 [ 1623.689877] proc_reg_read+0x78/0xd0 [ 1623.697346] __vfs_read+0x60/0x1a0 [ 1623.704564] vfs_read+0x94/0x150 [ 1623.711339] ksys_read+0x6c/0xd8 [ 1623.717939] __arm64_sys_read+0x24/0x30 [ 1623.725077] el0_svc_common+0x120/0x148 [ 1623.732035] el0_svc_handler+0x30/0x40 [ 1623.738757] el0_svc+0x8/0xc [ 1623.744520] Code: d1000406 aa0103e2 54000149 b4000080 (39400085) [ 1623.753441] ---[ end trace f91b6a4937de9835 ]--- [ 1623.760871] Kernel panic - not syncing: Fatal exception [ 1623.768935] SMP: stopping secondary CPUs [ 1623.775718] Kernel Offset: disabled [ 1623.781998] CPU features: 0x002,21006008 [ 1623.788777] Memory Limit: none [ 1623.798329] Starting crashdump kernel... [ 1623.805202] Bye! If io_setup is called successful in try_smi_init() but try_smi_init() goes out_err before calling ipmi_register_smi(), so ipmi_unregister_smi() will not be called while removing module. It leads to the resource that allocated in io_setup() can not be freed, but the name(DEVICE_NAME) of resource is freed while removing the module. It causes use-after-free when cat /proc/ioports. Fix this by calling io_cleanup() while try_smi_init() goes to out_err. and don't call io_cleanup() until io_setup() returns successful to avoid warning prints. Fixes: 93c303d2045b ("ipmi_si: Clean up shutdown a bit") Cc: stable@vger.kernel.org Reported-by: NuoHan Qiao Suggested-by: Corey Minyard Signed-off-by: Yang Yingliang Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit d3432e5d0831f3dd1cd850ec45b5073eaabece63 Author: Corey Minyard Date: Thu Feb 21 12:10:07 2019 -0600 ipmi_si: Fix crash when using hard-coded device commit 41b766d661bf94a364960862cfc248a78313dbd3 upstream. When excuting a command like: modprobe ipmi_si ports=0xffc0e3 type=bt The system would get an oops. The trouble here is that ipmi_si_hardcode_find_bmc() is called before ipmi_si_platform_init(), but initialization of the hard-coded device creates an IPMI platform device, which won't be initialized yet. The real trouble is that hard-coded devices aren't created with any device, and the fixup is done later. So do it right, create the hard-coded devices as normal platform devices. This required adding some new resource types to the IPMI platform code for passing information required by the hard-coded device and adding some code to remove the hard-coded platform devices on module removal. To enforce the "hard-coded devices passed by the user take priority over firmware devices" rule, some special code was added to check and see if a hard-coded device already exists. Reported-by: Yang Yingliang Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Corey Minyard Tested-by: Yang Yingliang Signed-off-by: Greg Kroah-Hartman commit 98ab3b877400c2cbd025c112fb3d2b759f067193 Author: Ben Gardon Date: Tue Mar 12 11:45:58 2019 -0700 Revert "KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()" commit 92da008fa21034c369cdb8ca2b629fe5c196826b upstream. This reverts commit 71883a62fcd6c70639fa12cda733378b4d997409. The above commit contains an optimization to kvm_zap_gfn_range which uses gfn-limited TLB flushes, if enabled. If using these limited flushes, kvm_zap_gfn_range passes lock_flush_tlb=false to slot_handle_level_range which creates a race when the function unlocks to call cond_resched. See an example of this race below: CPU 0 CPU 1 CPU 3 // zap_direct_gfn_range mmu_lock() // *ptep == pte_1 *ptep = 0 if (lock_flush_tlb) flush_tlbs() mmu_unlock() // In invalidate range // MMU notifier mmu_lock() if (pte != 0) *ptep = 0 flush = true if (flush) flush_remote_tlbs() mmu_unlock() return // Host MM reallocates // page previously // backing guest memory. // Guest accesses // invalid page // through pte_1 // in its TLB!! Tested: Ran all kvm-unit-tests on a Intel Haswell machine with and without this patch. The patch introduced no new failures. Signed-off-by: Ben Gardon Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit bf5615991a915bfce37a6abdd8419325a4ac2f9a Author: Dave Martin Date: Thu Feb 21 11:42:32 2019 +0000 arm64: KVM: Fix architecturally invalid reset value for FPEXC32_EL2 commit c88b093693ccbe41991ef2e9b1d251945e6e54ed upstream. Due to what looks like a typo dating back to the original addition of FPEXC32_EL2 handling, KVM currently initialises this register to an architecturally invalid value. As a result, the VECITR field (RES1) in bits [10:8] is initialised with 0, and the two reserved (RES0) bits [6:5] are initialised with 1. (In the Common VFP Subarchitecture as specified by ARMv7-A, these two bits were IMP DEF. ARMv8-A removes them.) This patch changes the reset value from 0x70 to 0x700, which reflects the architectural constraints and is presumably what was originally intended. Cc: # 4.12.x- Cc: Christoffer Dall Fixes: 62a89c44954f ("arm64: KVM: 32bit handling of coprocessor traps") Signed-off-by: Dave Martin Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 4b6d75b38664ab8869e99b80b5ff1911209cbe59 Author: Will Deacon Date: Fri Mar 1 13:28:01 2019 +0000 arm64: debug: Ensure debug handlers check triggering exception level commit 6bd288569b50bc89fa5513031086746968f585cb upstream. Debug exception handlers may be called for exceptions generated both by user and kernel code. In many cases, this is checked explicitly, but in other cases things either happen to work by happy accident or they go slightly wrong. For example, executing 'brk #4' from userspace will enter the kprobes code and be ignored, but the instruction will be retried forever in userspace instead of delivering a SIGTRAP. Fix this issue in the most stable-friendly fashion by simply adding explicit checks of the triggering exception level to all of our debug exception handlers. Cc: Reviewed-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 4f771d8acc7452b6900a02df3235dd67c064b52d Author: Will Deacon Date: Fri Mar 1 13:28:00 2019 +0000 arm64: debug: Don't propagate UNKNOWN FAR into si_code for debug signals commit b9a4b9d084d978f80eb9210727c81804588b42ff upstream. FAR_EL1 is UNKNOWN for all debug exceptions other than those caused by taking a hardware watchpoint. Unfortunately, if a debug handler returns a non-zero value, then we will propagate the UNKNOWN FAR value to userspace via the si_addr field of the SIGTRAP siginfo_t. Instead, let's set si_addr to take on the PC of the faulting instruction, which we have available in the current pt_regs. Cc: Reviewed-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 9afab3b6b9c549ea84ad2812559f7ab986808f5a Author: Julien Thierry Date: Thu Jan 31 14:58:39 2019 +0000 arm64: Fix HCR.TGE status for NMI contexts commit 5870970b9a828d8693aa6d15742573289d7dbcd0 upstream. When using VHE, the host needs to clear HCR_EL2.TGE bit in order to interact with guest TLBs, switching from EL2&0 translation regime to EL1&0. However, some non-maskable asynchronous event could happen while TGE is cleared like SDEI. Because of this address translation operations relying on EL2&0 translation regime could fail (tlb invalidation, userspace access, ...). Fix this by properly setting HCR_EL2.TGE when entering NMI context and clear it if necessary when returning to the interrupted context. Signed-off-by: Julien Thierry Suggested-by: Marc Zyngier Reviewed-by: Marc Zyngier Reviewed-by: James Morse Cc: Arnd Bergmann Cc: Will Deacon Cc: Marc Zyngier Cc: James Morse Cc: linux-arch@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 8f67dd8570ac05366b06b7de00b5a1cc192b15de Author: Gustavo A. R. Silva Date: Thu Jan 3 14:14:08 2019 -0600 ARM: s3c24xx: Fix boolean expressions in osiris_dvs_notify commit e2477233145f2156434afb799583bccd878f3e9f upstream. Fix boolean expressions by using logical AND operator '&&' instead of bitwise operator '&'. This issue was detected with the help of Coccinelle. Fixes: 4fa084af28ca ("ARM: OSIRIS: DVS (Dynamic Voltage Scaling) supoort.") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva [krzk: Fix -Wparentheses warning] Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 6a4c3ab2d53e6e144898a98a9495ae629e75683e Author: Christophe Leroy Date: Tue Jan 29 16:37:55 2019 +0000 powerpc/traps: Fix the message printed when stack overflows commit 9bf3d3c4e4fd82c7174f4856df372ab2a71005b9 upstream. Today's message is useless: [ 42.253267] Kernel stack overflow in process (ptrval), r1=c65500b0 This patch fixes it: [ 66.905235] Kernel stack overflow in process sh[356], r1=c65560b0 Fixes: ad67b74d2469 ("printk: hash addresses printed with %p") Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Christophe Leroy [mpe: Use task_pid_nr()] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 24bf608e74387d8ac6e617302aa1c4f536d12277 Author: Christophe Leroy Date: Tue Jan 22 14:11:24 2019 +0000 powerpc/traps: fix recoverability of machine check handling on book3s/32 commit 0bbea75c476b77fa7d7811d6be911cc7583e640f upstream. Looks like book3s/32 doesn't set RI on machine check, so checking RI before calling die() will always be fatal allthought this is not an issue in most cases. Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable interrupt") Fixes: daf00ae71dad ("powerpc/traps: restore recoverability of machine_check interrupts") Signed-off-by: Christophe Leroy Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 71bb4d02441620f983e119edae46d2bbe1f459f5 Author: Nicholas Piggin Date: Mon Nov 26 12:01:06 2018 +1000 powerpc/smp: Fix NMI IPI xmon timeout commit 88b9a3d1425a436e95c41f09986fdae2daee437a upstream. The xmon debugger IPI handler waits in the callback function while xmon is still active. This means they don't complete the IPI, and the initiator always times out waiting for them. Things manage to work after the timeout because there is some fallback logic to keep NMI IPI state sane in case of the timeout, but this is a bit ugly. This patch changes NMI IPI back to half-asynchronous (i.e., wait for everyone to call in, do not wait for IPI function to complete), but the complexity is avoided by going one step further and allowing new IPIs to be issued before the IPI functions to all complete. If synchronization against that is required, it is left up to the caller, but current callers don't require that. In fact with the timeout handling, callers must be able to cope with this already. Fixes: 5b73151fff63 ("powerpc: NMI IPI make NMI IPIs fully sychronous") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 850a95bf2a4626745d7a4de59fb08d23a93f305f Author: Nicholas Piggin Date: Mon Nov 26 12:01:05 2018 +1000 powerpc/smp: Fix NMI IPI timeout commit 1b5fc84aba170bdfe3533396ca9662ceea1609b7 upstream. The NMI IPI timeout logic is broken, if __smp_send_nmi_ipi() times out on the first condition, delay_us will be zero which will send it into the second spin loop with no timeout so it will spin forever. Fixes: 5b73151fff63 ("powerpc: NMI IPI make NMI IPIs fully sychronous") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit fcf1ca937f59cee7dbaac4aabca45ebd95997aba Author: Aneesh Kumar K.V Date: Fri Feb 22 22:55:31 2019 +0530 powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration commit 35f2806b481f5b9207f25e1886cba5d1c4d12cc7 upstream. We added runtime allocation of 16G pages in commit 4ae279c2c96a ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.") That was done to enable 16G allocation on PowerNV and KVM config. In case of KVM config, we mostly would have the entire guest RAM backed by 16G hugetlb pages for this to work. PAPR do support partial backing of guest RAM with hugepages via ibm,expected#pages node of memory node in the device tree. This means rest of the guest RAM won't be backed by 16G contiguous pages in the host and hence a hash page table insertion can fail in such case. An example error message will look like hash-mmu: mm: Hashing failure ! EA=0x7efc00000000 access=0x8000000000000006 current=readback hash-mmu: trap=0x300 vsid=0x67af789 ssize=1 base psize=14 psize 14 pte=0xc000000400000386 readback[12260]: unhandled signal 7 at 00007efc00000000 nip 00000000100012d0 lr 000000001000127c code 2 This patch address that by preventing runtime allocation of 16G hugepages in LPAR config. To allocate 16G hugetlb one need to kernel command line hugepagesz=16G hugepages= With radix translation mode we don't run into this issue. This change will prevent runtime allocation of 16G hugetlb pages on kvm with hash translation mode. However, with the current upstream it was observed that 16G hugetlbfs backed guest doesn't boot at all. We observe boot failure with the below message: [131354.647546] KVM: map_vrma at 0 failed, ret=-4 That means this patch is not resulting in an observable regression. Once we fix the boot issue with 16G hugetlb backed memory, we need to use ibm,expected#pages memory node attribute to indicate 16G page reservation to the guest. This will also enable partial backing of guest RAM with 16G pages. Fixes: 4ae279c2c96a ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4ca936a493606bea2224c3b3796235fd398f31d0 Author: Michael Ellerman Date: Thu Feb 14 11:08:29 2019 +1100 powerpc/ptrace: Simplify vr_get/set() to avoid GCC warning commit ca6d5149d2ad0a8d2f9c28cbe379802260a0a5e0 upstream. GCC 8 warns about the logic in vr_get/set(), which with -Werror breaks the build: In function ‘user_regset_copyin’, inlined from ‘vr_set’ at arch/powerpc/kernel/ptrace.c:628:9: include/linux/regset.h:295:4: error: ‘memcpy’ offset [-527, -529] is out of the bounds [0, 16] of object ‘vrsave’ with type ‘union ’ [-Werror=array-bounds] arch/powerpc/kernel/ptrace.c: In function ‘vr_set’: arch/powerpc/kernel/ptrace.c:623:5: note: ‘vrsave’ declared here } vrsave; This has been identified as a regression in GCC, see GCC bug 88273. However we can avoid the warning and also simplify the logic and make it more robust. Currently we pass -1 as end_pos to user_regset_copyout(). This says "copy up to the end of the regset". The definition of the regset is: [REGSET_VMX] = { .core_note_type = NT_PPC_VMX, .n = 34, .size = sizeof(vector128), .align = sizeof(vector128), .active = vr_active, .get = vr_get, .set = vr_set }, The end is calculated as (n * size), ie. 34 * sizeof(vector128). In vr_get/set() we pass start_pos as 33 * sizeof(vector128), meaning we can copy up to sizeof(vector128) into/out-of vrsave. The on-stack vrsave is defined as: union { elf_vrreg_t reg; u32 word; } vrsave; And elf_vrreg_t is: typedef __vector128 elf_vrreg_t; So there is no bug, but we rely on all those sizes lining up, otherwise we would have a kernel stack exposure/overwrite on our hands. Rather than relying on that we can pass an explict end_pos based on the sizeof(vrsave). The result should be exactly the same but it's more obviously not over-reading/writing the stack and it avoids the compiler warning. Reported-by: Meelis Roos Reported-by: Mathieu Malaterre Cc: stable@vger.kernel.org Tested-by: Mathieu Malaterre Tested-by: Meelis Roos Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 55b852a06fe18acfb0cb684fbd3f3fbc75aa91a3 Author: Mark Cave-Ayland Date: Fri Feb 8 14:33:19 2019 +0000 powerpc: Fix 32-bit KVM-PR lockup and host crash with MacOS guest commit fe1ef6bcdb4fca33434256a802a3ed6aacf0bd2f upstream. Commit 8792468da5e1 "powerpc: Add the ability to save FPU without giving it up" unexpectedly removed the MSR_FE0 and MSR_FE1 bits from the bitmask used to update the MSR of the previous thread in __giveup_fpu() causing a KVM-PR MacOS guest to lockup and panic the host kernel. Leaving FE0/1 enabled means unrelated processes might receive FPEs when they're not expecting them and crash. In particular if this happens to init the host will then panic. eg (transcribed): qemu-system-ppc[837]: unhandled signal 8 at 12cc9ce4 nip 12cc9ce4 lr 12cc9ca4 code 0 systemd[1]: unhandled signal 8 at 202f02e0 nip 202f02e0 lr 001003d4 code 0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Reinstate these bits to the MSR bitmask to enable MacOS guests to run under 32-bit KVM-PR once again without issue. Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Mark Cave-Ayland Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 651db146179376b543d0ee159da8101c4080d3ad Author: Nicholas Piggin Date: Fri Feb 15 20:20:20 2019 +1000 powerpc/64s/hash: Fix assert_slb_presence() use of the slbfee. instruction commit 7104dccfd052fde51eecc9972dad9c40bd3e0d11 upstream. The slbfee. instruction must have bit 24 of RB clear, failure to do so can result in false negatives that result in incorrect assertions. This is not obvious from the ISA v3.0B document, which only says: The hardware ignores the contents of RB 36:38 40:63 -- p.1032 This patch fixes the bug and also clears all other bits from PPC bit 36-63, which is good practice when dealing with reserved or ignored bits. Fixes: e15a4fea4dee ("powerpc/64s/hash: Add some SLB debugging tests") Cc: stable@vger.kernel.org # v4.20+ Reported-by: Aneesh Kumar K.V Tested-by: Aneesh Kumar K.V Signed-off-by: Nicholas Piggin Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 702c1ab420ab4265a98fa5a9eae7db20c2de52ff Author: Paul Mackerras Date: Tue Feb 12 11:58:29 2019 +1100 powerpc/powernv: Don't reprogram SLW image on every KVM guest entry/exit commit 19f8a5b5be2898573a5e1dc1db93e8d40117606a upstream. Commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via stop-api only on Hotplug", 2017-07-21) added two calls to opal_slw_set_reg() inside pnv_cpu_offline(), with the aim of changing the LPCR value in the SLW image to disable wakeups from the decrementer while a CPU is offline. However, pnv_cpu_offline() gets called each time a secondary CPU thread is woken up to participate in running a KVM guest, that is, not just when a CPU is offlined. Since opal_slw_set_reg() is a very slow operation (with observed execution times around 20 milliseconds), this means that an offline secondary CPU can often be busy doing the opal_slw_set_reg() call when the primary CPU wants to grab all the secondary threads so that it can run a KVM guest. This leads to messages like "KVM: couldn't grab CPU n" being printed and guest execution failing. There is no need to reprogram the SLW image on every KVM guest entry and exit. So that we do it only when a CPU is really transitioning between online and offline, this moves the calls to pnv_program_cpu_hotplug_lpcr() into pnv_smp_cpu_kill_self(). Fixes: 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via stop-api only on Hotplug") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f7d68a102ad4685b6c40c398185e585453754601 Author: Michael Ellerman Date: Fri Feb 22 13:22:08 2019 +1100 powerpc/kvm: Save and restore host AMR/IAMR/UAMOR commit c3c7470c75566a077c8dc71dcf8f1948b8ddfab4 upstream. When the hash MMU is active the AMR, IAMR and UAMOR are used for pkeys. The AMR is directly writable by user space, and the UAMOR masks those writes, meaning both registers are effectively user register state. The IAMR is used to create an execute only key. Also we must maintain the value of at least the AMR when running in process context, so that any memory accesses done by the kernel on behalf of the process are correctly controlled by the AMR. Although we are correctly switching all registers when going into a guest, on returning to the host we just write 0 into all regs, except on Power9 where we restore the IAMR correctly. This could be observed by a user process if it writes the AMR, then runs a guest and we then return immediately to it without rescheduling. Because we have written 0 to the AMR that would have the effect of granting read/write permission to pages that the process was trying to protect. In addition, when using the Radix MMU, the AMR can prevent inadvertent kernel access to userspace data, writing 0 to the AMR disables that protection. So save and restore AMR, IAMR and UAMOR. Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Russell Currey Signed-off-by: Michael Ellerman Acked-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit 3b218d244482379551a1c415c1f9d27f2c71b0b7 Author: Christophe Leroy Date: Fri Jan 25 12:03:55 2019 +0000 powerpc/83xx: Also save/restore SPRG4-7 during suspend commit 36da5ff0bea2dc67298150ead8d8471575c54c7d upstream. The 83xx has 8 SPRG registers and uses at least SPRG4 for DTLB handling LRU. Fixes: 2319f1239592 ("powerpc/mm: e300c2/c3/c4 TLB errata workaround") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 16ee62368aaa56bc52793b563f93bf3ba7410c22 Author: Jordan Niethe Date: Wed Feb 27 14:02:29 2019 +1100 powerpc/powernv: Make opal log only readable by root commit 7b62f9bd2246b7d3d086e571397c14ba52645ef1 upstream. Currently the opal log is globally readable. It is kernel policy to limit the visibility of physical addresses / kernel pointers to root. Given this and the fact the opal log may contain this information it would be better to limit the readability to root. Fixes: bfc36894a48b ("powerpc/powernv: Add OPAL message log interface") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Jordan Niethe Reviewed-by: Stewart Smith Reviewed-by: Andrew Donnellan Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 8d2cc8c1c4fec1c33376fd2ae01ac393720723ec Author: Christophe Leroy Date: Thu Feb 21 19:08:37 2019 +0000 powerpc/wii: properly disable use of BATs when requested. commit 6d183ca8baec983dc4208ca45ece3c36763df912 upstream. 'nobats' kernel parameter or some options like CONFIG_DEBUG_PAGEALLOC deny the use of BATS for mapping memory. This patch makes sure that the specific wii RAM mapping function takes it into account as well. Fixes: de32400dd26e ("wii: use both mem1 and mem2 as ram") Cc: stable@vger.kernel.org Reviewed-by: Jonathan Neuschafer Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit d0d33e87d1438384461596015a580dc51820d5d1 Author: Christophe Leroy Date: Wed Feb 27 11:45:30 2019 +0000 powerpc/32: Clear on-stack exception marker upon exception return commit 9580b71b5a7863c24a9bd18bcd2ad759b86b1eff upstream. Clear the on-stack STACK_FRAME_REGS_MARKER on exception exit in order to avoid confusing stacktrace like the one below. Call Trace: [c0e9dca0] [c01c42a0] print_address_description+0x64/0x2bc (unreliable) [c0e9dcd0] [c01c4684] kasan_report+0xfc/0x180 [c0e9dd10] [c0895130] memchr+0x24/0x74 [c0e9dd30] [c00a9e38] msg_print_text+0x124/0x574 [c0e9dde0] [c00ab710] console_unlock+0x114/0x4f8 [c0e9de40] [c00adc60] vprintk_emit+0x188/0x1c4 --- interrupt: c0e9df00 at 0x400f330 LR = init_stack+0x1f00/0x2000 [c0e9de80] [c00ae3c4] printk+0xa8/0xcc (unreliable) [c0e9df20] [c0c27e44] early_irq_init+0x38/0x108 [c0e9df50] [c0c15434] start_kernel+0x310/0x488 [c0e9dff0] [00003484] 0x3484 With this patch the trace becomes: Call Trace: [c0e9dca0] [c01c42c0] print_address_description+0x64/0x2bc (unreliable) [c0e9dcd0] [c01c46a4] kasan_report+0xfc/0x180 [c0e9dd10] [c0895150] memchr+0x24/0x74 [c0e9dd30] [c00a9e58] msg_print_text+0x124/0x574 [c0e9dde0] [c00ab730] console_unlock+0x114/0x4f8 [c0e9de40] [c00adc80] vprintk_emit+0x188/0x1c4 [c0e9de80] [c00ae3e4] printk+0xa8/0xcc [c0e9df20] [c0c27e44] early_irq_init+0x38/0x108 [c0e9df50] [c0c15434] start_kernel+0x310/0x488 [c0e9dff0] [00003484] 0x3484 Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 232aa30f16b95c0a6a5fb6fb1acffa52e8f8bd8f Author: J. Bruce Fields Date: Tue Mar 5 16:17:58 2019 -0500 security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock commit 3815a245b50124f0865415dcb606a034e97494d4 upstream. In the case when we're reusing a superblock, selinux_sb_clone_mnt_opts() fails to set set_kern_flags, with the result that nfs_clone_sb_security() incorrectly clears NFS_CAP_SECURITY_LABEL. The result is that if you mount the same NFS filesystem twice, NFS security labels are turned off, even if they would work fine if you mounted the filesystem only once. ("fixes" may be not exactly the right tag, it may be more like "fixed-other-cases-but-missed-this-one".) Cc: Scott Mayhew Cc: stable@vger.kernel.org Fixes: 0b4d3452b8b4 "security/selinux: allow security_sb_clone_mnt_opts..." Signed-off-by: J. Bruce Fields Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 7e30471146d2a450df421e2462ae220e8303a167 Author: Xin Long Date: Sat Mar 9 00:07:34 2019 +0800 selinux: add the missing walk_size + len check in selinux_sctp_bind_connect commit 292c997a1970f8d1e1dfa354ed770a22f7b5a434 upstream. As does in __sctp_connect(), when checking addrs in a while loop, after get the addr len according to sa_family, it's necessary to do the check walk_size + af->sockaddr_len > addrs_size to make sure it won't access an out-of-bounds addr. The same thing is needed in selinux_sctp_bind_connect(), otherwise an out-of-bounds issue can be triggered: [14548.772313] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x1aa/0x1f0 [14548.927083] Call Trace: [14548.938072] dump_stack+0x9a/0xe9 [14548.953015] print_address_description+0x65/0x22e [14548.996524] kasan_report.cold.6+0x92/0x1a6 [14549.015335] selinux_sctp_bind_connect+0x1aa/0x1f0 [14549.036947] security_sctp_bind_connect+0x58/0x90 [14549.058142] __sctp_setsockopt_connectx+0x5a/0x150 [sctp] [14549.081650] sctp_setsockopt.part.24+0x1322/0x3ce0 [sctp] Cc: stable@vger.kernel.org Fixes: d452930fd3b9 ("selinux: Add SCTP support") Reported-by: Chunyu Hu Signed-off-by: Xin Long Reviewed-by: Marcelo Ricardo Leitner Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit f9897a30deb7d93670d0bfd15f56a181158ccc41 Author: zhangyi (F) Date: Thu Feb 21 11:24:09 2019 -0500 jbd2: fix compile warning when using JBUFFER_TRACE commit 01215d3edb0f384ddeaa5e4a22c1ae5ff634149f upstream. The jh pointer may be used uninitialized in the two cases below and the compiler complain about it when enabling JBUFFER_TRACE macro, fix them. In file included from fs/jbd2/transaction.c:19:0: fs/jbd2/transaction.c: In function ‘jbd2_journal_get_undo_access’: ./include/linux/jbd2.h:1637:38: warning: ‘jh’ is used uninitialized in this function [-Wuninitialized] #define JBUFFER_TRACE(jh, info) do { printk("%s: %d\n", __func__, jh->b_jcount);} while (0) ^ fs/jbd2/transaction.c:1219:23: note: ‘jh’ was declared here struct journal_head *jh; ^ In file included from fs/jbd2/transaction.c:19:0: fs/jbd2/transaction.c: In function ‘jbd2_journal_dirty_metadata’: ./include/linux/jbd2.h:1637:38: warning: ‘jh’ may be used uninitialized in this function [-Wmaybe-uninitialized] #define JBUFFER_TRACE(jh, info) do { printk("%s: %d\n", __func__, jh->b_jcount);} while (0) ^ fs/jbd2/transaction.c:1332:23: note: ‘jh’ was declared here struct journal_head *jh; ^ Signed-off-by: zhangyi (F) Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Reviewed-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 8c343062c8faf4e17c9c38c4bc850f557a6aed43 Author: zhangyi (F) Date: Sun Feb 10 23:23:04 2019 -0500 jbd2: clear dirty flag when revoking a buffer from an older transaction commit 904cdbd41d749a476863a0ca41f6f396774f26e4 upstream. Now, we capture a data corruption problem on ext4 while we're truncating an extent index block. Imaging that if we are revoking a buffer which has been journaled by the committing transaction, the buffer's jbddirty flag will not be cleared in jbd2_journal_forget(), so the commit code will set the buffer dirty flag again after refile the buffer. fsx kjournald2 jbd2_journal_commit_transaction jbd2_journal_revoke commit phase 1~5... jbd2_journal_forget belongs to older transaction commit phase 6 jbddirty not clear __jbd2_journal_refile_buffer __jbd2_journal_unfile_buffer test_clear_buffer_jbddirty mark_buffer_dirty Finally, if the freed extent index block was allocated again as data block by some other files, it may corrupt the file data after writing cached pages later, such as during unmount time. (In general, clean_bdev_aliases() related helpers should be invoked after re-allocation to prevent the above corruption, but unfortunately we missed it when zeroout the head of extra extent blocks in ext4_ext_handle_unwritten_extents()). This patch mark buffer as freed and set j_next_transaction to the new transaction when it already belongs to the committing transaction in jbd2_journal_forget(), so that commit code knows it should clear dirty bits when it is done with the buffer. This problem can be reproduced by xfstests generic/455 easily with seeds (3246 3247 3248 3249). Signed-off-by: zhangyi (F) Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bb47633ab15e32d5c5de9b4e97ad1f3867c07acc Author: Jay Dolan Date: Tue Feb 12 21:43:12 2019 -0800 serial: 8250_pci: Have ACCES cards that use the four port Pericom PI7C9X7954 chip use the pci_pericom_setup() commit 78d3820b9bd39028727c6aab7297b63c093db343 upstream. The four port Pericom chips have the fourth port at the wrong address. Make use of quirk to fix it. Fixes: c8d192428f52 ("serial: 8250: added acces i/o products quad and octal serial cards") Cc: stable Signed-off-by: Jay Dolan Signed-off-by: Greg Kroah-Hartman commit 7271438208b6c7954d8b27364c955c8302f9e8ad Author: Jay Dolan Date: Tue Feb 12 21:43:11 2019 -0800 serial: 8250_pci: Fix number of ports for ACCES serial cards commit b896b03bc7fce43a07012cc6bf5e2ab2fddf3364 upstream. Have the correct number of ports created for ACCES serial cards. Two port cards show up as four ports, and four port cards show up as eight. Fixes: c8d192428f52 ("serial: 8250: added acces i/o products quad and octal serial cards") Signed-off-by: Jay Dolan Cc: stable Signed-off-by: Greg Kroah-Hartman commit c7388ba1090255168aeec594a5b6fc7d7643ac4c Author: Lubomir Rintel Date: Sun Feb 24 13:00:53 2019 +0100 serial: 8250_of: assume reg-shift of 2 for mrvl,mmp-uart commit f4817843e39ce78aace0195a57d4e8500a65a898 upstream. There are two other drivers that bind to mrvl,mmp-uart and both of them assume register shift of 2 bits. There are device trees that lack the property and rely on that assumption. If this driver wins the race to bind to those devices, it should behave the same as the older deprecated driver. Signed-off-by: Lubomir Rintel Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fa4d0361304f844f8536df0f826659e6ff54904d Author: Anssi Hannula Date: Fri Feb 15 18:45:08 2019 +0200 serial: uartps: Fix stuck ISR if RX disabled with non-empty FIFO commit 7abab1605139bc41442864c18f9573440f7ca105 upstream. If RX is disabled while there are still unprocessed bytes in RX FIFO, cdns_uart_handle_rx() called from interrupt handler will get stuck in the receive loop as read bytes will not get removed from the RX FIFO and CDNS_UART_SR_RXEMPTY bit will never get set. Avoid the stuck handler by checking first if RX is disabled. port->lock protects against race with RX-disabling functions. This HW behavior was mentioned by Nathan Rossi in 43e98facc4a3 ("tty: xuartps: Fix RX hang, and TX corruption in termios call") which fixed a similar issue in cdns_uart_set_termios(). The behavior can also be easily verified by e.g. setting CDNS_UART_CR_RX_DIS at the beginning of cdns_uart_handle_rx() - the following loop will then get stuck. Resetting the FIFO using RXRST would not set RXEMPTY either so simply issuing a reset after RX-disable would not work. I observe this frequently on a ZynqMP board during heavy RX load at 1M baudrate when the reader process exits and thus RX gets disabled. Fixes: 61ec9016988f ("tty/serial: add support for Xilinx PS UART") Signed-off-by: Anssi Hannula Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 37fe1d56aa2c19dc51022a6a884b7e65b821b3dd Author: Phuong Nguyen Date: Thu Jan 17 17:44:17 2019 +0900 dmaengine: usb-dmac: Make DMAC system sleep callbacks explicit commit d9140a0da4a230a03426d175145989667758aa6a upstream. This commit fixes the issue that USB-DMAC hangs silently after system resumes on R-Car Gen3 hence renesas_usbhs will not work correctly when using USB-DMAC for bulk transfer e.g. ethernet or serial gadgets. The issue can be reproduced by these steps: 1. modprobe g_serial 2. Suspend and resume system. 3. connect a usb cable to host side 4. Transfer data from Host to Target 5. cat /dev/ttyGS0 (Target side) 6. echo "test" > /dev/ttyACM0 (Host side) The 'cat' will not result anything. However, system still can work normally. Currently, USB-DMAC driver does not have system sleep callbacks hence this driver relies on the PM core to force runtime suspend/resume to suspend and reinitialize USB-DMAC during system resume. After the commit 17218e0092f8 ("PM / genpd: Stop/start devices without pm_runtime_force_suspend/resume()"), PM core will not force runtime suspend/resume anymore so this issue happens. To solve this, make system suspend resume explicit by using pm_runtime_force_{suspend,resume}() as the system sleep callbacks. SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() is used to make sure USB-DMAC suspended after and initialized before renesas_usbhs." Signed-off-by: Phuong Nguyen Signed-off-by: Hiroyuki Yokoyama Cc: # v4.16+ [shimoda: revise the commit log and add Cc tag] Signed-off-by: Yoshihiro Shimoda Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 39367147f046bf92eef5a542bc1326d72658db6a Author: Nikolaus Voss Date: Wed Feb 20 16:11:38 2019 +0100 usb: typec: tps6598x: handle block writes separately with plain-I2C adapters commit 8a863a608d47fa5d9dd15cf841817f73f804cf91 upstream. Commit 1a2f474d328f handles block _reads_ separately with plain-I2C adapters, but the problem described with regmap-i2c not handling SMBus block transfers (i.e. read and writes) correctly also exists with writes. As workaround, this patch adds a block write function the same way 1a2f474d328f adds a block read function. Fixes: 1a2f474d328f ("usb: typec: tps6598x: handle block reads separately with plain-I2C adapters") Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Signed-off-by: Nikolaus Voss Cc: stable Reviewed-by: Guenter Roeck Acked-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman commit 07e326fd07d76449aa89053ef0f92fd6969e7115 Author: Dmitry Osipenko Date: Sun Feb 24 18:36:22 2019 +0300 usb: chipidea: tegra: Fix missed ci_hdrc_remove_device() commit 563b9372f7ec57e44e8f9a8600c5107d7ffdd166 upstream. The ChipIdea's platform device need to be unregistered on Tegra's driver module removal. Fixes: dfebb5f43a78827a ("usb: chipidea: Add support for Tegra20/30/114/124") Signed-off-by: Dmitry Osipenko Acked-by: Peter Chen Cc: stable Signed-off-by: Greg Kroah-Hartman commit f11fa22a7a5f9ddfa9fabcf919fad4728ea38acd Author: Paul Cercueil Date: Sun Jan 27 23:09:21 2019 -0300 clk: ingenic: Fix doc of ingenic_cgu_div_info commit 7ca4c922aad2e3c46767a12f80d01c6b25337b59 upstream. The 'div' field does not represent a number of bits used to divide (understand: right-shift) the divider, but a number itself used to divide the divider. Signed-off-by: Paul Cercueil Signed-off-by: Maarten ter Huurne Cc: Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 7d4966247a99b8d549a3301fe06310911db286b8 Author: Paul Cercueil Date: Sun Jan 27 23:09:20 2019 -0300 clk: ingenic: Fix round_rate misbehaving with non-integer dividers commit bc5d922c93491878c44c9216e9d227c7eeb81d7f upstream. Take a parent rate of 180 MHz, and a requested rate of 4.285715 MHz. This results in a theorical divider of 41.999993 which is then rounded up to 42. The .round_rate function would then return (180 MHz / 42) as the clock, rounded down, so 4.285714 MHz. Calling clk_set_rate on 4.285714 MHz would round the rate again, and give a theorical divider of 42,0000028, now rounded up to 43, and the rate returned would be (180 MHz / 43) which is 4.186046 MHz, aka. not what we requested. Fix this by rounding up the divisions. Signed-off-by: Paul Cercueil Tested-by: Maarten ter Huurne Cc: Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 1a29715073a181d6d41b8b6b1a9b7a3b67f4c0b9 Author: Krzysztof Kozlowski Date: Thu Feb 21 12:45:52 2019 +0100 clk: samsung: exynos5: Fix kfree() of const memory on setting driver_override commit 785c9f411eb2d9a6076d3511c631587d5e676bf3 upstream. Platform driver driver_override field should not be initialized from const memory because the core later kfree() it. If driver_override is manually set later through sysfs, kfree() of old value leads to: $ echo "new_value" > /sys/bus/platform/drivers/.../driver_override kernel BUG at ../mm/slub.c:3960! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM ... (kfree) from [] (platform_set_driver_override+0x84/0xac) (platform_set_driver_override) from [] (driver_override_store+0x20/0x34) (driver_override_store) from [] (kernfs_fop_write+0x100/0x1dc) (kernfs_fop_write) from [] (__vfs_write+0x2c/0x17c) (__vfs_write) from [] (vfs_write+0xa4/0x188) (vfs_write) from [] (ksys_write+0x4c/0xac) (ksys_write) from [] (ret_fast_syscall+0x0/0x28) The clk-exynos5-subcmu driver uses override only for the purpose of creating meaningful names for children devices (matching names of power domains, e.g. DISP, MFC). The driver_override was not developed for this purpose so just switch to default names of devices to fix the issue. Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Geert Uytterhoeven Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 7da58ad824b10393f15a02375638945cbdde8389 Author: Krzysztof Kozlowski Date: Thu Feb 21 12:45:51 2019 +0100 clk: samsung: exynos5: Fix possible NULL pointer exception on platform_device_alloc() failure commit 5f0b6216ea381b43c0dff88702d6cc5673d63922 upstream. During initialization of subdevices if platform_device_alloc() failed, returned NULL pointer will be later dereferenced. Add proper error paths to exynos5_clk_register_subcmu(). The return value of this function is still ignored because at this stage of init there is nothing we can do. Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Geert Uytterhoeven Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit d9d7760c1e45ecb9c4c2e6a2d2668ad2bd10f10c Author: Tony Lindgren Date: Mon Feb 11 14:59:07 2019 -0800 clk: clk-twl6040: Fix imprecise external abort for pdmclk commit 5ae51d67aec95f6f9386aa8dd5db424964895575 upstream. I noticed that modprobe clk-twl6040 can fail after a cold boot with: abe_cm:clk:0010:0: failed to enable ... Unhandled fault: imprecise external abort (0x1406) at 0xbe896b20 WARNING: CPU: 1 PID: 29 at drivers/clk/clk.c:828 clk_core_disable_lock+0x18/0x24 ... (clk_core_disable_lock) from [] (_disable_clocks+0x18/0x90) (_disable_clocks) from [] (_idle+0x17c/0x244) (_idle) from [] (omap_hwmod_idle+0x24/0x44) (omap_hwmod_idle) from [] (sysc_runtime_suspend+0x48/0x108) (sysc_runtime_suspend) from [] (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [] (rpm_callback+0x20/0x80) (rpm_callback) from [] (rpm_suspend+0x120/0x694) (rpm_suspend) from [] (__pm_runtime_idle+0x60/0x84) (__pm_runtime_idle) from [] (sysc_probe+0x874/0xf2c) (sysc_probe) from [] (platform_drv_probe+0x48/0x98) After searching around for a similar issue, I came across an earlier fix that never got merged upstream in the Android tree for glass-omap-xrr02. There is patch "MFD: twl6040-codec: Implement PDMCLK cold temp errata" by Misael Lopez Cruz . Based on my observations, this fix is also needed when cold booting devices, and not just for deeper idle modes. Since we now have a clock driver for pdmclk, let's fix the issue in twl6040_pdmclk_prepare(). Cc: Misael Lopez Cruz Cc: Peter Ujfalusi Signed-off-by: Tony Lindgren Acked-by: Peter Ujfalusi Cc: Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit a712a38100b569ddb5a55b421531f48dcd030b4b Author: Kunihiko Hayashi Date: Fri Feb 8 11:25:23 2019 +0900 clk: uniphier: Fix update register for CPU-gear commit 521282237b9d78b9bff423ec818becd4c95841c2 upstream. Need to set the update bit in UNIPHIER_CLK_CPUGEAR_UPD to update the CPU-gear value. Fixes: d08f1f0d596c ("clk: uniphier: add CPU-gear change (cpufreq) support") Cc: linux-stable@vger.kernel.org Signed-off-by: Kunihiko Hayashi Acked-by: Masahiro Yamada Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit e1ac0077345670a71613dc8c92da3ae5c8bfd489 Author: Jan Kara Date: Tue Jan 29 17:17:24 2019 +0100 ext2: Fix underflow in ext2_max_size() commit 1c2d14212b15a60300a2d4f6364753e87394c521 upstream. When ext2 filesystem is created with 64k block size, ext2_max_size() will return value less than 0. Also, we cannot write any file in this fs since the sb->maxbytes is less than 0. The core of the problem is that the size of block index tree for such large block size is more than i_blocks can carry. So fix the computation to count with this possibility. File size limits computed with the new function for the full range of possible block sizes look like: bits file_size 10 17247252480 11 275415851008 12 2196873666560 13 2197948973056 14 2198486220800 15 2198754754560 16 2198888906752 CC: stable@vger.kernel.org Reported-by: yangerkun Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 96728f35572ebe2ce959a820cc981e5eec806139 Author: Vaibhav Jain Date: Tue Jan 29 16:36:18 2019 +0530 cxl: Wrap iterations over afu slices inside 'afu_list_lock' commit edeb304f659792fb5bab90d7d6f3408b4c7301fb upstream. Within cxl module, iteration over array 'adapter->afu' may be racy at few points as it might be simultaneously read during an EEH and its contents being set to NULL while driver is being unloaded or unbound from the adapter. This might result in a NULL pointer to 'struct afu' being de-referenced during an EEH thereby causing a kernel oops. This patch fixes this by making sure that all access to the array 'adapter->afu' is wrapped within the context of spin-lock 'adapter->afu_list_lock'. Fixes: 9e8df8a21963 ("cxl: EEH support") Cc: stable@vger.kernel.org # v4.3+ Acked-by: Andrew Donnellan Acked-by: Frederic Barrat Acked-by: Christophe Lombard Signed-off-by: Vaibhav Jain Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 25636de95557a95d54ac30be94af3748345a0a90 Author: Michael J. Ruhl Date: Tue Feb 26 08:45:25 2019 -0800 IB/rdmavt: Fix concurrency panics in QP post_send and modify to error commit d757c60eca9b22f4d108929a24401e0fdecda0b1 upstream. The RC/UC code path can go through a software loopback. In this code path the receive side QP is manipulated. If two threads are working on the QP receive side (i.e. post_send, and modify_qp to an error state), QP information can be corrupted. (post_send via loopback) set r_sge loop update r_sge (modify_qp) take r_lock update r_sge <---- r_sge is now incorrect (post_send) update r_sge <---- crash, etc. ... This can lead to one of the two following crashes: BUG: unable to handle kernel NULL pointer dereference at (null) IP: hfi1_copy_sge+0xf1/0x2e0 [hfi1] PGD 8000001fe6a57067 PUD 1fd9e0c067 PMD 0 Call Trace: ruc_loopback+0x49b/0xbc0 [hfi1] hfi1_do_send+0x38e/0x3e0 [hfi1] _hfi1_do_send+0x1e/0x20 [hfi1] process_one_work+0x17f/0x440 worker_thread+0x126/0x3c0 kthread+0xd1/0xe0 ret_from_fork_nospec_begin+0x21/0x21 or: BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 IP: rvt_clear_mr_refs+0x45/0x370 [rdmavt] PGD 80000006ae5eb067 PUD ef15d0067 PMD 0 Call Trace: rvt_error_qp+0xaa/0x240 [rdmavt] rvt_modify_qp+0x47f/0xaa0 [rdmavt] ib_security_modify_qp+0x8f/0x400 [ib_core] ib_modify_qp_with_udata+0x44/0x70 [ib_core] modify_qp.isra.23+0x1eb/0x2b0 [ib_uverbs] ib_uverbs_modify_qp+0xaa/0xf0 [ib_uverbs] ib_uverbs_write+0x272/0x430 [ib_uverbs] vfs_write+0xc0/0x1f0 SyS_write+0x7f/0xf0 system_call_fastpath+0x1c/0x21 Fix by using the appropriate locking on the receiving QP. Fixes: 15703461533a ("IB/{hfi1, qib, rdmavt}: Move ruc_loopback to rdmavt") Cc: #v4.9+ 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 ada60723d7cd01d811d20144db50da96e633e8c2 Author: Mike Marciniszyn Date: Tue Feb 26 08:45:16 2019 -0800 IB/rdmavt: Fix loopback send with invalidate ordering commit 38bbc9f0381550d1d227fc57afa08436e36b32fc upstream. The IBTA spec notes: o9-5.2.1: For any HCA which supports SEND with Invalidate, upon receiving an IETH, the Invalidate operation must not take place until after the normal transport header validation checks have been successfully completed. The rdmavt loopback code does the validation after the invalidate. Fix by relocating the operation specific logic for all SEND variants until after the validity checks. Cc: #v4.20+ Reviewed-by: Michael J. Ruhl Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit c8a23dfeb2d63e79a1cb60640007c04e6c4c39fb Author: Michael J. Ruhl Date: Tue Feb 26 08:45:35 2019 -0800 IB/hfi1: Close race condition on user context disable and close commit bc5add09764c123f58942a37c8335247e683d234 upstream. When disabling and removing a receive context, it is possible for an asynchronous event (i.e IRQ) to occur. Because of this, there is a race between cleaning up the context, and the context being used by the asynchronous event. cpu 0 (context cleanup) rc->ref_count-- (ref_count == 0) hfi1_rcd_free() cpu 1 (IRQ (with rcd index)) rcd_get_by_index() lock ref_count+++ <-- reference count race (WARNING) return rcd unlock cpu 0 hfi1_free_ctxtdata() <-- incorrect free location lock remove rcd from array unlock free rcd This race will cause the following WARNING trace: WARNING: CPU: 0 PID: 175027 at include/linux/kref.h:52 hfi1_rcd_get_by_index+0x84/0xa0 [hfi1] CPU: 0 PID: 175027 Comm: IMB-MPI1 Kdump: loaded Tainted: G OE ------------ 3.10.0-957.el7.x86_64 #1 Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.11.01.0076.C4.111920150602 11/19/2015 Call Trace: dump_stack+0x19/0x1b __warn+0xd8/0x100 warn_slowpath_null+0x1d/0x20 hfi1_rcd_get_by_index+0x84/0xa0 [hfi1] is_rcv_urgent_int+0x24/0x90 [hfi1] general_interrupt+0x1b6/0x210 [hfi1] __handle_irq_event_percpu+0x44/0x1c0 handle_irq_event_percpu+0x32/0x80 handle_irq_event+0x3c/0x60 handle_edge_irq+0x7f/0x150 handle_irq+0xe4/0x1a0 do_IRQ+0x4d/0xf0 common_interrupt+0x162/0x162 The race can also lead to a use after free which could be similar to: general protection fault: 0000 1 SMP CPU: 71 PID: 177147 Comm: IMB-MPI1 Kdump: loaded Tainted: G W OE ------------ 3.10.0-957.el7.x86_64 #1 Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.11.01.0076.C4.111920150602 11/19/2015 task: ffff9962a8098000 ti: ffff99717a508000 task.ti: ffff99717a508000 __kmalloc+0x94/0x230 Call Trace: ? hfi1_user_sdma_process_request+0x9c8/0x1250 [hfi1] hfi1_user_sdma_process_request+0x9c8/0x1250 [hfi1] hfi1_aio_write+0xba/0x110 [hfi1] do_sync_readv_writev+0x7b/0xd0 do_readv_writev+0xce/0x260 ? handle_mm_fault+0x39d/0x9b0 ? pick_next_task_fair+0x5f/0x1b0 ? sched_clock_cpu+0x85/0xc0 ? __schedule+0x13a/0x890 vfs_writev+0x35/0x60 SyS_writev+0x7f/0x110 system_call_fastpath+0x22/0x27 Use the appropriate kref API to verify access. Reorder context cleanup to ensure context removal before cleanup occurs correctly. Cc: stable@vger.kernel.org # v4.14.0+ Fixes: f683c80ca68e ("IB/hfi1: Resolve kernel panics by reference counting receive contexts") 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 2b9ef0bedaac2acc648a03bb519e4609661da6dc Author: Thomas Petazzoni Date: Wed Feb 20 10:48:41 2019 +0100 PCI: pci-bridge-emul: Extend pci_bridge_emul_init() with flags commit 33776d059630e5045ea9ccf756c74de8f9cc86de upstream. Depending on the capabilities of the PCI controller/platform, the PCI-to-PCI bridge emulation behavior might need to be different. For example, on platforms that use the pci-mvebu code, we currently don't support prefetchable memory BARs, so the corresponding fields in the PCI-to-PCI bridge configuration space should be read-only. To implement this, extend pci_bridge_emul_init() to take a "flags" argument, with currently one flag supported: PCI_BRIDGE_EMUL_NO_PREFETCHABLE_BAR that will make the prefetchable memory base and limit registers read-only. The pci-mvebu and pci-aardvark drivers are updated accordingly. Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config space") Reported-by: Luís Mendes Reported-by: Leigh Brown Tested-by: Leigh Brown Tested-by: Luis Mendes Signed-off-by: Thomas Petazzoni Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Cc: Luís Mendes Cc: Leigh Brown Signed-off-by: Greg Kroah-Hartman commit d011c7871d16e81168faaccce9a977499f8a5f97 Author: Thomas Petazzoni Date: Wed Feb 20 10:48:40 2019 +0100 PCI: pci-bridge-emul: Create per-bridge copy of register behavior commit 59f81c35e0df840f7112cb296dde48df84a67c79 upstream. The behavior of the different registers of the PCI-to-PCI bridge is currently encoded in two global arrays, shared by all instances of PCI-to-PCI bridge emulation. However, we will need to tweak the behavior on a per-bridge basis, to accommodate for different capabilities of the platforms where this code is used. In preparation for this, create a per-bridge copy of the register behavior arrays, so that they can later be tweaked on a per-bridge basis. Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config space") Reported-by: Luís Mendes Reported-by: Leigh Brown Tested-by: Leigh Brown Tested-by: Luis Mendes Signed-off-by: Thomas Petazzoni Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Cc: Luís Mendes Cc: Leigh Brown Signed-off-by: Greg Kroah-Hartman commit ee0bf8d6e7fca46dd8e53a7b97683cb57bb4c3fd Author: Mika Westerberg Date: Thu Jan 31 20:07:46 2019 +0300 PCI: pciehp: Disable Data Link Layer State Changed event on suspend commit bbe54ea5330d828cc396d451c0e1e5c3f9764c1e upstream. Commit 0e157e528604 ("PCI/PME: Implement runtime PM callbacks") tried to solve an issue where the hierarchy immediately wakes up when it is transitioned into D3cold. However, it turns out to prevent PME propagation on some systems that do not support D3cold. I looked more closely at what might cause the immediate wakeup. It happens when the ACPI power resource of the root port is turned off. The AML code associated with the _OFF() method of the ACPI power resource starts a PCIe L2/L3 Ready transition and waits for it to complete. Right after the L2/L3 Ready transition is started the root port receives a PME from the downstream port. The simplest hierarchy where this happens looks like this: 00:1d.0 PCIe Root Port ^ | v 05:00.0 PCIe switch #1 upstream port 06:01.0 PCIe switch #1 downstream hotplug port ^ | v 08:00.0 PCIe switch #2 upstream port It seems that the PCIe link between the two switches, before PME_Turn_Off/PME_TO_Ack is complete for the whole hierarchy, goes inactive and triggers PME towards the root port bringing it back to D0. The L2/L3 Ready sequence is described in PCIe r4.0 spec sections 5.2 and 5.3.3 but unfortunately they do not state what happens if DLLSCE is enabled during the sequence. Disabling Data Link Layer State Changed event (DLLSCE) seems to prevent the issue and still allows the downstream hotplug port to notice when a device is plugged/unplugged. Link: https://bugzilla.kernel.org/show_bug.cgi?id=202593 Fixes: 0e157e528604 ("PCI/PME: Implement runtime PM callbacks") Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki CC: stable@vger.kernel.org # v4.20+ Signed-off-by: Greg Kroah-Hartman commit 0d5bc50f524afb84a882cb5f507c4aeeab08aa8a Author: Lucas Stach Date: Wed Feb 27 17:52:19 2019 +0100 PCI: dwc: skip MSI init if MSIs have been explicitly disabled commit 3afc8299f39a27b60e1519a28e18878ce878e7dd upstream. Since 7c5925afbc58 (PCI: dwc: Move MSI IRQs allocation to IRQ domains hierarchical API) the MSI init claims one of the controller IRQs as a chained IRQ line for the MSI controller. On some designs, like the i.MX6, this line is shared with a PCIe legacy IRQ. When the line is claimed for the MSI domain, any device trying to use this legacy IRQs will fail to request this IRQ line. As MSI and legacy IRQs are already mutually exclusive on the DWC core, as the core won't forward any legacy IRQs once any MSI has been enabled, users wishing to use legacy IRQs already need to explictly disable MSI support (usually via the pci=nomsi kernel commandline option). To avoid any issues with MSI conflicting with legacy IRQs, just skip all of the DWC MSI initalization, including the IRQ line claim, when MSI is disabled. Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains hierarchical API") Tested-by: Tim Harvey Signed-off-by: Lucas Stach Signed-off-by: Lorenzo Pieralisi Acked-by: Gustavo Pimentel Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 63a9e7ce6624ef0385a1c65bdae0708d3abb7f47 Author: Bjorn Andersson Date: Fri Jan 25 15:26:16 2019 -0800 PCI: qcom: Don't deassert reset GPIO during probe commit 02b485e31d98265189b91f3e69c43df2ed50610c upstream. Acquiring the reset GPIO low means that reset is being deasserted, this is followed almost immediately with qcom_pcie_host_init() asserting it, initializing it and then finally deasserting it again, for the link to come up. Some PCIe devices requires a minimum time between the initial deassert and subsequent reset cycles. In a platform that boots with the reset GPIO asserted this requirement is being violated by this deassert/assert pulse. Acquire the reset GPIO high to prevent this situation by matching the state to the subsequent asserted state. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Bjorn Andersson [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Stanimir Varbanov Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit eafa704de27bbb428f83d282aabcb5087256aa77 Author: Dongdong Liu Date: Mon Feb 11 15:02:59 2019 +0800 PCI/DPC: Fix print AER status in DPC event handling commit 9f08a5d896ce43380314c34ed3f264c8e6075b80 upstream. Previously dpc_handler() called aer_get_device_error_info() without initializing info->severity, so aer_get_device_error_info() relied on uninitialized data. Add dpc_get_aer_uncorrect_severity() to read the port's AER status, mask, and severity registers and set info->severity. Also, clear the port's AER fatal error status bits. Fixes: 8aefa9b0d910 ("PCI/DPC: Print AER status in DPC event handling") Signed-off-by: Dongdong Liu [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Reviewed-by: Keith Busch Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman commit bae1cf68370d3938f864da041e37cc96c3d7ba2b Author: Bjorn Helgaas Date: Fri Jan 4 17:59:07 2019 -0600 PCI/ASPM: Use LTR if already enabled by platform commit 10ecc818ea7319b5d0d2b4e1aa6a77323e776f76 upstream. RussianNeuroMancer reported that the Intel 7265 wifi on a Dell Venue 11 Pro 7140 table stopped working after wakeup from suspend and bisected the problem to 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"). David Ward reported the same problem on a Dell Latitude 7350. After af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it"), we don't enable LTR unless the platform has granted LTR control to us. In addition, we don't notice if the platform had already enabled LTR itself. After 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"), we avoid using LTR if we don't think the path to the device has LTR enabled. The combination means that if the platform itself enables LTR but declines to give the OS control over LTR, we unnecessarily avoided using ASPM L1.2. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201469 Fixes: 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR") Fixes: af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it") Reported-by: RussianNeuroMancer Reported-by: David Ward Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v4.18+ Signed-off-by: Greg Kroah-Hartman commit 4e9f8e86d6c781a5098e46b175355f6109a46d72 Author: Joerg Roedel Date: Thu Feb 7 12:59:14 2019 +0100 swiotlb: Add is_swiotlb_active() function commit 492366f7b4237257ef50ca9c431a6a0d50225aca upstream. This function will be used from dma_direct code to determine the maximum segment size of a dma mapping. Cc: stable@vger.kernel.org Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Christoph Hellwig Signed-off-by: Joerg Roedel Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit a4eeaa9cc9dadd79369e91b9f8220c4aa0d77098 Author: Joerg Roedel Date: Thu Feb 7 12:59:13 2019 +0100 swiotlb: Introduce swiotlb_max_mapping_size() commit abe420bfae528c92bd8cc5ecb62dc95672b1fd6f upstream. The function returns the maximum size that can be remapped by the SWIOTLB implementation. This function will be later exposed to users through the DMA-API. Cc: stable@vger.kernel.org Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Christoph Hellwig Signed-off-by: Joerg Roedel Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 38c3a86a8226ac78b1fd10b4dd7912530bcd3c9c Author: Joerg Roedel Date: Thu Feb 7 12:59:15 2019 +0100 dma: Introduce dma_max_mapping_size() commit 133d624b1cee16906134e92d5befb843b58bcf31 upstream. The function returns the maximum size that can be mapped using DMA-API functions. The patch also adds the implementation for direct DMA and a new dma_map_ops pointer so that other implementations can expose their limit. Cc: stable@vger.kernel.org Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Christoph Hellwig Signed-off-by: Joerg Roedel Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit db8913b46d74dc10fd4a9063b840e695f33e3eb9 Author: Jan Kara Date: Mon Feb 11 13:30:32 2019 -0500 ext4: fix crash during online resizing commit f96c3ac8dfc24b4e38fc4c2eba5fea2107b929d1 upstream. When computing maximum size of filesystem possible with given number of group descriptor blocks, we forget to include s_first_data_block into the number of blocks. Thus for filesystems with non-zero s_first_data_block it can happen that computed maximum filesystem size is actually lower than current filesystem size which confuses the code and eventually leads to a BUG_ON in ext4_alloc_group_tables() hitting on flex_gd->count == 0. The problem can be reproduced like: truncate -s 100g /tmp/image mkfs.ext4 -b 1024 -E resize=262144 /tmp/image 32768 mount -t ext4 -o loop /tmp/image /mnt resize2fs /dev/loop0 262145 resize2fs /dev/loop0 300000 Fix the problem by properly including s_first_data_block into the computed number of filesystem blocks. Fixes: 1c6bd7173d66 "ext4: convert file system to meta_bg if needed..." Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit edc0bf6532ba167697ce6588d3311b6692bfb3d7 Author: yangerkun Date: Mon Feb 11 00:35:06 2019 -0500 ext4: add mask of ext4 flags to swap commit abdc644e8cbac2e9b19763680e5a7cf9bab2bee7 upstream. The reason is that while swapping two inode, we swap the flags too. Some flags such as EXT4_JOURNAL_DATA_FL can really confuse the things since we're not resetting the address operations structure. The simplest way to keep things sane is to restrict the flags that can be swapped. Signed-off-by: yangerkun Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7c2cfdf99ae97e13bea5d0919a03a6b9bb2c02f2 Author: yangerkun Date: Mon Feb 11 00:14:02 2019 -0500 ext4: update quota information while swapping boot loader inode commit aa507b5faf38784defe49f5e64605ac3c4425e26 upstream. While do swap between two inode, they swap i_data without update quota information. Also, swap_inode_boot_loader can do "revert" somtimes, so update the quota while all operations has been finished. Signed-off-by: yangerkun Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit ef2dfe6f8c82f427531b7556e2ee1b65f1301543 Author: Mark Walton Date: Thu Feb 28 15:46:36 2019 +0000 gpio: pca953x: Fix dereference of irq data in shutdown commit c378b3aa015931a46c91d6ccc2fe04d97801d060 upstream. If a PCA953x gpio was used as an interrupt and then released, the shutdown function was trying to extract the pca953x_chip pointer directly from the irq_data, but in reality was getting the gpio_chip structure. The net effect was that the subsequent writes to the data structure corrupted data in the gpio_chip structure, which wasn't immediately obvious until attempting to use the GPIO again in the future, at which point the kernel panics. This fix correctly extracts the pca953x_chip structure via the gpio_chip structure, as is correctly done in the other irq functions. Fixes: 0a70fe00efea ("gpio: pca953x: Clear irq trigger type on irq shutdown") Cc: stable@vger.kernel.org Signed-off-by: Mark Walton Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 13cef9edc45b5d30fbee28d4ed54b18ed016ea76 Author: Loic Poulain Date: Wed Jan 30 11:48:07 2019 -0500 media: i2c: ov5640: Fix post-reset delay commit 1d4c41f3d887bcd66e82cb2fda124533dad8808a upstream. According to the ov5640 specification (2.7 power up sequence), host can access the sensor's registers 20ms after reset. Trying to access them before leads to undefined behavior and result in sporadic initialization errors. Signed-off-by: Loic Poulain Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Cc: Adam Ford Signed-off-by: Greg Kroah-Hartman commit 8b82d499df877ed7a9c2bcc9456dab83249a534c Author: Sowjanya Komatineni Date: Tue Feb 12 11:06:45 2019 -0800 i2c: tegra: update maximum transfer size commit b03ff2a23359d0dd6f0a1516c6a9e9c4760ed230 upstream. Tegra194 supports maximum 64K bytes per packet including 12 bytes of packet header irrespective of PIO or DMA mode transfer. This patch updates Tegra194 max write length to account for packet header size for transfers. Cc: stable@vger.kernel.org # 4.20+ Reviewed-by: Dmitry Osipenko Signed-off-by: Sowjanya Komatineni Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 986d964baaaa37e8f3dd14d93e222ebff1756905 Author: Sowjanya Komatineni Date: Tue Feb 12 11:06:44 2019 -0800 i2c: tegra: fix maximum transfer size commit f4e3f4ae1d9c9330de355f432b69952e8cef650c upstream. Tegra186 and prior supports maximum 4K bytes per packet transfer including 12 bytes of packet header. This patch fixes max write length limit to account packet header size for transfers. Cc: stable@vger.kernel.org # 4.4+ Reviewed-by: Dmitry Osipenko Signed-off-by: Sowjanya Komatineni Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 775bd984147eac0b8cee0c46150b0fae4743a61c Author: QiaoChong Date: Sat Feb 9 20:59:07 2019 +0000 parport_pc: fix find_superio io compare code, should use equal test. commit 21698fd57984cd28207d841dbdaa026d6061bceb upstream. In the original code before 181bf1e815a2 the loop was continuing until it finds the first matching superios[i].io and p->base. But after 181bf1e815a2 the logic changed and the loop now returns the pointer to the first mismatched array element which is then used in get_superio_dma() and get_superio_irq() and thus returning the wrong value. Fix the condition so that it now returns the correct pointer. Fixes: 181bf1e815a2 ("parport_pc: clean up the modified while loops using for") Cc: Alan Cox Cc: stable@vger.kernel.org Signed-off-by: QiaoChong [rewrite the commit message] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit d91315e99c550a0facdd01cb461305ed79ba0822 Author: Alexander Shishkin Date: Thu Jan 24 15:11:53 2019 +0200 intel_th: Don't reference unassigned outputs commit 9ed3f22223c33347ed963e7c7019cf2956dd4e37 upstream. When an output port driver is removed, also remove references to it from any masters. Failing to do this causes a NULL ptr dereference when configuring another output port: > BUG: unable to handle kernel NULL pointer dereference at 000000000000000d > RIP: 0010:master_attr_store+0x9d/0x160 [intel_th_gth] > Call Trace: > dev_attr_store+0x1b/0x30 > sysfs_kf_write+0x3c/0x50 > kernfs_fop_write+0x125/0x1a0 > __vfs_write+0x3a/0x190 > ? __vfs_write+0x5/0x190 > ? _cond_resched+0x1a/0x50 > ? rcu_all_qs+0x5/0xb0 > ? __vfs_write+0x5/0x190 > vfs_write+0xb8/0x1b0 > ksys_write+0x55/0xc0 > __x64_sys_write+0x1a/0x20 > do_syscall_64+0x5a/0x140 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Alexander Shishkin Fixes: b27a6a3f97b9 ("intel_th: Add Global Trace Hub driver") CC: stable@vger.kernel.org # v4.4+ Reported-by: Ammy Yi Signed-off-by: Greg Kroah-Hartman commit 1a1d6860c5394d08518364303222c848edda266c Author: Heikki Krogerus Date: Wed Jan 23 17:44:16 2019 +0300 device property: Fix the length used in PROPERTY_ENTRY_STRING() commit 2b6e492467c78183bb629bb0a100ea3509b615a5 upstream. With string type property entries we need to use sizeof(const char *) instead of the number of characters as the length of the entry. If the string was shorter then sizeof(const char *), attempts to read it would have failed with -EOVERFLOW. The problem has been hidden because all build-in string properties have had a string longer then 8 characters until now. Fixes: a85f42047533 ("device property: helper macros for property entry creation") Cc: 4.5+ # 4.5+ Signed-off-by: Heikki Krogerus Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9a638bb82ff5dbd7efc94640bf7334022e9f5efd Author: Bartosz Golaszewski Date: Fri Feb 15 11:42:59 2019 +0100 nvmem: core: don't check the return value of notifier chain call commit f4853e1c321edb48af229ad5ac85076790d34968 upstream. blocking_notifier_call_chain() returns the value returned by the last registered callback. A positive return value doesn't indicate an error and an nvmem device should correctly register irrespective of any notifier callback failures. Drop the retval check. Fixes: bee1138bea15 ("nvmem: add a notifier chain") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Acked-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman commit d09e7041330bb07ab41d8cfd4bccea3f9b9284c2 Author: Zev Weiss Date: Mon Mar 11 23:28:02 2019 -0700 kernel/sysctl.c: add missing range check in do_proc_dointvec_minmax_conv commit 8cf7630b29701d364f8df4a50e4f1f5e752b2778 upstream. This bug has apparently existed since the introduction of this function in the pre-git era (4500e91754d3 in Thomas Gleixner's history.git, "[NET]: Add proc_dointvec_userhz_jiffies, use it for proper handling of neighbour sysctls."). As a minimal fix we can simply duplicate the corresponding check in do_proc_dointvec_conv(). Link: http://lkml.kernel.org/r/20190207123426.9202-3-zev@bewilderbeest.net Signed-off-by: Zev Weiss Cc: Brendan Higgins Cc: Iurii Zaikin Cc: Kees Cook Cc: Luis Chamberlain Cc: [2.6.2+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9a842b43e4b86a77c09cd722e0dfed7782bc274b Author: Jan Stancek Date: Tue Mar 5 15:50:08 2019 -0800 mm/memory.c: do_fault: avoid usage of stale vm_area_struct commit fc8efd2ddfed3f343c11b693e87140ff358d7ff5 upstream. LTP testcase mtest06 [1] can trigger a crash on s390x running 5.0.0-rc8. This is a stress test, where one thread mmaps/writes/munmaps memory area and other thread is trying to read from it: CPU: 0 PID: 2611 Comm: mmap1 Not tainted 5.0.0-rc8+ #51 Hardware name: IBM 2964 N63 400 (z/VM 6.4.0) Krnl PSW : 0404e00180000000 00000000001ac8d8 (__lock_acquire+0x7/0x7a8) Call Trace: ([<0000000000000000>] (null)) [<00000000001adae4>] lock_acquire+0xec/0x258 [<000000000080d1ac>] _raw_spin_lock_bh+0x5c/0x98 [<000000000012a780>] page_table_free+0x48/0x1a8 [<00000000002f6e54>] do_fault+0xdc/0x670 [<00000000002fadae>] __handle_mm_fault+0x416/0x5f0 [<00000000002fb138>] handle_mm_fault+0x1b0/0x320 [<00000000001248cc>] do_dat_exception+0x19c/0x2c8 [<000000000080e5ee>] pgm_check_handler+0x19e/0x200 page_table_free() is called with NULL mm parameter, but because "0" is a valid address on s390 (see S390_lowcore), it keeps going until it eventually crashes in lockdep's lock_acquire. This crash is reproducible at least since 4.14. Problem is that "vmf->vma" used in do_fault() can become stale. Because mmap_sem may be released, other threads can come in, call munmap() and cause "vma" be returned to kmem cache, and get zeroed/re-initialized and re-used: handle_mm_fault | __handle_mm_fault | do_fault | vma = vmf->vma | do_read_fault | __do_fault | vma->vm_ops->fault(vmf); | mmap_sem is released | | | do_munmap() | remove_vma_list() | remove_vma() | vm_area_free() | # vma is released | ... | # same vma is allocated | # from kmem cache | do_mmap() | vm_area_alloc() | memset(vma, 0, ...) | pte_free(vma->vm_mm, ...); | page_table_free | spin_lock_bh(&mm->context.lock);| | Cache mm_struct to avoid using potentially stale "vma". [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mtest06/mmap1.c Link: http://lkml.kernel.org/r/5b3fdf19e2a5be460a384b936f5b56e13733f1b8.1551595137.git.jstancek@redhat.com Signed-off-by: Jan Stancek Reviewed-by: Andrea Arcangeli Reviewed-by: Matthew Wilcox Acked-by: Rafael Aquini Reviewed-by: Minchan Kim Acked-by: Kirill A. Shutemov Cc: Rik van Riel Cc: Michal Hocko Cc: Huang Ying Cc: Souptick Joarder Cc: Jerome Glisse Cc: Aneesh Kumar K.V Cc: David Hildenbrand Cc: Andrea Arcangeli Cc: David Rientjes Cc: Mel Gorman Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8df6ab770e2036e82f3f7ed3004da7aa8740f6c7 Author: Roman Penyaev Date: Tue Mar 5 15:43:20 2019 -0800 mm/vmalloc: fix size check for remap_vmalloc_range_partial() commit 401592d2e095947344e10ec0623adbcd58934dd4 upstream. When VM_NO_GUARD is not set area->size includes adjacent guard page, thus for correct size checking get_vm_area_size() should be used, but not area->size. This fixes possible kernel oops when userspace tries to mmap an area on 1 page bigger than was allocated by vmalloc_user() call: the size check inside remap_vmalloc_range_partial() accounts non-existing guard page also, so check successfully passes but vmalloc_to_page() returns NULL (guard page does not physically exist). The following code pattern example should trigger an oops: static int oops_mmap(struct file *file, struct vm_area_struct *vma) { void *mem; mem = vmalloc_user(4096); BUG_ON(!mem); /* Do not care about mem leak */ return remap_vmalloc_range(vma, mem, 0); } And userspace simply mmaps size + PAGE_SIZE: mmap(NULL, 8192, PROT_WRITE|PROT_READ, MAP_PRIVATE, fd, 0); Possible candidates for oops which do not have any explicit size checks: *** drivers/media/usb/stkwebcam/stk-webcam.c: v4l_stk_mmap[789] ret = remap_vmalloc_range(vma, sbuf->buffer, 0); Or the following one: *** drivers/video/fbdev/core/fbmem.c static int fb_mmap(struct file *file, struct vm_area_struct * vma) ... res = fb->fb_mmap(info, vma); Where fb_mmap callback calls remap_vmalloc_range() directly without any explicit checks: *** drivers/video/fbdev/vfb.c static int vfb_mmap(struct fb_info *info, struct vm_area_struct *vma) { return remap_vmalloc_range(vma, (void *)info->fix.smem_start, vma->vm_pgoff); } Link: http://lkml.kernel.org/r/20190103145954.16942-2-rpenyaev@suse.de Signed-off-by: Roman Penyaev Acked-by: Michal Hocko Cc: Andrey Ryabinin Cc: Joe Perches Cc: "Luis R. Rodriguez" Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 84fe80428739b7f40763b4d4c1c84c2ce8591fe5 Author: zhongjiang Date: Tue Mar 5 15:41:16 2019 -0800 mm: hwpoison: fix thp split handing in soft_offline_in_use_page() commit 46612b751c4941c5c0472ddf04027e877ae5990f upstream. When soft_offline_in_use_page() runs on a thp tail page after pmd is split, we trigger the following VM_BUG_ON_PAGE(): Memory failure: 0x3755ff: non anonymous thp __get_any_page: 0x3755ff: unknown zero refcount page type 2fffff80000000 Soft offlining pfn 0x34d805 at process virtual address 0x20fff000 page:ffffea000d360140 count:0 mapcount:0 mapping:0000000000000000 index:0x1 flags: 0x2fffff80000000() raw: 002fffff80000000 ffffea000d360108 ffffea000d360188 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) ------------[ cut here ]------------ kernel BUG at ./include/linux/mm.h:519! soft_offline_in_use_page() passed refcount and page lock from tail page to head page, which is not needed because we can pass any subpage to split_huge_page(). Naoya had fixed a similar issue in c3901e722b29 ("mm: hwpoison: fix thp split handling in memory_failure()"). But he missed fixing soft offline. Link: http://lkml.kernel.org/r/1551452476-24000-1-git-send-email-zhongjiang@huawei.com Fixes: 61f5d698cc97 ("mm: re-enable THP") Signed-off-by: zhongjiang Acked-by: Naoya Horiguchi Cc: Michal Hocko Cc: Hugh Dickins Cc: Kirill A. Shutemov Cc: Andrea Arcangeli Cc: [4.5+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7a34997043f1c042ae91d780630445bbf23fa435 Author: yangerkun Date: Mon Feb 11 00:05:24 2019 -0500 ext4: cleanup pagecache before swap i_data commit a46c68a318b08f819047843abf349aeee5d10ac2 upstream. While do swap, we should make sure there has no new dirty page since we should swap i_data between two inode: 1.We should lock i_mmap_sem with write to avoid new pagecache from mmap read/write; 2.Change filemap_flush to filemap_write_and_wait and move them to the space protected by inode lock to avoid new pagecache from buffer read/write. Signed-off-by: yangerkun Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit a0f6f657ac446194c190fab6aca9f6f71c8404f4 Author: yangerkun Date: Mon Feb 11 00:02:05 2019 -0500 ext4: fix check of inode in swap_inode_boot_loader commit 67a11611e1a5211f6569044fbf8150875764d1d0 upstream. Before really do swap between inode and boot inode, something need to check to avoid invalid or not permitted operation, like does this inode has inline data. But the condition check should be protected by inode lock to avoid change while swapping. Also some other condition will not change between swapping, but there has no problem to do this under inode lock. Signed-off-by: yangerkun Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit f9308e46e02bbb6f0f15a880a4fce9e5ba29ab2c Author: Arnd Bergmann Date: Thu Mar 7 11:22:41 2019 +0100 cpufreq: pxa2xx: remove incorrect __init annotation commit 9505b98ccddc454008ca7efff90044e3e857c827 upstream. pxa_cpufreq_init_voltages() is marked __init but usually inlined into the non-__init pxa_cpufreq_init() function. When building with clang, it can stay as a standalone function in a discarded section, and produce this warning: WARNING: vmlinux.o(.text+0x616a00): Section mismatch in reference from the function pxa_cpufreq_init() to the function .init.text:pxa_cpufreq_init_voltages() The function pxa_cpufreq_init() references the function __init pxa_cpufreq_init_voltages(). This is often because pxa_cpufreq_init lacks a __init annotation or the annotation of pxa_cpufreq_init_voltages is wrong. Fixes: 50e77fcd790e ("ARM: pxa: remove __init from cpufreq_driver->init()") Signed-off-by: Arnd Bergmann Acked-by: Viresh Kumar Reviewed-by: Nathan Chancellor Acked-by: Robert Jarzmik Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 272b28097c30114e749a66e30ade16a262866953 Author: Yangtao Li Date: Mon Feb 4 02:48:54 2019 -0500 cpufreq: tegra124: add missing of_node_put() commit 446fae2bb5395f3028d8e3aae1508737e5a72ea1 upstream. of_cpu_device_node_get() will increase the refcount of device_node, it is necessary to call of_node_put() at the end to release the refcount. Fixes: 9eb15dbbfa1a2 ("cpufreq: Add cpufreq driver for Tegra124") Cc: # 4.4+ Signed-off-by: Yangtao Li Acked-by: Thierry Reding Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 144c3557b1e1e8c3626a698ff3ccd197443fb865 Author: Viresh Kumar Date: Wed Feb 20 16:41:18 2019 +0530 cpufreq: kryo: Release OPP tables on module removal commit 0334906c06967142c8805fbe88acf787f65d3d26 upstream. Commit 5ad7346b4ae2 ("cpufreq: kryo: Add module remove and exit") made it possible to build the kryo cpufreq driver as a module, but it failed to release all the resources, i.e. OPP tables, when the module is unloaded. This patch fixes it by releasing the OPP tables, by calling dev_pm_opp_put_supported_hw() for them, from the qcom_cpufreq_kryo_remove() routine. The array of pointers to the OPP tables is also allocated dynamically now in qcom_cpufreq_kryo_probe(), as the pointers will be required while releasing the resources. Compile tested only. Cc: 4.18+ # v4.18+ Fixes: 5ad7346b4ae2 ("cpufreq: kryo: Add module remove and exit") Reviewed-by: Georgi Djakov Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 737f4ead9606e748e43260a46dbd9c302abbf8e5 Author: Masami Hiramatsu Date: Wed Feb 13 01:11:19 2019 +0900 x86/kprobes: Prohibit probing on optprobe template code commit 0192e6535ebe9af68614198ced4fd6d37b778ebf upstream. Prohibit probing on optprobe template code, since it is not a code but a template instruction sequence. If we modify this template, copied template must be broken. Signed-off-by: Masami Hiramatsu Cc: Alexander Shishkin Cc: Andrea Righi Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner Cc: stable@vger.kernel.org Fixes: 9326638cbee2 ("kprobes, x86: Use NOKPROBE_SYMBOL() instead of __kprobes annotation") Link: http://lkml.kernel.org/r/154998787911.31052.15274376330136234452.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit dbbb26db89383723dd2b9fe63165be171d847e1c Author: Doug Berger Date: Wed Feb 20 14:15:28 2019 -0800 irqchip/brcmstb-l2: Use _irqsave locking variants in non-interrupt code commit 33517881ede742107f416533b8c3e4abc56763da upstream. Using the irq_gc_lock/irq_gc_unlock functions in the suspend and resume functions creates the opportunity for a deadlock during suspend, resume, and shutdown. Using the irq_gc_lock_irqsave/ irq_gc_unlock_irqrestore variants prevents this possible deadlock. Cc: stable@vger.kernel.org Fixes: 7f646e92766e2 ("irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 interrupt controller") Signed-off-by: Doug Berger Signed-off-by: Florian Fainelli [maz: tidied up $SUBJECT] Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 830d66c95e02a425c357835e64e16d3ce686ae05 Author: Zenghui Yu Date: Sun Feb 10 05:24:10 2019 +0000 irqchip/gic-v3-its: Avoid parsing _indirect_ twice for Device table commit 8d565748b6035eeda18895c213396a4c9fac6a4c upstream. In current logic, its_parse_indirect_baser() will be invoked twice when allocating Device tables. Add a *break* to omit the unnecessary and annoying (might be ...) invoking. Fixes: 32bd44dc19de ("irqchip/gic-v3-its: Fix the incorrect parsing of VCPU table size") Cc: stable@vger.kernel.org Signed-off-by: Zenghui Yu Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit bd05a30753ebd84004f132bf20aca8c94625bec6 Author: Lubomir Rintel Date: Sun Feb 10 20:47:49 2019 +0100 libertas_tf: don't set URB_ZERO_PACKET on IN USB transfer commit 607076a904c435f2677fadaadd4af546279db68b upstream. It doesn't make sense and the USB core warns on each submit of such URB, easily flooding the message buffer with tracebacks. Analogous issue was fixed in regular libertas driver in commit 6528d8804780 ("libertas: don't set URB_ZERO_PACKET on IN USB transfer"). Cc: stable@vger.kernel.org Signed-off-by: Lubomir Rintel Reviewed-by: Steve deRosier Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 028cbca07ab58f77a532b3587ac4ba9d85fd5f55 Author: Stephen Boyd Date: Tue Jan 15 14:54:47 2019 -0800 soc: qcom: rpmh: Avoid accessing freed memory from batch API commit baef1c90aac7e5bf13f0360a3b334825a23d31a1 upstream. Using the batch API from the interconnect driver sometimes leads to a KASAN error due to an access to freed memory. This is easier to trigger with threadirqs on the kernel commandline. BUG: KASAN: use-after-free in rpmh_tx_done+0x114/0x12c Read of size 1 at addr fffffff51414ad84 by task irq/110-apps_rs/57 CPU: 0 PID: 57 Comm: irq/110-apps_rs Tainted: G W 4.19.10 #72 Call trace: dump_backtrace+0x0/0x2f8 show_stack+0x20/0x2c __dump_stack+0x20/0x28 dump_stack+0xcc/0x10c print_address_description+0x74/0x240 kasan_report+0x250/0x26c __asan_report_load1_noabort+0x20/0x2c rpmh_tx_done+0x114/0x12c tcs_tx_done+0x450/0x768 irq_forced_thread_fn+0x58/0x9c irq_thread+0x120/0x1dc kthread+0x248/0x260 ret_from_fork+0x10/0x18 Allocated by task 385: kasan_kmalloc+0xac/0x148 __kmalloc+0x170/0x1e4 rpmh_write_batch+0x174/0x540 qcom_icc_set+0x8dc/0x9ac icc_set+0x288/0x2e8 a6xx_gmu_stop+0x320/0x3c0 a6xx_pm_suspend+0x108/0x124 adreno_suspend+0x50/0x60 pm_generic_runtime_suspend+0x60/0x78 __rpm_callback+0x214/0x32c rpm_callback+0x54/0x184 rpm_suspend+0x3f8/0xa90 pm_runtime_work+0xb4/0x178 process_one_work+0x544/0xbc0 worker_thread+0x514/0x7d0 kthread+0x248/0x260 ret_from_fork+0x10/0x18 Freed by task 385: __kasan_slab_free+0x12c/0x1e0 kasan_slab_free+0x10/0x1c kfree+0x134/0x588 rpmh_write_batch+0x49c/0x540 qcom_icc_set+0x8dc/0x9ac icc_set+0x288/0x2e8 a6xx_gmu_stop+0x320/0x3c0 a6xx_pm_suspend+0x108/0x124 adreno_suspend+0x50/0x60 cr50_spi spi5.0: SPI transfer timed out pm_generic_runtime_suspend+0x60/0x78 __rpm_callback+0x214/0x32c rpm_callback+0x54/0x184 rpm_suspend+0x3f8/0xa90 pm_runtime_work+0xb4/0x178 process_one_work+0x544/0xbc0 worker_thread+0x514/0x7d0 kthread+0x248/0x260 ret_from_fork+0x10/0x18 The buggy address belongs to the object at fffffff51414ac80 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 260 bytes inside of 512-byte region [fffffff51414ac80, fffffff51414ae80) The buggy address belongs to the page: page:ffffffbfd4505200 count:1 mapcount:0 mapping:fffffff51e00c680 index:0x0 compound_mapcount: 0 flags: 0x4000000000008100(slab|head) raw: 4000000000008100 ffffffbfd4529008 ffffffbfd44f9208 fffffff51e00c680 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: fffffff51414ac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fffffff51414ad00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >fffffff51414ad80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ fffffff51414ae00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fffffff51414ae80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc The batch API sets the same completion for each rpmh message that's sent and then loops through all the messages and waits for that single completion declared on the stack to be completed before returning from the function and freeing the message structures. Unfortunately, some messages may still be in process and 'stuck' in the TCS. At some later point, the tcs_tx_done() interrupt will run and try to process messages that have already been freed at the end of rpmh_write_batch(). This will in turn access the 'needs_free' member of the rpmh_request structure and cause KASAN to complain. Furthermore, if there's a message that's completed in rpmh_tx_done() and freed immediately after the complete() call is made we'll be racing with potentially freed memory when accessing the 'needs_free' member: CPU0 CPU1 ---- ---- rpmh_tx_done() complete(&compl) wait_for_completion(&compl) kfree(rpm_msg) if (rpm_msg->needs_free) Let's fix this by allocating a chunk of completions for each message and waiting for all of them to be completed before returning from the batch API. Alternatively, we could wait for the last message in the batch, but that may be a more complicated change because it looks like tcs_tx_done() just iterates through the indices of the queue and completes each message instead of tracking the last inserted message and completing that first. Fixes: c8790cb6da58 ("drivers: qcom: rpmh: add support for batch RPMH request") Cc: Lina Iyer Cc: "Raju P.L.S.S.S.N" Cc: Matthias Kaehlcke Cc: Evan Green Cc: stable@vger.kernel.org Reviewed-by: Lina Iyer Reviewed-by: Evan Green Signed-off-by: Stephen Boyd Signed-off-by: Bjorn Andersson Signed-off-by: Andy Gross Signed-off-by: Greg Kroah-Hartman commit 1098803b8cb7cd18d1696cb79fd60cc57977e980 Author: Filipe Manana Date: Tue Feb 26 12:06:09 2019 +0000 Btrfs: fix deadlock between clone/dedupe and rename commit 4ea748e1d2c9f8a27332b949e8210dbbf392987e upstream. Reflinking (clone/dedupe) and rename are operations that operate on two inodes and therefore need to lock them in the same order to avoid ABBA deadlocks. It happens that Btrfs' reflink implementation always locked them in a different order from VFS's lock_two_nondirectories() helper, which is used by the rename code in VFS, resulting in ABBA type deadlocks. Btrfs' locking order: static void btrfs_double_inode_lock(struct inode *inode1, struct inode *inode2) { if (inode1 < inode2) swap(inode1, inode2); inode_lock_nested(inode1, I_MUTEX_PARENT); inode_lock_nested(inode2, I_MUTEX_CHILD); } VFS's locking order: void lock_two_nondirectories(struct inode *inode1, struct inode *inode2) { if (inode1 > inode2) swap(inode1, inode2); if (inode1 && !S_ISDIR(inode1->i_mode)) inode_lock(inode1); if (inode2 && !S_ISDIR(inode2->i_mode) && inode2 != inode1) inode_lock_nested(inode2, I_MUTEX_NONDIR2); } Fix this by killing the btrfs helper function that does the double inode locking and replace it with VFS's helper lock_two_nondirectories(). Reported-by: Zygo Blaxell Fixes: 416161db9b63e3 ("btrfs: offline dedupe") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 3486142a68e34448cd1f591d82f5eae544862d2d Author: Filipe Manana Date: Thu Feb 14 15:17:20 2019 +0000 Btrfs: fix corruption reading shared and compressed extents after hole punching commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream. In the past we had data corruption when reading compressed extents that are shared within the same file and they are consecutive, this got fixed by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared extents") and by commit 808f80b46790f ("Btrfs: update fix for read corruption of compressed and shared extents"). However there was a case that was missing in those fixes, which is when the shared and compressed extents are referenced with a non-zero offset. The following shell script creates a reproducer for this issue: #!/bin/bash mkfs.btrfs -f /dev/sdc &> /dev/null mount -o compress /dev/sdc /mnt/sdc # Create a file with 3 consecutive compressed extents, each has an # uncompressed size of 128Kb and a compressed size of 4Kb. for ((i = 1; i <= 3; i++)); do head -c 4096 /dev/zero for ((j = 1; j <= 31; j++)); do head -c 4096 /dev/zero | tr '\0' "\377" done done > /mnt/sdc/foobar sync echo "Digest after file creation: $(md5sum /mnt/sdc/foobar)" # Clone the first extent into offsets 128K and 256K. xfs_io -c "reflink /mnt/sdc/foobar 0 128K 128K" /mnt/sdc/foobar xfs_io -c "reflink /mnt/sdc/foobar 0 256K 128K" /mnt/sdc/foobar sync echo "Digest after cloning: $(md5sum /mnt/sdc/foobar)" # Punch holes into the regions that are already full of zeroes. xfs_io -c "fpunch 0 4K" /mnt/sdc/foobar xfs_io -c "fpunch 128K 4K" /mnt/sdc/foobar xfs_io -c "fpunch 256K 4K" /mnt/sdc/foobar sync echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)" echo "Dropping page cache..." sysctl -q vm.drop_caches=1 echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)" umount /dev/sdc When running the script we get the following output: Digest after file creation: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar linked 131072/131072 bytes at offset 131072 128 KiB, 1 ops; 0.0033 sec (36.960 MiB/sec and 295.6830 ops/sec) linked 131072/131072 bytes at offset 262144 128 KiB, 1 ops; 0.0015 sec (78.567 MiB/sec and 628.5355 ops/sec) Digest after cloning: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar Digest after hole punching: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar Dropping page cache... Digest after hole punching: fba694ae8664ed0c2e9ff8937e7f1484 /mnt/sdc/foobar This happens because after reading all the pages of the extent in the range from 128K to 256K for example, we read the hole at offset 256K and then when reading the page at offset 260K we don't submit the existing bio, which is responsible for filling all the page in the range 128K to 256K only, therefore adding the pages from range 260K to 384K to the existing bio and submitting it after iterating over the entire range. Once the bio completes, the uncompressed data fills only the pages in the range 128K to 256K because there's no more data read from disk, leaving the pages in the range 260K to 384K unfilled. It is just a slightly different variant of what was solved by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared extents"). Fix this by forcing a bio submit, during readpages(), whenever we find a compressed extent map for a page that is different from the extent map for the previous page or has a different starting offset (in case it's the same compressed extent), instead of the extent map's original start offset. A test case for fstests follows soon. Reported-by: Zygo Blaxell Fixes: 808f80b46790f ("Btrfs: update fix for read corruption of compressed and shared extents") Fixes: 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared extents") Cc: stable@vger.kernel.org # 4.3+ Tested-by: Zygo Blaxell Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ebbb48419e8a7933779a5d849d54de47398ba2b1 Author: Dan Robertson Date: Tue Feb 19 02:56:43 2019 +0000 btrfs: init csum_list before possible free commit e49be14b8d80e23bb7c53d78c21717a474ade76b upstream. The scrub_ctx csum_list member must be initialized before scrub_free_ctx is called. If the csum_list is not initialized beforehand, the list_empty call in scrub_free_csums will result in a null deref if the allocation fails in the for loop. Fixes: a2de733c78fa ("btrfs: scrub") CC: stable@vger.kernel.org # 3.0+ Reviewed-by: Nikolay Borisov Signed-off-by: Dan Robertson Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 88e610ae4c3af07d964ba792313c1ac9d50ec7b6 Author: Johannes Thumshirn Date: Mon Feb 18 11:28:37 2019 +0100 btrfs: ensure that a DUP or RAID1 block group has exactly two stripes commit 349ae63f40638a28c6fce52e8447c2d14b84cc0c upstream. We recently had a customer issue with a corrupted filesystem. When trying to mount this image btrfs panicked with a division by zero in calc_stripe_length(). The corrupt chunk had a 'num_stripes' value of 1. calc_stripe_length() takes this value and divides it by the number of copies the RAID profile is expected to have to calculate the amount of data stripes. As a DUP profile is expected to have 2 copies this division resulted in 1/2 = 0. Later then the 'data_stripes' variable is used as a divisor in the stripe length calculation which results in a division by 0 and thus a kernel panic. When encountering a filesystem with a DUP block group and a 'num_stripes' value unequal to 2, refuse mounting as the image is corrupted and will lead to unexpected behaviour. Code inspection showed a RAID1 block group has the same issues. Fixes: e06cd3dd7cea ("Btrfs: add validadtion checks for chunk loading") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Qu Wenruo Reviewed-by: Nikolay Borisov Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9c58f2ada4fab31f5bf508185ee8b0e4e83cdcd1 Author: Dan Carpenter Date: Mon Feb 11 21:32:10 2019 +0300 btrfs: drop the lock on error in btrfs_dev_replace_cancel commit 669e859b5ea7c6f4fce0149d3907c64e550c294b upstream. We should drop the lock on this error path. This has been found by a static tool. The lock needs to be released, it's there to protect access to the dev_replace members and is not supposed to be left locked. The value of state that's being switched would need to be artifically changed to an invalid value so the default: branch is taken. Fixes: d189dd70e255 ("btrfs: fix use-after-free due to race between replace start and cancel") CC: stable@vger.kernel.org # 5.0+ Reviewed-by: Anand Jain Signed-off-by: Dan Carpenter Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit fb9c36acfab1119669a5c6313ebe5da2311539a5 Author: Anand Jain Date: Wed Jan 30 14:45:00 2019 +0800 btrfs: scrub: fix circular locking dependency warning commit 1cec3f27168d7835ff3d23ab371cd548440131bb upstream. This fixes a longstanding lockdep warning triggered by fstests/btrfs/011. Circular locking dependency check reports warning[1], that's because the btrfs_scrub_dev() calls the stack #0 below with, the fs_info::scrub_lock held. The test case leading to this warning: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /btrfs $ btrfs scrub start -B /btrfs In fact we have fs_info::scrub_workers_refcnt to track if the init and destroy of the scrub workers are needed. So once we have incremented and decremented the fs_info::scrub_workers_refcnt value in the thread, its ok to drop the scrub_lock, and then actually do the btrfs_destroy_workqueue() part. So this patch drops the scrub_lock before calling btrfs_destroy_workqueue(). [359.258534] ====================================================== [359.260305] WARNING: possible circular locking dependency detected [359.261938] 5.0.0-rc6-default #461 Not tainted [359.263135] ------------------------------------------------------ [359.264672] btrfs/20975 is trying to acquire lock: [359.265927] 00000000d4d32bea ((wq_completion)"%s-%s""btrfs", name){+.+.}, at: flush_workqueue+0x87/0x540 [359.268416] [359.268416] but task is already holding lock: [359.270061] 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs] [359.272418] [359.272418] which lock already depends on the new lock. [359.272418] [359.274692] [359.274692] the existing dependency chain (in reverse order) is: [359.276671] [359.276671] -> #3 (&fs_info->scrub_lock){+.+.}: [359.278187] __mutex_lock+0x86/0x9c0 [359.279086] btrfs_scrub_pause+0x31/0x100 [btrfs] [359.280421] btrfs_commit_transaction+0x1e4/0x9e0 [btrfs] [359.281931] close_ctree+0x30b/0x350 [btrfs] [359.283208] generic_shutdown_super+0x64/0x100 [359.284516] kill_anon_super+0x14/0x30 [359.285658] btrfs_kill_super+0x12/0xa0 [btrfs] [359.286964] deactivate_locked_super+0x29/0x60 [359.288242] cleanup_mnt+0x3b/0x70 [359.289310] task_work_run+0x98/0xc0 [359.290428] exit_to_usermode_loop+0x83/0x90 [359.291445] do_syscall_64+0x15b/0x180 [359.292598] entry_SYSCALL_64_after_hwframe+0x49/0xbe [359.294011] [359.294011] -> #2 (sb_internal#2){.+.+}: [359.295432] __sb_start_write+0x113/0x1d0 [359.296394] start_transaction+0x369/0x500 [btrfs] [359.297471] btrfs_finish_ordered_io+0x2aa/0x7c0 [btrfs] [359.298629] normal_work_helper+0xcd/0x530 [btrfs] [359.299698] process_one_work+0x246/0x610 [359.300898] worker_thread+0x3c/0x390 [359.302020] kthread+0x116/0x130 [359.303053] ret_from_fork+0x24/0x30 [359.304152] [359.304152] -> #1 ((work_completion)(&work->normal_work)){+.+.}: [359.306100] process_one_work+0x21f/0x610 [359.307302] worker_thread+0x3c/0x390 [359.308465] kthread+0x116/0x130 [359.309357] ret_from_fork+0x24/0x30 [359.310229] [359.310229] -> #0 ((wq_completion)"%s-%s""btrfs", name){+.+.}: [359.311812] lock_acquire+0x90/0x180 [359.312929] flush_workqueue+0xaa/0x540 [359.313845] drain_workqueue+0xa1/0x180 [359.314761] destroy_workqueue+0x17/0x240 [359.315754] btrfs_destroy_workqueue+0x57/0x200 [btrfs] [359.317245] scrub_workers_put+0x2c/0x60 [btrfs] [359.318585] btrfs_scrub_dev+0x336/0x590 [btrfs] [359.319944] btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs] [359.321622] btrfs_ioctl+0x28a4/0x2e40 [btrfs] [359.322908] do_vfs_ioctl+0xa2/0x6d0 [359.324021] ksys_ioctl+0x3a/0x70 [359.325066] __x64_sys_ioctl+0x16/0x20 [359.326236] do_syscall_64+0x54/0x180 [359.327379] entry_SYSCALL_64_after_hwframe+0x49/0xbe [359.328772] [359.328772] other info that might help us debug this: [359.328772] [359.330990] Chain exists of: [359.330990] (wq_completion)"%s-%s""btrfs", name --> sb_internal#2 --> &fs_info->scrub_lock [359.330990] [359.334376] Possible unsafe locking scenario: [359.334376] [359.336020] CPU0 CPU1 [359.337070] ---- ---- [359.337821] lock(&fs_info->scrub_lock); [359.338506] lock(sb_internal#2); [359.339506] lock(&fs_info->scrub_lock); [359.341461] lock((wq_completion)"%s-%s""btrfs", name); [359.342437] [359.342437] *** DEADLOCK *** [359.342437] [359.343745] 1 lock held by btrfs/20975: [359.344788] #0: 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs] [359.346778] [359.346778] stack backtrace: [359.347897] CPU: 0 PID: 20975 Comm: btrfs Not tainted 5.0.0-rc6-default #461 [359.348983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014 [359.350501] Call Trace: [359.350931] dump_stack+0x67/0x90 [359.351676] print_circular_bug.isra.37.cold.56+0x15c/0x195 [359.353569] check_prev_add.constprop.44+0x4f9/0x750 [359.354849] ? check_prev_add.constprop.44+0x286/0x750 [359.356505] __lock_acquire+0xb84/0xf10 [359.357505] lock_acquire+0x90/0x180 [359.358271] ? flush_workqueue+0x87/0x540 [359.359098] flush_workqueue+0xaa/0x540 [359.359912] ? flush_workqueue+0x87/0x540 [359.360740] ? drain_workqueue+0x1e/0x180 [359.361565] ? drain_workqueue+0xa1/0x180 [359.362391] drain_workqueue+0xa1/0x180 [359.363193] destroy_workqueue+0x17/0x240 [359.364539] btrfs_destroy_workqueue+0x57/0x200 [btrfs] [359.365673] scrub_workers_put+0x2c/0x60 [btrfs] [359.366618] btrfs_scrub_dev+0x336/0x590 [btrfs] [359.367594] ? start_transaction+0xa1/0x500 [btrfs] [359.368679] btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs] [359.369545] btrfs_ioctl+0x28a4/0x2e40 [btrfs] [359.370186] ? __lock_acquire+0x263/0xf10 [359.370777] ? kvm_clock_read+0x14/0x30 [359.371392] ? kvm_sched_clock_read+0x5/0x10 [359.372248] ? sched_clock+0x5/0x10 [359.372786] ? sched_clock_cpu+0xc/0xc0 [359.373662] ? do_vfs_ioctl+0xa2/0x6d0 [359.374552] do_vfs_ioctl+0xa2/0x6d0 [359.375378] ? do_sigaction+0xff/0x250 [359.376233] ksys_ioctl+0x3a/0x70 [359.376954] __x64_sys_ioctl+0x16/0x20 [359.377772] do_syscall_64+0x54/0x180 [359.378841] entry_SYSCALL_64_after_hwframe+0x49/0xbe [359.380422] RIP: 0033:0x7f5429296a97 Backporting to older kernels: scrub_nocow_workers must be freed the same way as the others. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Anand Jain [ update changelog ] Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9d7b327affb831572acecd6132cb39d90ace1d6a Author: Filipe Manana Date: Thu Dec 13 21:16:56 2018 +0000 Btrfs: setup a nofs context for memory allocation at __btrfs_set_acl commit a0873490660246db587849a9e172f2b7b21fa88a upstream. We are holding a transaction handle when setting an acl, therefore we can not allocate the xattr value buffer using GFP_KERNEL, as we could deadlock if reclaim is triggered by the allocation, therefore setup a nofs context. Fixes: 39a27ec1004e8 ("btrfs: use GFP_KERNEL for xattr and acl allocations") CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Nikolay Borisov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 80dcd07c27dfe24f79a40897d8ecac4c38b1875d Author: Filipe Manana Date: Thu Dec 13 21:16:45 2018 +0000 Btrfs: setup a nofs context for memory allocation at btrfs_create_tree() commit b89f6d1fcb30a8cbdc18ce00c7d93792076af453 upstream. We are holding a transaction handle when creating a tree, therefore we can not allocate the root using GFP_KERNEL, as we could deadlock if reclaim is triggered by the allocation, therefore setup a nofs context. Fixes: 74e4d82757f74 ("btrfs: let callers of btrfs_alloc_root pass gfp flags") CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Nikolay Borisov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 98bb142aaff299c44486d4e763c6da58fb913daf Author: Finn Thain Date: Wed Jan 16 16:23:24 2019 +1100 m68k: Add -ffreestanding to CFLAGS commit 28713169d879b67be2ef2f84dcf54905de238294 upstream. This patch fixes a build failure when using GCC 8.1: /usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock': block/partitions/ldm.c:153: undefined reference to `strcmp' This is caused by a new optimization which effectively replaces a strncmp() call with a strcmp() call. This affects a number of strncmp() call sites in the kernel. The entire class of optimizations is avoided with -fno-builtin, which gets enabled by -ffreestanding. This may avoid possible future build failures in case new optimizations appear in future compilers. I haven't done any performance measurements with this patch but I did count the function calls in a defconfig build. For example, there are now 23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the other libc functions is smaller. If this harms performance we can tackle that regression by optimizing the call sites, ideally using semantic patches. That way, clang and ICC builds might benfit too. Cc: stable@vger.kernel.org Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2 Signed-off-by: Finn Thain Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 3381b362f74ce0e5ae1af117698fa5ec80534e1c Author: Vivek Goyal Date: Wed Jan 30 14:01:57 2019 -0500 ovl: Do not lose security.capability xattr over metadata file copy-up commit 993a0b2aec52754f0897b1dab4c453be8217cae5 upstream. If a file has been copied up metadata only, and later data is copied up, upper loses any security.capability xattr it has (underlying filesystem clears it as upon file write). From a user's point of view, this is just a file copy-up and that should not result in losing security.capability xattr. Hence, before data copy up, save security.capability xattr (if any) and restore it on upper after data copy up is complete. Signed-off-by: Vivek Goyal Reviewed-by: Amir Goldstein Fixes: 0c2888749363 ("ovl: A new xattr OVL_XATTR_METACOPY for file on upper") Cc: # v4.19+ Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 0fa6688a288281aad8e6352d70ac772ec14db20c Author: Vivek Goyal Date: Fri Jan 11 19:37:00 2019 +0100 ovl: During copy up, first copy up data and then xattrs commit 5f32879ea35523b9842bdbdc0065e13635caada2 upstream. If a file with capability set (and hence security.capability xattr) is written kernel clears security.capability xattr. For overlay, during file copy up if xattrs are copied up first and then data is, copied up. This means data copy up will result in clearing of security.capability xattr file on lower has. And this can result into surprises. If a lower file has CAP_SETUID, then it should not be cleared over copy up (if nothing was actually written to file). This also creates problems with chown logic where it first copies up file and then tries to clear setuid bit. But by that time security.capability xattr is already gone (due to data copy up), and caller gets -ENODATA. This has been reported by Giuseppe here. https://github.com/containers/libpod/issues/2015#issuecomment-447824842 Fix this by copying up data first and then metadta. This is a regression which has been introduced by my commit as part of metadata only copy up patches. TODO: There will be some corner cases where a file is copied up metadata only and later data copy up happens and that will clear security.capability xattr. Something needs to be done about that too. Fixes: bd64e57586d3 ("ovl: During copy up, first copy up metadata and then data") Cc: # v4.19+ Reported-by: Giuseppe Scrivano Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit ef02f9fe514878336f2440d4b0d06d2bd04096ee Author: Jann Horn Date: Wed Jan 23 15:19:17 2019 +0100 splice: don't merge into linked buffers commit a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 upstream. Before this patch, it was possible for two pipes to affect each other after data had been transferred between them with tee(): ============ $ cat tee_test.c int main(void) { int pipe_a[2]; if (pipe(pipe_a)) err(1, "pipe"); int pipe_b[2]; if (pipe(pipe_b)) err(1, "pipe"); if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write"); if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee"); if (write(pipe_b[1], "xx", 2) != 2) err(1, "write"); char buf[5]; if (read(pipe_a[0], buf, 4) != 4) err(1, "read"); buf[4] = 0; printf("got back: '%s'\n", buf); } $ gcc -o tee_test tee_test.c $ ./tee_test got back: 'abxx' $ ============ As suggested by Al Viro, fix it by creating a separate type for non-mergeable pipe buffers, then changing the types of buffers in splice_pipe_to_pipe() and link_pipe(). Cc: Fixes: 7c77f0b3f920 ("splice: implement pipe to pipe splicing") Fixes: 70524490ee2e ("[PATCH] splice: add support for sys_tee()") Suggested-by: Al Viro Signed-off-by: Jann Horn Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 61d06e123502de4443391cc1bb2b6c1c071c9919 Author: Varad Gautam Date: Thu Jan 24 14:03:06 2019 +0100 fs/devpts: always delete dcache dentry-s in dput() commit 73052b0daee0b750b39af18460dfec683e4f5887 upstream. d_delete only unhashes an entry if it is reached with dentry->d_lockref.count != 1. Prior to commit 8ead9dd54716 ("devpts: more pty driver interface cleanups"), d_delete was called on a dentry from devpts_pty_kill with two references held, which would trigger the unhashing, and the subsequent dputs would release it. Commit 8ead9dd54716 reworked devpts_pty_kill to stop acquiring the second reference from d_find_alias, and the d_delete call left the dentries still on the hashed list without actually ever being dropped from dcache before explicit cleanup. This causes the number of negative dentries for devpts to pile up, and an `ls /dev/pts` invocation can take seconds to return. Provide always_delete_dentry() from simple_dentry_operations as .d_delete for devpts, to make the dentry be dropped from dcache. Without this cleanup, the number of dentries in /dev/pts/ can be grown arbitrarily as: `python -c 'import pty; pty.spawn(["ls", "/dev/pts"])'` A systemtap probe on dcache_readdir to count d_subdirs shows this count to increase with each pty spawn invocation above: probe kernel.function("dcache_readdir") { subdirs = &@cast($file->f_path->dentry, "dentry")->d_subdirs; p = subdirs; p = @cast(p, "list_head")->next; i = 0 while (p != subdirs) { p = @cast(p, "list_head")->next; i = i+1; } printf("number of dentries: %d\n", i); } Fixes: 8ead9dd54716 ("devpts: more pty driver interface cleanups") Signed-off-by: Varad Gautam Reported-by: Zheng Wang Reported-by: Brandon Schwartz Root-caused-by: Maximilian Heyne Root-caused-by: Nicolas Pernas Maradei CC: David Woodhouse CC: Maximilian Heyne CC: Stefan Nuernberger CC: Amit Shah CC: Linus Torvalds CC: Greg Kroah-Hartman CC: Al Viro CC: Christian Brauner CC: Eric W. Biederman CC: Matthew Wilcox CC: Eric Biggers CC: # 4.9+ Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit a15cf4d9a6229cefd0d1a2696f1e51b9bbd20bef Author: Quinn Tran Date: Thu Jan 24 23:23:50 2019 -0800 scsi: qla2xxx: Use complete switch scan for RSCN events commit 1560bafdff9ed54857ac3a03c4c8d8f10d791ba6 upstream. This patch removes unnecessary code to handle RSCN, instead performs full scan everytime driver receives RSCN Fixes: d4f7a16aeca6f ("scsi: qla2xxx: Remove ASYNC GIDPN switch command") Cc: stable@vger.kernel.org #4.19 Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit f54e2394acf740b8c9efa3755aba0b474fd1b95f Author: Giridhar Malavali Date: Fri Feb 15 16:42:55 2019 -0800 scsi: qla2xxx: Avoid PCI IRQ affinity mapping when multiqueue is not supported commit f3e026951771bceb17319a4d0d6121ca58746c88 upstream. This patch fixes warning seen when BLK-MQ is enabled and hardware does not support MQ. This will result into driver requesting MSIx vectors which are equal or less than pre_desc via PCI IRQ Affinity infrastructure. [ 19.746300] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 10.00.00.12-k. [ 19.746599] qla2xxx [0000:02:00.0]-001d: : Found an ISP2432 irq 18 iobase 0x(____ptrval____). [ 20.203186] ------------[ cut here ]------------ [ 20.203306] WARNING: CPU: 8 PID: 268 at drivers/pci/msi.c:1273 pci_irq_get_affinity+0xf4/0x120 [ 20.203481] Modules linked in: tg3 ptp qla2xxx(+) pps_core sg libphy scsi_transport_fc flash loop autofs4 [ 20.203700] CPU: 8 PID: 268 Comm: systemd-udevd Not tainted 5.0.0-rc5-00358-gdf3865f #113 [ 20.203830] Call Trace: [ 20.203933] [0000000000461bb0] __warn+0xb0/0xe0 [ 20.204090] [00000000006c8f34] pci_irq_get_affinity+0xf4/0x120 [ 20.204219] [000000000068c764] blk_mq_pci_map_queues+0x24/0x120 [ 20.204396] [00000000007162f4] scsi_map_queues+0x14/0x40 [ 20.204626] [0000000000673654] blk_mq_update_queue_map+0x94/0xe0 [ 20.204698] [0000000000676ce0] blk_mq_alloc_tag_set+0x120/0x300 [ 20.204869] [000000000071077c] scsi_add_host_with_dma+0x7c/0x300 [ 20.205419] [00000000100ead54] qla2x00_probe_one+0x19d4/0x2640 [qla2xxx] [ 20.205621] [00000000006b3c88] pci_device_probe+0xc8/0x160 [ 20.205697] [0000000000701c0c] really_probe+0x1ac/0x2e0 [ 20.205770] [0000000000701f90] driver_probe_device+0x50/0x100 [ 20.205843] [0000000000702134] __driver_attach+0xf4/0x120 [ 20.205913] [0000000000700644] bus_for_each_dev+0x44/0x80 [ 20.206081] [0000000000700c98] bus_add_driver+0x198/0x220 [ 20.206300] [0000000000702950] driver_register+0x70/0x120 [ 20.206582] [0000000010248224] qla2x00_module_init+0x224/0x284 [qla2xxx] [ 20.206857] ---[ end trace b1de7a3f79fab2c2 ]--- The fix is to check if the hardware does not have Multi Queue capabiltiy, use pci_alloc_irq_vectors() call instead of pci_alloc_irq_affinity(). Fixes: f664a3cc17b7d ("scsi: kill off the legacy IO path") Cc: stable@vger.kernel.org #4.19 Signed-off-by: Giridhar Malavali Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 54e834ee7a6eeb1a6c520a3fa28c39c589147a97 Author: Himanshu Madhani Date: Fri Feb 15 14:37:12 2019 -0800 scsi: qla2xxx: Fix LUN discovery if loop id is not assigned yet by firmware commit ec322937a7f152d68755dc8316523bf6f831b48f upstream. This patch fixes LUN discovery when loop ID is not yet assigned by the firmware during driver load/sg_reset operations. Driver will now search for new loop id before retrying login. Fixes: 48acad099074 ("scsi: qla2xxx: Fix N2N link re-connect") Cc: stable@vger.kernel.org #4.19 Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 7d6d14a119c861d349257e3c3f2c84a18580413c Author: Bart Van Assche Date: Fri Jan 25 10:34:56 2019 -0800 scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock commit 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 upstream. When using SCSI passthrough in combination with the iSCSI target driver then cmd->t_state_lock may be obtained from interrupt context. Hence, all code that obtains cmd->t_state_lock from thread context must disable interrupts first. This patch avoids that lockdep reports the following: WARNING: inconsistent lock state 4.18.0-dbg+ #1 Not tainted -------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. iscsi_ttx/1800 [HC1[1]:SC0[2]:HE0:SE0] takes: 000000006e7b0ceb (&(&cmd->t_state_lock)->rlock){?...}, at: target_complete_cmd+0x47/0x2c0 [target_core_mod] {HARDIRQ-ON-W} state was registered at: lock_acquire+0xd2/0x260 _raw_spin_lock+0x32/0x50 iscsit_close_connection+0x97e/0x1020 [iscsi_target_mod] iscsit_take_action_for_connection_exit+0x108/0x200 [iscsi_target_mod] iscsi_target_rx_thread+0x180/0x190 [iscsi_target_mod] kthread+0x1cf/0x1f0 ret_from_fork+0x24/0x30 irq event stamp: 1281 hardirqs last enabled at (1279): [] __local_bh_enable_ip+0xa9/0x160 hardirqs last disabled at (1281): [] interrupt_entry+0xb5/0xd0 softirqs last enabled at (1278): [] lock_sock_nested+0x51/0xc0 softirqs last disabled at (1280): [] ip6_finish_output2+0x124/0xe40 [ipv6] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&cmd->t_state_lock)->rlock); lock(&(&cmd->t_state_lock)->rlock); commit 6c922faf889a49ef95120ae700398f30941e9466 Author: Martin K. Petersen Date: Tue Feb 12 16:21:05 2019 -0500 scsi: sd: Optimal I/O size should be a multiple of physical block size commit a83da8a4509d3ebfe03bb7fffce022e4d5d4764f upstream. It was reported that some devices report an OPTIMAL TRANSFER LENGTH of 0xFFFF blocks. That looks bogus, especially for a device with a 4096-byte physical block size. Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's reported physical block size. To make the sanity checking conditionals more readable--and to facilitate printing warnings--relocate the checking to a helper function. No functional change aside from the printks. Cc: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759 Reported-by: Christoph Anton Mitterer Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1ba35e5a3c5ce1bfbb753438349c9151341c558b Author: Sagar Biradar Date: Thu Mar 7 23:26:41 2019 -0800 scsi: aacraid: Fix performance issue on logical drives commit 0015437cc046e5ec2b57b00ff8312b8d432eac7c upstream. Fix performance issue where the queue depth for SmartIOC logical volumes is set to 1, and allow the usual logical volume code to be executed Fixes: a052865fe287 (aacraid: Set correct Queue Depth for HBA1000 RAW disks) Cc: stable@vger.kernel.org Signed-off-by: Sagar Biradar Reviewed-by: Dave Carroll Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit bd1558978695b42263d2ee7d612e8aee1bf55f59 Author: Felipe Franciosi Date: Wed Feb 27 16:10:34 2019 +0000 scsi: virtio_scsi: don't send sc payload with tmfs commit 3722e6a52174d7c3a00e6f5efd006ca093f346c1 upstream. The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of device-readable records and a single device-writable response entry: struct virtio_scsi_ctrl_tmf { // Device-readable part le32 type; le32 subtype; u8 lun[8]; le64 id; // Device-writable part u8 response; } The above should be organised as two descriptor entries (or potentially more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64 id" or after "u8 response". The Linux driver doesn't respect that, with virtscsi_abort() and virtscsi_device_reset() setting cmd->sc before calling virtscsi_tmf(). It results in the original scsi command payload (or writable buffers) added to the tmf. This fixes the problem by leaving cmd->sc zeroed out, which makes virtscsi_kick_cmd() add the tmf to the control vq without any payload. Cc: stable@vger.kernel.org Signed-off-by: Felipe Franciosi Reviewed-by: Paolo Bonzini Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit ffd4a428a54efe2f6bad6d0e63df605cbc90b3bb Author: Halil Pasic Date: Mon Jan 21 13:19:43 2019 +0100 s390/virtio: handle find on invalid queue gracefully commit 3438b2c039b4bf26881786a1f3450f016d66ad11 upstream. A queue with a capacity of zero is clearly not a valid virtio queue. Some emulators report zero queue size if queried with an invalid queue index. Instead of crashing in this case let us just return -ENOENT. To make that work properly, let us fix the notifier cleanup logic as well. Cc: stable@vger.kernel.org Signed-off-by: Halil Pasic Signed-off-by: Cornelia Huck Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 39fdc16138b799d2603d9b18ba4d4059df8f54cc Author: Martin Schwidefsky Date: Thu Feb 14 15:40:56 2019 +0100 s390/setup: fix early warning messages commit 8727638426b0aea59d7f904ad8ddf483f9234f88 upstream. The setup_lowcore() function creates a new prefix page for the boot CPU. The PSW mask for the system_call, external interrupt, i/o interrupt and the program check handler have the DAT bit set in this new prefix page. At the time setup_lowcore is called the system still runs without virtual address translation, the paging_init() function creates the kernel page table and loads the CR13 with the kernel ASCE. Any code between setup_lowcore() and the end of paging_init() that has a BUG or WARN statement will create a program check that can not be handled correctly as there is no kernel page table yet. To allow early WARN statements initially setup the lowcore with DAT off and set the DAT bit only after paging_init() has completed. Cc: stable@vger.kernel.org Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 2aa8ab08c82c68cedc09a9e0d19f568b16ad0fe5 Author: Pierre Morel Date: Tue Feb 12 16:53:45 2019 +0100 s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem commit 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 upstream. Libudev relies on having a subsystem link for non-root devices. To avoid libudev (and potentially other userspace tools) choking on the matrix device let us introduce a matrix bus and with it the matrix bus subsytem. Also make the matrix device reside within the matrix bus. Doing this we remove the forced link from the matrix device to the vfio_ap driver and the device_type we do not need anymore. Since the associated matrix driver is not the vfio_ap driver any more, we have to change the search for the devices on the vfio_ap driver in the function vfio_ap_verify_queue_reserved. Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver") Cc: stable@vger.kernel.org Reported-by: Marc Hartmayer Reported-by: Christian Borntraeger Signed-off-by: Pierre Morel Tested-by: Christian Borntraeger Reviewed-by: Cornelia Huck Reviewed-by: Tony Krowiak Acked-by: Halil Pasic Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 4b280a0bfc6d977148915dfbe27ef3af68ac6597 Author: Samuel Holland Date: Sat Jan 12 20:17:18 2019 -0600 clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability commit c950ca8c35eeb32224a63adc47e12f9e226da241 upstream. The Allwinner A64 SoC is known[1] to have an unstable architectural timer, which manifests itself most obviously in the time jumping forward a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a timer frequency of 24 MHz, implying that the time went slightly backward (and this was interpreted by the kernel as it jumping forward and wrapping around past the epoch). Investigation revealed instability in the low bits of CNTVCT at the point a high bit rolls over. This leads to power-of-two cycle forward and backward jumps. (Testing shows that forward jumps are about twice as likely as backward jumps.) Since the counter value returns to normal after an indeterminate read, each "jump" really consists of both a forward and backward jump from the software perspective. Unless the kernel is trapping CNTVCT reads, a userspace program is able to read the register in a loop faster than it changes. A test program running on all 4 CPU cores that reported jumps larger than 100 ms was run for 13.6 hours and reported the following: Count | Event -------+--------------------------- 9940 | jumped backward 699ms 268 | jumped backward 1398ms 1 | jumped backward 2097ms 16020 | jumped forward 175ms 6443 | jumped forward 699ms 2976 | jumped forward 1398ms 9 | jumped forward 356516ms 9 | jumped forward 357215ms 4 | jumped forward 714430ms 1 | jumped forward 3578440ms This works out to a jump larger than 100 ms about every 5.5 seconds on each CPU core. The largest jump (almost an hour!) was the following sequence of reads: 0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000 Note that the middle bits don't necessarily all read as all zeroes or all ones during the anomalous behavior; however the low 10 bits checked by the function in this patch have never been observed with any other value. Also note that smaller jumps are much more common, with backward jumps of 2048 (2^11) cycles observed over 400 times per second on each core. (Of course, this is partially explained by lower bits rolling over more frequently.) Any one of these could have caused the 95 year time skip. Similar anomalies were observed while reading CNTPCT (after patching the kernel to allow reads from userspace). However, the CNTPCT jumps are much less frequent, and only small jumps were observed. The same program as before (except now reading CNTPCT) observed after 72 hours: Count | Event -------+--------------------------- 17 | jumped backward 699ms 52 | jumped forward 175ms 2831 | jumped forward 699ms 5 | jumped forward 1398ms Further investigation showed that the instability in CNTPCT/CNTVCT also affected the respective timer's TVAL register. The following values were observed immediately after writing CNVT_TVAL to 0x10000000: CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error --------------------+------------+--------------------+----------------- 0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000 The pattern of errors in CNTV_TVAL seemed to depend on exactly which value was written to it. For example, after writing 0x10101010: CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error --------------------+------------+--------------------+----------------- 0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000 I was also twice able to reproduce the issue covered by Allwinner's workaround[4], that writing to TVAL sometimes fails, and both CVAL and TVAL are left with entirely bogus values. One was the following values: CNTVCT | CNTV_TVAL | CNTV_CVAL --------------------+------------+-------------------------------------- 0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past) Reviewed-by: Marc Zyngier ======================================================================== Because the CPU can read the CNTPCT/CNTVCT registers faster than they change, performing two reads of the register and comparing the high bits (like other workarounds) is not a workable solution. And because the timer can jump both forward and backward, no pair of reads can distinguish a good value from a bad one. The only way to guarantee a good value from consecutive reads would be to read _three_ times, and take the middle value only if the three values are 1) each unique and 2) increasing. This takes at minimum 3 counter cycles (125 ns), or more if an anomaly is detected. However, since there is a distinct pattern to the bad values, we can optimize the common case (1022/1024 of the time) to a single read by simply ignoring values that match the error pattern. This still takes no more than 3 cycles in the worst case, and requires much less code. As an additional safety check, we still limit the loop iteration to the number of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods. For the TVAL registers, the simple solution is to not use them. Instead, read or write the CVAL and calculate the TVAL value in software. Although the manufacturer is aware of at least part of the erratum[4], there is no official name for it. For now, use the kernel-internal name "UNKNOWN1". [1]: https://github.com/armbian/build/commit/a08cd6fe7ae9 [2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/ [3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26 [4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272 Acked-by: Maxime Ripard Tested-by: Andre Przywara Signed-off-by: Samuel Holland Cc: stable@vger.kernel.org Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 773b445425d67891fb58c47d7e059a32c0e99c76 Author: Stuart Menefy Date: Sun Feb 10 22:51:14 2019 +0000 clocksource/drivers/exynos_mct: Clear timer interrupt when shutdown commit d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c upstream. When shutting down the timer, ensure that after we have stopped the timer any pending interrupts are cleared. This fixes a problem when suspending, as interrupts are disabled before the timer is stopped, so the timer interrupt may still be asserted, preventing the system entering a low power state when the wfi is executed. Signed-off-by: Stuart Menefy Reviewed-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Cc: # v4.3+ Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit de90b88a20de2fbb10811c8505aa493a4620a5f4 Author: Stuart Menefy Date: Sun Feb 10 22:51:13 2019 +0000 clocksource/drivers/exynos_mct: Move one-shot check from tick clear to ISR commit a5719a40aef956ba704f2aa1c7b977224d60fa96 upstream. When a timer tick occurs and the clock is in one-shot mode, the timer needs to be stopped to prevent it triggering subsequent interrupts. Currently this code is in exynos4_mct_tick_clear(), but as it is only needed when an ISR occurs move it into exynos4_mct_tick_isr(), leaving exynos4_mct_tick_clear() just doing what its name suggests it should. Signed-off-by: Stuart Menefy Reviewed-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 9d67c5e995dabb1e75740e01e6d4f202d68a285b Author: Felix Fietkau Date: Fri Jan 25 17:59:06 2019 +0100 mt76: fix corrupted software generated tx CCMP PN commit 906d2d3f874a54183df5a609fda180adf0462428 upstream. Since ccmp_pn is u8 *, the second half needs to start at array index 4 instead of 0. Fixes a connection stall after a certain amount of traffic Fixes: 23405236460b9 ("mt76: fix transmission of encrypted management frames") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 6b65a01d2dcc6ff096d5db0d9ced5354b5b86a52 Author: Stuart Menefy Date: Tue Feb 12 21:51:18 2019 +0000 regulator: s2mpa01: Fix step values for some LDOs commit 28c4f730d2a44f2591cb104091da29a38dac49fe upstream. The step values for some of the LDOs appears to be incorrect, resulting in incorrect voltages (or at least, ones which are different from the Samsung 3.4 vendor kernel). Signed-off-by: Stuart Menefy Reviewed-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 60cb8b444fbf641b8ca36be3a6f99e51d3e213f6 Author: Mark Zhang Date: Thu Jan 10 12:11:16 2019 +0800 regulator: max77620: Initialize values for DT properties commit 0ab66b3c326ef8f77dae9f528118966365757c0c upstream. If regulator DT node doesn't exist, its of_parse_cb callback function isn't called. Then all values for DT properties are filled with zero. This leads to wrong register update for FPS and POK settings. Signed-off-by: Jinyoung Park Signed-off-by: Mark Zhang Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4527a24a8f518edf6ad8f74c0ca4fdf6f027b2ad Author: Krzysztof Kozlowski Date: Sat Feb 9 18:14:14 2019 +0100 regulator: s2mps11: Fix steps for buck7, buck8 and LDO35 commit 56b5d4ea778c1b0989c5cdb5406d4a488144c416 upstream. LDO35 uses 25 mV step, not 50 mV. Bucks 7 and 8 use 12.5 mV step instead of 6.25 mV. Wrong step caused over-voltage (LDO35) or under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420 Arndale Octa board). Cc: Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a34758ac6ad4f33edb99caaecf27f0a76d3142a5 Author: Russell King Date: Thu Feb 21 15:59:58 2019 +0000 spi: spi-gpio: fix SPI_CS_HIGH capability commit b89fefda7d4e3a649129584d855be233c7465264 upstream. spi-gpio is capable of dealing with active-high chip-selects. Unfortunately, commit 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support") broke this by setting master->mode_bits, which overrides the setting in the spi-bitbang code. Fix this. [Fixed a trivial conflict with SPI_3WIRE_HIZ support -- broonie] Fixes: 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support") Signed-off-by: Russell King Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6184910148467a7e7fc9e8036aceda495b28ac78 Author: Vignesh R Date: Tue Jan 15 12:28:32 2019 +0530 spi: omap2-mcspi: Fix DMA and FIFO event trigger size mismatch commit baf8b9f8d260c55a86405f70a384c29cda888476 upstream. Commit b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word length") broke SPI transfers where bits_per_word != 8. This is because of mimsatch between McSPI FIFO level event trigger size (SPI word length) and DMA request size(word length * maxburst). This leads to data corruption, lockup and errors like: spi1.0: EOW timed out Fix this by setting DMA maxburst size to 1 so that McSPI FIFO level event trigger size matches DMA request size. Fixes: b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word length") Cc: stable@vger.kernel.org Reported-by: David Lechner Tested-by: David Lechner Signed-off-by: Vignesh R Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7406a055c507313cdd9e0c628127ed4a3c8876c0 Author: Andy Shevchenko Date: Tue Feb 19 23:21:28 2019 +0300 spi: pxa2xx: Setup maximum supported DMA transfer length commit ef070b4e4aa25bb5f8632ad196644026c11903bf upstream. When the commit b6ced294fb61 ("spi: pxa2xx: Switch to SPI core DMA mapping functionality") switches to SPI core provided DMA helpers, it missed to setup maximum supported DMA transfer length for the controller and thus users mistakenly try to send more data than supported with the following warning: ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536 Setup maximum supported DMA transfer length in order to make users know the limit. Fixes: b6ced294fb61 ("spi: pxa2xx: Switch to SPI core DMA mapping functionality") Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5d919139baf9d609895425c44fa51779fb558536 Author: Vignesh R Date: Tue Jan 29 13:14:22 2019 +0530 spi: ti-qspi: Fix mmap read when more than one CS in use commit 673c865efbdc5fec3cc525c46d71844d42c60072 upstream. Commit 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") has has got order of parameter wrong when calling regmap_update_bits() to select CS for mmap access. Mask and value arguments are interchanged. Code will work on a system with single slave, but fails when more than one CS is in use. Fix this by correcting the order of parameters when calling regmap_update_bits(). Fixes: 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") Cc: stable@vger.kernel.org Signed-off-by: Vignesh R Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4a9932c94626ea4a574a91bfca64423ae8c0695d Author: Jiong Wu Date: Fri Mar 1 00:18:33 2019 +0800 mmc:fix a bug when max_discard is 0 commit d4721339dcca7def04909a8e60da43c19a24d8bf upstream. The original purpose of the code I fix is to replace max_discard with max_trim if max_trim is less than max_discard. When max_discard is 0 we should replace max_discard with max_trim as well, because max_discard equals 0 happens only when the max_do_calc_max_discard process is overflowed, so if mmc_can_trim(card) is true, max_discard should be replaced by an available max_trim. However, in the original code, there are two lines of code interfere the right process. 1) if (max_discard && mmc_can_trim(card)) when max_discard is 0, it skips the process checking if max_discard needs to be replaced with max_trim. 2) if (max_trim < max_discard) the condition is false when max_discard is 0. it also skips the process that replaces max_discard with max_trim, in fact, we should replace the 0-valued max_discard with max_trim. Signed-off-by: Jiong Wu Fixes: b305882fbc87 (mmc: core: optimize mmc_calc_max_discard) Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit aaf1e755f8f9c6a4b6cf8514352164940db78cbd Author: Takeshi Saito Date: Tue Jan 29 06:40:39 2019 +0100 mmc: renesas_sdhi: Fix card initialization failure in high speed mode commit d30ae056adb81e1d2b8b953efa74735a020b8e3b upstream. This fixes card initialization failure in high speed mode. If U-Boot uses SDR or HS200/400 mode before starting Linux and Linux DT does not enable SDR/HS200/HS400 mode, card initialization fails in high speed mode. It is necessary to initialize SCC registers during card initialization phase. HW reset function is registered only for a port with either of SDR/HS200/HS400 properties in device tree. If SDR/HS200/HS400 properties are not present in device tree, SCC registers will not be reset. In SoC that support SCC registers, HW reset function should be registered regardless of the configuration of device tree. Reproduction procedure: - Use U-Boot that support MMC HS200/400 mode. - Delete HS200/HS400 properties in device tree. (Delete mmc-hs200-1_8v and mmc-hs400-1_8v) - MMC port works high speed mode and all commands fail. Signed-off-by: Takeshi Saito Signed-off-by: Marek Vasut Cc: Niklas Söderlund Cc: Simon Horman Reviewed-by: Wolfram Sang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 351062f08fc1b57f33f29ceeee7dc67a9e39b5c4 Author: BOUGH CHEN Date: Thu Dec 27 11:20:24 2018 +0000 mmc: sdhci-esdhc-imx: fix HS400 timing issue commit de0a0decf2edfc5b0c782915f4120cf990a9bd13 upstream. Now tuning reset will be done when the timing is MMC_TIMING_LEGACY/ MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS. But for timing MMC_TIMING_MMC_HS, we can not do tuning reset, otherwise HS400 timing is not right. Here is the process of init HS400, first finish tuning in HS200 mode, then switch to HS mode and 8 bit DDR mode, finally switch to HS400 mode. If we do tuning reset in HS mode, this will cause HS400 mode lost the tuning setting, which will cause CRC error. Signed-off-by: Haibo Chen Cc: stable@vger.kernel.org # v4.12+ Acked-by: Adrian Hunter Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card") Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cb1c7a9d2897b70d44e8e8b88b67c933c52fb11b Author: Andy Shevchenko Date: Mon Mar 11 18:41:03 2019 +0200 ACPI / device_sysfs: Avoid OF modalias creation for removed device commit f16eb8a4b096514ac06fb25bf599dcc792899b3d upstream. If SSDT overlay is loaded via ConfigFS and then unloaded the device, we would like to have OF modalias for, already gone. Thus, acpi_get_name() returns no allocated buffer for such case and kernel crashes afterwards: ACPI: Host-directed Dynamic ACPI Table Unload ads7950 spi-PRP0001:00: Dropping the link to regulator.0 BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 #PF error: [normal kernel read fault] PGD 80000000070d6067 P4D 80000000070d6067 PUD 70d0067 PMD 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 40 Comm: kworker/u4:2 Not tainted 5.0.0+ #96 Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 Workqueue: kacpi_hotplug acpi_device_del_work_fn RIP: 0010:create_of_modalias.isra.1+0x4c/0x150 Code: 00 00 48 89 44 24 18 31 c0 48 8d 54 24 08 48 c7 44 24 10 00 00 00 00 48 c7 44 24 08 ff ff ff ff e8 7a b0 03 00 48 8b 4c 24 10 <0f> b6 01 84 c0 74 27 48 c7 c7 00 09 f4 a5 0f b6 f0 8d 50 20 f6 04 RSP: 0000:ffffa51040297c10 EFLAGS: 00010246 RAX: 0000000000001001 RBX: 0000000000000785 RCX: 0000000000000000 RDX: 0000000000001001 RSI: 0000000000000286 RDI: ffffa2163dc042e0 RBP: ffffa216062b1196 R08: 0000000000001001 R09: ffffa21639873000 R10: ffffffffa606761d R11: 0000000000000001 R12: ffffa21639873218 R13: ffffa2163deb5060 R14: ffffa216063d1010 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa2163e000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000007114000 CR4: 00000000001006f0 Call Trace: __acpi_device_uevent_modalias+0xb0/0x100 spi_uevent+0xd/0x40 ... In order to fix above let create_of_modalias() check the status returned by acpi_get_name() and bail out in case of failure. Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present") Link: https://bugzilla.kernel.org/show_bug.cgi?id=201381 Reported-by: Ferry Toth Tested-by: Ferry Toth Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Cc: 4.1+ # 4.1+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 050b87cb66c641b389008b35f1146ec9d70188a8 Author: Juergen Gross Date: Thu Mar 7 10:11:19 2019 +0100 xen: fix dom0 boot on huge systems commit 01bd2ac2f55a1916d81dace12fa8d7ae1c79b5ea upstream. Commit f7c90c2aa40048 ("x86/xen: don't write ptes directly in 32-bit PV guests") introduced a regression for booting dom0 on huge systems with lots of RAM (in the TB range). Reason is that on those hosts the p2m list needs to be moved early in the boot process and this requires temporary page tables to be created. Said commit modified xen_set_pte_init() to use a hypercall for writing a PTE, but this requires the page table being in the direct mapped area, which is not the case for the temporary page tables used in xen_relocate_p2m(). As the page tables are completely written before being linked to the actual address space instead of set_pte() a plain write to memory can be used in xen_relocate_p2m(). Fixes: f7c90c2aa40048 ("x86/xen: don't write ptes directly in 32-bit PV guests") Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit c0b8e1d95cbf94e53ba991339761d03e523f2e00 Author: Dan Carpenter Date: Mon Feb 11 21:45:45 2019 +0300 vmw_balloon: release lock on error in vmballoon_reset() commit d04071a5d6413b65f17f7bd6e2bdb22e22e4ace7 upstream. We added some locking to this function but forgot to drop the lock on these two error paths. This bug would lead to an immediate deadlock. Fixes: c7b3690fb152 ("vmw_balloon: stats rework") Signed-off-by: Dan Carpenter Cc: stable@vger.kernel.org Reviewed-by: Nadav Amit Signed-off-by: Greg Kroah-Hartman commit 020c90c694dc36b345eeecc59ac48eae88faa983 Author: Jann Horn Date: Wed Feb 20 17:54:43 2019 +0100 tracing/perf: Use strndup_user() instead of buggy open-coded version commit 83540fbc8812a580b6ad8f93f4c29e62e417687e upstream. The first version of this method was missing the check for `ret == PATH_MAX`; then such a check was added, but it didn't call kfree() on error, so there was still a small memory leak in the error case. Fix it by using strndup_user() instead of open-coding it. Link: http://lkml.kernel.org/r/20190220165443.152385-1-jannh@google.com Cc: Ingo Molnar Cc: stable@vger.kernel.org Fixes: 0eadcc7a7bc0 ("perf/core: Fix perf_uprobe_init()") Reviewed-by: Masami Hiramatsu Acked-by: Song Liu Signed-off-by: Jann Horn Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit aca126f4a451b36fc6841d7bf76b3a5f4e5d3b01 Author: zhangyi (F) Date: Wed Feb 13 20:29:06 2019 +0800 tracing: Do not free iter->trace in fail path of tracing_open_pipe() commit e7f0c424d0806b05d6f47be9f202b037eb701707 upstream. Commit d716ff71dd12 ("tracing: Remove taking of trace_types_lock in pipe files") use the current tracer instead of the copy in tracing_open_pipe(), but it forget to remove the freeing sentence in the error path. There's an error path that can call kfree(iter->trace) after the iter->trace was assigned to tr->current_trace, which would be bad to free. Link: http://lkml.kernel.org/r/1550060946-45984-1-git-send-email-yi.zhang@huawei.com Cc: stable@vger.kernel.org Fixes: d716ff71dd12 ("tracing: Remove taking of trace_types_lock in pipe files") Signed-off-by: zhangyi (F) Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit e5cde571ee5fef726d62a013c7aeef53705dfd32 Author: Tom Zanussi Date: Mon Feb 4 15:07:24 2019 -0600 tracing: Use strncpy instead of memcpy for string keys in hist triggers commit 9f0bbf3115ca9f91f43b7c74e9ac7d79f47fc6c2 upstream. Because there may be random garbage beyond a string's null terminator, it's not correct to copy the the complete character array for use as a hist trigger key. This results in multiple histogram entries for the 'same' string key. So, in the case of a string key, use strncpy instead of memcpy to avoid copying in the extra bytes. Before, using the gdbus entries in the following hist trigger as an example: # echo 'hist:key=comm' > /sys/kernel/debug/tracing/events/sched/sched_waking/trigger # cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist ... { comm: ImgDecoder #4 } hitcount: 203 { comm: gmain } hitcount: 213 { comm: gmain } hitcount: 216 { comm: StreamTrans #73 } hitcount: 221 { comm: mozStorage #3 } hitcount: 230 { comm: gdbus } hitcount: 233 { comm: StyleThread#5 } hitcount: 253 { comm: gdbus } hitcount: 256 { comm: gdbus } hitcount: 260 { comm: StyleThread#4 } hitcount: 271 ... # cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist | egrep gdbus | wc -l 51 After: # cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist | egrep gdbus | wc -l 1 Link: http://lkml.kernel.org/r/50c35ae1267d64eee975b8125e151e600071d4dc.1549309756.git.tom.zanussi@linux.intel.com Cc: Namhyung Kim Cc: stable@vger.kernel.org Fixes: 79e577cbce4c4 ("tracing: Support string type key properly") Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit c892f4ee3db2d45ac78172fd2de4fb5e642d6f7b Author: Steve French Date: Thu Feb 28 21:32:15 2019 -0600 smb3: make default i/o size for smb3 mounts larger commit e8506d25f740fd058791cc12a6dfa9386ada6b96 upstream. We negotiate rsize mounts (and it can be overridden by user) to typically 4MB, so using larger default I/O sizes from userspace (changing to 1MB default i/o size returned by stat) the performance is much better (and not just for long latency network connections) in most use cases for SMB3 than the default I/O size (which ends up being 128K for cp and can be even smaller for cp). This can be 4x slower or worse depending on network latency. By changing inode->blocksize from 32K (which was perhaps ok for very old SMB1/CIFS) to a larger value, 1MB (but still less than max size negotiated with the server which is 4MB, in order to minimize risk) it significantly increases performance for the noncached case, and slightly increases it for the cached case. This can be changed by the user on mount (specifying bsize= values from 16K to 16MB) to tune better for performance for applications that depend on blocksize. Signed-off-by: Steve French Reviewed-by: Ronnie Sahlberg CC: Stable Signed-off-by: Greg Kroah-Hartman commit 3eb2412dd9da1c459bcd45ad8f567e489c060ad2 Author: Pavel Shilovsky Date: Mon Mar 4 17:48:01 2019 -0800 CIFS: Fix read after write for files with read caching commit 6dfbd84684700cb58b34e8602c01c12f3d2595c8 upstream. When we have a READ lease for a file and have just issued a write operation to the server we need to purge the cache and set oplock/lease level to NONE to avoid reading stale data. Currently we do that only if a write operation succedeed thus not covering cases when a request was sent to the server but a negative error code was returned later for some other reasons (e.g. -EIOCBQUEUED or -EINTR). Fix this by turning off caching regardless of the error code being returned. The patches fixes generic tests 075 and 112 from the xfs-tests. Cc: Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Reviewed-by: Ronnie Sahlberg Signed-off-by: Greg Kroah-Hartman commit c73a769b63fb86b38fda5a01765c9540b8c9c5a6 Author: Pavel Shilovsky Date: Mon Mar 4 14:02:50 2019 -0800 CIFS: Do not skip SMB2 message IDs on send failures commit c781af7e0c1fed9f1d0e0ec31b86f5b21a8dca17 upstream. When we hit failures during constructing MIDs or sending PDUs through the network, we end up not using message IDs assigned to the packet. The next SMB packet will skip those message IDs and continue with the next one. This behavior may lead to a server not granting us credits until we use the skipped IDs. Fix this by reverting the current ID to the original value if any errors occur before we push the packet through the network stack. This patch fixes the generic/310 test from the xfs-tests. Cc: # 4.19.x Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a992916a9c893116ed106258b16630bd958aaac1 Author: Pavel Shilovsky Date: Wed Feb 13 15:43:08 2019 -0800 CIFS: Do not reset lease state to NONE on lease break commit 7b9b9edb49ad377b1e06abf14354c227e9ac4b06 upstream. Currently on lease break the client sets a caching level twice: when oplock is detected and when oplock is processed. While the 1st attempt sets the level to the value provided by the server, the 2nd one resets the level to None unconditionally. This happens because the oplock/lease processing code was changed to avoid races between page cache flushes and oplock breaks. The commit c11f1df5003d534 ("cifs: Wait for writebacks to complete before attempting write.") fixed the races for oplocks but didn't apply the same changes for leases resulting in overwriting the server granted value to None. Fix this by properly processing lease breaks. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French CC: Stable Signed-off-by: Greg Kroah-Hartman commit 75bbb83e80c764ddfb4a70270c5b269c92cebd66 Author: Pavel Shilovsky Date: Tue Jan 29 16:40:28 2019 -0800 CIFS: Fix leaking locked VFS cache pages in writeback retry commit 165df9a080b6863ae286fa01780c13d87cd81076 upstream. If we don't find a writable file handle when retrying writepages we break of the loop and do not unlock and put pages neither from wdata2 nor from the original wdata. Fix this by walking through all the remaining pages and cleanup them properly. Cc: Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit afaf9d664b0f2e94110947db89123be1fcc1f5e9 Author: Ard Biesheuvel Date: Thu Jan 24 17:33:46 2019 +0100 crypto: arm64/aes-ccm - fix bugs in non-NEON fallback routine commit 969e2f59d589c15f6aaf306e590dde16f12ea4b3 upstream. Commit 5092fcf34908 ("crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback") introduced C fallback code to replace the NEON routines when invoked from a context where the NEON is not available (i.e., from the context of a softirq taken while the NEON is already being used in kernel process context) Fix two logical flaws in the MAC calculation of the associated data. Reported-by: Eric Biggers Fixes: 5092fcf34908 ("crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback") Cc: stable@vger.kernel.org Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 741ae3caa62f622123ea91dd785018aeaba0daba Author: Ard Biesheuvel Date: Thu Jan 24 17:33:45 2019 +0100 crypto: arm64/aes-ccm - fix logical bug in AAD MAC handling commit eaf46edf6ea89675bd36245369c8de5063a0272c upstream. The NEON MAC calculation routine fails to handle the case correctly where there is some data in the buffer, and the input fills it up exactly. In this case, we enter the loop at the end with w8 == 0, while a negative value is assumed, and so the loop carries on until the increment of the 32-bit counter wraps around, which is quite obviously wrong. So omit the loop altogether in this case, and exit right away. Reported-by: Eric Biggers Fixes: a3fd82105b9d1 ("arm64/crypto: AES in CCM mode using ARMv8 Crypto ...") Cc: stable@vger.kernel.org Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d78c34dfc2882a11ece54f555b8853031def4b08 Author: Eric Biggers Date: Thu Jan 31 23:51:39 2019 -0800 crypto: x86/morus - fix handling chunked inputs and MAY_SLEEP commit 2060e284e9595fc3baed6e035903c05b93266555 upstream. The x86 MORUS implementations all fail the improved AEAD tests because they produce the wrong result with some data layouts. The issue is that they assume that if the skcipher_walk API gives 'nbytes' not aligned to the walksize (a.k.a. walk.stride), then it is the end of the data. In fact, this can happen before the end. Also, when the CRYPTO_TFM_REQ_MAY_SLEEP flag is given, they can incorrectly sleep in the skcipher_walk_*() functions while preemption has been disabled by kernel_fpu_begin(). Fix these bugs. Fixes: 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for MORUS") Cc: # v4.18+ Cc: Ondrej Mosnacek Signed-off-by: Eric Biggers Reviewed-by: Ondrej Mosnacek Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 814ec1461901602180810c0b4fb310c34c9b5d5e Author: Eric Biggers Date: Thu Jan 31 23:51:40 2019 -0800 crypto: x86/aesni-gcm - fix crash on empty plaintext commit 3af349639597fea582a93604734d717e59a0e223 upstream. gcmaes_crypt_by_sg() dereferences the NULL pointer returned by scatterwalk_ffwd() when encrypting an empty plaintext and the source scatterlist ends immediately after the associated data. Fix it by only fast-forwarding to the src/dst data scatterlists if the data length is nonzero. This bug is reproduced by the "rfc4543(gcm(aes))" test vectors when run with the new AEAD test manager. Fixes: e845520707f8 ("crypto: aesni - Update aesni-intel_glue to use scatter/gather") Cc: # v4.17+ Cc: Dave Watson Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 2e0e52c3d61895944c8250b87d0fff6b8a7fa09c Author: Eric Biggers Date: Thu Jan 31 23:51:38 2019 -0800 crypto: x86/aegis - fix handling chunked inputs and MAY_SLEEP commit ba6771c0a0bc2fac9d6a8759bab8493bd1cffe3b upstream. The x86 AEGIS implementations all fail the improved AEAD tests because they produce the wrong result with some data layouts. The issue is that they assume that if the skcipher_walk API gives 'nbytes' not aligned to the walksize (a.k.a. walk.stride), then it is the end of the data. In fact, this can happen before the end. Also, when the CRYPTO_TFM_REQ_MAY_SLEEP flag is given, they can incorrectly sleep in the skcipher_walk_*() functions while preemption has been disabled by kernel_fpu_begin(). Fix these bugs. Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations") Cc: # v4.18+ Cc: Ondrej Mosnacek Signed-off-by: Eric Biggers Reviewed-by: Ondrej Mosnacek Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c9e34c3c34b928ff35a9ef84be2220ea1a3067e8 Author: Eric Biggers Date: Wed Jan 23 20:57:35 2019 -0800 crypto: testmgr - skip crc32c context test for ahash algorithms commit eb5e6730db98fcc4b51148b4a819fa4bf864ae54 upstream. Instantiating "cryptd(crc32c)" causes a crypto self-test failure because the crypto_alloc_shash() in alg_test_crc32c() fails. This is because cryptd(crc32c) is an ahash algorithm, not a shash algorithm; so it can only be accessed through the ahash API, unlike shash algorithms which can be accessed through both the ahash and shash APIs. As the test is testing the shash descriptor format which is only applicable to shash algorithms, skip it for ahash algorithms. (Note that it's still important to fix crypto self-test failures even for weird algorithm instantiations like cryptd(crc32c) that no one would really use; in fips_enabled mode unprivileged users can use them to panic the kernel, and also they prevent treating a crypto self-test failure as a bug when fuzzing the kernel.) Fixes: 8e3ee85e68c5 ("crypto: crc32c - Test descriptor context format") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c58580801420cfe5e82c105e71741e31dfe506b6 Author: Eric Biggers Date: Sun Jan 6 18:47:43 2019 -0800 crypto: skcipher - set CRYPTO_TFM_NEED_KEY if ->setkey() fails commit b1f6b4bf416b49f00f3abc49c639371cdecaaad1 upstream. Some algorithms have a ->setkey() method that is not atomic, in the sense that setting a key can fail after changes were already made to the tfm context. In this case, if a key was already set the tfm can end up in a state that corresponds to neither the old key nor the new key. For example, in lrw.c, if gf128mul_init_64k_bbe() fails due to lack of memory, then priv::table will be left NULL. After that, encryption with that tfm will cause a NULL pointer dereference. It's not feasible to make all ->setkey() methods atomic, especially ones that have to key multiple sub-tfms. Therefore, make the crypto API set CRYPTO_TFM_NEED_KEY if ->setkey() fails and the algorithm requires a key, to prevent the tfm from being used until a new key is set. [Cc stable mainly because when introducing the NEED_KEY flag I changed AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG previously didn't have this problem. So these "incompletely keyed" states became theoretically accessible via AF_ALG -- though, the opportunities for causing real mischief seem pretty limited.] Fixes: f8d33fac8480 ("crypto: skcipher - prevent using skciphers without setting key") Cc: # v4.16+ Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 0173f7ca0e2222f42310a49ad89481b5a877973d Author: Eric Biggers Date: Thu Jan 3 20:16:13 2019 -0800 crypto: pcbc - remove bogus memcpy()s with src == dest commit 251b7aea34ba3c4d4fdfa9447695642eb8b8b098 upstream. The memcpy()s in the PCBC implementation use walk->iv as both the source and destination, which has undefined behavior. These memcpy()'s are actually unneeded, because walk->iv is already used to hold the previous plaintext block XOR'd with the previous ciphertext block. Thus, walk->iv is already updated to its final value. So remove the broken and unnecessary memcpy()s. Fixes: 91652be5d1b9 ("[CRYPTO] pcbc: Add Propagated CBC template") Cc: # v2.6.21+ Cc: David Howells Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9cbfb0a8d1afb0b47327fe0e0956c106070abf64 Author: Eric Biggers Date: Thu Jan 31 23:51:37 2019 -0800 crypto: morus - fix handling chunked inputs commit d644f1c8746ed24f81075480f9e9cb3777ae8d65 upstream. The generic MORUS implementations all fail the improved AEAD tests because they produce the wrong result with some data layouts. The issue is that they assume that if the skcipher_walk API gives 'nbytes' not aligned to the walksize (a.k.a. walk.stride), then it is the end of the data. In fact, this can happen before the end. Fix them. Fixes: 396be41f16fd ("crypto: morus - Add generic MORUS AEAD implementations") Cc: # v4.18+ Cc: Ondrej Mosnacek Signed-off-by: Eric Biggers Reviewed-by: Ondrej Mosnacek Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c850ff289c4ea283f147157945297a96ed9cdae0 Author: Eric Biggers Date: Sun Jan 6 18:47:42 2019 -0800 crypto: hash - set CRYPTO_TFM_NEED_KEY if ->setkey() fails commit ba7d7433a0e998c902132bd47330e355a1eaa894 upstream. Some algorithms have a ->setkey() method that is not atomic, in the sense that setting a key can fail after changes were already made to the tfm context. In this case, if a key was already set the tfm can end up in a state that corresponds to neither the old key nor the new key. It's not feasible to make all ->setkey() methods atomic, especially ones that have to key multiple sub-tfms. Therefore, make the crypto API set CRYPTO_TFM_NEED_KEY if ->setkey() fails and the algorithm requires a key, to prevent the tfm from being used until a new key is set. Note: we can't set CRYPTO_TFM_NEED_KEY for OPTIONAL_KEY algorithms, so ->setkey() for those must nevertheless be atomic. That's fine for now since only the crc32 and crc32c algorithms set OPTIONAL_KEY, and it's not intended that OPTIONAL_KEY be used much. [Cc stable mainly because when introducing the NEED_KEY flag I changed AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG previously didn't have this problem. So these "incompletely keyed" states became theoretically accessible via AF_ALG -- though, the opportunities for causing real mischief seem pretty limited.] Fixes: 9fa68f620041 ("crypto: hash - prevent using keyed hashes without setting key") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7007b2645f6e8be0d236ad293ca6229228d9a7f5 Author: Ard Biesheuvel Date: Sun Jan 27 10:16:53 2019 +0100 crypto: arm64/crct10dif - revert to C code for short inputs commit d72b9d4acd548251f55b16843fc7a05dc5c80de8 upstream. The SIMD routine ported from x86 used to have a special code path for inputs < 16 bytes, which got lost somewhere along the way. Instead, the current glue code aligns the input pointer to 16 bytes, which is not really necessary on this architecture (although it could be beneficial to performance to expose aligned data to the the NEON routine), but this could result in inputs of less than 16 bytes to be passed in. This not only fails the new extended tests that Eric has implemented, it also results in the code reading past the end of the input, which could potentially result in crashes when dealing with less than 16 bytes of input at the end of a page which is followed by an unmapped page. So update the glue code to only invoke the NEON routine if the input is at least 16 bytes. Reported-by: Eric Biggers Reviewed-by: Eric Biggers Fixes: 6ef5737f3931 ("crypto: arm64/crct10dif - port x86 SSE implementation to arm64") Cc: # v4.10+ Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d78abd635e6c31825737fbc67c631832cc15b92f Author: Eric Biggers Date: Thu Jan 31 23:51:42 2019 -0800 crypto: arm64/aes-neonbs - fix returning final keystream block commit 12455e320e19e9cc7ad97f4ab89c280fe297387c upstream. The arm64 NEON bit-sliced implementation of AES-CTR fails the improved skcipher tests because it sometimes produces the wrong ciphertext. The bug is that the final keystream block isn't returned from the assembly code when the number of non-final blocks is zero. This can happen if the input data ends a few bytes after a page boundary. In this case the last bytes get "encrypted" by XOR'ing them with uninitialized memory. Fix the assembly code to return the final keystream block when needed. Fixes: 88a3f582bea9 ("crypto: arm64/aes - don't use IV buffer to return final keystream block") Cc: # v4.11+ Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 844351fc03b0d8f34ed8ef9426b344d3096b6dc9 Author: Ard Biesheuvel Date: Sun Jan 27 10:16:52 2019 +0100 crypto: arm/crct10dif - revert to C code for short inputs commit 62fecf295e3c48be1b5f17c440b93875b9adb4d6 upstream. The SIMD routine ported from x86 used to have a special code path for inputs < 16 bytes, which got lost somewhere along the way. Instead, the current glue code aligns the input pointer to permit the NEON routine to use special versions of the vld1 instructions that assume 16 byte alignment, but this could result in inputs of less than 16 bytes to be passed in. This not only fails the new extended tests that Eric has implemented, it also results in the code reading past the end of the input, which could potentially result in crashes when dealing with less than 16 bytes of input at the end of a page which is followed by an unmapped page. So update the glue code to only invoke the NEON routine if the input is at least 16 bytes. Reported-by: Eric Biggers Reviewed-by: Eric Biggers Fixes: 1d481f1cd892 ("crypto: arm/crct10dif - port x86 SSE implementation to ARM") Cc: # v4.10+ Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e414d9bc86a7d71d9dc8b65d5b371cb0971d8394 Author: Eric Biggers Date: Thu Jan 31 23:51:36 2019 -0800 crypto: aegis - fix handling chunked inputs commit 0f533e67d26f228ea5dfdacc8a4bdeb487af5208 upstream. The generic AEGIS implementations all fail the improved AEAD tests because they produce the wrong result with some data layouts. The issue is that they assume that if the skcipher_walk API gives 'nbytes' not aligned to the walksize (a.k.a. walk.stride), then it is the end of the data. In fact, this can happen before the end. Fix them. Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD implementations") Cc: # v4.18+ Cc: Ondrej Mosnacek Signed-off-by: Eric Biggers Reviewed-by: Ondrej Mosnacek Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 650b7246d4606306a9b780468e1e9f3a9b262f27 Author: Eric Biggers Date: Sun Jan 6 18:47:44 2019 -0800 crypto: aead - set CRYPTO_TFM_NEED_KEY if ->setkey() fails commit 6ebc97006b196aafa9df0497fdfa866cf26f259b upstream. Some algorithms have a ->setkey() method that is not atomic, in the sense that setting a key can fail after changes were already made to the tfm context. In this case, if a key was already set the tfm can end up in a state that corresponds to neither the old key nor the new key. For example, in gcm.c, if the kzalloc() fails due to lack of memory, then the CTR part of GCM will have the new key but GHASH will not. It's not feasible to make all ->setkey() methods atomic, especially ones that have to key multiple sub-tfms. Therefore, make the crypto API set CRYPTO_TFM_NEED_KEY if ->setkey() fails, to prevent the tfm from being used until a new key is set. [Cc stable mainly because when introducing the NEED_KEY flag I changed AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG previously didn't have this problem. So these "incompletely keyed" states became theoretically accessible via AF_ALG -- though, the opportunities for causing real mischief seem pretty limited.] Fixes: dc26c17f743a ("crypto: aead - prevent using AEADs without setting key") Cc: # v4.16+ Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 781bcac5b19943d4275e5ddc113b468c880e0eb7 Author: Al Viro Date: Sun Jan 6 11:41:29 2019 -0500 fix cgroup_do_mount() handling of failure exits commit 399504e21a10be16dd1408ba0147367d9d82a10c upstream. same story as with last May fixes in sysfs (7b745a4e4051 "unfuck sysfs_mount()"); new_sb is left uninitialized in case of early errors in kernfs_mount_ns() and papering over it by treating any error from kernfs_mount_ns() as equivalent to !new_ns ends up conflating the cases when objects had never been transferred to a superblock with ones when that has happened and resulting new superblock had been dropped. Easily fixed (same way as in sysfs case). Additionally, there's a superblock leak on kernfs_node_dentry() failure *and* a dentry leak inside kernfs_node_dentry() itself - the latter on probably impossible errors, but the former not impossible to trigger (as the matter of fact, injecting allocation failures at that point *does* trigger it). Cc: stable@kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 2ac714d69197f48fb87208c6994284075dcdb4fd Author: Oliver O'Halloran Date: Wed Feb 6 13:04:53 2019 +1100 libnvdimm: Fix altmap reservation size calculation commit 07464e88365e9236febaca9ed1a2e2006d8bc952 upstream. Libnvdimm reserves the first 8K of pfn and devicedax namespaces to store a superblock describing the namespace. This 8K reservation is contained within the altmap area which the kernel uses for the vmemmap backing for the pages within the namespace. The altmap allows for some pages at the start of the altmap area to be reserved and that mechanism is used to protect the superblock from being re-used as vmemmap backing. The number of PFNs to reserve is calculated using: PHYS_PFN(SZ_8K) Which is implemented as: #define PHYS_PFN(x) ((unsigned long)((x) >> PAGE_SHIFT)) So on systems where PAGE_SIZE is greater than 8K the reservation size is truncated to zero and the superblock area is re-used as vmemmap backing. As a result all the namespace information stored in the superblock (i.e. if it's a PFN or DAX namespace) is lost and the namespace needs to be re-created to get access to the contents. This patch fixes this by using PFN_UP() rather than PHYS_PFN() to ensure that at least one page is reserved. On systems with a 4K pages size this patch should have no effect. Cc: stable@vger.kernel.org Cc: Dan Williams Fixes: ac515c084be9 ("libnvdimm, pmem, pfn: move pfn setup to the core") Signed-off-by: Oliver O'Halloran Reviewed-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit fefd9f16efc31418c2d9de99f5ca6a48b36ce679 Author: Dan Williams Date: Thu Jan 24 17:33:06 2019 -0800 libnvdimm/pmem: Honor force_raw for legacy pmem regions commit fa7d2e639cd90442d868dfc6ca1d4cc9d8bf206e upstream. For recovery, where non-dax access is needed to a given physical address range, and testing, allow the 'force_raw' attribute to override the default establishment of a dev_pagemap. Otherwise without this capability it is possible to end up with a namespace that can not be activated due to corrupted info-block, and one that can not be repaired due to a section collision. Cc: Fixes: 004f1afbe199 ("libnvdimm, pmem: direct map legacy pmem by default") Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 4b9d1f8b61e8a8a5228fd76fddf0e9dfdfb3a797 Author: Wei Yang Date: Tue Jan 22 10:48:09 2019 +0800 libnvdimm, pfn: Fix over-trim in trim_pfn_device() commit f101ada7da6551127d192c2f1742c1e9e0f62799 upstream. When trying to see whether current nd_region intersects with others, trim_pfn_device() has already calculated the *size* to be expanded to SECTION size. Do not double append 'adjust' to 'size' when calculating whether the end of a region collides with the next pmem region. Fixes: ae86cbfef381 "libnvdimm, pfn: Pad pfn namespaces relative to other regions" Cc: Signed-off-by: Wei Yang Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit dd40489f675180171f5c14929c8424e09b68b75a Author: Dan Williams Date: Tue Jan 15 10:47:00 2019 -0800 libnvdimm/label: Clear 'updating' flag after label-set update commit 966d23a006ca7b44ac8cf4d0c96b19785e0c3da0 upstream. The UEFI 2.7 specification sets expectations that the 'updating' flag is eventually cleared. To date, the libnvdimm core has never adhered to that protocol. The policy of the core matches the policy of other multi-device info-block formats like MD-Software-RAID that expect administrator intervention on inconsistent info-blocks, not automatic invalidation. However, some pre-boot environments may unfortunately attempt to "clean up" the labels and invalidate a set when it fails to find at least one "non-updating" label in the set. Clear the updating flag after set updates to minimize the window of vulnerability to aggressive pre-boot environments. Ideally implementations would not write to the label area outside of creating namespaces. Note that this only minimizes the window, it does not close it as the system can still crash while clearing the flag and the set can be subsequently deleted / invalidated by the pre-boot environment. Fixes: f524bf271a5c ("libnvdimm: write pmem label set") Cc: Cc: Kelly Couch Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 5fa9cb709adc46b52c25a45d919563b02c8fca6e Author: Dan Williams Date: Wed Feb 13 09:01:13 2019 -0800 nfit/ars: Attempt short-ARS even in the no_init_ars case commit fa3ed4d981b1fc19acdd07fcb152a4bd3706892b upstream. The no_init_ars option is meant to prevent long-ARS, but short-ARS should be allowed to grab any immediate results. Fixes: bc6ba8085842 ("nfit, address-range-scrub: rework and simplify ARS...") Cc: Reported-by: Erwin Tsaur Reviewed-by: Toshi Kani Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit b3971c932d0d10f95c8d7c9e972276c3319941de Author: Dan Williams Date: Wed Feb 13 08:58:40 2019 -0800 nfit/ars: Attempt a short-ARS whenever the ARS state is idle at boot commit c6c5df293bf1b488cf8459aac658aecfdccb13a9 upstream. If query-ARS reports that ARS has stopped and requires continuation attempt to retrieve short-ARS results before continuing the long operation. Fixes: bc6ba8085842 ("nfit, address-range-scrub: rework and simplify ARS...") Cc: Reported-by: Krzysztof Rusocki Reviewed-by: Toshi Kani Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 0c79794474895dbbc3c52225f7e9f73cfecbb7dd Author: Dan Williams Date: Thu Feb 7 14:56:50 2019 -0800 acpi/nfit: Fix bus command validation commit ebe9f6f19d80d8978d16078dff3d5bd93ad8d102 upstream. Commit 11189c1089da "acpi/nfit: Fix command-supported detection" broke ND_CMD_CALL for bus-level commands. The "func = cmd" assumption is only valid for: ND_CMD_ARS_CAP ND_CMD_ARS_START ND_CMD_ARS_STATUS ND_CMD_CLEAR_ERROR The function number otherwise needs to be pulled from the command payload for: NFIT_CMD_TRANSLATE_SPA NFIT_CMD_ARS_INJECT_SET NFIT_CMD_ARS_INJECT_CLEAR NFIT_CMD_ARS_INJECT_GET Update cmd_to_func() for the bus case and call it in the common path. Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection") Cc: Reviewed-by: Vishal Verma Reported-by: Grzegorz Burzynski Tested-by: Jeff Moyer Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit a2690301c9762c5c26c33fbd93002384b30be15b Author: Dexuan Cui Date: Wed Jan 30 01:23:01 2019 +0000 nfit: acpi_nfit_ctl(): Check out_obj->type in the right place commit 43f89877f26671c6309cd87d7364b1a3e66e71cf upstream. In the case of ND_CMD_CALL, we should also check out_obj->type. The patch uses out_obj->type, which is a short alias to out_obj->package.type. Fixes: 31eca76ba2fc ("nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism") Cc: Signed-off-by: Dexuan Cui Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 59a0e57f0cd3cfb5afc815247b0c8b9c9977d55d Author: Dan Williams Date: Tue Jan 29 22:06:41 2019 -0800 nfit: Fix nfit_intel_shutdown_status() command submission commit f596c8844fe1d0022007ae6c7a377361fb653eff upstream. The implementation is broken in all the ways the unit test did not touch: 1/ The local definition of in_buf and in_obj violated C99 initializer expectations for zeroing. By only initializing 2 out of the three struct members the compiler was free to zero-initialize the remaining entry even though the aliased location in the union was initialized. 2/ The implementation made assumptions about the state of the 'smart' payload after command execution that are satisfied by acpi_nfit_ctl(), but not acpi_evaluate_dsm(). 3/ populate_shutdown_status() is skipped on Intel NVDIMMs due to the early return for skipping the common _LS{I,R,W} enabling. 4/ The input length should be zero. This breakage was missed due to the unit test implementation only testing the case where nfit_intel_shutdown_status() returns a valid payload. Much of this complexity would be saved if acpi_nfit_ctl() could be used, but that currently requires a 'struct nvdimm *' argument and one is not created until later in the init process. The health result is needed before the device is created because the payload gates whether the nmemX/nfit/dirty_shutdown property is visible in sysfs. Cc: Fixes: 0ead11181fe0 ("acpi, nfit: Collect shutdown status") Reported-by: Dexuan Cui Reviewed-by: Dexuan Cui Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 9cd805133b844a965570723bacb88595b0a62615 Author: Matthew Wilcox Date: Fri Mar 1 11:12:41 2019 -0800 dax: Flush partial PMDs correctly commit e4b3448bc346fedf36db64124a664a959995b085 upstream. The radix tree would rewind the index in an iterator to the lowest index of a multi-slot entry. The XArray iterators instead leave the index unchanged, but I overlooked that when converting DAX from the radix tree to the XArray. Adjust the index that we use for flushing to the start of the PMD range. Fixes: c1901cd33cf4 ("page cache: Convert find_get_entries_tag to XArray") Cc: Reported-by: Piotr Balcer Tested-by: Dan Williams Reviewed-by: Jan Kara Signed-off-by: Matthew Wilcox Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit c2ca8161971a964531b4afe23a1a236bcec16022 Author: Zhang Zhijie Date: Wed Feb 13 16:24:39 2019 +0800 crypto: rockchip - update new iv to device in multiple operations commit c1c214adcb56d36433480c8fedf772498e7e539c upstream. For chain mode in cipher(eg. AES-CBC/DES-CBC), the iv is continuously updated in the operation. The new iv value should be written to device register by software. Reported-by: Eric Biggers Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288") Cc: # v4.5+ Signed-off-by: Zhang Zhijie Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e400988e1daef9f38aaf6cfe3d9d4491b43d79f2 Author: Zhang Zhijie Date: Wed Feb 13 16:24:38 2019 +0800 crypto: rockchip - fix scatterlist nents error commit 4359669a087633132203c52d67dd8c31e09e7b2e upstream. In some cases, the nents of src scatterlist is different from dst scatterlist. So two variables are used to handle the nents of src&dst scatterlist. Reported-by: Eric Biggers Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288") Cc: # v4.5+ Signed-off-by: Zhang Zhijie Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 20af3634022b2abda46f8b2c8e06a9154c878bd2 Author: Eric Biggers Date: Thu Jan 31 23:51:41 2019 -0800 crypto: ahash - fix another early termination in hash walk commit 77568e535af7c4f97eaef1e555bf0af83772456c upstream. Hash algorithms with an alignmask set, e.g. "xcbc(aes-aesni)" and "michael_mic", fail the improved hash tests because they sometimes produce the wrong digest. The bug is that in the case where a scatterlist element crosses pages, not all the data is actually hashed because the scatterlist walk terminates too early. This happens because the 'nbytes' variable in crypto_hash_walk_done() is assigned the number of bytes remaining in the page, then later interpreted as the number of bytes remaining in the scatterlist element. Fix it. Fixes: 900a081f6912 ("crypto: ahash - Fix early termination in hash walk") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit b03aa2833d567ad2b6985dde425e5e7f0978cc7f Author: Eric Biggers Date: Thu Jan 3 20:16:12 2019 -0800 crypto: ofb - fix handling partial blocks and make thread-safe commit b3e3e2db7de4a1ffe8845876c3520b866cd48de1 upstream. Fix multiple bugs in the OFB implementation: 1. It stored the per-request state 'cnt' in the tfm context, which can be used by multiple threads concurrently (e.g. via AF_ALG). 2. It didn't support messages not a multiple of the block cipher size, despite being a stream cipher. 3. It didn't set cra_blocksize to 1 to indicate it is a stream cipher. To fix these, set the 'chunksize' property to the cipher block size to guarantee that when walking through the scatterlist, a partial block can only occur at the end. Then change the implementation to XOR a block at a time at first, then XOR the partial block at the end if needed. This is the same way CTR and CFB are implemented. As a bonus, this also improves performance in most cases over the current approach. Fixes: e497c51896b3 ("crypto: ofb - add output feedback mode") Cc: # v4.20+ Cc: Gilad Ben-Yossef Signed-off-by: Eric Biggers Reviewed-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5d894501d42350021f28e2df2fe68394a0e96c3e Author: Eric Biggers Date: Thu Jan 3 20:16:11 2019 -0800 crypto: cfb - remove bogus memcpy() with src == dest commit 6c2e322b3621dc8be72e5c86d4fdb587434ba625 upstream. The memcpy() in crypto_cfb_decrypt_inplace() uses walk->iv as both the source and destination, which has undefined behavior. It is unneeded because walk->iv is already used to hold the previous ciphertext block; thus, walk->iv is already updated to its final value. So, remove it. Also, note that in-place decryption is the only case where the previous ciphertext block is not directly available. Therefore, as a related cleanup I also updated crypto_cfb_encrypt_segment() to directly use the previous ciphertext block rather than save it into walk->iv. This makes it consistent with in-place encryption and out-of-place decryption; now only in-place decryption is different, because it has to be. Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack mode") Cc: # v4.17+ Cc: James Bottomley Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 64ae3c3d0c16817d2b89c5140dac76e06890ded1 Author: Eric Biggers Date: Thu Jan 3 20:16:10 2019 -0800 crypto: cfb - add missing 'chunksize' property commit 394a9e044702e6a8958a5e89d2a291605a587a2a upstream. Like some other block cipher mode implementations, the CFB implementation assumes that while walking through the scatterlist, a partial block does not occur until the end. But the walk is incorrectly being done with a blocksize of 1, as 'cra_blocksize' is set to 1 (since CFB is a stream cipher) but no 'chunksize' is set. This bug causes incorrect encryption/decryption for some scatterlist layouts. Fix it by setting the 'chunksize'. Also extend the CFB test vectors to cover this bug as well as cases where the message length is not a multiple of the block size. Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack mode") Cc: # v4.17+ Cc: James Bottomley Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ded8d6308ffd691475fe2c80e7ff4f3aa3979a99 Author: Gilad Ben-Yossef Date: Tue Jan 15 15:43:17 2019 +0200 crypto: ccree - don't copy zero size ciphertext commit 2b5ac17463dcb2411fed506edcf259a89bb538ba upstream. For decryption in CBC mode we need to save the last ciphertext block for use as the next IV. However, we were trying to do this also with zero sized ciphertext resulting in a panic. Fix this by only doing the copy if the ciphertext length is at least of IV size. Signed-off-by: Gilad Ben-Yossef Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4fc9f0e1c9ffe9ae6dd8591055be95c5fc176996 Author: Gilad Ben-Yossef Date: Tue Jan 15 15:43:15 2019 +0200 crypto: ccree - unmap buffer before copying IV commit c139c72e2beb3e3db5148910b3962b7322e24374 upstream. We were copying the last ciphertext block into the IV field for CBC before removing the DMA mapping of the output buffer with the result of the buffer sometime being out-of-sync cache wise and were getting intermittent cases of bad output IV. Fix it by moving the DMA buffer unmapping before the copy. Signed-off-by: Gilad Ben-Yossef Fixes: 00904aa0cd59 ("crypto: ccree - fix iv handling") Cc: Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 37ff06fd9cb5dd7dbf401a321d0cd3658e918a63 Author: Hadar Gat Date: Tue Jan 15 15:43:13 2019 +0200 crypto: ccree - fix free of unallocated mlli buffer commit a49411959ea6d4915a9fd2a7eb5ba220e6284e9a upstream. In cc_unmap_aead_request(), call dma_pool_free() for mlli buffer only if an item is allocated from the pool and not always if there is a pool allocated. This fixes a kernel panic when trying to free a non-allocated item. Cc: stable@vger.kernel.org Signed-off-by: Hadar Gat Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6e905e258c50b32fdda68dff8a7686b8d2636ce7 Author: Horia Geantă Date: Sat Jan 26 20:02:15 2019 +0200 crypto: caam - fix DMA mapping of stack memory commit c19650d6ea99bcd903d3e55dd61860026c701339 upstream. Roland reports the following issue and provides a root cause analysis: "On a v4.19 i.MX6 system with IMA and CONFIG_DMA_API_DEBUG enabled, a warning is generated when accessing files on a filesystem for which IMA measurement is enabled: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:1181 check_for_stack.part.9+0xd0/0x120 caam_jr 2101000.jr0: DMA-API: device driver maps memory from stack [addr=b668049e] Modules linked in: CPU: 0 PID: 1 Comm: switch_root Not tainted 4.19.0-20181214-1 #2 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [] (dump_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0xa0/0xcc) [] (dump_stack) from [] (__warn+0xf0/0x108) [] (__warn) from [] (warn_slowpath_fmt+0x58/0x74) [] (warn_slowpath_fmt) from [] (check_for_stack.part.9+0xd0/0x120) [] (check_for_stack.part.9) from [] (debug_dma_map_page+0x144/0x174) [] (debug_dma_map_page) from [] (ahash_final_ctx+0x5b4/0xcf0) [] (ahash_final_ctx) from [] (ahash_final+0x1c/0x20) [] (ahash_final) from [] (crypto_ahash_op+0x38/0x80) [] (crypto_ahash_op) from [] (crypto_ahash_final+0x20/0x24) [] (crypto_ahash_final) from [] (ima_calc_file_hash+0x29c/0xa40) [] (ima_calc_file_hash) from [] (ima_collect_measurement+0x1dc/0x240) [] (ima_collect_measurement) from [] (process_measurement+0x4c4/0x6b8) [] (process_measurement) from [] (ima_file_check+0x88/0xa4) [] (ima_file_check) from [] (path_openat+0x5d8/0x1364) [] (path_openat) from [] (do_filp_open+0x84/0xf0) [] (do_filp_open) from [] (do_open_execat+0x84/0x1b0) [] (do_open_execat) from [] (__do_execve_file+0x43c/0x890) [] (__do_execve_file) from [] (sys_execve+0x44/0x4c) [] (sys_execve) from [] (ret_fast_syscall+0x0/0x28) ---[ end trace 3455789a10e3aefd ]--- The cause is that the struct ahash_request *req is created as a stack-local variable up in the stack (presumably somewhere in the IMA implementation), then passed down into the CAAM driver, which tries to dma_single_map the req->result (indirectly via map_seq_out_ptr_result) in order to make that buffer available for the CAAM to store the result of the following hash operation. The calling code doesn't know how req will be used by the CAAM driver, and there could be other such occurrences where stack memory is passed down to the CAAM driver. Therefore we should rather fix this issue in the CAAM driver where the requirements are known." Fix this problem by: -instructing the crypto engine to write the final hash in state->caam_ctx -subsequently memcpy-ing the final hash into req->result Cc: # v4.19+ Reported-by: Roland Hieber Signed-off-by: Horia Geantă Tested-by: Roland Hieber Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e86dc780320e586fb1a30536f2b017fc7a4beb9c Author: Pankaj Gupta Date: Fri Feb 1 07:18:20 2019 +0000 crypto: caam - fixed handling of sg list commit 42e95d1f10dcf8b18b1d7f52f7068985b3dc5b79 upstream. when the source sg contains more than 1 fragment and destination sg contains 1 fragment, the caam driver mishandle the buffers to be sent to caam. Fixes: f2147b88b2b1 ("crypto: caam - Convert GCM to new AEAD interface") Cc: # 4.2+ Signed-off-by: Pankaj Gupta Signed-off-by: Arun Pathak Reviewed-by: Horia Geanta Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4a18213573b811d1910964dae36c3b3c358c0ba2 Author: Gustavo A. R. Silva Date: Mon Feb 11 12:31:31 2019 -0600 crypto: ccree - fix missing break in switch statement commit b5be853181a8d4a6e20f2073ccd273d6280cad88 upstream. Add missing break statement in order to prevent the code from falling through to case S_DIN_to_DES. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit fce3d391401a0fd25955a02a4a4577c7eae85aeb Author: Franck LENORMAND Date: Tue Feb 19 16:56:55 2019 +0200 crypto: caam - fix hash context DMA unmap size commit 65055e2108847af5e577cc7ce6bde45ea136d29a upstream. When driver started using state->caam_ctxt for storing both running hash and final hash, it was not updated to handle different DMA unmap lengths. Cc: # v4.19+ Fixes: c19650d6ea99 ("crypto: caam - fix DMA mapping of stack memory") Signed-off-by: Franck LENORMAND Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9b2fdbdce1fb6774cd234b64b854e9090f4d6ba9 Author: Zhi Jin Date: Thu Sep 6 15:22:10 2018 +0800 stm class: Fix an endless loop in channel allocation commit a1d75dad3a2c689e70a1c4e0214cca9de741d0aa upstream. There is a bug in the channel allocation logic that leads to an endless loop when looking for a contiguous range of channels in a range with a mixture of free and occupied channels. For example, opening three consequtive channels, closing the first two and requesting 4 channels in a row will trigger this soft lockup. The bug is that the search loop forgets to skip over the range once it detects that one channel in that range is occupied. Restore the original intent to the logic by fixing the omission. Signed-off-by: Zhi Jin Signed-off-by: Alexander Shishkin Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices") CC: stable@vger.kernel.org # v4.4+ Signed-off-by: Greg Kroah-Hartman commit 2adb36ff325d889e7771c90fdbc413a811873b2d Author: Alexander Shishkin Date: Thu Feb 21 14:19:17 2019 +0200 stm class: Prevent division by zero commit bf7cbaae0831252b416f375ca9b1027ecd4642dd upstream. Using STP_POLICY_ID_SET ioctl command with dummy_stm device, or any STM device that supplies zero mmio channel size, will trigger a division by zero bug in the kernel. Prevent this by disallowing channel widths other than 1 for such devices. Signed-off-by: Alexander Shishkin Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices") CC: stable@vger.kernel.org # v4.4+ Signed-off-by: Greg Kroah-Hartman commit 1cfec56130907b513d01d04688859d39f9563b2c Author: Alexander Usyskin Date: Mon Feb 25 11:09:28 2019 +0200 mei: bus: move hw module get/put to probe/release commit b5958faa34e2f99f3475ad89c52d98dfea079d33 upstream. Fix unbalanced module reference counting during internal reset, which prevents the drivers unloading. Tracking mei_me/txe modules on mei client bus via mei_cldev_enable/disable is error prone due to possible internal reset flow, where clients are disconnected underneath. Moving reference counting to probe and release of mei bus client driver solves this issue in simplest way, as each client provides only a single connection to a client bus driver. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 55ced4559dbf812384a8e0dc74b6f33866e132b1 Author: Alexander Usyskin Date: Wed Feb 20 16:55:37 2019 +0200 mei: hbm: clean the feature flags on link reset commit 37fd0b623023484ef6df79ed46f21f06ecc611ff upstream. The list of supported functions can be altered upon link reset, clean the flags to allow correct selections of supported features. Cc: v4.19+ Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit f644d56fe1d7e8f264c2d86c0eebcfa84883b071 Author: Krzysztof Kozlowski Date: Tue Feb 12 18:45:49 2019 +0100 iio: adc: exynos-adc: Use proper number of channels for Exynos4x12 commit 103cda6a3b8d2c10d5f8cd7abad118e9db8f4776 upstream. Exynos4212 and Exynos4412 have only four ADC channels so using "samsung,exynos-adc-v1" compatible (for eight channels ADCv1) on them is wrong. Add a new compatible for Exynos4x12. Signed-off-by: Krzysztof Kozlowski Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a52251155bab8c569bf697f1eb23302e61fd2beb Author: Krzysztof Kozlowski Date: Sat Feb 9 00:39:27 2019 +0100 iio: adc: exynos-adc: Fix NULL pointer exception on unbind commit 2ea8bab4dd2a9014e723b28091831fa850b82d83 upstream. Fix NULL pointer exception on device unbind when device tree does not contain "has-touchscreen" property. In such case the input device is not registered so it should not be unregistered. $ echo "12d10000.adc" > /sys/bus/platform/drivers/exynos-adc/unbind Unable to handle kernel NULL pointer dereference at virtual address 00000474 ... (input_unregister_device) from [] (exynos_adc_remove+0x20/0x80) (exynos_adc_remove) from [] (platform_drv_remove+0x20/0x40) (platform_drv_remove) from [] (device_release_driver_internal+0xdc/0x1ac) (device_release_driver_internal) from [] (unbind_store+0x60/0xd4) (unbind_store) from [] (kernfs_fop_write+0x100/0x1e0) (kernfs_fop_write) from [] (__vfs_write+0x2c/0x17c) (__vfs_write) from [] (vfs_write+0xa4/0x184) (vfs_write) from [] (ksys_write+0x4c/0xac) (ksys_write) from [] (ret_fast_syscall+0x0/0x28) Fixes: 2bb8ad9b44c5 ("iio: exynos-adc: add experimental touchscreen support") Cc: Signed-off-by: Krzysztof Kozlowski Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 61328520e0b65bf409845e8e00ee1d691a1ca27c Author: Codrin Ciubotariu Date: Tue Feb 19 16:29:28 2019 +0000 ASoC: codecs: pcm186x: Fix energysense SLEEP bit commit 05bd7fcdd06b19a10f069af1bea3ad9abac038d7 upstream. The ADCs are sleeping when the SLEEP bit is set and running when it's cleared, so the bit should be inverted. Tested on pcm1863. Signed-off-by: Codrin Ciubotariu Acked-by: Andrew F. Davis Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5bd4f972e594b381b8d185e734216f5557d4527a Author: Codrin Ciubotariu Date: Tue Feb 19 16:29:12 2019 +0000 ASoC: codecs: pcm186x: fix wrong usage of DECLARE_TLV_DB_SCALE() commit fcf4daabf08079e6d09958a2992e7446ef8d0438 upstream. According to DS, the gain is between -12 dB and 40 dB, with a 0.5 dB step. Tested on pcm1863. Signed-off-by: Codrin Ciubotariu Acked-by: Andrew F. Davis Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a7abca8506b56002a2d168764eaf05ffa3ac22ef Author: S.j. Wang Date: Mon Feb 18 08:29:11 2019 +0000 ASoC: fsl_esai: fix register setting issue in RIGHT_J mode commit cc29ea007347f39f4c5a4d27b0b555955a0277f9 upstream. The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to wrong register, correct it. Fixes 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Cc: Signed-off-by: Shengjiu Wang Reviewed-by: Fabio Estevam Ackedy-by: Nicolin Chen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5ababa4e34db899d8947474df6139641d5347794 Author: zhengbin Date: Wed Mar 13 16:01:37 2019 +0800 9p/net: fix memory leak in p9_client_create commit bb06c388fa20ae24cfe80c52488de718a7e3a53f upstream. If msize is less than 4096, we should close and put trans, destroy tagpool, not just free client. This patch fixes that. Link: http://lkml.kernel.org/m/1552464097-142659-1-git-send-email-zhengbin13@huawei.com Cc: stable@vger.kernel.org Fixes: 574d356b7a02 ("9p/net: put a lower bound on msize") Reported-by: Hulk Robot Signed-off-by: zhengbin Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 3cccba9a38d5119c48eebf60e1071b60c457591f Author: Hou Tao Date: Thu Jan 24 14:35:13 2019 +0800 9p: use inode->i_lock to protect i_size_write() under 32-bit commit 5e3cc1ee1405a7eb3487ed24f786dec01b4cbe1f upstream. Use inode->i_lock to protect i_size_write(), else i_size_read() in generic_fillattr() may loop infinitely in read_seqcount_begin() when multiple processes invoke v9fs_vfs_getattr() or v9fs_vfs_getattr_dotl() simultaneously under 32-bit SMP environment, and a soft lockup will be triggered as show below: watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [stat:2217] Modules linked in: CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e #4 Hardware name: Generic DT based system PC is at generic_fillattr+0x104/0x108 LR is at 0xec497f00 pc : [<802b8898>] lr : [] psr: 200c0013 sp : ec497e20 ip : ed608030 fp : ec497e3c r10: 00000000 r9 : ec497f00 r8 : ed608030 r7 : ec497ebc r6 : ec497f00 r5 : ee5c1550 r4 : ee005780 r3 : 0000052d r2 : 00000000 r1 : ec497f00 r0 : ed608030 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: ac48006a DAC: 00000051 CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e #4 Hardware name: Generic DT based system Backtrace: [<8010d974>] (dump_backtrace) from [<8010dc88>] (show_stack+0x20/0x24) [<8010dc68>] (show_stack) from [<80a1d194>] (dump_stack+0xb0/0xdc) [<80a1d0e4>] (dump_stack) from [<80109f34>] (show_regs+0x1c/0x20) [<80109f18>] (show_regs) from [<801d0a80>] (watchdog_timer_fn+0x280/0x2f8) [<801d0800>] (watchdog_timer_fn) from [<80198658>] (__hrtimer_run_queues+0x18c/0x380) [<801984cc>] (__hrtimer_run_queues) from [<80198e60>] (hrtimer_run_queues+0xb8/0xf0) [<80198da8>] (hrtimer_run_queues) from [<801973e8>] (run_local_timers+0x28/0x64) [<801973c0>] (run_local_timers) from [<80197460>] (update_process_times+0x3c/0x6c) [<80197424>] (update_process_times) from [<801ab2b8>] (tick_nohz_handler+0xe0/0x1bc) [<801ab1d8>] (tick_nohz_handler) from [<80843050>] (arch_timer_handler_virt+0x38/0x48) [<80843018>] (arch_timer_handler_virt) from [<80180a64>] (handle_percpu_devid_irq+0x8c/0x240) [<801809d8>] (handle_percpu_devid_irq) from [<8017ac20>] (generic_handle_irq+0x34/0x44) [<8017abec>] (generic_handle_irq) from [<8017b344>] (__handle_domain_irq+0x6c/0xc4) [<8017b2d8>] (__handle_domain_irq) from [<801022e0>] (gic_handle_irq+0x4c/0x88) [<80102294>] (gic_handle_irq) from [<80101a30>] (__irq_svc+0x70/0x98) [<802b8794>] (generic_fillattr) from [<8056b284>] (v9fs_vfs_getattr_dotl+0x74/0xa4) [<8056b210>] (v9fs_vfs_getattr_dotl) from [<802b8904>] (vfs_getattr_nosec+0x68/0x7c) [<802b889c>] (vfs_getattr_nosec) from [<802b895c>] (vfs_getattr+0x44/0x48) [<802b8918>] (vfs_getattr) from [<802b8a74>] (vfs_statx+0x9c/0xec) [<802b89d8>] (vfs_statx) from [<802b9428>] (sys_lstat64+0x48/0x78) [<802b93e0>] (sys_lstat64) from [<80101000>] (ret_fast_syscall+0x0/0x28) [dominique.martinet@cea.fr: updated comment to not refer to a function in another subsystem] Link: http://lkml.kernel.org/r/20190124063514.8571-2-houtao1@huawei.com Cc: stable@vger.kernel.org Fixes: 7549ae3e81cc ("9p: Use the i_size_[read, write]() macros instead of using inode->i_size directly.") Reported-by: Xing Gaopeng Signed-off-by: Hou Tao Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman