commit c8cd75e69bb5419052f50e6ae1daa9e30c59a221 Author: Alexandre Frade Date: Sun Sep 16 11:03:40 2018 -0300 4.18.8-xanmod5 Signed-off-by: Alexandre Frade commit 5b6c7607e9d071697014f40671562e556e950d5c Merge: dbbcd7b38e7d dfba61ec760e Author: Alexandre Frade Date: Sun Sep 16 10:52:41 2018 -0300 Merge tag 'v4.18.8' into 4.18 This is the 4.18.8 stable release commit dfba61ec760efc578a3f3702e752b51ca1dfed52 Author: Greg Kroah-Hartman Date: Sat Sep 15 09:47:02 2018 +0200 Linux 4.18.8 commit d27f3eb84d52c11051882137f91201ffacfa7895 Author: Gustavo A. R. Silva Date: Mon Aug 6 07:14:51 2018 -0500 ASoC: wm8994: Fix missing break in switch commit ad0eaee6195db1db1749dd46b9e6f4466793d178 upstream. Add missing break statement in order to prevent the code from falling through to the default case. Addresses-Coverity-ID: 115050 ("Missing break in switch") Reported-by: Valdis Kletnieks Signed-off-by: Gustavo A. R. Silva Acked-by: Charles Keepax Signed-off-by: Mark Brown Cc: stable@vger.kernel.org [Gustavo: Backported to 3.16..4.18 - Remove code comment removal] Signed-off-by: Gustavo A. R. Silva Signed-off-by: Greg Kroah-Hartman commit e496c9a4c17d4a97ed8d222f368f3b8ad8133fb9 Author: Robert Munteanu Date: Tue Jun 19 11:20:40 2018 +0300 HID: redragon: fix num lock and caps lock LEDs commit dc9b8e85ed95cbe7e3ad0eabb5b48d617bbc365e upstream. The redragon asura keyboard registers two input devices. The initial commit 85455dd906d5 ("HID: redragon: Fix modifier keys for Redragon Asura Keyboard") considered this an error and prevented one of the devices from registering. However, once this is done the num lock and caps lock leds no longer toggle on and off, although the key functionality is not affected. This commit removes the code that prevents the input device registration and restores the num lock and caps lock LEDs. Fixes: 85455dd906d5 ("HID: redragon: Fix modifier keys for Redragon Asura Keyboard") Signed-off-by: Robert Munteanu Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 838ddbf08cc724778431c927aa0f8c2c2ad4501e Author: Arnd Bergmann Date: Mon Aug 20 23:37:50 2018 +0200 x86: kvm: avoid unused variable warning commit 7288bde1f9df6c1475675419bdd7725ce84dec56 upstream. Removing one of the two accesses of the maxphyaddr variable led to a harmless warning: arch/x86/kvm/x86.c: In function 'kvm_set_mmio_spte_mask': arch/x86/kvm/x86.c:6563:6: error: unused variable 'maxphyaddr' [-Werror=unused-variable] Removing the #ifdef seems to be the nicest workaround, as it makes the code look cleaner than adding another #ifdef. Fixes: 28a1f3ac1d0c ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs") Signed-off-by: Arnd Bergmann Cc: stable@vger.kernel.org # L1TF Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d9b47449c1a17be65332e07c1e8acba0f8b27e10 Author: Junaid Shahid Date: Tue Aug 14 10:15:34 2018 -0700 kvm: x86: Set highest physical address bits in non-present/reserved SPTEs commit 28a1f3ac1d0c8558ee4453d9634dad891a6e922e upstream. Always set the 5 upper-most supported physical address bits to 1 for SPTEs that are marked as non-present or reserved, to make them unusable for L1TF attacks from the guest. Currently, this just applies to MMIO SPTEs. (We do not need to mark PTEs that are completely 0 as physical page 0 is already reserved.) This allows mitigation of L1TF without disabling hyper-threading by using shadow paging mode instead of EPT. Signed-off-by: Junaid Shahid Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f9acfbec6652b971930e9423894d33c85230e8ac Author: Randy Dunlap Date: Tue Aug 28 12:59:10 2018 -0700 kbuild: make missing $DEPMOD a Warning instead of an Error commit 914b087ff9e0e9a399a4927fa30793064afc0178 upstream. When $DEPMOD is not found, only print a warning instead of exiting with an error message and error status: Warning: 'make modules_install' requires /sbin/depmod. Please install it. This is probably in the kmod package. Change the Error to a Warning because "not all build hosts for cross compiling Linux are Linux systems and are able to provide a working port of depmod, especially at the file patch /sbin/depmod." I.e., "make modules_install" may be used to copy/install the loadable modules files to a target directory on a build system and then transferred to an embedded device where /sbin/depmod is run instead of it being run on the build system. Fixes: 934193a654c1 ("kbuild: verify that $DEPMOD is installed") Signed-off-by: Randy Dunlap Reported-by: H. Nikolaus Schaller Cc: stable@vger.kernel.org Cc: Lucas De Marchi Cc: Lucas De Marchi Cc: Michal Marek Cc: Jessica Yu Cc: Chih-Wei Huang Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 30566a3520bb5d5010782519b3efa70eb231c42f Author: Juergen Gross Date: Tue Aug 21 17:37:54 2018 +0200 x86/xen: don't write ptes directly in 32-bit PV guests commit f7c90c2aa4004808dff777ba6ae2c7294dd06851 upstream. In some cases 32-bit PAE PV guests still write PTEs directly instead of using hypercalls. This is especially bad when clearing a PTE as this is done via 32-bit writes which will produce intermediate L1TF attackable PTEs. Change the code to use hypercalls instead. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 22b734b0c850139bb0cd31dcaa37cde7f00ccbd6 Author: Juergen Gross Date: Tue Aug 21 17:37:55 2018 +0200 x86/pae: use 64 bit atomic xchg function in native_ptep_get_and_clear commit b2d7a075a1ccef2fb321d595802190c8e9b39004 upstream. Using only 32-bit writes for the pte will result in an intermediate L1TF vulnerable PTE. When running as a Xen PV guest this will at once switch the guest to shadow mode resulting in a loss of performance. Use arch_atomic64_xchg() instead which will perform the requested operation atomically with all 64 bits. Some performance considerations according to: https://software.intel.com/sites/default/files/managed/ad/dc/Intel-Xeon-Scalable-Processor-throughput-latency.pdf The main number should be the latency, as there is no tight loop around native_ptep_get_and_clear(). "lock cmpxchg8b" has a latency of 20 cycles, while "lock xchg" (with a memory operand) isn't mentioned in that document. "lock xadd" (with xadd having 3 cycles less latency than xchg) has a latency of 11, so we can assume a latency of 14 for "lock xchg". Signed-off-by: Juergen Gross Reviewed-by: Thomas Gleixner Reviewed-by: Jan Beulich Tested-by: Jason Andryuk Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 9fdac01484509f597f0256c94c745bb1a52e315f Author: Joel Fernandes (Google) Date: Mon Jul 23 14:25:31 2018 -0700 debugobjects: Make stack check warning more informative commit fc91a3c4c27acdca0bc13af6fbb68c35cfd519f2 upstream. While debugging an issue debugobject tracking warned about an annotation issue of an object on stack. It turned out that the issue was due to the object in concern being on a different stack which was due to another issue. Thomas suggested to print the pointers and the location of the stack for the currently running task. This helped to figure out that the object was on the wrong stack. As this is general useful information for debugging similar issues, make the error message more informative by printing the pointers. [ tglx: Massaged changelog ] Signed-off-by: Joel Fernandes (Google) Signed-off-by: Thomas Gleixner Acked-by: Waiman Long Acked-by: Yang Shi Cc: kernel-team@android.com Cc: Arnd Bergmann Cc: astrachan@google.com Link: https://lkml.kernel.org/r/20180723212531.202328-1-joel@joelfernandes.org Signed-off-by: Greg Kroah-Hartman commit 977f362a1f7bd1ef2c5cb092444055b376bc4b6e Author: Michel Dänzer Date: Thu Jul 19 17:38:18 2018 +0200 drm/amdgpu: Don't warn on destroying a pinned BO commit 456607d816d89a442a3d5ec98b02c8bc950b5228 upstream. The warning turned out to be not so useful, as BO destruction tends to be deferred to a workqueue. Also, we should be preventing any damage from this now, so not really important anymore to fix code doing this. Acked-by: Alex Deucher Tested-by: Mike Lothian Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ff9ac76caaee4a814a2834a13281c1004d82ad76 Author: Michel Dänzer Date: Wed Jul 11 12:42:55 2018 +0200 drm/amdgpu: Warn and update pin_size values when destroying a pinned BO commit 15e6b76880e65be24250e30986084b5569b7a06f upstream. This shouldn't happen, but if it does, we'll get a backtrace of the caller, and update the pin_size values as needed. v2: * Check bo->pin_count instead of placement flags (Christian König) Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e2a81121f62a6c7886040f799105307bc9b535fa Author: Michel Dänzer Date: Wed Jul 11 12:00:40 2018 +0200 drm/amdgpu: Make pin_size values atomic commit a5ccfe5c20740f2fbf00291490cdf8d2373ec255 upstream. Concurrent execution of the non-atomic arithmetic could result in completely bogus values. v2: * Rebased on v2 of the previous patch Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/106872 Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit df058ec846fe1fc520e41a254b3fa22765255fbb Author: Michel Dänzer Date: Wed Jul 11 12:06:31 2018 +0200 drm/amdgpu: Keep track of amount of pinned CPU visible VRAM commit ddc21af4d0f37f42b33c54cb69b215997fe5b082 upstream. Instead of CPU invisible VRAM. Preparation for the following, no functional change intended. v2: * Also change amdgpu_vram_mgr_bo_invisible_size to amdgpu_vram_mgr_bo_visible_size, allowing further simplification (Christian König) Cc: stable@vger.kernel.org Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit dd458c42c28a36f76df001f5643ef8323ce9b28f Author: Chuanhua Lei Date: Thu Sep 6 18:03:23 2018 +0800 x86/tsc: Prevent result truncation on 32bit commit 17f6bac2249356c795339e03a0742cd79be3cab8 upstream. Loops per jiffy is calculated by multiplying tsc_khz with 1e3 and then dividing it by HZ. Both tsc_khz and the temporary variable holding the multiplication result are of type unsigned long, so on 32bit the result is truncated to the lower 32bit. Use u64 as type for the temporary variable and cast tsc_khz to it before multiplying. [ tglx: Massaged changelog and removed pointless braces ] [ tglx: Backport to stable. Due to massive code changes is the upstream commit not applicable anymore. The issue has gone unnoticed in kernels pre 4.19 because the bogus LPJ value gets fixed up in a later stage of early boot, but it still might cause subtle and hard to debug issues between these two points. ] Fixes: cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once") Signed-off-by: Chuanhua Lei Signed-off-by: Thomas Gleixner Cc: yixin.zhu@linux.intel.com Cc: "H. Peter Anvin" Cc: Peter Zijlstra Cc: Len Brown Cc: Pavel Tatashin Cc: Rajvi Jingar Cc: Dou Liyang Link: https://lkml.kernel.org/r/1536228203-18701-1-git-send-email-chuanhua.lei@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 009a091aae1c538f54bd7bdd1c3dc82def2845d7 Author: Jani Nikula Date: Tue Aug 14 09:00:01 2018 +0300 drm/i915: set DP Main Stream Attribute for color range on DDI platforms commit 6209c285e7a5e68dbcdf8fd2456c6dd68433806b upstream. Since Haswell we have no color range indication either in the pipe or port registers for DP. Instead, there's a separate register for setting the DP Main Stream Attributes (MSA) directly. The MSA register definition makes no references to colorimetry, just a vague reference to the DP spec. The connection to the color range was lost. Apparently we've failed to set the proper MSA bit for limited, or CEA, range ever since the first DDI platforms. We've started setting other MSA parameters since commit dae847991a43 ("drm/i915: add intel_ddi_set_pipe_settings"). Without the crucial bit of information, the DP sink has no way of knowing the source is actually transmitting limited range RGB, leading to "washed out" colors. With the colorimetry information, compliant sinks should be able to handle the limited range properly. Native (i.e. non-LSPCON) HDMI was not affected because we do pass the color range via AVI infoframes. Though not the root cause, the problem was made worse for DDI platforms with commit 55bc60db5988 ("drm/i915: Add "Automatic" mode for the "Broadcast RGB" property"), which selects limited range RGB automatically based on the mode, as per the DP, HDMI and CEA specs. After all these years, the fix boils down to flipping one bit. [Per testing reports, this fixes DP sinks, but not the LSPCON. My educated guess is that the LSPCON fails to turn the CEA range MSA into AVI infoframes for HDMI.] Reported-by: Michał Kopeć Reported-by: N. W. Reported-by: Nicholas Stommel Reported-by: Tom Yan Tested-by: Nicholas Stommel References: https://bugs.freedesktop.org/show_bug.cgi?id=100023 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921 Cc: Paulo Zanoni Cc: Rodrigo Vivi Cc: Ville Syrjälä Cc: # v3.9+ Reviewed-by: Rodrigo Vivi Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com (cherry picked from commit dc5977da99ea28094b8fa4e9bacbd29bedc41de5) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 7a5d47d5faa3003ad1fbfc16c71122ab17f45c16 Author: Nadav Amit Date: Tue Sep 4 15:45:41 2018 -0700 mm: respect arch_dup_mmap() return value commit 1ed0cc5a01a4d868d9907ce96468c4b4c6709556 upstream. Commit d70f2a14b72a ("include/linux/sched/mm.h: uninline mmdrop_async(), etc") ignored the return value of arch_dup_mmap(). As a result, on x86, a failure to duplicate the LDT (e.g. due to memory allocation error) would leave the duplicated memory mapping in an inconsistent state. Fix by using the return value, as it was before the change. Link: http://lkml.kernel.org/r/20180823051229.211856-1-namit@vmware.com Fixes: d70f2a14b72a4 ("include/linux/sched/mm.h: uninline mmdrop_async(), etc") Signed-off-by: Nadav Amit Acked-by: Michal Hocko Cc: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds commit 153fedc6ba3251609158302b379478c0d7bbee66 Author: Randy Dunlap Date: Tue Sep 4 15:46:13 2018 -0700 uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name commit 8a2336e549d385bb0b46880435b411df8d8200e8 upstream. Since this header is in "include/uapi/linux/", apparently people want to use it in userspace programs -- even in C++ ones. However, the header uses a C++ reserved keyword ("private"), so change that to "dh_private" instead to allow the header file to be used in C++ userspace. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=191051 Link: http://lkml.kernel.org/r/0db6c314-1ef4-9bfa-1baa-7214dd2ee061@infradead.org Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command") Signed-off-by: Randy Dunlap Reviewed-by: Andrew Morton Cc: David Howells Cc: James Morris Cc: "Serge E. Hallyn" Cc: Mat Martineau Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 97cdbf04a0528967adfaf12888667192998ebebe Author: Jan-Marek Glogowski Date: Sat Aug 25 15:10:35 2018 -0400 drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse" commit 399334708b4f07b107094e5db4a390f0f25d2d4f upstream. This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147bb939 ("drm/i915: Perform link quality check unconditionally during long pulse"). It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again. This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by: Lyude Paul Signed-off-by: Jan-Marek Glogowski Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-lyude@redhat.com (cherry picked from commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 15ca3cf67c1872f6d0de9fe8588ec754b30b29ef Author: Christian König Date: Fri Aug 17 19:38:33 2018 +0200 drm/amdgpu: fix incorrect use of drm_file->pid commit c4aed87630d41ee54e2ee23d4583c3dd423296dd upstream. That's the PID of the creator of the file (usually the X server) and not the end user of the file. Signed-off-by: Christian König Acked-by: Alex Deucher Signed-off-by: Alex Deucher CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dd4a6ffb5bc1a36776bc4de1b3dc72cc31f48be6 Author: Christian König Date: Fri Aug 17 19:36:08 2018 +0200 drm/amdgpu: fix incorrect use of fcheck commit bce31d4c1ae8865d6382e3a27b07b4bb8e020ade upstream. The usage isn't RCU protected. Signed-off-by: Christian König Acked-by: Alex Deucher Signed-off-by: Alex Deucher CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0d34ba1b3d33c9366e5e471de6bde921d12c3f08 Author: Likun Gao Date: Fri Aug 10 00:31:42 2018 +0800 drm/amdgpu:add VCN booting with firmware loaded by PSP commit 4d77c0f676e910fb1f1870738aa4bd168f253621 upstream. Setup psp firmware loading for VCN, and make VCN block booting from tmr mac address. Signed-off-by: James Zhu Reviewed-by: Alex Deucher Acked-by: Huang Rui Reviewed-by: Likun Gao Signed-off-by: Likun Gao Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e765455ea299677437022a7ea7872a5ed806d80e Author: Likun Gao Date: Fri Aug 10 00:31:41 2018 +0800 drm/amdgpu:add VCN support in PSP driver commit 235ac9de625a0a586093ad81b3de6f7d7ab913ed upstream. Add VCN support in PSP driver Signed-off-by: James Zhu Reviewed-by: Alex Deucher Acked-by: Huang Rui Reviewed-by: Likun Gao Signed-off-by: Likun Gao Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 56c8d038c465daf5ef53d1c63cace0f1e80ab312 Author: Likun Gao Date: Fri Aug 10 00:31:40 2018 +0800 drm/amdgpu:add new firmware id for VCN commit c9ca989696ff28ffb015cc2b7c5577938ef2626c upstream. Add the new firmware id for VCN into the enum Signed-off-by: James Zhu Reviewed-by: Alex Deucher Acked-by: Huang Rui Reviewed-by: Likun Gao Signed-off-by: Likun Gao Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 467fce24d1373b5eafeef30fc0ef71ff244af8ac Author: James Zhu Date: Fri Aug 10 00:31:38 2018 +0800 drm/amdgpu:add tmr mc address into amdgpu_firmware_info commit abf412b3efb2f943d9b98a489e9aca836be21333 upstream. amdgpu IP blocks booting need Trust Memory Region(tmr) mc address of its firmware which is loaded by PSP Signed-off-by: James Zhu Reviewed-by: Alex Deucher Acked-by: Huang Rui Reviewed-by: Likun Gao Signed-off-by: Likun Gao Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9eba3ada1217f90d45840949d1bc91b4afccadf1 Author: James Zhu Date: Fri Aug 10 00:31:39 2018 +0800 drm/amdgpu: update tmr mc address commit 435198f33b56d7b875a8173a0227ddf0de285aa1 upstream. Update tmr mc address with firmware loading address which is returned from PSP firmware Signed-off-by: James Zhu Reviewed-by: Alex Deucher Acked-by: Huang Rui Reviewed-by: Likun Gao Signed-off-by: Likun Gao Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1e7e7a541e0812df95ebeb73828118a88283a35d Author: Mikita Lipski Date: Thu Aug 2 09:45:09 2018 -0400 drm/amd/display: Check if clock source in use before disabling commit ad8960a6cb06c446d0a391ce095f6f28edf36aff upstream. [why] We are disabling clock source while other pipes are still using it, because we don't verify the number of pipes that share it. [how] - Adding a function in resources to return the number of pipes sharing the clock source. - Checking that no one is sharing the clock source before disabling Signed-off-by: Mikita Lipski Reviewed-by: Harry Wentland Acked-by: Leo Li Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dfe84b71296f6d28a60038287d5159ca0f177f06 Author: Mikita Lipski Date: Tue Jul 17 10:52:19 2018 -0400 drm/amd/display: Pass connector id when executing VBIOS CT commit 433149130c31de3f63b17b4ce08b45dab208f7e8 upstream. [why] Older ASICs require both phys_id and connector_id to execute bios command table. If we are not passing the right connector_id - it can lead to a black screen. [how] Set connector_obj_id when executing vbios command table Signed-off-by: Mikita Lipski Reviewed-by: Hersen Wu Acked-by: Leo Li Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 433009dc1b81b7125202194021dc1b4e44e7a77c Author: Sandy Huang Date: Tue Jun 12 15:20:28 2018 +0200 drm/rockchip: vop: fix irq disabled after vop driver probed commit 6456314ff1de246414a43e3132075b70b3e050ac upstream. The vop irq is shared between vop and iommu and irq probing in the iommu driver moved to the probe function recently. This can in some cases lead to a stall if the irq is triggered while the vop driver still has it disabled, but the vop irq handler gets called. But there is no real need to disable the irq, as the vop can simply also track its enabled state and ignore irqs in that case. For this we can simply check the power-domain state of the vop, similar to how the iommu driver does it. So remove the enable/disable handling and add appropriate condition to the irq handler. changes in v2: - move to just check the power-domain state - add clock handling changes in v3: - clarify comment to speak of runtime-pm not power-domain changes in v4: - address Marc's comments (clk-enable WARN_ON and style improvement) Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()") Cc: stable@vger.kernel.org Signed-off-by: Sandy Huang Signed-off-by: Heiko Stuebner Tested-by: Ezequiel Garcia Reviewed-by: Tomasz Figa Reviewed-by: Marc Zyngier Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-3-heiko@sntech.de Signed-off-by: Greg Kroah-Hartman commit 5e1f742d4bbba95ae577ca805b8279e894bb149c Author: Heiko Stuebner Date: Tue Jun 12 15:20:27 2018 +0200 drm/rockchip: vop: split out core clock enablement into separate functions commit e2810a7167df14c762e085fae5aade38425b71bf upstream. Judging from the iommu code, both the hclk and aclk are necessary for register access. Split them off into separate functions from the regular vop enablement, so that we can use them elsewhere as well. Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()") [prerequisite change for the actual fix] Cc: stable@vger.kernel.org Signed-off-by: Heiko Stuebner Tested-by: Ezequiel Garcia Reviewed-by: Tomasz Figa Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-2-heiko@sntech.de Signed-off-by: Greg Kroah-Hartman commit 2781b277d5892fb3b2aad4dd741c07dab387c58d Author: Julia Lawall Date: Wed May 23 21:07:16 2018 +0200 drm/rockchip: lvds: add missing of_node_put commit ebfb081edc8afd250a6d290c37481bfb2262e7cb upstream. The device node iterators perform an of_node_get on each iteration, so a jump out of the loop requires an of_node_put. The semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // @@ expression root,e; local idexpression child; iterator name for_each_child_of_node; @@ for_each_child_of_node(root, child) { ... when != of_node_put(child) when != e = child + of_node_put(child); ? break; ... } ... when != child // Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Cc: stable@vger.kernel.org Signed-off-by: Julia Lawall Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/1527102436-13447-6-git-send-email-Julia.Lawall@lip6.fr Signed-off-by: Greg Kroah-Hartman commit 590eda32ee4291e3862c607f69711192a6612b03 Author: Harry Wentland Date: Wed Aug 1 10:48:23 2018 -0400 drm/amd/display: Report non-DP display as disconnected without EDID commit 01dc285d5cd89b77686d8baef8482c58d7dc3ead upstream. [Why] Some boards seem to have a problem where HPD is high on HDMI even though no display is connected. We don't want to report these as connected. DP spec still requires us to report DP displays as connected when HPD is high but we can't read the EDID in order to go to fail-safe mode. [How] If connector_signal is not DP abort detection if we can't retrieve the EDID. v2: Add Bugzilla and stable Bugzilla: https://bugs.freedesktop.org/107390 Bugzilla: https://bugs.freedesktop.org/106846 Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland Acked-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 823057fc0a2c088bcbecfaac933a131e93385b75 Author: Leo (Sunpeng) Li Date: Thu Jul 19 08:22:16 2018 -0400 drm/amd/display: Use requested HDMI aspect ratio commit e11d41472a50742c16d53c968e143fb498fa482f upstream. [Why] The DRM mode's HDMI picture aspect ratio field was never saved in dc_stream's timing struct. This causes us to mistake a new stream to have the same timings as the old, even though the user has requested a different aspect ratio. [How] Save DRM's aspect ratio field within dc_stream's timing struct. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107153 Signed-off-by: Leo (Sunpeng) Li Reviewed-by: Mikita Lipski Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 691f2d763d0731224439686ecf2d440df8fe910e Author: Mikita Lipski Date: Fri Jul 13 09:07:35 2018 -0400 drm/amd/display: update clk for various HDMI color depths commit 81aca8e75c1b046865fb2badef95a0dcff6f73de upstream. [why] When programming tonga's connector's backend we didn't take in account that HDMI's colour depth might be more than 8bpc therefore we need to add a switch statement that would adjust the pixel clock accordingly. [how] Add a switch statement updating clock by its appropriate coefficient. Signed-off-by: Mikita Lipski Reviewed-by: Charlene Liu Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b31d6596d7d2eae01c9b65f6cfbf889c2a60f4a6 Author: Mikita Lipski Date: Thu Jul 12 16:44:05 2018 -0400 drm/amd/display: Don't share clk source between DP and HDMI commit 3e27e10e2ecee0d3a0083f8ae76354ac9c6ad15c upstream. [why] Prevent clock source sharing between HDMI and DP connectors. DP shouldn't be sharing its ref clock with phy clock, which caused an issue of older ASICS booting up with multiple diplays plugged in. [how] Add an extra check that would prevent HDMI and DP sharing clk. Signed-off-by: Mikita Lipski Reviewed-by: Hersen Wu Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a74410c9d4e4344f63bf7783ab5ca2eb90f1a053 Author: Gustavo A. R. Silva Date: Fri Jun 15 08:32:28 2018 -0500 drm/amd/display: fix type of variable commit fe78627d430435d22316fe39f2012ece31bf23c2 upstream. Currently, the maximum value that *counter* can reach is 255, and code at line 150: while (counter < 1000) { implies a bigger value could be expected. Fix this by changing the type of variable *counter* from uint8_t to uint16_t. Addresses-Coverity-ID: 1470030 ("Operands don't affect result") Fixes: 2b6199a1d1b7 ("drm/amd/display: replace msleep with udelay in fbc path") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 401a86f7321694346e3fbb3ceb16056c492a7b3b Author: Kai-Heng Feng Date: Thu Aug 23 05:53:32 2018 +0000 drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80 commit 25da75043f8690fd083878447c91f289dfb63b87 upstream. Another panel that reports "DFP 1.x compliant TMDS" but it supports 6bpc instead of 8 bpc. Apply 6 bpc quirk for the panel to fix it. BugLink: https://bugs.launchpad.net/bugs/1788308 Cc: # v4.8+ Signed-off-by: Kai-Heng Feng Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180823055332.7723-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman commit fd0f192ab66c1b53c73ceefc8d3237943be3dbb4 Author: Lubosz Sarnecki Date: Tue May 29 13:52:15 2018 +0200 drm/edid: Quirk Vive Pro VR headset non-desktop. commit 6931317c714885f2d792e8150ef6715d416ac681 upstream. This adds the Vive Pro's EDID information and sets EDID_QUIRK_NON_DESKTOP. Signed-off-by: Lubosz Sarnecki Signed-off-by: Daniel Stone Reviewed-by: Daniel Stone Cc: # v4.15+ Link: https://patchwork.freedesktop.org/patch/msgid/20180529115215.4526-1-lubosz.sarnecki@collabora.com Signed-off-by: Greg Kroah-Hartman commit ef78d745f0fd38cb3e4f5f0bf9aeaca322e5a83c Author: Rex Zhu Date: Fri Jul 20 16:26:46 2018 +0800 drm/amd/pp/Polaris12: Fix a chunk of registers missed to program commit 2d227ec2c11c568910299e8f913bac2dda47397c upstream. DIDTConfig_Polaris12[] table missed a big chunk of data. Pointed by aidan.fabius Reviewed-by: Alex Deucher Signed-off-by: Rex Zhu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e327748100363bc9c36cce2b4ab357cadf2c8ee2 Author: Evan Quan Date: Thu Jul 19 13:21:43 2018 +0800 drm/amd/powerplay: fixed uninitialized value commit 1ce0688f3f6a9e9d34ae66bf779d54855def7bec upstream. The 'result' is not initialized correctly. It causes the API return an error code even on success. Signed-off-by: Evan Quan Acked-by: Huang Rui Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8ec9ca91819ff879323a00e2c0dba886c26926e3 Author: Rex Zhu Date: Wed Jul 25 11:45:03 2018 +0800 drm/amd/pp: Convert voltage unit in mV*4 to mV on CZ/ST commit 8a50bb47a863c3cb8950a2e810448c9a82a9d446 upstream. the voltage showed in debugfs and hwmon should be in mV Reviewed-by: Evan Quan Acked-by: Alex Deucher Signed-off-by: Rex Zhu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4c518d5abdf415fc2a6038e537edb76ee9c73dda Author: Michel Dänzer Date: Thu Jul 19 18:33:39 2018 +0200 drm/amdgpu: Fix RLC safe mode test in gfx_v9_0_enter_rlc_safe_mode commit 226127a67e31a9518d9516d3e4890759b379d874 upstream. We were testing the register offset, instead of the value stored in the register, therefore always timing out the loop. This reduces suspend time of the system in the bug report below by ~600 ms. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/107277 Tested-by: Paul Menzel Reviewed-by: Alex Deucher Reviewed-by: Junwei Zhang Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 7acffde7a949cd8bb08fd550faae519140c8a609 Author: Rex Zhu Date: Wed Jul 25 11:51:46 2018 +0800 drm/amdgpu: fix a reversed condition commit ccf9ef0b0d10434dec5046bcfc4e834a7b1830fd upstream. This test was reversed so it would end up leading to vddnb value can't be read via hwmon on APU. Reviewed-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Rex Zhu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c8fe7d36e49b333f4db60c7a9ba6ba17e6c9e35e Author: Alex Deucher Date: Thu Jun 28 12:32:27 2018 -0500 drm/amdgpu: update uvd_v6_0_ring_vm_funcs to use new nop packet commit afb1436c7b44ab928e6369a4d48e3abb8215241e upstream. Was missed when updating the uvd 6 module. Fixes: 1aac3c9180 (drm/amdgpu: fix insert nop for UVD6 ring) Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7ddb29b09517a8b923944d556fbf7df0055cddff Author: Rodrigo Vivi Date: Thu Aug 23 13:51:36 2018 -0700 drm/i915: Free write_buf that we allocated with kzalloc. commit 1b1b1162745e5f9e5c6c095afc8081df3edabc50 upstream. We use kzalloc to allocate the write_buf that we use for i2c transfer on hdcp write. But it seems that we are forgetting to free the memory that is not needed after i2c transfer is completed. Reported-by: Brian J Wood Fixes: 2320175feb74 ("drm/i915: Implement HDCP for HDMI") Cc: Ramalingam C Cc: Sean Paul Cc: Jani Nikula Cc: Rodrigo Vivi Cc: # v4.17+ Signed-off-by: Rodrigo Vivi Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20180823205136.31310-1-rodrigo.vivi@intel.com (cherry picked from commit 62d3a8deaa10b8346d979d0dabde56c33b742afa) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 087ed76cb538a93ce9b99652c724a8d1334bced7 Author: Fredrik Schön Date: Fri Aug 17 22:07:28 2018 +0200 drm/i915: Increase LSPCON timeout commit 299c2a904b1e8d5096d4813df6371357d97a6cd1 upstream. 100 ms is not enough time for the LSPCON adapter on Intel NUC devices to settle. This causes dropped display modes at boot or screen reconfiguration. Empirical testing can reproduce the error up to a timeout of 190 ms. Basic boot and stress testing at 200 ms has not (yet) failed. Increase timeout to 400 ms to get some margin of error. Changes from v1: The initial suggestion of 1000 ms was lowered due to concerns about delaying valid timeout cases. Update patch metadata. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107503 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392 Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to settle") Cc: Shashank Sharma Cc: Imre Deak Cc: Jani Nikula Cc: # v4.11+ Reviewed-by: Rodrigo Vivi Reviewed-by: Shashank Sharma Signed-off-by: Fredrik Schön Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20180817200728.8154-1-fredrik.schon@gmail.com (cherry picked from commit 59f1c8ab30d6f9042562949f42cbd3f3cf69de94) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit cfc7d9e0064b32db7b77ee0110a7d90d81a370c4 Author: Ville Syrjälä Date: Tue Jul 17 20:42:14 2018 +0300 drm/i915: Nuke the LVDS lid notifier commit 05c72e77ccda89ff624108b1b59a0fc43843f343 upstream. We broke the LVDS notifier resume thing in (presumably) commit e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") as we no longer duplicate the current state in the LVDS notifier and thus we never resume it properly either. Instead of trying to fix it again let's just kill off the lid notifier entirely. None of the machines tested thus far have apparently needed it. Originally the lid notifier was added to work around cases where the VBIOS was clobbering some of the hardware state behind the driver's back, mostly on Thinkpads. We now have a few report of Thinkpads working just fine without the notifier. So maybe it was misdiagnosed originally, or something else has changed (ACPI video stuff perhaps?). If we do end up finding a machine where the VBIOS is still causing problems I would suggest that we first try setting various bits in the VBIOS scratch registers. There are several to choose from that may instruct the VBIOS to steer clear. With the notifier gone we'll also stop looking at the panel status in ->detect(). v2: Nuke enum modeset_restore (Rodrigo) Cc: stable@vger.kernel.org Cc: Wolfgang Draxinger Cc: Vito Caputo Cc: kitsunyan Cc: Joonas Saarinen Tested-by: Vito Caputo # Thinkapd X61s Tested-by: kitsunyan # ThinkPad X200 Tested-by: Joonas Saarinen # Fujitsu Siemens U9210 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105902 References: https://lists.freedesktop.org/archives/intel-gfx/2018-June/169315.html References: https://bugs.freedesktop.org/show_bug.cgi?id=21230 Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit a23feb39586aa7725dd0fe8c58fa41f7ff324004 Author: Chris Wilson Date: Thu Aug 2 15:04:16 2018 +0100 drm/i915/lpe: Mark LPE audio runtime pm as "no callbacks" commit 75eef0f1ed478284911b8723a5bdb659499a7aac upstream. The LPE audio is a child device of i915, it is powered up and down alongside the igfx and presents no independent runtime interface. This aptly fulfils the description of a "No-Callback" Device, so mark it thus. Fixes: 183c00350ccd ("drm/i915: Fix runtime PM for LPE audio") Testcase: igt/pm_rpm/basic-pci-d3-state Testcase: igt/pm_rpm/basic-rte Signed-off-by: Chris Wilson Cc: Takashi Iwai Cc: Pierre-Louis Bossart Cc: Ville Syrjälä Cc: stable@vger.kernel.org Reviewed-by: Joonas Lahtinen Link: https://patchwork.freedesktop.org/patch/msgid/20180802140416.6062-1-chris@chris-wilson.co.uk (cherry picked from commit 46e831abe864a6b59fa3de253a681c0f2ee1bf2f) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 760d0077abc1d7730639767e712908c12f511741 Author: David Sterba Date: Tue Jun 19 18:04:07 2018 +0200 btrfs: fix mount and ioctl device scan ioctl race [ Upstream commit 81ffd56b5745355b70d54ca4e1bdd0d64a66ff9f ] Technically this extends the critical section covered by uuid_mutex to: - parse early mount options -- here we can call device scan on paths that can be passed as 'device=/dev/...' - scan the device passed to mount - open the devices related to the fs_devices -- this increases fs_devices::opened The race can happen when mount calls one of the scans and there's another one called eg. by mkfs or 'btrfs dev scan': Mount Scan ----- ---- scan_one_device (dev1, fsid1) scan_one_device (dev2, fsid1) add the device free stale devices fsid1 fs_devices::opened == 0 find fsid1:dev1 free fsid1:dev1 if it's the last one, free fs_devices of fsid1 too open_devices (dev1, fsid1) dev1 not found When fixed, the uuid mutex will make sure that mount will increase fs_devices::opened and this will not be touched by the racing scan ioctl. Reported-and-tested-by: syzbot+909a5177749d7990ffa4@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+ceb2606025ec1cc3479c@syzkaller.appspotmail.com Reviewed-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 49db06e7f366c26a71dd3589617b43c3110be649 Author: David Sterba Date: Tue Jun 19 18:01:24 2018 +0200 btrfs: reorder initialization before the mount locks uuid_mutex [ Upstream commit 399f7f4c42e8a58c8456264d5112287aefe44cf4 ] In preparation to take a big lock, move resource initialization before the critical section. It's not obvious from the diff, the desired order is: - initialize mount security options - allocate temporary fs_info - allocate superblock buffers Reviewed-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1ef9a3009ba9df130ebf932de96455f357edaed0 Author: David Sterba Date: Tue Jun 19 17:50:25 2018 +0200 btrfs: lift uuid_mutex to callers of btrfs_parse_early_options [ Upstream commit 5139cff598d42b1e531f40c84691a7e945f04553 ] Prepartory work to fix race between mount and device scan. btrfs_parse_early_options calls the device scan from mount and we'll need to let mount completely manage the critical section. Reviewed-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 71ddab54bee5c571647fd5ed9bb9be9db305f7c1 Author: David Sterba Date: Tue Jun 19 16:37:36 2018 +0200 btrfs: lift uuid_mutex to callers of btrfs_scan_one_device [ Upstream commit 899f9307c33ce4758c30a076b10ed54d5c91c6e7 ] Prepartory work to fix race between mount and device scan. The callers will have to manage the critical section, eg. mount wants to scan and then call btrfs_open_devices without the ioctl scan walking in and modifying the fs devices in the meantime. Reviewed-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 40ce21951aab62b8cdd6d2b852154d6fe9f11163 Author: Anand Jain Date: Tue May 29 17:23:20 2018 +0800 btrfs: use device_list_mutex when removing stale devices [ Upstream commit 7bcb8164ad9435068d9bc3b83b8a002c64d63ff6 ] btrfs_free_stale_devices() finds a stale (not opened) device matching path in the fs_uuid list. We are already under uuid_mutex so when we check for each fs_devices, hold the device_list_mutex too. Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b57a7b0d4122033fba58c60f0560cdf9004fbf88 Author: Anand Jain Date: Tue May 29 15:33:08 2018 +0800 btrfs: rename local devices for fs_devices in btrfs_free_stale_devices( [ Upstream commit fa6d2ae540a200a17bb7ee769f9df22d411c9404 ] Over the years we named %fs_devices and %devices to represent the struct btrfs_fs_devices and the struct btrfs_device. So follow the same scheme here too. No functional changes. Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0b40d58d469f3e78ec644b3a0ada4295e596e190 Author: Anand Jain Date: Tue May 29 14:10:20 2018 +0800 btrfs: extend locked section when adding a new device in device_list_add [ Upstream commit 9c6d173ea6e4c8c939ae6c257c7fc18f7b320316 ] Make sure the device_list_lock is held the whole time: * when the device is being looked up * new device is initialized and put to the list * the list counters are updated (fs_devices::opened, fs_devices::total_devices) Signed-off-by: Anand Jain [ update changelog ] Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2d4bbb81bac654db2d5e66887d0a3be704aab060 Author: Anand Jain Date: Tue May 29 12:28:37 2018 +0800 btrfs: do btrfs_free_stale_devices outside of device_list_add [ Upstream commit 4306a97449f9a0f9e5229af7889d4401315355aa ] btrfs_free_stale_devices() looks for device path reused for another filesystem, and deletes the older fs_devices::device entry. In preparation to handle locking in device_list_add, move btrfs_free_stale_devices outside as these two functions serve a different purpose. Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8515518d6365f19bc40ef6f8b690145c641cb4eb Author: Marc Zyngier Date: Fri Aug 24 16:06:34 2018 +0100 ARM: rockchip: Force CONFIG_PM on Rockchip systems [ Upstream commit d1558dfd9f22c99a5b8e1354ad881ee40749da89 ] A number of the Rockchip-specific drivers (IOMMU, display controllers) are now assuming that CONFIG_PM is set, and may completely misbehave if that's not the case. Since there is hardly any reason for this configuration option not to be selected anyway, let's require it (in the same way Tegra already does). Signed-off-by: Marc Zyngier Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c4e3acea0ebc79ed3b8d9c3e30a9d68275f16cee Author: Marc Zyngier Date: Fri Aug 24 16:06:35 2018 +0100 arm64: rockchip: Force CONFIG_PM on Rockchip systems [ Upstream commit 7db7a8f5638a2ffe0c0c0d55b5186b6191fd6af7 ] A number of the Rockchip-specific drivers (IOMMU, display controllers) are now assuming that CONFIG_PM is set, and may completely misbehave if that's not the case. Since there is hardly any reason for this configuration option not to be selected anyway, let's require it (in the same way Tegra already does). Signed-off-by: Marc Zyngier Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3ffbbcafe9a5175247bf87f2d084886390247973 Author: Bart Van Assche Date: Wed Jun 20 10:03:33 2018 -0700 btrfs: Fix a C compliance issue [ Upstream commit edf57cbf2b030781885e339f32e35a470d2f8eba ] The C programming language does not allow to use preprocessor statements inside macro arguments (pr_info() is defined as a macro). Hence rework the pr_info() statement in btrfs_print_mod_info() such that it becomes compliant. This patch allows tools like sparse to analyze the BTRFS source code. Fixes: 62e855771dac ("btrfs: convert printk(KERN_* to use pr_* calls") Signed-off-by: Bart Van Assche Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c8c9b6c0716672047350d0cefcac77a39ae49102 Author: Qu Wenruo Date: Fri Jun 22 12:35:00 2018 +0800 btrfs: Don't remove block group that still has pinned down bytes [ Upstream commit 43794446548730ac8461be30bbe47d5d027d1d16 ] [BUG] Under certain KVM load and LTP tests, it is possible to hit the following calltrace if quota is enabled: BTRFS critical (device vda2): unable to find logical 8820195328 length 4096 BTRFS critical (device vda2): unable to find logical 8820195328 length 4096 WARNING: CPU: 0 PID: 49 at ../block/blk-core.c:172 blk_status_to_errno+0x1a/0x30 CPU: 0 PID: 49 Comm: kworker/u2:1 Not tainted 4.12.14-15-default #1 SLE15 (unreleased) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] task: ffff9f827b340bc0 task.stack: ffffb4f8c0304000 RIP: 0010:blk_status_to_errno+0x1a/0x30 Call Trace: submit_extent_page+0x191/0x270 [btrfs] ? btrfs_create_repair_bio+0x130/0x130 [btrfs] __do_readpage+0x2d2/0x810 [btrfs] ? btrfs_create_repair_bio+0x130/0x130 [btrfs] ? run_one_async_done+0xc0/0xc0 [btrfs] __extent_read_full_page+0xe7/0x100 [btrfs] ? run_one_async_done+0xc0/0xc0 [btrfs] read_extent_buffer_pages+0x1ab/0x2d0 [btrfs] ? run_one_async_done+0xc0/0xc0 [btrfs] btree_read_extent_buffer_pages+0x94/0xf0 [btrfs] read_tree_block+0x31/0x60 [btrfs] read_block_for_search.isra.35+0xf0/0x2e0 [btrfs] btrfs_search_slot+0x46b/0xa00 [btrfs] ? kmem_cache_alloc+0x1a8/0x510 ? btrfs_get_token_32+0x5b/0x120 [btrfs] find_parent_nodes+0x11d/0xeb0 [btrfs] ? leaf_space_used+0xb8/0xd0 [btrfs] ? btrfs_leaf_free_space+0x49/0x90 [btrfs] ? btrfs_find_all_roots_safe+0x93/0x100 [btrfs] btrfs_find_all_roots_safe+0x93/0x100 [btrfs] btrfs_find_all_roots+0x45/0x60 [btrfs] btrfs_qgroup_trace_extent_post+0x20/0x40 [btrfs] btrfs_add_delayed_data_ref+0x1a3/0x1d0 [btrfs] btrfs_alloc_reserved_file_extent+0x38/0x40 [btrfs] insert_reserved_file_extent.constprop.71+0x289/0x2e0 [btrfs] btrfs_finish_ordered_io+0x2f4/0x7f0 [btrfs] ? pick_next_task_fair+0x2cd/0x530 ? __switch_to+0x92/0x4b0 btrfs_worker_helper+0x81/0x300 [btrfs] process_one_work+0x1da/0x3f0 worker_thread+0x2b/0x3f0 ? process_one_work+0x3f0/0x3f0 kthread+0x11a/0x130 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x35/0x40 BTRFS critical (device vda2): unable to find logical 8820195328 length 16384 BTRFS: error (device vda2) in btrfs_finish_ordered_io:3023: errno=-5 IO failure BTRFS info (device vda2): forced readonly BTRFS error (device vda2): pending csums is 2887680 [CAUSE] It's caused by race with block group auto removal: - There is a meta block group X, which has only one tree block The tree block belongs to fs tree 257. - In current transaction, some operation modified fs tree 257 The tree block gets COWed, so the block group X is empty, and marked as unused, queued to be deleted. - Some workload (like fsync) wakes up cleaner_kthread() Which will call btrfs_delete_unused_bgs() to remove unused block groups. So block group X along its chunk map get removed. - Some delalloc work finished for fs tree 257 Quota needs to get the original reference of the extent, which will read tree blocks of commit root of 257. Then since the chunk map gets removed, the above warning gets triggered. [FIX] Just let btrfs_delete_unused_bgs() skip block group which still has pinned bytes. However there is a minor side effect: currently we only queue empty blocks at update_block_group(), and such empty block group with pinned bytes won't go through update_block_group() again, such block group won't be removed, until it gets new extent allocated and removed. Signed-off-by: Qu Wenruo Reviewed-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 122fe306d072fbd2e9cce5c89dc34c17da04f3ba Author: David Sterba Date: Tue Jun 19 17:09:47 2018 +0200 btrfs: lift uuid_mutex to callers of btrfs_open_devices [ Upstream commit f5194e34cabaddd348a90f950e0a8188dd26cdc0 ] Prepartory work to fix race between mount and device scan. The callers will have to manage the critical section, eg. mount wants to scan and then call btrfs_open_devices without the ioctl scan walking in and modifying the fs devices in the meantime. Reviewed-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f88b40c1472a3691a942b9e397e62d3be560ad0f Author: Qu Wenruo Date: Wed Jun 20 15:38:58 2018 +0800 btrfs: check-integrity: Fix NULL pointer dereference for degraded mount [ Upstream commit 9912bbf6440ba0555e91d3306520da01872c7c1d ] Commit f8f84b2dfda5 ("btrfs: index check-integrity state hash by a dev_t") changed how btrfsic indexes device state. Now we need to access device->bdev->bd_dev, while for degraded mount it's completely possible to have device->bdev as NULL, thus it will trigger a NULL pointer dereference at mount time. Fix it by checking if the device is degraded before accessing device->bdev->bd_dev. There are a lot of other places accessing device->bdev->bd_dev, however the other call sites have either checked device->bdev, or the device->bdev is passed from btrfsic_map_block(), so it won't cause harm. Fixes: f8f84b2dfda5 ("btrfs: index check-integrity state hash by a dev_t") Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fb2799b05c2358453eaf25c9a1352d35e13b9cf Author: Qu Wenruo Date: Tue Jul 3 17:10:06 2018 +0800 btrfs: tree-checker: Detect invalid and empty essential trees [ Upstream commit ba480dd4db9f1798541eb2d1c423fc95feee8d36 ] A crafted image has empty root tree block, which will later cause NULL pointer dereference. The following trees should never be empty: 1) Tree root Must contain at least root items for extent tree, device tree and fs tree 2) Chunk tree Or we can't even bootstrap as it contains the mapping. 3) Fs tree At least inode item for top level inode (.). 4) Device tree Dev extents for chunks 5) Extent tree Must have corresponding extent for each chunk. If any of them is empty, we are sure the fs is corrupted and no need to mount it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199847 Reported-by: Xu Wen Signed-off-by: Qu Wenruo Tested-by: Gu Jinxiang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 13b0dbef7dd51d845f17fd43fef46f356283b797 Author: Qu Wenruo Date: Tue Jul 3 17:10:07 2018 +0800 btrfs: relocation: Only remove reloc rb_trees if reloc control has been initialized [ Upstream commit 389305b2aa68723c754f88d9dbd268a400e10664 ] Invalid reloc tree can cause kernel NULL pointer dereference when btrfs does some cleanup of the reloc roots. It turns out that fs_info::reloc_ctl can be NULL in btrfs_recover_relocation() as we allocate relocation control after all reloc roots have been verified. So when we hit: note, we haven't called set_reloc_control() thus fs_info::reloc_ctl is still NULL. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199833 Reported-by: Xu Wen Signed-off-by: Qu Wenruo Tested-by: Gu Jinxiang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4c8415cf5b5a992189b922661ace9e2ab7f5fa0e Author: Anand Jain Date: Tue Jul 3 17:07:23 2018 +0800 btrfs: fix in-memory value of total_devices after seed device deletion [ Upstream commit b4993e64f78a9605b45252fa9ba385c88a1f4ce9 ] In case of deleting the seed device the %cur_devices (seed) and the %fs_devices (parent) are different. Now, as the parent fs_devices::total_devices also maintains the total number of devices including the seed device, so decrement its in-memory value for the successful seed delete. We are already updating its corresponding on-disk btrfs_super_block::number_devices value. Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 32455d96e3eedbd5912122ed799f6603b92375c5 Author: Misono Tomohiro Date: Tue Jul 31 16:20:21 2018 +0900 btrfs: replace: Reset on-disk dev stats value after replace [ Upstream commit 1e7e1f9e3aba00c9b9c323bfeeddafe69ff21ff6 ] on-disk devs stats value is updated in btrfs_run_dev_stats(), which is called during commit transaction, if device->dev_stats_ccnt is not zero. Since current replace operation does not touch dev_stats_ccnt, on-disk dev stats value is not updated. Therefore "btrfs device stats" may return old device's value after umount/mount (Example: See "btrfs ins dump-t -t DEV $DEV" after btrfs/100 finish). Fix this by just incrementing dev_stats_ccnt in btrfs_dev_replace_finishing() when replace is succeeded and this will update the values. Signed-off-by: Misono Tomohiro Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 464a90e380f29dcc7642964f9a9b86bae86fa4c4 Author: Qu Wenruo Date: Wed Aug 1 10:37:20 2018 +0800 btrfs: Exit gracefully when chunk map cannot be inserted to the tree [ Upstream commit 64f64f43c89aca1782aa672e0586f6903c5d8979 ] It's entirely possible that a crafted btrfs image contains overlapping chunks. Although we can't detect such problem by tree-checker, it's not a catastrophic problem, current extent map can already detect such problem and return -EEXIST. We just only need to exit gracefully and fail the mount. Reported-by: Xu Wen Link: https://bugzilla.kernel.org/show_bug.cgi?id=200409 Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f5cf5b0383e39f184f7bf966e72f6aac44378146 Author: Lucas Stach Date: Mon Jul 23 14:27:23 2018 +0200 drm/etnaviv: fix crash in GPU suspend when init failed due to buffer placement [ Upstream commit 5b147465532365dc4e2fee8499d6ca1f52dd0d16 ] When the suballocator was unable to provide a suitable buffer for the MMUv1 linear window, we roll back the GPU initialization. As the GPU is runtime resumed at that point we need to clear the kernel cmdbuf suballoc entry to properly skip any attempt to manipulate the cmdbuf when the GPU gets shut down in the runtime suspend later on. Signed-off-by: Lucas Stach Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc73680f9cf770785ef0f7e79a0f4c613a6ebc43 Author: Jim Mattson Date: Fri Jul 27 09:18:50 2018 -0700 kvm: nVMX: Fix fault vector for VMX operation at CPL > 0 [ Upstream commit 36090bf43a6b835a42f515cb515ff6fa293a25fe ] The fault that should be raised for a privilege level violation is #GP rather than #UD. Fixes: 727ba748e110b4 ("kvm: nVMX: Enforce cpl=0 for VMX instructions") Signed-off-by: Jim Mattson Reviewed-by: David Hildenbrand Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 68b0ce42a7f4146e03d93b8a5c59dcfd2b4e6608 Author: Sean Christopherson Date: Mon Jul 23 12:32:42 2018 -0700 KVM: vmx: track host_state.loaded using a loaded_vmcs pointer [ Upstream commit bd9966de4e14fb559e89a06f7f5c9aab2cc028b9 ] Using 'struct loaded_vmcs*' to track whether the CPU registers contain host or guest state kills two birds with one stone. 1. The (effective) boolean host_state.loaded is poorly named. It does not track whether or not host state is loaded into the CPU registers (which most readers would expect), but rather tracks if host state has been saved AND guest state is loaded. 2. Using a loaded_vmcs pointer provides a more robust framework for the optimized guest/host state switching, especially when consideration per-VMCS enhancements. To that end, WARN_ONCE if we try to switch to host state with a different VMCS than was last used to save host state. Resolve an occurrence of the new WARN by setting loaded_vmcs after the call to vmx_vcpu_put() in vmx_switch_vmcs(). Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ac5395827d489b1a9484b2474cb1dba72fb9bd98 Author: David Francis Date: Wed Jul 18 16:03:30 2018 -0400 drm/amd/display: Read back max backlight value at boot [ Upstream commit 53a53f8687faf492df2644d8c18ff0217fc18730 ] [Why] If there is no program explicitly setting the backlight brightness (for example, during a minimal install of linux), the hardware defaults to maximum brightness but the backlight_device defaults to 0 value. Thus, settings displays the wrong brightness value. [How] When creating the backlight device, set brightness to max Signed-off-by: David Francis Reviewed-by: Harry Wentland Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5bd634167f2f2f28b8c280935200df07897ad580 Author: Levin Du Date: Sat Aug 4 15:31:02 2018 +0800 clk: rockchip: Add pclk_rkpwm_pmu to PMU critical clocks in rk3399 [ Upstream commit 640332d1a089909df08bc9f3e42888a2019c66e2 ] PWM2 is commonly used to control voltage of PWM regulator of VDD_LOG in RK3399. On the Firefly-RK3399 board, PWM2 outputs 40 KHz square wave from power on and the VDD_LOG is about 0.9V. When the kernel boots normally into the system, the PWM2 keeps outputing PWM signal. But the kernel hangs randomly after "Starting kernel ..." line on that board. When it happens, PWM2 outputs high level which causes VDD_LOG drops to 0.4V below the normal operating voltage. By adding "pclk_rkpwm_pmu" to the rk3399_pmucru_critical_clocks array, PWM clock is ensured to be prepared at startup and the PWM2 output is normal. After repeated tests, the early boot hang is gone. This patch works on both Firefly-RK3399 and ROC-RK3399-PC boards. Signed-off-by: Levin Du Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 214d87aee3af055c96a6fc693ad39d0f9625e594 Author: Mahesh Salgaonkar Date: Wed Jul 4 23:27:02 2018 +0530 powerpc/pseries: Avoid using the size greater than RTAS_ERROR_LOG_MAX. [ Upstream commit 74e96bf44f430cf7a01de19ba6cf49b361cdfd6e ] The global mce data buffer that used to copy rtas error log is of 2048 (RTAS_ERROR_LOG_MAX) bytes in size. Before the copy we read extended_log_length from rtas error log header, then use max of extended_log_length and RTAS_ERROR_LOG_MAX as a size of data to be copied. Ideally the platform (phyp) will never send extended error log with size > 2048. But if that happens, then we have a risk of buffer overrun and corruption. Fix this by using min_t instead. Fixes: d368514c3097 ("powerpc: Fix corruption when grabbing FWNMI data") Reported-by: Michal Suchanek Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b070664de855025ac11ef13858189299b31871ba Author: Masahiro Yamada Date: Sat Aug 4 13:47:01 2018 +0900 um: fix parallel building with O= option [ Upstream commit 13d3d01e26b942ada7cfced68ccb6db49597874a ] Randy Dunlap reports UML occasionally fails to build with -j and O= options. make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64' UPD include/generated/uapi/linux/version.h WRAP arch/x86/include/generated/asm/dma-contiguous.h WRAP arch/x86/include/generated/asm/export.h WRAP arch/x86/include/generated/asm/early_ioremap.h WRAP arch/x86/include/generated/asm/mcs_spinlock.h WRAP arch/x86/include/generated/asm/mm-arch-hooks.h WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAP arch/x86/include/generated/uapi/asm/poll.h GEN ./Makefile make[2]: *** No rule to make target 'archheaders'. Stop. arch/um/Makefile:119: recipe for target 'archheaders' failed make[1]: *** [archheaders] Error 2 make[1]: *** Waiting for unfinished jobs.... UPD include/config/kernel.release make[1]: *** wait: No child processes. Stop. Makefile:146: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 The cause of the problem is the use of '$(MAKE) KBUILD_SRC=', which recurses to the top Makefile via the $(objtree)/Makefile generated by scripts/mkmakefile. When you run "make -j O= ARCH=um", Make can execute 'archheaders' and 'outputmakefile' targets simultaneously because there is no dependency between them. If it happens, $(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders ... tries to run $(objtree)/Makefile that is being updated. The correct way for the recursion is $(Q)$(MAKE) -f $(srctree)/Makefile ARCH=$(HEADER_ARCH) archheaders ..., which does not rely on the generated Makefile. Reported-by: Randy Dunlap Signed-off-by: Masahiro Yamada Tested-by: Randy Dunlap Acked-by: Richard Weinberger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d7e16ec6ee193d71995a7049c10528bd0ca0818c Author: Michael Ellerman Date: Thu Jul 26 22:42:44 2018 +1000 powerpc/64s: Make rfi_flush_fallback a little more robust [ Upstream commit 78ee9946371f5848ddfc88ab1a43867df8f17d83 ] Because rfi_flush_fallback runs immediately before the return to userspace it currently runs with the user r1 (stack pointer). This means if we oops in there we will report a bad kernel stack pointer in the exception entry path, eg: Bad kernel stack pointer 7ffff7150e40 at c0000000000023b4 Oops: Bad kernel stack pointer, sig: 6 [#1] LE SMP NR_CPUS=32 NUMA PowerNV Modules linked in: CPU: 0 PID: 1246 Comm: klogd Not tainted 4.18.0-rc2-gcc-7.3.1-00175-g0443f8a69ba3 #7 NIP: c0000000000023b4 LR: 0000000010053e00 CTR: 0000000000000040 REGS: c0000000fffe7d40 TRAP: 4100 Not tainted (4.18.0-rc2-gcc-7.3.1-00175-g0443f8a69ba3) MSR: 9000000002803031 CR: 44000442 XER: 20000000 CFAR: c00000000000bac8 IRQMASK: c0000000f1e66a80 GPR00: 0000000002000000 00007ffff7150e40 00007fff93a99900 0000000000000020 ... NIP [c0000000000023b4] rfi_flush_fallback+0x34/0x80 LR [0000000010053e00] 0x10053e00 Although the NIP tells us where we were, and the TRAP number tells us what happened, it would still be nicer if we could report the actual exception rather than barfing about the stack pointer. We an do that fairly simply by loading the kernel stack pointer on entry and restoring the user value before returning. That way we see a regular oops such as: Unrecoverable exception 4100 at c00000000000239c Oops: Unrecoverable exception, sig: 6 [#1] LE SMP NR_CPUS=32 NUMA PowerNV Modules linked in: CPU: 0 PID: 1251 Comm: klogd Not tainted 4.18.0-rc3-gcc-7.3.1-00097-g4ebfcac65acd-dirty #40 NIP: c00000000000239c LR: 0000000010053e00 CTR: 0000000000000040 REGS: c0000000f1e17bb0 TRAP: 4100 Not tainted (4.18.0-rc3-gcc-7.3.1-00097-g4ebfcac65acd-dirty) MSR: 9000000002803031 CR: 44000442 XER: 20000000 CFAR: c00000000000bac8 IRQMASK: 0 ... NIP [c00000000000239c] rfi_flush_fallback+0x3c/0x80 LR [0000000010053e00] 0x10053e00 Call Trace: [c0000000f1e17e30] [c00000000000b9e4] system_call+0x5c/0x70 (unreliable) Note this shouldn't make the kernel stack pointer vulnerable to a meltdown attack, because it should be flushed from the cache before we return to userspace. The user r1 value will be in the cache, because we load it in the return path, but that is harmless. Signed-off-by: Michael Ellerman Reviewed-by: Nicholas Piggin Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a4b8adb73ba1cc6f94273e8ed0df12e2ce1c98e8 Author: Randy Dunlap Date: Sun Jul 15 10:34:46 2018 -0700 powerpc/platforms/85xx: fix t1042rdb_diu.c build errors & warning [ Upstream commit f5daf77a55ef0e695cc90c440ed6503073ac5e07 ] Fix build errors and warnings in t1042rdb_diu.c by adding header files and MODULE_LICENSE(). ../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: data definition has no type or storage class early_initcall(t1042rdb_diu_init); ../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: error: type defaults to 'int' in declaration of 'early_initcall' [-Werror=implicit-int] ../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: parameter names (without types) in function declaration and WARNING: modpost: missing MODULE_LICENSE() in arch/powerpc/platforms/85xx/t1042rdb_diu.o Signed-off-by: Randy Dunlap Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Scott Wood Cc: Kumar Gala Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 813cbe22dc04e9661aca291857982448edbfa8bd Author: Steve French Date: Mon Jun 18 14:01:59 2018 -0500 smb3: if server does not support posix do not allow posix mount option [ Upstream commit 8505c8bfd85a260c9dc5c47e15bd8c5357fcbcd2 ] If user specifies "posix" on an SMB3.11 mount, then fail the mount if server does not return the POSIX negotiate context indicating support for posix. Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c2704b5e46882d7b5cf4600187523f699efd41f5 Author: Steve French Date: Mon Jul 23 09:15:18 2018 -0500 SMB3: Number of requests sent should be displayed for SMB3 not just CIFS [ Upstream commit 289131e1f1e6ad8c661ec05e176b8f0915672059 ] For SMB2/SMB3 the number of requests sent was not displayed in /proc/fs/cifs/Stats unless CONFIG_CIFS_STATS2 was enabled (only number of failed requests displayed). As with earlier dialects, we should be displaying these counters if CONFIG_CIFS_STATS is enabled. They are important for debugging. e.g. when you cat /proc/fs/cifs/Stats (before the patch) Resources in use CIFS Session: 1 Share (unique mount targets): 2 SMB Request/Response Buffer: 1 Pool size: 5 SMB Small Req/Resp Buffer: 1 Pool size: 30 Operations (MIDs): 0 0 session 0 share reconnects Total vfs operations: 690 maximum at one time: 2 1) \\localhost\test SMBs: 975 Negotiates: 0 sent 0 failed SessionSetups: 0 sent 0 failed Logoffs: 0 sent 0 failed TreeConnects: 0 sent 0 failed TreeDisconnects: 0 sent 0 failed Creates: 0 sent 2 failed Closes: 0 sent 0 failed Flushes: 0 sent 0 failed Reads: 0 sent 0 failed Writes: 0 sent 0 failed Locks: 0 sent 0 failed IOCTLs: 0 sent 1 failed Cancels: 0 sent 0 failed Echos: 0 sent 0 failed QueryDirectories: 0 sent 63 failed Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Reviewed-by: Pavel Shilovsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 31bd39126330030389dbe246060c9ce94a5ad7b3 Author: Aurelien Aptel Date: Tue Jun 19 15:18:48 2018 -0700 CIFS: fix memory leak and remove dead code [ Upstream commit 256b4c3f03d77d8c0dc69e3a6ceb3afd0d1810bd ] also fixes error code in smb311_posix_mkdir() (where the error assignment needs to go before the goto) a typo that Dan Carpenter and Paulo and Gustavo pointed out. Signed-off-by: Aurelien Aptel Signed-off-by: Dan Carpenter Signed-off-by: Gustavo A. R. Silva Reviewed-by: Paulo Alcantara Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b91052f950551a4df2447483862f0dbca72d226f Author: Steve French Date: Wed Aug 1 00:56:12 2018 -0500 smb3: fix reset of bytes read and written stats [ Upstream commit c281bc0c7412308c7ec0888904f7c99353da4796 ] echo 0 > /proc/fs/cifs/Stats is supposed to reset the stats but there were four (see example below) that were not reset (bytes read and witten, total vfs ops and max ops at one time). ... 0 session 0 share reconnects Total vfs operations: 100 maximum at one time: 2 1) \\localhost\test SMBs: 0 Bytes read: 502092 Bytes written: 31457286 TreeConnects: 0 total 0 failed TreeDisconnects: 0 total 0 failed ... This patch fixes cifs_stats_proc_write to properly reset those four. Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0cf56c159d64e14fe5c68b5b2a245f4c266ffa13 Author: Bart Van Assche Date: Tue Aug 7 16:17:29 2018 -0700 cfq: Suppress compiler warnings about comparisons [ Upstream commit f7ecb1b109da1006a08d5675debe60990e824432 ] This patch does not change any functionality but avoids that gcc reports the following warnings when building with W=1: block/cfq-iosched.c: In function ?cfq_back_seek_max_store?: block/cfq-iosched.c:4741:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] if (__data < (MIN)) \ ^ block/cfq-iosched.c:4756:1: note: in expansion of macro ?STORE_FUNCTION? STORE_FUNCTION(cfq_back_seek_max_store, &cfqd->cfq_back_max, 0, UINT_MAX, 0); ^~~~~~~~~~~~~~ block/cfq-iosched.c: In function ?cfq_slice_idle_store?: block/cfq-iosched.c:4741:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] if (__data < (MIN)) \ ^ block/cfq-iosched.c:4759:1: note: in expansion of macro ?STORE_FUNCTION? STORE_FUNCTION(cfq_slice_idle_store, &cfqd->cfq_slice_idle, 0, UINT_MAX, 1); ^~~~~~~~~~~~~~ block/cfq-iosched.c: In function ?cfq_group_idle_store?: block/cfq-iosched.c:4741:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] if (__data < (MIN)) \ ^ block/cfq-iosched.c:4760:1: note: in expansion of macro ?STORE_FUNCTION? STORE_FUNCTION(cfq_group_idle_store, &cfqd->cfq_group_idle, 0, UINT_MAX, 1); ^~~~~~~~~~~~~~ block/cfq-iosched.c: In function ?cfq_low_latency_store?: block/cfq-iosched.c:4741:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] if (__data < (MIN)) \ ^ block/cfq-iosched.c:4765:1: note: in expansion of macro ?STORE_FUNCTION? STORE_FUNCTION(cfq_low_latency_store, &cfqd->cfq_latency, 0, 1, 0); ^~~~~~~~~~~~~~ block/cfq-iosched.c: In function ?cfq_slice_idle_us_store?: block/cfq-iosched.c:4775:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] if (__data < (MIN)) \ ^ block/cfq-iosched.c:4782:1: note: in expansion of macro ?USEC_STORE_FUNCTION? USEC_STORE_FUNCTION(cfq_slice_idle_us_store, &cfqd->cfq_slice_idle, 0, UINT_MAX); ^~~~~~~~~~~~~~~~~~~ block/cfq-iosched.c: In function ?cfq_group_idle_us_store?: block/cfq-iosched.c:4775:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] if (__data < (MIN)) \ ^ block/cfq-iosched.c:4783:1: note: in expansion of macro ?USEC_STORE_FUNCTION? USEC_STORE_FUNCTION(cfq_group_idle_us_store, &cfqd->cfq_group_idle, 0, UINT_MAX); ^~~~~~~~~~~~~~~~~~~ Signed-off-by: Bart Van Assche Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b59b7c743dcdc37438a473ac54ceb2369edfdc9 Author: YueHaibing Date: Tue Aug 7 19:34:16 2018 +0800 RDS: IB: fix 'passing zero to ERR_PTR()' warning [ Upstream commit 5941923da29e84bc9e2a1abb2c14fffaf8d71e2f ] Fix a static code checker warning: net/rds/ib_frmr.c:82 rds_ib_alloc_frmr() warn: passing zero to 'ERR_PTR' The error path for ib_alloc_mr failure should set err to PTR_ERR. Fixes: 1659185fb4d0 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode") Signed-off-by: YueHaibing Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fe5e418c6bc3c2b27115e167dfefc4ca341d8c13 Author: nixiaoming Date: Sun Aug 5 17:10:36 2018 +0800 selinux: cleanup dentry and inodes on error in selinuxfs [ Upstream commit 7e4237faa7213c1cc1d0aa65a44c67ba4729ce9f ] If the resource requested by d_alloc_name is not added to the linked list through d_add, then dput needs to be called to release the subsequent abnormal branch to avoid resource leakage. Add missing dput to selinuxfs.c Signed-off-by: nixiaoming [PM: tweak the subject line] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c3fb1a354ccf3f4756a1f159ef7817d072d66b98 Author: Breno Leitao Date: Tue Aug 7 11:15:39 2018 -0300 selftests/powerpc: Kill child processes on SIGINT [ Upstream commit 7c27a26e1ed5a7dd709aa19685d2c98f64e1cf0c ] There are some powerpc selftests, as tm/tm-unavailable, that run for a long period (>120 seconds), and if it is interrupted, as pressing CRTL-C (SIGINT), the foreground process (harness) dies but the child process and threads continue to execute (with PPID = 1 now) in background. In this case, you'd think the whole test exited, but there are remaining threads and processes being executed in background. Sometimes these zombies processes are doing annoying things, as consuming the whole CPU or dumping things to STDOUT. This patch fixes this problem by attaching an empty signal handler to SIGINT in the harness process. This handler will interrupt (EINTR) the parent process waitpid() call, letting the code to follow through the normal flow, which will kill all the processes in the child process group. This patch also fixes a typo. Signed-off-by: Breno Leitao Signed-off-by: Gustavo Romero Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0510985d146069b5746be841d5e51ac8183e2ed6 Author: Ralf Goebel Date: Mon Aug 6 17:00:36 2018 +0200 iommu/omap: Fix cache flushes on L2 table entries [ Upstream commit 04c532a1cdc7e423656c07937aa4b5c1c2b064f9 ] The base address used for DMA operations on the second-level table did incorrectly include the offset for the table entry. The offset was then added again which lead to incorrect behavior. Operations on the L1 table are not affected. The calculation of the base address is changed to point to the beginning of the L2 table. Fixes: bfee0cf0ee1d ("iommu/omap: Use DMA-API for performing cache flushes") Acked-by: Suman Anna Signed-off-by: Ralf Goebel Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8041b94f4eda1308ef90584f50e8a1cf6e2e6162 Author: Matthias Kaehlcke Date: Tue Aug 7 10:19:40 2018 -0700 ASoC: rt5677: Fix initialization of rt5677_of_match.data [ Upstream commit f861e3e28a3016a2064d9f600eaa92a530b732b4 ] The driver expects to find the device id in rt5677_of_match.data, however it is currently assigned to rt5677_of_match.type. Fix this. The problem was found with the help of clang: sound/soc/codecs/rt5677.c:5010:36: warning: expression which evaluates to zero treated as a null pointer constant of type 'const void *' [-Wnon-literal-null-conversion] { .compatible = "realtek,rt5677", RT5677 }, ^~~~~~ Fixes: ddc9e69b9dc2 ("ASoC: rt5677: Hide platform data in the module sources") Signed-off-by: Matthias Kaehlcke Reviewed-by: Guenter Roeck Acked-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3fb096cdad594b52bf780cfd6b7d546336c5ba14 Author: Ian Abbott Date: Mon Aug 6 11:05:13 2018 +0100 staging: comedi: ni_mio_common: fix subdevice flags for PFI subdevice [ Upstream commit e083926b3e269d4064825dcf2ad50c636fddf8cf ] The PFI subdevice flags indicate that the subdevice is readable and writeable, but that is only true for the supported "M-series" boards, not the older "E-series" boards. Only set the SDF_READABLE and SDF_WRITABLE subdevice flags for the M-series boards. These two flags are mainly for informational purposes. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aee3d110a1046e53b0756726a0f37c8fee877830 Author: John Pittman Date: Mon Aug 6 15:53:12 2018 -0400 dm kcopyd: avoid softlockup in run_complete_job [ Upstream commit 784c9a29e99eb40b842c29ecf1cc3a79e00fb629 ] It was reported that softlockups occur when using dm-snapshot ontop of slow (rbd) storage. E.g.: [ 4047.990647] watchdog: BUG: soft lockup - CPU#10 stuck for 22s! [kworker/10:23:26177] ... [ 4048.034151] Workqueue: kcopyd do_work [dm_mod] [ 4048.034156] RIP: 0010:copy_callback+0x41/0x160 [dm_snapshot] ... [ 4048.034190] Call Trace: [ 4048.034196] ? __chunk_is_tracked+0x70/0x70 [dm_snapshot] [ 4048.034200] run_complete_job+0x5f/0xb0 [dm_mod] [ 4048.034205] process_jobs+0x91/0x220 [dm_mod] [ 4048.034210] ? kcopyd_put_pages+0x40/0x40 [dm_mod] [ 4048.034214] do_work+0x46/0xa0 [dm_mod] [ 4048.034219] process_one_work+0x171/0x370 [ 4048.034221] worker_thread+0x1fc/0x3f0 [ 4048.034224] kthread+0xf8/0x130 [ 4048.034226] ? max_active_store+0x80/0x80 [ 4048.034227] ? kthread_bind+0x10/0x10 [ 4048.034231] ret_from_fork+0x35/0x40 [ 4048.034233] Kernel panic - not syncing: softlockup: hung tasks Fix this by calling cond_resched() after run_complete_job()'s callout to the dm_kcopyd_notify_fn (which is dm-snap.c:copy_callback in the above trace). Signed-off-by: John Pittman Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ab131d7f7a9c2132c2d60bc6485d75299740dfa5 Author: Thomas Petazzoni Date: Fri Aug 3 16:38:44 2018 +0200 PCI: mvebu: Fix I/O space end address calculation [ Upstream commit dfd0309fd7b30a5baffaf47b2fccb88b46d64d69 ] pcie->realio.end should be the address of last byte of the area, therefore using resource_size() of another resource is not correct, we must substract 1 to get the address of the last byte. Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout") Signed-off-by: Thomas Petazzoni Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 00bb59025eafc13e7ba46f8c6dde730555c81dc0 Author: Roger Pau Monne Date: Wed Aug 8 13:46:41 2018 +0200 xen/balloon: fix balloon initialization for PVH Dom0 [ Upstream commit 3596924a233e45aa918c961a902170fc4916461b ] The current balloon code tries to calculate a delta factor for the balloon target when running in HVM mode in order to account for memory used by the firmware. This workaround for memory accounting doesn't work properly on a PVH Dom0, that has a static-max value different from the target value even at startup. Note that this is not a problem for DomUs because guests are started with a static-max value that matches the amount of RAM in the memory map. Fix this by forcefully setting target_diff for Dom0, regardless of it's mode. Reported-by: Gabriel Bercarug Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 19f2289b4ec9e559c857727096c8d2774bda5383 Author: Dmitry Torokhov Date: Mon Aug 6 15:10:40 2018 -0700 Input: do not use WARN() in input_alloc_absinfo() [ Upstream commit 100294cee9a98bfd4d6cb2d1c8a8aef0e959b0c4 ] Some of fuzzers set panic_on_warn=1 so that they can handle WARN()ings the same way they handle full-blown kernel crashes. We used WARN() in input_alloc_absinfo() to get a better idea where memory allocation failed, but since then kmalloc() and friends started dumping call stack on memory allocation failures anyway, so we are not getting anything extra from WARN(). Because of the above, let's replace WARN with dev_err(). We use dev_err() instead of simply removing message and relying on kcalloc() to give us stack dump so that we'd know the instance of hardware device to which we were trying to attach input device. Reported-by: Dmitry Vyukov Acked-by: Dmitry Vyukov Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4d89c871694affda9e246b15a3afed793e0c0b35 Author: Wei Yongjun Date: Thu Aug 2 05:42:04 2018 +0000 NFSv4: Fix error handling in nfs4_sp4_select_mode() [ Upstream commit 72bf75cfc00c02aa66ef6133048f37aa5d88825c ] Error code is set in the error handling cases but never used. Fix it. Fixes: 937e3133cd0b ("NFSv4.1: Ensure we clear the SP4_MACH_CRED flags in nfs4_sp4_select_mode()") Signed-off-by: Wei Yongjun Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 12af4639cfe2ffbc047336da3719e77ca973953d Author: Dan Carpenter Date: Wed Aug 8 17:29:09 2018 +0300 scsi: aic94xx: fix an error code in aic94xx_init() [ Upstream commit 0756c57bce3d26da2592d834d8910b6887021701 ] We accidentally return success instead of -ENOMEM on this error path. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Dan Carpenter Reviewed-by: Johannes Thumshirn Reviewed-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d5fed61a3d2e4f840980c90c94433dd5316771b4 Author: Jianchao Wang Date: Thu Aug 9 08:34:17 2018 -0600 blk-mq: count the hctx as active before allocating tag [ Upstream commit d263ed9926823c462f99a7679e18f0c9e5b8550d ] Currently, we count the hctx as active after allocate driver tag successfully. If a previously inactive hctx try to get tag first time, it may fails and need to wait. However, due to the stale tag ->active_queues, the other shared-tags users are still able to occupy all driver tags while there is someone waiting for tag. Consequently, even if the previously inactive hctx is waked up, it still may not be able to get a tag and could be starved. To fix it, we count the hctx as active before try to allocate driver tag, then when it is waiting the tag, the other shared-tag users will reserve budget for it. Reviewed-by: Ming Lei Signed-off-by: Jianchao Wang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e904dff96e84eef5854fa71e9d4a5c83728224c4 Author: Hans de Goede Date: Wed Aug 8 10:30:03 2018 +0200 ACPI / scan: Initialize status to ACPI_STA_DEFAULT [ Upstream commit 5971b0c1594d6c34e257101ed5fdffec65205c50 ] Since commit 63347db0affa "ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs" the status field of normal acpi_devices gets set to 0 by acpi_bus_type_and_status() and filled with its actual value later when acpi_add_single_object() calls acpi_bus_get_status(). This means that any acpi_match_device_ids() calls in between will always fail with -ENOENT. We already have a workaround for this, which temporary forces status to ACPI_STA_DEFAULT in drivers/acpi/x86/utils.c: acpi_device_always_present() and the next commit in this series adds another acpi_match_device_ids() call between status being initialized as 0 and the acpi_bus_get_status() call. Rather then adding another workaround, this commit makes acpi_bus_type_and_status() initialize status to ACPI_STA_DEFAULT, this is safe to do as the only code looking at status between the initialization and the acpi_bus_get_status() call is those acpi_match_device_ids() calls. Note this does mean that we need to (re)set status to 0 in case the acpi_bus_get_status() call fails. Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e1d82ba3d8350e107bde44889514449d4204d6f0 Author: Stefan Haberland Date: Wed Jul 25 13:27:10 2018 +0200 s390/dasd: fix panic for failed online processing [ Upstream commit 7c6553d4db03350dad0110c3224194c19df76a8f ] Fix a panic that occurs for a device that got an error in dasd_eckd_check_characteristics() during online processing. For example the read configuration data command may have failed. If this error occurs the device is not being set online and the earlier invoked steps during online processing are rolled back. Therefore dasd_eckd_uncheck_device() is called which needs a valid private structure. But this pointer is not valid if dasd_eckd_check_characteristics() has failed. Check for a valid device->private pointer to prevent a panic. Reviewed-by: Jan Hoeppner Signed-off-by: Stefan Haberland Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 70866799dd6fb93950aeaffd4280829f2336905f Author: Stefan Haberland Date: Wed Jul 25 14:00:47 2018 +0200 s390/dasd: fix hanging offline processing due to canceled worker [ Upstream commit 669f3765b755fd8739ab46ce3a9c6292ce8b3d2a ] During offline processing two worker threads are canceled without freeing the device reference which leads to a hanging offline process. Reviewed-by: Jan Hoeppner Signed-off-by: Stefan Haberland Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 151751ec48a2e78bb5b0e8ceb8a3859fa54383ed Author: Winnie Chang Date: Tue Aug 7 21:19:41 2018 -0500 brcmfmac: fix brcmf_wiphy_wowl_params() NULL pointer dereference [ Upstream commit 27a8aea13053700ad2a08189024df7e341d1ee51 ] The kernel BUG happens when wowl is enabled from firmware. In brcmf_wiphy_wowl_params(), cfg is a NULL pointer because it is drvr->config returned from wiphy_to_cfg(), and drvr->config is not set yet. To fix it, set drvr->config before brcmf_setup_wiphy() which calls brcmf_wiphy_wowl_params(). Fixes: 856d5a011c86 ("brcmfmac: allocate struct brcmf_pub instance using wiphy_new()") Signed-off-by: Winnie Chang Signed-off-by: Chi-Hsien Lin Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d0e21e43cd3e6942cfcdb799c177918199339597 Author: Greg Edwards Date: Wed Aug 8 13:27:53 2018 -0600 block: bvec_nr_vecs() returns value for wrong slab [ Upstream commit d6c02a9beb67f13d5f14f23e72fa9981e8b84477 ] In commit ed996a52c868 ("block: simplify and cleanup bvec pool handling"), the value of the slab index is incremented by one in bvec_alloc() after the allocation is done to indicate an index value of 0 does not need to be later freed. bvec_nr_vecs() was not updated accordingly, and thus returns the wrong value. Decrement idx before performing the lookup. Fixes: ed996a52c868 ("block: simplify and cleanup bvec pool handling") Signed-off-by: Greg Edwards Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c728031a35356c5c76be8b908f502384e225b18c Author: Sandipan Das Date: Thu Aug 9 21:49:29 2018 +0530 perf probe powerpc: Fix trace event post-processing [ Upstream commit 354b064b8ebc1e1ede58550ca9e08bfa81e6af43 ] In some cases, a symbol may have multiple aliases. Attempting to add an entry probe for such symbols results in a probe being added at an incorrect location while it fails altogether for return probes. This is only applicable for binaries with debug information. During the arch-dependent post-processing, the offset from the start of the symbol at which the probe is to be attached is determined and added to the start address of the symbol to get the probe's location. In case there are multiple aliases, this offset gets added multiple times for each alias of the symbol and we end up with an incorrect probe location. This can be verified on a powerpc64le system as shown below. $ nm /lib/modules/$(uname -r)/build/vmlinux | grep "sys_open$" ... c000000000414290 T __se_sys_open c000000000414290 T sys_open $ objdump -d /lib/modules/$(uname -r)/build/vmlinux | grep -A 10 "<__se_sys_open>:" c000000000414290 <__se_sys_open>: c000000000414290: 19 01 4c 3c addis r2,r12,281 c000000000414294: 70 c4 42 38 addi r2,r2,-15248 c000000000414298: a6 02 08 7c mflr r0 c00000000041429c: e8 ff a1 fb std r29,-24(r1) c0000000004142a0: f0 ff c1 fb std r30,-16(r1) c0000000004142a4: f8 ff e1 fb std r31,-8(r1) c0000000004142a8: 10 00 01 f8 std r0,16(r1) c0000000004142ac: c1 ff 21 f8 stdu r1,-64(r1) c0000000004142b0: 78 23 9f 7c mr r31,r4 c0000000004142b4: 78 1b 7e 7c mr r30,r3 For both the entry probe and the return probe, the probe location should be _text+4276888 (0xc000000000414298). Since another alias exists for 'sys_open', the post-processing code will end up adding the offset (8 for powerpc64le) twice and perf will attempt to add the probe at _text+4276896 (0xc0000000004142a0) instead. Before: # perf probe -v -a sys_open probe-definition(0): sys_open symbol:sys_open file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux Try to find probe point from debuginfo. Symbol sys_open address found : c000000000414290 Matched function: __se_sys_open [2ad03a0] Probe point found: __se_sys_open+0 Found 1 probe_trace_events. Opening /sys/kernel/debug/tracing/kprobe_events write=1 Writing event: p:probe/sys_open _text+4276896 Added new event: probe:sys_open (on sys_open) ... # perf probe -v -a sys_open%return $retval probe-definition(0): sys_open%return symbol:sys_open file:(null) line:0 offset:0 return:1 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux Try to find probe point from debuginfo. Symbol sys_open address found : c000000000414290 Matched function: __se_sys_open [2ad03a0] Probe point found: __se_sys_open+0 Found 1 probe_trace_events. Opening /sys/kernel/debug/tracing/README write=0 Opening /sys/kernel/debug/tracing/kprobe_events write=1 Parsing probe_events: p:probe/sys_open _text+4276896 Group:probe Event:sys_open probe:p Writing event: r:probe/sys_open__return _text+4276896 Failed to write event: Invalid argument Error: Failed to add events. Reason: Invalid argument (Code: -22) After: # perf probe -v -a sys_open probe-definition(0): sys_open symbol:sys_open file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux Try to find probe point from debuginfo. Symbol sys_open address found : c000000000414290 Matched function: __se_sys_open [2ad03a0] Probe point found: __se_sys_open+0 Found 1 probe_trace_events. Opening /sys/kernel/debug/tracing/kprobe_events write=1 Writing event: p:probe/sys_open _text+4276888 Added new event: probe:sys_open (on sys_open) ... # perf probe -v -a sys_open%return $retval probe-definition(0): sys_open%return symbol:sys_open file:(null) line:0 offset:0 return:1 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux Try to find probe point from debuginfo. Symbol sys_open address found : c000000000414290 Matched function: __se_sys_open [2ad03a0] Probe point found: __se_sys_open+0 Found 1 probe_trace_events. Opening /sys/kernel/debug/tracing/README write=0 Opening /sys/kernel/debug/tracing/kprobe_events write=1 Parsing probe_events: p:probe/sys_open _text+4276888 Group:probe Event:sys_open probe:p Writing event: r:probe/sys_open__return _text+4276888 Added new event: probe:sys_open__return (on sys_open%return) ... Reported-by: Aneesh Kumar Signed-off-by: Sandipan Das Acked-by: Naveen N. Rao Cc: Aneesh Kumar Cc: Jiri Olsa Cc: Ravi Bangoria Fixes: 99e608b5954c ("perf probe ppc64le: Fix probe location when using DWARF") Link: http://lkml.kernel.org/r/20180809161929.35058-1-sandipan@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f3bddbfb636ec091ec3bc516c4794fb3dac6ef2 Author: Dan Carpenter Date: Wed Aug 8 14:57:24 2018 +0300 powerpc: Fix size calculation using resource_size() [ Upstream commit c42d3be0c06f0c1c416054022aa535c08a1f9b39 ] The problem is the the calculation should be "end - start + 1" but the plus one is missing in this calculation. Fixes: 8626816e905e ("powerpc: add support for MPIC message register API") Signed-off-by: Dan Carpenter Reviewed-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 118522ed5fa7f8eac79bbc75e94f7f87efa6c004 Author: Michael Ellerman Date: Tue Jul 10 16:20:56 2018 +1000 powerpc/uaccess: Enable get_user(u64, *p) on 32-bit [ Upstream commit f7a6947cd49b7ff4e03f1b4f7e7b223003d752ca ] Currently if you build a 32-bit powerpc kernel and use get_user() to load a u64 value it will fail to build with eg: kernel/rseq.o: In function `rseq_get_rseq_cs': kernel/rseq.c:123: undefined reference to `__get_user_bad' This is hitting the check in __get_user_size() that makes sure the size we're copying doesn't exceed the size of the destination: #define __get_user_size(x, ptr, size, retval) do { retval = 0; __chk_user_ptr(ptr); if (size > sizeof(x)) (x) = __get_user_bad(); Which doesn't immediately make sense because the size of the destination is u64, but it's not really, because __get_user_check() etc. internally create an unsigned long and copy into that: #define __get_user_check(x, ptr, size) ({ long __gu_err = -EFAULT; unsigned long __gu_val = 0; The problem being that on 32-bit unsigned long is not big enough to hold a u64. We can fix this with a trick from hpa in the x86 code, we statically check the type of x and set the type of __gu_val to either unsigned long or unsigned long long. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c565269d06e982cd947cc5e5ef020274c9c03c11 Author: Yonghong Song Date: Thu Aug 9 08:55:19 2018 -0700 bpf: fix bpffs non-array map seq_show issue [ Upstream commit dc1508a579e682a1e5f1ed0753390e0aa7c23a97 ] In function map_seq_next() of kernel/bpf/inode.c, the first key will be the "0" regardless of the map type. This works for array. But for hash type, if it happens key "0" is in the map, the bpffs map show will miss some items if the key "0" is not the first element of the first bucket. This patch fixed the issue by guaranteeing to get the first element, if the seq_show is just started, by passing NULL pointer key to map_get_next_key() callback. This way, no missing elements will occur for bpffs hash table show even if key "0" is in the map. Fixes: a26ca7c982cb5 ("bpf: btf: Add pretty print support to the basic arraymap") Acked-by: Alexei Starovoitov Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 77197f8d9628a564a99925dd9eeeb5932725637b Author: Anton Vasilyev Date: Mon Aug 6 19:06:35 2018 +0300 pinctrl: axp209: Fix NULL pointer dereference after allocation [ Upstream commit 504c76979bccec66e4c2e41f6a006e49e284466f ] There is no check that allocation in axp20x_funcs_groups_from_mask is successful. The patch adds corresponding check and return values. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Anton Vasilyev Acked-by: Chen-Yu Tsai Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0fbcbc408cec16eefc3f55d1368c8daa336ce857 Author: Chao Yu Date: Sun Jul 29 12:16:59 2018 +0800 f2fs: fix to clear PG_checked flag in set_page_dirty() [ Upstream commit 66110abc4c931f879d70e83e1281f891699364bf ] PG_checked flag will be set on data page during GC, later, we can recognize such page by the flag and migrate page to cold segment. But previously, we don't clear this flag when invalidating data page, after page redirtying, we will write it into wrong log. Let's clear PG_checked flag in set_page_dirty() to avoid this. Signed-off-by: Weichao Guo Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ec3fb9172b86bf9f41cfbb17b66e6a4360ef5743 Author: Jean-Philippe Brucker Date: Tue Jul 17 19:14:45 2018 -0700 net/9p: fix error path of p9_virtio_probe [ Upstream commit 92aef4675d5b1b55404e1532379e343bed0e5cf2 ] Currently when virtio_find_single_vq fails, we go through del_vqs which throws a warning (Trying to free already-free IRQ). Skip del_vqs if vq allocation failed. Link: http://lkml.kernel.org/r/20180524101021.49880-1-jean-philippe.brucker@arm.com Signed-off-by: Jean-Philippe Brucker Reviewed-by: Greg Kurz Cc: Eric Van Hensbergen Cc: Ron Minnich Cc: Latchesar Ionkov Signed-off-by: Andrew Morton Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 91ca7c5644c370dc5132b1db1aea81416a4b2181 Author: Tomas Bortoli Date: Mon Jul 23 20:42:53 2018 +0200 net/9p/trans_fd.c: fix race by holding the lock [ Upstream commit 9f476d7c540cb57556d3cc7e78704e6cd5100f5f ] It may be possible to run p9_fd_cancel() with a deleted req->req_list and incur in a double del. To fix hold the client->lock while changing the status, so the other threads will be synchronized. Link: http://lkml.kernel.org/r/20180723184253.6682-1-tomasbortoli@gmail.com Signed-off-by: Tomas Bortoli Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com To: Eric Van Hensbergen To: Ron Minnich To: Latchesar Ionkov Cc: Yiwen Jiang Cc: David S. Miller Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8542647689ad50822fbc63e90f372f83aebf6dae Author: Jonas Gorski Date: Thu Aug 9 10:59:01 2018 +0200 irqchip/bcm7038-l1: Hide cpu offline callback when building for !SMP [ Upstream commit 0702bc4d2fe793018ad9aa0eb14bff7f526c4095 ] When compiling bmips with SMP disabled, the build fails with: drivers/irqchip/irq-bcm7038-l1.o: In function `bcm7038_l1_cpu_offline': drivers/irqchip/irq-bcm7038-l1.c:242: undefined reference to `irq_set_affinity_locked' make[5]: *** [vmlinux] Error 1 Fix this by adding and setting bcm7038_l1_cpu_offline only when actually compiling for SMP. It wouldn't have been used anyway, as it requires CPU_HOTPLUG, which in turn requires SMP. Fixes: 34c535793bcb ("irqchip/bcm7038-l1: Implement irq_cpu_offline() callback") Signed-off-by: Jonas Gorski Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e51977e08ef06576668fb4ef39a1de5f2239a1aa Author: Dan Carpenter Date: Wed Aug 8 15:03:19 2018 +0300 irqchip/stm32: Fix init error handling [ Upstream commit 4096165d55218a6f58b6c2ebc5d2428aa0aa70e4 ] If there are any errors in stm32_exti_host_init() then it leads to a NULL dereference in the callers. The function should clean up after itself. Fixes: f9fc1745501e ("irqchip/stm32: Add host and driver data structures") Reviewed-by: Ludovic Barre Signed-off-by: Dan Carpenter Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e71ea647e9ae874fbcb6861abb26b73305a22076 Author: Palmer Dabbelt Date: Wed Jul 4 14:07:14 2018 -0700 RISC-V: Use KBUILD_CFLAGS instead of KCFLAGS when building the vDSO [ Upstream commit 4938c79bd0f5f3650c8c2cd4cdc972f0a6962ce4 ] If you use a 64-bit compiler to build a 32-bit kernel then you'll get an error when building the vDSO due to a library mismatch. The happens because the relevant "-march" argument isn't supplied to the GCC run that generates one of the vDSO intermediate files. I'm not actually sure what the right thing to do here is as I'm not particularly familiar with the kernel build system. I poked the documentation and it appears that KCFLAGS is the correct thing to do (it's suggested that should be used when building modules), but we set KBUILD_CFLAGS in arch/riscv/Makefile. This does at least fix the build error. Reviewed-by: Christoph Hellwig Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd2b9872d3cbf523208cdd8e666ccdaac13499a8 Author: Chao Yu Date: Sun Aug 5 23:04:25 2018 +0800 f2fs: fix avoid race between truncate and background GC [ Upstream commit a33c150237a20d97a174243bc658c86502f9d370 ] Thread A Background GC - f2fs_setattr isize to 0 - truncate_setsize - gc_data_segment - f2fs_get_read_data_page page #0 - set_page_dirty - set_cold_data - f2fs_truncate - f2fs_setattr isize to 4k - read 4k <--- hit data in cached page #0 Above race condition can cause read out invalid data in a truncated page, fix it by i_gc_rwsem[WRITE] lock. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7038712b79a1e4ae0f0187852af0f11529a8895a Author: Chao Yu Date: Sun Aug 5 23:02:22 2018 +0800 f2fs: avoid race between zero_range and background GC [ Upstream commit c7079853c859c910b9d047a37891b4aafb8f8dd7 ] Thread A Background GC - f2fs_zero_range - truncate_pagecache_range - gc_data_segment - get_read_data_page - move_data_page - set_page_dirty - set_cold_data - f2fs_do_zero_range - dn->data_blkaddr = NEW_ADDR; - f2fs_set_data_blkaddr Actually, we don't need to set dirty & checked flag on the page, since all valid data in the page should be zeroed by zero_range(). Use i_gc_rwsem[WRITE] to avoid such race condition. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aa8ce04f531f77466beaab8c0d7afb7f01d925c0 Author: Benno Evers Date: Fri Aug 10 15:36:13 2018 +0200 perf tools: Check for null when copying nsinfo. [ Upstream commit 3f4417d693b43fa240ac8bde4487f67745ca23d8 ] The argument to nsinfo__copy() was assumed to be valid, but some code paths exist that will lead to NULL being passed. In particular, running 'perf script -D' on a perf.data file containing an PERF_RECORD_MMAP event associating the '[vdso]' dso with pid 0 earlier in the event stream will lead to a segfault. Since all calling code is already checking for a non-null return value, just return NULL for this case as well. Signed-off-by: Benno Evers Acked-by: Namhyung Kim Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Krister Johansen Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20180810133614.9925-1-bevers@mesosphere.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6d39ab3401ff072eee6e93d5575fcbeba63bf69a Author: Denis Efremov Date: Fri Aug 10 23:25:55 2018 +0300 coccicheck: return proper error code on fail [ Upstream commit 512ddf7d7db056edfed3159ea7cb4e4a5eefddd4 ] If coccicheck fails, it should return an error code distinct from zero to signal about an internal problem. Current code instead of exiting with the tool's error code returns the error code of 'echo "coccicheck failed"' which is almost always equals to zero, thus failing the original intention of alerting about a problem. This patch fixes the code. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Denis Efremov Acked-by: Julia Lawall Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 243b6c6a90cc7332a41d889a52b18297d193ea26 Author: Nicholas Kazlauskas Date: Fri Aug 3 10:40:20 2018 -0400 drm/amd/display: Guard against null crtc in CRC IRQ [ Upstream commit dddc0557e3a02499ce336b1e2e67f5afaecccc80 ] [Why] A null pointer deference can occur if crtc is null in amdgpu_dm_crtc_handle_crc_irq. This can happen if get_crtc_by_otg_inst returns NULL during dm_crtc_high_irq, leading to a hang in some IGT test cases. [How] Check that CRTC is non-null before accessing its fields. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Sun peng Li Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1e089219547547700e79e8320c7b0b9f3f3778dc Author: Myron Stowe Date: Mon Aug 13 12:19:46 2018 -0600 PCI: Match Root Port's MPS to endpoint's MPSS as necessary [ Upstream commit 9f0e89359775ee21fe1ea732e34edb52aef5addf ] In commit 27d868b5e6cf ("PCI: Set MPS to match upstream bridge"), we made sure every device's MPS setting matches its upstream bridge, making it more likely that a hot-added device will work in a system with an optimized MPS configuration. Recently I've started encountering systems where the endpoint device's MPSS capability is less than its Root Port's current MPS value, thus the endpoint is not capable of matching its upstream bridge's MPS setting (see: bugzilla via "Link:" below). This leaves the system vulnerable - the upstream Root Port could respond with larger TLPs than the device can handle, and the device will consider them to be 'Malformed'. One could use the "pci=pcie_bus_safe" kernel parameter to work around the issue, but that forces a user to supply a kernel parameter to get the system to function reliably and may end up limiting MPS settings of other unrelated, sub-topologies which could benefit from maintaining their larger values. Augment Keith's approach to include tuning down a Root Port's MPS setting when its hot-added endpoint device is not capable of matching it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527 Signed-off-by: Myron Stowe Signed-off-by: Bjorn Helgaas Acked-by: Jon Mason Cc: Keith Busch Cc: Sinan Kaya Cc: Dongdong Liu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0472229e385cd157c2c2402ed4a4a21e1c005656 Author: Jian Shen Date: Tue Aug 14 17:13:15 2018 +0100 net: hns3: Fix for phy link issue when using marvell phy driver [ Upstream commit 60081dcc4fce385ade26d3145b2479789df0b7e5 ] For marvell phy m88e1510, bit SUPPORTED_FIBRE of phydev->supported is default on. Both phy_resume() and phy_suspend() will check the SUPPORTED_FIBRE bit and write register of fibre page. Currently in hns3 driver, the SUPPORTED_FIBRE bit will be cleared after phy_connect_direct() finished. Because phy_resume() is called in phy_connect_direct(), and phy_suspend() is called when disconnect phy device, so the operation for fibre page register is not symmetrical. It will cause phy link issue when reload hns3 driver. This patch fixes it by disable the SUPPORTED_FIBRE before connecting phy. Fixes: 256727da7395 ("net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC") Signed-off-by: Jian Shen Signed-off-by: Peng Li Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b02fd8a8dc25e237b2f8b78ff662c6b4d6995598 Author: Jens Axboe Date: Tue Aug 14 10:52:40 2018 -0600 block: don't warn for flush on read-only device [ Upstream commit b089cfd95d32638335c551651a8e00fd2c4edb0b ] Don't warn for a flush issued to a read-only device. It's not strictly a writable command, as it doesn't change any on-media data by itself. Reported-by: Stefan Agner Fixes: 721c7fc701c7 ("block: fail op_is_write() requests to read-only partitions") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 534dde34bb7dfe47e030a0a1cb0e2d17c0c4bac3 Author: Xi Wang Date: Tue Aug 14 17:13:13 2018 +0100 net: hns3: Fix for command format parsing error in hclge_is_all_function_id_zero [ Upstream commit 6c39d5278e62956238a681e4cfc69fae5507fc57 ] According to the functional specification of hardware, the first descriptor of response from command 'lookup vlan talbe' is not valid. Currently, the first descriptor is parsed as normal value, which will cause an expected error. This patch fixes this problem by skipping the first descriptor. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Xi Wang Signed-off-by: Peng Li Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit faba3f032e96a390057db5b3b362a73734b85f32 Author: Kim Phillips Date: Fri Aug 10 17:45:12 2018 -0500 perf arm spe: Fix uninitialized record error variable [ Upstream commit 344353366591acf659a0d0dea498611da78d67e2 ] The auxtrace init variable 'err' was not being initialized, leading perf to abort early in an SPE record command when there was no explicit error, rather only based whatever memory contents were on the stack. Initialize it explicitly on getting an SPE successfully, the same way cs-etm does. Signed-off-by: Kim Phillips Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Dongjiu Geng Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: ffd3d18c20b8 ("perf tools: Add ARM Statistical Profiling Extensions (SPE) support") Link: http://lkml.kernel.org/r/20180810174512.52900813e57cbccf18ce99a2@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7da94d53075d8e9d489936420301658b676e2129 Author: Erik Schmauss Date: Fri Aug 10 14:42:55 2018 -0700 ACPICA: ACPICA: add status check for acpi_hw_read before assigning return value [ Upstream commit f016b19a9275089a2ab06c2144567c2ad8d5d6ad ] The value coming from acpi_hw_read() should not be used if it returns an error code, so check the status returned by it before using that value in two places in acpi_hw_register_read(). Reported-by: Mark Gross Signed-off-by: Erik Schmauss [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 08100b285966e0fe90a33c607c5fc42094d9d746 Author: Gal Pressman Date: Thu Aug 9 22:00:47 2018 +0300 RDMA/hns: Fix usage of bitmap allocation functions return values [ Upstream commit a1ceeca679dccc492235f0f629d9e9f7b3d51ca8 ] hns bitmap allocation functions return 0 on success and -1 on failure. Callers of these functions wrongly used their return value as an errno, fix that by making a proper conversion. Fixes: a598c6f4c5a8 ("IB/hns: Simplify function of pd alloc and qp alloc") Signed-off-by: Gal Pressman Acked-by: Lijun Ou Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 59e8e46ada765101d24dd5a608c3f8f24c0143d6 Author: Richard Weinberger Date: Tue Jun 12 09:33:16 2018 +0200 ubi: Initialize Fastmap checkmapping correctly [ Upstream commit 25677478474a91fa1b46f19a4a591a9848bca6fb ] We cannot do it last, otherwithse it will be skipped for dynamic volumes. Reported-by: Lachmann, Juergen Fixes: 34653fd8c46e ("ubi: fastmap: Check each mapping only once") Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 58d705bdcd855010bf203549a321374297d63396 Author: Daniel Borkmann Date: Thu Aug 16 21:49:06 2018 +0200 tcp, ulp: add alias for all ulp modules [ Upstream commit 037b0b86ecf5646f8eae777d8b52ff8b401692ec ] Lets not turn the TCP ULP lookup into an arbitrary module loader as we only intend to load ULP modules through this mechanism, not other unrelated kernel modules: [root@bar]# cat foo.c #include #include #include #include int main(void) { int sock = socket(PF_INET, SOCK_STREAM, 0); setsockopt(sock, IPPROTO_TCP, TCP_ULP, "sctp", sizeof("sctp")); return 0; } [root@bar]# gcc foo.c -O2 -Wall [root@bar]# lsmod | grep sctp [root@bar]# ./a.out [root@bar]# lsmod | grep sctp sctp 1077248 4 libcrc32c 16384 3 nf_conntrack,nf_nat,sctp [root@bar]# Fix it by adding module alias to TCP ULP modules, so probing module via request_module() will be limited to tcp-ulp-[name]. The existing modules like kTLS will load fine given tcp-ulp-tls alias, but others will fail to load: [root@bar]# lsmod | grep sctp [root@bar]# ./a.out [root@bar]# lsmod | grep sctp [root@bar]# Sockmap is not affected from this since it's either built-in or not. Fixes: 734942cc4ea6 ("tcp: ULP infrastructure") Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Song Liu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 30d2d473b6c29f632441fb16190448135458ad84 Author: Florian Westphal Date: Tue Jul 31 13:41:23 2018 +0200 netfilter: fix memory leaks on netlink_dump_start error [ Upstream commit 3e673b23b541b8e7f773b2d378d6eb99831741cd ] Shaochun Chen points out we leak dumper filter state allocations stored in dump_control->data in case there is an error before netlink sets cb_running (after which ->done will be called at some point). In order to fix this, add .start functions and move allocations there. Same pattern as used in commit 90fd131afc565159c9e0ea742f082b337e10f8c6 ("netfilter: nf_tables: move dumper state allocation into ->start"). Reported-by: shaochun chen Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2d24a4ca620445b6ce860615e4ff52728818b253 Author: Aleh Filipovich Date: Fri Aug 10 22:07:25 2018 +0200 platform/x86: asus-nb-wmi: Add keymap entry for lid flip action on UX360 [ Upstream commit 880b29ac107d15644bf4da228376ba3cd6af6d71 ] Add entry to WMI keymap for lid flip event on Asus UX360. On Asus Zenbook ux360 flipping lid from/to tablet mode triggers keyscan code 0xfa which cannot be handled and results in kernel log message "Unknown key fa pressed". Signed-off-by: Aleh Filipovich Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3bf9fa21774a2ab8b91ee41b9aa27f923e61c27c Author: Michal Hocko Date: Tue Aug 7 21:54:00 2018 +0200 netfilter: x_tables: do not fail xt_alloc_table_info too easilly [ Upstream commit a148ce15375fc664ad64762c751c0c2aecb2cafe ] eacd86ca3b03 ("net/netfilter/x_tables.c: use kvmalloc() in xt_alloc_table_info()") has unintentionally fortified xt_alloc_table_info allocation when __GFP_RETRY has been dropped from the vmalloc fallback. Later on there was a syzbot report that this can lead to OOM killer invocations when tables are too large and 0537250fdc6c ("netfilter: x_tables: make allocation less aggressive") has been merged to restore the original behavior. Georgi Nikolov however noticed that he is not able to install his iptables anymore so this can be seen as a regression. The primary argument for 0537250fdc6c was that this allocation path shouldn't really trigger the OOM killer and kill innocent tasks. On the other hand the interface requires root and as such should allow what the admin asks for. Root inside a namespaces makes this more complicated because those might be not trusted in general. If they are not then such namespaces should be restricted anyway. Therefore drop the __GFP_NORETRY and replace it by __GFP_ACCOUNT to enfore memcg constrains on it. Fixes: 0537250fdc6c ("netfilter: x_tables: make allocation less aggressive") Reported-by: Georgi Nikolov Suggested-by: Vlastimil Babka Acked-by: Florian Westphal Signed-off-by: Michal Hocko Acked-by: Vlastimil Babka Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8dea99cf8b434c7f2d70059eac198cbd097e49dc Author: Guenter Roeck Date: Fri Aug 3 20:59:51 2018 -0700 mfd: sm501: Set coherent_dma_mask when creating subdevices [ Upstream commit 2f606da78230f09cf1a71fde6ee91d0c710fa2b2 ] Instantiating the sm501 OHCI subdevice results in a kernel warning. sm501-usb sm501-usb: SM501 OHCI sm501-usb sm501-usb: new USB bus registered, assigned bus number 1 WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 ohci_init+0x194/0x2d8 Modules linked in: CPU: 0 PID: 1 Comm: swapper Tainted: G W 4.18.0-rc7-00178-g0b5b1f9a78b5 #1 PC is at ohci_init+0x194/0x2d8 PR is at ohci_init+0x168/0x2d8 PC : 8c27844c SP : 8f81dd94 SR : 40008001 TEA : 29613060 R0 : 00000000 R1 : 00000000 R2 : 00000000 R3 : 00000202 R4 : 8fa98b88 R5 : 8c277e68 R6 : 00000000 R7 : 00000000 R8 : 8f965814 R9 : 8c388100 R10 : 8fa98800 R11 : 8fa98928 R12 : 8c48302c R13 : 8fa98920 R14 : 8c48302c MACH: 00000096 MACL: 0000017c GBR : 00000000 PR : 8c278420 Call trace: [<(ptrval)>] usb_add_hcd+0x1e8/0x6ec [<(ptrval)>] _dev_info+0x0/0x54 [<(ptrval)>] arch_local_save_flags+0x0/0x8 [<(ptrval)>] arch_local_irq_restore+0x0/0x24 [<(ptrval)>] ohci_hcd_sm501_drv_probe+0x114/0x2d8 ... Initialize coherent_dma_mask when creating SM501 subdevices to fix the problem. Fixes: b6d6454fdb66f ("mfd: SM501 core driver") Signed-off-by: Guenter Roeck Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c63f900720bac3001200c75792a79ff3dbe611a3 Author: Tan Hu Date: Wed Jul 25 15:23:07 2018 +0800 ipvs: fix race between ip_vs_conn_new() and ip_vs_del_dest() [ Upstream commit a53b42c11815d2357e31a9403ae3950517525894 ] We came across infinite loop in ipvs when using ipvs in docker env. When ipvs receives new packets and cannot find an ipvs connection, it will create a new connection, then if the dest is unavailable (i.e. IP_VS_DEST_F_AVAILABLE), the packet will be dropped sliently. But if the dropped packet is the first packet of this connection, the connection control timer never has a chance to start and the ipvs connection cannot be released. This will lead to memory leak, or infinite loop in cleanup_net() when net namespace is released like this: ip_vs_conn_net_cleanup at ffffffffa0a9f31a [ip_vs] __ip_vs_cleanup at ffffffffa0a9f60a [ip_vs] ops_exit_list at ffffffff81567a49 cleanup_net at ffffffff81568b40 process_one_work at ffffffff810a851b worker_thread at ffffffff810a9356 kthread at ffffffff810b0b6f ret_from_fork at ffffffff81697a18 race condition: CPU1 CPU2 ip_vs_in() ip_vs_conn_new() ip_vs_del_dest() __ip_vs_unlink_dest() ~IP_VS_DEST_F_AVAILABLE cp->dest && !IP_VS_DEST_F_AVAILABLE __ip_vs_conn_put ... cleanup_net ---> infinite looping Fix this by checking whether the timer already started. Signed-off-by: Tan Hu Reviewed-by: Jiang Biao Acked-by: Julian Anastasov Acked-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df1ce63447eab99baa0ded47ccde357863c2d976 Author: Philipp Rudo Date: Mon Aug 13 11:16:57 2018 +0200 s390/kdump: Fix memleak in nt_vmcoreinfo [ Upstream commit 2d2e7075b87181ed0c675e4936e20bdadba02e1f ] The vmcoreinfo of a crashed system is potentially fragmented. Thus the crash kernel has an intermediate step where the vmcoreinfo is copied into a temporary, continuous buffer in the crash kernel memory. This temporary buffer is never freed. Free it now to prevent the memleak. While at it replace all occurrences of "VMCOREINFO" by its corresponding macro to prevent potential renaming issues. Signed-off-by: Philipp Rudo Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 875fefda91d42d617c2d1bf0cdf9f5bcb452c355 Author: Florian Westphal Date: Wed Jul 25 21:38:43 2018 +0200 netfilter: ip6t_rpfilter: set F_IFACE for linklocal addresses [ Upstream commit da786717e0894886301ed2536843c13f9e8fd53e ] Roman reports that DHCPv6 client no longer sees replies from server due to ip6tables -t raw -A PREROUTING -m rpfilter --invert -j DROP rule. We need to set the F_IFACE flag for linklocal addresses, they are scoped per-device. Fixes: 47b7e7f82802 ("netfilter: don't set F_IFACE on ipv6 fib lookups") Reported-by: Roman Mamedov Tested-by: Roman Mamedov Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bdcdbe6e48f088db30fdd4d8d4e3e258f1d80ee7 Author: Jesper Dangaard Brouer Date: Wed Aug 15 16:57:14 2018 +0200 samples/bpf: all XDP samples should unload xdp/bpf prog on SIGTERM [ Upstream commit 817b89beb9d8876450fcde9155e17425c329569d ] It is common XDP practice to unload/deattach the XDP bpf program, when the XDP sample program is Ctrl-C interrupted (SIGINT) or killed (SIGTERM). The samples/bpf programs xdp_redirect_cpu and xdp_rxq_info, forgot to trap signal SIGTERM (which is the default signal used by the kill command). This was discovered by Red Hat QA, which automated scripts depend on killing the XDP sample program after a timeout period. Fixes: fad3917e361b ("samples/bpf: add cpumap sample program xdp_redirect_cpu") Fixes: 0fca931a6f21 ("samples/bpf: program demonstrating access to xdp_rxq_info") Reported-by: Jean-Tsung Hsiao Signed-off-by: Jesper Dangaard Brouer Acked-by: Yonghong Song Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2262b26d750dce70bdaaa2fe68c016a18e1b5ff7 Author: Daniel Borkmann Date: Thu Aug 16 21:49:08 2018 +0200 bpf, sockmap: fix leakage of smap_psock_map_entry [ Upstream commit d40b0116c94bd8fc2b63aae35ce8e66bb53bba42 ] While working on sockmap I noticed that we do not always kfree the struct smap_psock_map_entry list elements which track psocks attached to maps. In the case of sock_hash_ctx_update_elem(), these map entries are allocated outside of __sock_map_ctx_update_elem() with their linkage to the socket hash table filled. In the case of sock array, the map entries are allocated inside of __sock_map_ctx_update_elem() and added with their linkage to the psock->maps. Both additions are under psock->maps_lock each. Now, we drop these elements from their psock->maps list in a few occasions: i) in sock array via smap_list_map_remove() when an entry is either deleted from the map from user space, or updated via user space or BPF program where we drop the old socket at that map slot, or the sock array is freed via sock_map_free() and drops all its elements; ii) for sock hash via smap_list_hash_remove() in exactly the same occasions as just described for sock array; iii) in the bpf_tcp_close() where we remove the elements from the list via psock_map_pop() and iterate over them dropping themselves from either sock array or sock hash; and last but not least iv) once again in smap_gc_work() which is a callback for deferring the work once the psock refcount hit zero and thus the socket is being destroyed. Problem is that the only case where we kfree() the list entry is in case iv), which at that point should have an empty list in normal cases. So in cases from i) to iii) we unlink the elements without freeing where they go out of reach from us. Hence fix is to properly kfree() them as well to stop the leakage. Given these are all handled under psock->maps_lock there is no need for deferred RCU freeing. I later also ran with kmemleak detector and it confirmed the finding as well where in the state before the fix the object goes unreferenced while after the patch no kmemleak report related to BPF showed up. [...] unreferenced object 0xffff880378eadae0 (size 64): comm "test_sockmap", pid 2225, jiffies 4294720701 (age 43.504s) hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 00 02 00 00 00 00 ad de ................ 50 4d 75 5d 03 88 ff ff 00 00 00 00 00 00 00 00 PMu]............ backtrace: [<000000005225ac3c>] sock_map_ctx_update_elem.isra.21+0xd8/0x210 [<0000000045dd6d3c>] bpf_sock_map_update+0x29/0x60 [<00000000877723aa>] ___bpf_prog_run+0x1e1f/0x4960 [<000000002ef89e83>] 0xffffffffffffffff unreferenced object 0xffff880378ead240 (size 64): comm "test_sockmap", pid 2225, jiffies 4294720701 (age 43.504s) hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 00 02 00 00 00 00 ad de ................ 00 44 75 5d 03 88 ff ff 00 00 00 00 00 00 00 00 .Du]............ backtrace: [<000000005225ac3c>] sock_map_ctx_update_elem.isra.21+0xd8/0x210 [<0000000030e37a3a>] sock_map_update_elem+0x125/0x240 [<000000002e5ce36e>] map_update_elem+0x4eb/0x7b0 [<00000000db453cc9>] __x64_sys_bpf+0x1f9/0x360 [<0000000000763660>] do_syscall_64+0x9a/0x300 [<00000000422a2bb2>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<000000002ef89e83>] 0xffffffffffffffff [...] Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close") Fixes: 54fedb42c653 ("bpf: sockmap, fix smap_list_map_remove when psock is in many maps") Fixes: 2f857d04601a ("bpf: sockmap, remove STRPARSER map_flags and add multi-map support") Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Song Liu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ea775b6980083e7b09a2de036629f1fa52b61418 Author: Tariq Toukan Date: Mon Aug 13 12:21:58 2018 +0300 net/xdp: Fix suspicious RCU usage warning [ Upstream commit 21b172ee11b6ec260bd7e6a27b11a8a8d392fce5 ] Fix the warning below by calling rhashtable_lookup_fast. Also, make some code movements for better quality and human readability. [ 342.450870] WARNING: suspicious RCU usage [ 342.455856] 4.18.0-rc2+ #17 Tainted: G O [ 342.462210] ----------------------------- [ 342.467202] ./include/linux/rhashtable.h:481 suspicious rcu_dereference_check() usage! [ 342.476568] [ 342.476568] other info that might help us debug this: [ 342.476568] [ 342.486978] [ 342.486978] rcu_scheduler_active = 2, debug_locks = 1 [ 342.495211] 4 locks held by modprobe/3934: [ 342.500265] #0: 00000000e23116b2 (mlx5_intf_mutex){+.+.}, at: mlx5_unregister_interface+0x18/0x90 [mlx5_core] [ 342.511953] #1: 00000000ca16db96 (rtnl_mutex){+.+.}, at: unregister_netdev+0xe/0x20 [ 342.521109] #2: 00000000a46e2c4b (&priv->state_lock){+.+.}, at: mlx5e_close+0x29/0x60 [mlx5_core] [ 342.531642] #3: 0000000060c5bde3 (mem_id_lock){+.+.}, at: xdp_rxq_info_unreg+0x93/0x6b0 [ 342.541206] [ 342.541206] stack backtrace: [ 342.547075] CPU: 12 PID: 3934 Comm: modprobe Tainted: G O 4.18.0-rc2+ #17 [ 342.556621] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015 [ 342.565606] Call Trace: [ 342.568861] dump_stack+0x78/0xb3 [ 342.573086] xdp_rxq_info_unreg+0x3f5/0x6b0 [ 342.578285] ? __call_rcu+0x220/0x300 [ 342.582911] mlx5e_free_rq+0x38/0xc0 [mlx5_core] [ 342.588602] mlx5e_close_channel+0x20/0x120 [mlx5_core] [ 342.594976] mlx5e_close_channels+0x26/0x40 [mlx5_core] [ 342.601345] mlx5e_close_locked+0x44/0x50 [mlx5_core] [ 342.607519] mlx5e_close+0x42/0x60 [mlx5_core] [ 342.613005] __dev_close_many+0xb1/0x120 [ 342.617911] dev_close_many+0xa2/0x170 [ 342.622622] rollback_registered_many+0x148/0x460 [ 342.628401] ? __lock_acquire+0x48d/0x11b0 [ 342.633498] ? unregister_netdev+0xe/0x20 [ 342.638495] rollback_registered+0x56/0x90 [ 342.643588] unregister_netdevice_queue+0x7e/0x100 [ 342.649461] unregister_netdev+0x18/0x20 [ 342.654362] mlx5e_remove+0x2a/0x50 [mlx5_core] [ 342.659944] mlx5_remove_device+0xe5/0x110 [mlx5_core] [ 342.666208] mlx5_unregister_interface+0x39/0x90 [mlx5_core] [ 342.673038] cleanup+0x5/0xbfc [mlx5_core] [ 342.678094] __x64_sys_delete_module+0x16b/0x240 [ 342.683725] ? do_syscall_64+0x1c/0x210 [ 342.688476] do_syscall_64+0x5a/0x210 [ 342.693025] entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 8d5d88527587 ("xdp: rhashtable with allocator ID to pointer mapping") Signed-off-by: Tariq Toukan Suggested-by: Daniel Borkmann Cc: Jesper Dangaard Brouer Acked-by: Jesper Dangaard Brouer Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7fb58bc7549d3fe14a857550a9770244114bbf03 Author: Daniel Borkmann Date: Thu Aug 16 21:49:10 2018 +0200 bpf, sockmap: fix sock_map_ctx_update_elem race with exist/noexist [ Upstream commit 585f5a6252ee43ec8feeee07387e3fcc7e8bb292 ] The current code in sock_map_ctx_update_elem() allows for BPF_EXIST and BPF_NOEXIST map update flags. While on array-like maps this approach is rather uncommon, e.g. bpf_fd_array_map_update_elem() and others enforce map update flags to be BPF_ANY such that xchg() can be used directly, the current implementation in sock map does not guarantee that such operation with BPF_EXIST / BPF_NOEXIST is atomic. The initial test does a READ_ONCE(stab->sock_map[i]) to fetch the socket from the slot which is then tested for NULL / non-NULL. However later after __sock_map_ctx_update_elem(), the actual update is done through osock = xchg(&stab->sock_map[i], sock). Problem is that in the meantime a different CPU could have updated / deleted a socket on that specific slot and thus flag contraints won't hold anymore. I've been thinking whether best would be to just break UAPI and do an enforcement of BPF_ANY to check if someone actually complains, however trouble is that already in BPF kselftest we use BPF_NOEXIST for the map update, and therefore it might have been copied into applications already. The fix to keep the current behavior intact would be to add a map lock similar to the sock hash bucket lock only for covering the whole map. Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support") Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Song Liu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4cd728b4b50ae11c6fa583b461237984212fdd72 Author: Daniel Borkmann Date: Thu Aug 16 21:49:07 2018 +0200 tcp, ulp: fix leftover icsk_ulp_ops preventing sock from reattach [ Upstream commit 90545cdc3f2b2ea700e24335610cd181e73756da ] I found that in BPF sockmap programs once we either delete a socket from the map or we updated a map slot and the old socket was purged from the map that these socket can never get reattached into a map even though their related psock has been dropped entirely at that point. Reason is that tcp_cleanup_ulp() leaves the old icsk->icsk_ulp_ops intact, so that on the next tcp_set_ulp_id() the kernel returns an -EEXIST thinking there is still some active ULP attached. BPF sockmap is the only one that has this issue as the other user, kTLS, only calls tcp_cleanup_ulp() from tcp_v4_destroy_sock() whereas sockmap semantics allow dropping the socket from the map with all related psock state being cleaned up. Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks") Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Song Liu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 98d30c6ae96a5dd66f638d1fccb26779bd655b47 Author: Daniel Borkmann Date: Thu Aug 16 21:49:09 2018 +0200 bpf, sockmap: fix map elem deletion race with smap_stop_sock [ Upstream commit 166ab6f0a0702fdd4d865ad5090bf3094ed83428 ] The smap_start_sock() and smap_stop_sock() are each protected under the sock->sk_callback_lock from their call-sites except in the case of sock_map_delete_elem() where we drop the old socket from the map slot. This is racy because the same sock could be part of multiple sock maps, so we run smap_stop_sock() in parallel, and given at that point psock->strp_enabled might be true on both CPUs, we might for example wrongly restore the sk->sk_data_ready / sk->sk_write_space. Therefore, hold the sock->sk_callback_lock as well on delete. Looks like 2f857d04601a ("bpf: sockmap, remove STRPARSER map_flags and add multi-map support") had this right, but later on e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close") removed it again from delete leaving this smap_stop_sock() instance unprotected. Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close") Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Song Liu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af160422460ea8e5824e6930566f4c8ae91f3066 Author: Randy Dunlap Date: Wed Aug 15 09:12:07 2018 -0700 platform/x86: intel_punit_ipc: fix build errors [ Upstream commit 340fd4cff43f18bace9358d4decdc9b6ed0715be ] Fix build errors by #including . ../drivers/platform/x86/intel_punit_ipc.c: In function 'ipc_read_status': ../drivers/platform/x86/intel_punit_ipc.c:55:2: error: implicit declaration of function 'readl' [-Werror=implicit-function-declaration] return readl(ipcdev->base[type][BASE_IFACE]); ../drivers/platform/x86/intel_punit_ipc.c: In function 'ipc_write_cmd': ../drivers/platform/x86/intel_punit_ipc.c:60:2: error: implicit declaration of function 'writel' [-Werror=implicit-function-declaration] writel(cmd, ipcdev->base[type][BASE_IFACE]); Fixes: 447ae3166702 ("x86: Don't include linux/irq.h from asm/hardirq.h") Signed-off-by: Randy Dunlap Cc: Zha Qipeng Cc: platform-driver-x86@vger.kernel.org Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 56d0f1c6d4d235623b523818df83e1aa044af1f8 Author: Tetsuo Handa Date: Fri Aug 17 15:44:34 2018 -0700 fs/dcache.c: fix kmemcheck splat at take_dentry_name_snapshot() [ Upstream commit 6cd00a01f0c1ae6a852b09c59b8dd55cc6c35d1d ] Since only dentry->d_name.len + 1 bytes out of DNAME_INLINE_LEN bytes are initialized at __d_alloc(), we can't copy the whole size unconditionally. WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff8fa27465ac50) 636f6e66696766732e746d70000000000010000000000000020000000188ffff i i i i i i i i i i i i i u u u u u u u u u u i i i i i u u u u ^ RIP: 0010:take_dentry_name_snapshot+0x28/0x50 RSP: 0018:ffffa83000f5bdf8 EFLAGS: 00010246 RAX: 0000000000000020 RBX: ffff8fa274b20550 RCX: 0000000000000002 RDX: ffffa83000f5be40 RSI: ffff8fa27465ac50 RDI: ffffa83000f5be60 RBP: ffffa83000f5bdf8 R08: ffffa83000f5be48 R09: 0000000000000001 R10: ffff8fa27465ac00 R11: ffff8fa27465acc0 R12: ffff8fa27465ac00 R13: ffff8fa27465acc0 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f79737ac8c0(0000) GS:ffffffff8fc30000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8fa274c0b000 CR3: 0000000134aa7002 CR4: 00000000000606f0 take_dentry_name_snapshot+0x28/0x50 vfs_rename+0x128/0x870 SyS_rename+0x3b2/0x3d0 entry_SYSCALL_64_fastpath+0x1a/0xa4 0xffffffffffffffff Link: http://lkml.kernel.org/r/201709131912.GBG39012.QMJLOVFSFFOOtH@I-love.SAKURA.ne.jp Signed-off-by: Tetsuo Handa Cc: Vegard Nossum Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8bca1a92d8b8ddb57a4dfb70db60f0f3350ee1ce Author: Mike Rapoport Date: Fri Aug 17 15:47:07 2018 -0700 mm: make DEFERRED_STRUCT_PAGE_INIT explicitly depend on SPARSEMEM [ Upstream commit d39f8fb4b7776dcb09ec3bf7a321547083078ee3 ] The deferred memory initialization relies on section definitions, e.g PAGES_PER_SECTION, that are only available when CONFIG_SPARSEMEM=y on most architectures. Initially DEFERRED_STRUCT_PAGE_INIT depended on explicit ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT configuration option, but since the commit 2e3ca40f03bb13709df4 ("mm: relax deferred struct page requirements") this requirement was relaxed and now it is possible to enable DEFERRED_STRUCT_PAGE_INIT on architectures that support DISCONTINGMEM and NO_BOOTMEM which causes build failures. For instance, setting SMP=y and DEFERRED_STRUCT_PAGE_INIT=y on arc causes the following build failure: CC mm/page_alloc.o mm/page_alloc.c: In function 'update_defer_init': mm/page_alloc.c:321:14: error: 'PAGES_PER_SECTION' undeclared (first use in this function); did you mean 'USEC_PER_SEC'? (pfn & (PAGES_PER_SECTION - 1)) == 0) { ^~~~~~~~~~~~~~~~~ USEC_PER_SEC mm/page_alloc.c:321:14: note: each undeclared identifier is reported only once for each function it appears in In file included from include/linux/cache.h:5:0, from include/linux/printk.h:9, from include/linux/kernel.h:14, from include/asm-generic/bug.h:18, from arch/arc/include/asm/bug.h:32, from include/linux/bug.h:5, from include/linux/mmdebug.h:5, from include/linux/mm.h:9, from mm/page_alloc.c:18: mm/page_alloc.c: In function 'deferred_grow_zone': mm/page_alloc.c:1624:52: error: 'PAGES_PER_SECTION' undeclared (first use in this function); did you mean 'USEC_PER_SEC'? unsigned long nr_pages_needed = ALIGN(1 << order, PAGES_PER_SECTION); ^ include/uapi/linux/kernel.h:11:47: note: in definition of macro '__ALIGN_KERNEL_MASK' #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask)) ^~~~ include/linux/kernel.h:58:22: note: in expansion of macro '__ALIGN_KERNEL' #define ALIGN(x, a) __ALIGN_KERNEL((x), (a)) ^~~~~~~~~~~~~~ mm/page_alloc.c:1624:34: note: in expansion of macro 'ALIGN' unsigned long nr_pages_needed = ALIGN(1 << order, PAGES_PER_SECTION); ^~~~~ In file included from include/asm-generic/bug.h:18:0, from arch/arc/include/asm/bug.h:32, from include/linux/bug.h:5, from include/linux/mmdebug.h:5, from include/linux/mm.h:9, from mm/page_alloc.c:18: mm/page_alloc.c: In function 'free_area_init_node': mm/page_alloc.c:6379:50: error: 'PAGES_PER_SECTION' undeclared (first use in this function); did you mean 'USEC_PER_SEC'? pgdat->static_init_pgcnt = min_t(unsigned long, PAGES_PER_SECTION, ^ include/linux/kernel.h:812:22: note: in definition of macro '__typecheck' (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^ include/linux/kernel.h:836:24: note: in expansion of macro '__safe_cmp' __builtin_choose_expr(__safe_cmp(x, y), \ ^~~~~~~~~~ include/linux/kernel.h:904:27: note: in expansion of macro '__careful_cmp' #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) ^~~~~~~~~~~~~ mm/page_alloc.c:6379:29: note: in expansion of macro 'min_t' pgdat->static_init_pgcnt = min_t(unsigned long, PAGES_PER_SECTION, ^~~~~ include/linux/kernel.h:836:2: error: first argument to '__builtin_choose_expr' not a constant __builtin_choose_expr(__safe_cmp(x, y), \ ^ include/linux/kernel.h:904:27: note: in expansion of macro '__careful_cmp' #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) ^~~~~~~~~~~~~ mm/page_alloc.c:6379:29: note: in expansion of macro 'min_t' pgdat->static_init_pgcnt = min_t(unsigned long, PAGES_PER_SECTION, ^~~~~ scripts/Makefile.build:317: recipe for target 'mm/page_alloc.o' failed Let's make the DEFERRED_STRUCT_PAGE_INIT explicitly depend on SPARSEMEM as the systems that support DISCONTIGMEM do not seem to have that huge amounts of memory that would make DEFERRED_STRUCT_PAGE_INIT relevant. Link: http://lkml.kernel.org/r/1530279308-24988-1-git-send-email-rppt@linux.vnet.ibm.com Signed-off-by: Mike Rapoport Acked-by: Michal Hocko Reviewed-by: Pavel Tatashin Tested-by: Randy Dunlap Cc: Pasha Tatashin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b9f9fc3844d82d9912309ea7a826b5c5b5e8eb5b Author: Andrey Ryabinin Date: Fri Aug 17 15:46:57 2018 -0700 mm/fadvise.c: fix signed overflow UBSAN complaint [ Upstream commit a718e28f538441a3b6612da9ff226973376cdf0f ] Signed integer overflow is undefined according to the C standard. The overflow in ksys_fadvise64_64() is deliberate, but since it is signed overflow, UBSAN complains: UBSAN: Undefined behaviour in mm/fadvise.c:76:10 signed integer overflow: 4 + 9223372036854775805 cannot be represented in type 'long long int' Use unsigned types to do math. Unsigned overflow is defined so UBSAN will not complain about it. This patch doesn't change generated code. [akpm@linux-foundation.org: add comment explaining the casts] Link: http://lkml.kernel.org/r/20180629184453.7614-1-aryabinin@virtuozzo.com Signed-off-by: Andrey Ryabinin Reported-by: Reviewed-by: Andrew Morton Cc: Alexander Potapenko Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dfb5ad65ca177bf030f4523b76849e42684bfe2a Author: Srikar Dronamraju Date: Fri Aug 17 20:24:39 2018 +0530 powerpc/topology: Get topology for shared processors at boot [ Upstream commit 2ea62630681027c455117aa471ea3ab8bb099ead ] On a shared LPAR, Phyp will not update the CPU associativity at boot time. Just after the boot system does recognize itself as a shared LPAR and trigger a request for correct CPU associativity. But by then the scheduler would have already created/destroyed its sched domains. This causes - Broken load balance across Nodes causing islands of cores. - Performance degradation esp if the system is lightly loaded - dmesg to wrongly report all CPUs to be in Node 0. - Messages in dmesg saying borken topology. - With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node sched domain"), can cause rcu stalls at boot up. The sched_domains_numa_masks table which is used to generate cpumasks is only created at boot time just before creating sched domains and never updated. Hence, its better to get the topology correct before the sched domains are created. For example on 64 core Power 8 shared LPAR, dmesg reports Brought up 512 CPUs Node 0 CPUs: 0-511 Node 1 CPUs: Node 2 CPUs: Node 3 CPUs: Node 4 CPUs: Node 5 CPUs: Node 6 CPUs: Node 7 CPUs: Node 8 CPUs: Node 9 CPUs: Node 10 CPUs: Node 11 CPUs: ... BUG: arch topology borken the DIE domain not a subset of the NUMA domain BUG: arch topology borken the DIE domain not a subset of the NUMA domain numactl/lscpu output will still be correct with cores spreading across all nodes: Socket(s): 64 NUMA node(s): 12 Model: 2.0 (pvr 004d 0200) Model name: POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): 0-7,32-39,64-71,96-103,176-183,272-279,368-375,464-471 NUMA node1 CPU(s): 8-15,40-47,72-79,104-111,184-191,280-287,376-383,472-479 NUMA node2 CPU(s): 16-23,48-55,80-87,112-119,192-199,288-295,384-391,480-487 NUMA node3 CPU(s): 24-31,56-63,88-95,120-127,200-207,296-303,392-399,488-495 NUMA node4 CPU(s): 208-215,304-311,400-407,496-503 NUMA node5 CPU(s): 168-175,264-271,360-367,456-463 NUMA node6 CPU(s): 128-135,224-231,320-327,416-423 NUMA node7 CPU(s): 136-143,232-239,328-335,424-431 NUMA node8 CPU(s): 216-223,312-319,408-415,504-511 NUMA node9 CPU(s): 144-151,240-247,336-343,432-439 NUMA node10 CPU(s): 152-159,248-255,344-351,440-447 NUMA node11 CPU(s): 160-167,256-263,352-359,448-455 Currently on this LPAR, the scheduler detects 2 levels of Numa and created numa sched domains for all CPUs, but it finds a single DIE domain consisting of all CPUs. Hence it deletes all numa sched domains. To address this, detect the shared processor and update topology soon after CPUs are setup so that correct topology is updated just before scheduler creates sched domain. With the fix, dmesg reports: numa: Node 0 CPUs: 0-7 32-39 64-71 96-103 176-183 272-279 368-375 464-471 numa: Node 1 CPUs: 8-15 40-47 72-79 104-111 184-191 280-287 376-383 472-479 numa: Node 2 CPUs: 16-23 48-55 80-87 112-119 192-199 288-295 384-391 480-487 numa: Node 3 CPUs: 24-31 56-63 88-95 120-127 200-207 296-303 392-399 488-495 numa: Node 4 CPUs: 208-215 304-311 400-407 496-503 numa: Node 5 CPUs: 168-175 264-271 360-367 456-463 numa: Node 6 CPUs: 128-135 224-231 320-327 416-423 numa: Node 7 CPUs: 136-143 232-239 328-335 424-431 numa: Node 8 CPUs: 216-223 312-319 408-415 504-511 numa: Node 9 CPUs: 144-151 240-247 336-343 432-439 numa: Node 10 CPUs: 152-159 248-255 344-351 440-447 numa: Node 11 CPUs: 160-167 256-263 352-359 448-455 and lscpu also reports: Socket(s): 64 NUMA node(s): 12 Model: 2.0 (pvr 004d 0200) Model name: POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): 0-7,32-39,64-71,96-103,176-183,272-279,368-375,464-471 NUMA node1 CPU(s): 8-15,40-47,72-79,104-111,184-191,280-287,376-383,472-479 NUMA node2 CPU(s): 16-23,48-55,80-87,112-119,192-199,288-295,384-391,480-487 NUMA node3 CPU(s): 24-31,56-63,88-95,120-127,200-207,296-303,392-399,488-495 NUMA node4 CPU(s): 208-215,304-311,400-407,496-503 NUMA node5 CPU(s): 168-175,264-271,360-367,456-463 NUMA node6 CPU(s): 128-135,224-231,320-327,416-423 NUMA node7 CPU(s): 136-143,232-239,328-335,424-431 NUMA node8 CPU(s): 216-223,312-319,408-415,504-511 NUMA node9 CPU(s): 144-151,240-247,336-343,432-439 NUMA node10 CPU(s): 152-159,248-255,344-351,440-447 NUMA node11 CPU(s): 160-167,256-263,352-359,448-455 Reported-by: Manjunatha H R Signed-off-by: Srikar Dronamraju [mpe: Trim / format change log] Tested-by: Michael Ellerman Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3940236559d1c0315fe51a818125f5046f649b9d Author: Jerome Brunet Date: Wed Aug 1 12:57:20 2018 +0200 pwm: meson: Fix mux clock names [ Upstream commit b96e9eb62841c519ba1db32d036628be3cdef91f ] Current clock name looks like this: /soc/bus@ffd00000/pwm@1b000#mux0 This is bad because CCF uses the clock to create a directory in clk debugfs. With such name, the directory creation (silently) fails and the debugfs entry end up being created at the debugfs root. With this change, the clock name will now be: ffd1b000.pwm#mux0 This matches the clock naming scheme used in the ethernet and mmc driver. It also fixes the problem with debugfs. Fixes: 36af66a79056 ("pwm: Convert to using %pOF instead of full_name") Signed-off-by: Jerome Brunet Acked-by: Neil Armstrong Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 21601166889151e938dc3726a5139e935d4cd79a Author: Michael J. Ruhl Date: Wed Aug 15 22:54:49 2018 -0700 IB/hfi1: Invalid NUMA node information can cause a divide by zero [ Upstream commit c513de490f808d8480346f9a58e6a4a5f3de12e7 ] If the system BIOS does not supply NUMA node information to the PCI devices, the NUMA node is selected by choosing the current node. This can lead to the following crash: divide error: 0000 SMP CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G IOE ------------ 3.10.0-693.21.1.el7.x86_64 #1 Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.01.01.0005.101720141054 10/17/2014 Workqueue: events work_for_cpu_fn task: ffff880174480fd0 ti: ffff880174488000 task.ti: ffff880174488000 RIP: 0010: [] hfi1_dev_affinity_init+0x129/0x6a0 [hfi1] RSP: 0018:ffff88017448bbf8 EFLAGS: 00010246 RAX: 0000000000000011 RBX: ffff88107ffba6c0 RCX: ffff88085c22e130 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880824ad0000 RBP: ffff88017448bc48 R08: 0000000000000011 R09: 0000000000000002 R10: ffff8808582b6ca0 R11: 0000000000003151 R12: ffff8808582b6ca0 R13: ffff8808582b6518 R14: ffff8808582b6010 R15: 0000000000000012 FS: 0000000000000000(0000) GS:ffff88085ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007efc707404f0 CR3: 0000000001a02000 CR4: 00000000001607f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: hfi1_init_dd+0x14b3/0x27a0 [hfi1] ? pcie_capability_write_word+0x46/0x70 ? hfi1_pcie_init+0xc0/0x200 [hfi1] do_init_one+0x153/0x4c0 [hfi1] ? sched_clock_cpu+0x85/0xc0 init_one+0x1b5/0x260 [hfi1] local_pci_probe+0x4a/0xb0 work_for_cpu_fn+0x1a/0x30 process_one_work+0x17f/0x440 worker_thread+0x278/0x3c0 ? manage_workers.isra.24+0x2a0/0x2a0 kthread+0xd1/0xe0 ? insert_kthread_work+0x40/0x40 ret_from_fork+0x77/0xb0 ? insert_kthread_work+0x40/0x40 If the BIOS is not supplying NUMA information: - set the default table count to 1 for all possible nodes - select node 0 (instead of current NUMA) node to get consistent performance - generate an error indicating that the BIOS should be upgraded Reviewed-by: Gary Leshner Reviewed-by: Mike Marciniszyn Signed-off-by: Michael J. Ruhl Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8fb30bf797fecbe7499837a4530d62721c8fcc81 Author: Hans de Goede Date: Sun Aug 12 12:53:21 2018 +0200 i2c: core: ACPI: Make acpi_gsb_i2c_read_bytes() check i2c_transfer return value [ Upstream commit 0a30446c0dca3483c384b54a431cc951e15f7e79 ] Currently acpi_gsb_i2c_read_bytes() directly returns i2c_transfer's return value. i2c_transfer returns a value < 0 on error and 2 (for 2 successfully executed transfers) on success. But the ACPI code expects 0 on success, so currently acpi_gsb_i2c_read_bytes()'s caller does: if (status > 0) status = 0; This commit makes acpi_gsb_i2c_read_bytes() return a value which can be directly consumed by the ACPI code, mirroring acpi_gsb_i2c_write_bytes(), this commit also makes acpi_gsb_i2c_read_bytes() explitcly check that i2c_transfer returns 2, rather then accepting any value > 0. Signed-off-by: Hans de Goede Acked-by: Mika Westerberg Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 106fabc844a1b570b5a21f98fab8a17f74c2f4e3 Author: Arnd Bergmann Date: Fri Aug 17 12:01:36 2018 +0200 x86/mce: Add notifier_block forward declaration [ Upstream commit 704ae091b061082b37a9968621af4c290c641d50 ] Without linux/irq.h, there is no declaration of notifier_block, leading to a build warning: In file included from arch/x86/kernel/cpu/mcheck/threshold.c:10: arch/x86/include/asm/mce.h:151:46: error: 'struct notifier_block' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] It's sufficient to declare the struct tag here, which avoids pulling in more header files. Fixes: 447ae3166702 ("x86: Don't include linux/irq.h from asm/hardirq.h") Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Gleixner Cc: Nicolai Stange Cc: "H. Peter Anvin" Cc: Greg Kroah-Hartman Cc: Borislav Petkov Link: https://lkml.kernel.org/r/20180817100156.3009043-1-arnd@arndb.de Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 34f91b3d0e55c557b9ba91cb22a71d55aff85bf0 Author: Suzuki K Poulose Date: Wed Jul 18 10:18:45 2018 +0100 virtio: pci-legacy: Validate queue pfn [ Upstream commit 69599206ea9a3f8f2e94d46580579cbf9d08ad6c ] Legacy PCI over virtio uses a 32bit PFN for the queue. If the queue pfn is too large to fit in 32bits, which we could hit on arm64 systems with 52bit physical addresses (even with 64K page size), we simply miss out a proper link to the other side of the queue. Add a check to validate the PFN, rather than silently breaking the devices. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Marc Zyngier Cc: Christoffer Dall Cc: Peter Maydel Cc: Jean-Philippe Brucker Signed-off-by: Suzuki K Poulose Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cad3dc0a4563987e17868b04110417d7ea5c6e32 Author: Dan Carpenter Date: Thu Aug 2 11:38:23 2018 +0300 apparmor: fix an error code in __aa_create_ns() [ Upstream commit 0a6b29230ec336189bab32498df3f06c8a6944d8 ] We should return error pointers in this function. Returning NULL results in a NULL dereference in the caller. Fixes: 73688d1ed0b8 ("apparmor: refactor prepare_ns() and make usable from different views") Signed-off-by: Dan Carpenter Signed-off-by: John Johansen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fb6fc1b6a4080baae342e8e9bda8bd81e30d86b1 Author: Randy Dunlap Date: Wed Aug 15 12:30:38 2018 -0700 scripts: modpost: check memory allocation results [ Upstream commit 1f3aa9002dc6a0d59a4b599b4fc8f01cf43ef014 ] Fix missing error check for memory allocation functions in scripts/mod/modpost.c. Fixes kernel bugzilla #200319: https://bugzilla.kernel.org/show_bug.cgi?id=200319 Signed-off-by: Randy Dunlap Cc: Yuexing Wang Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 13892551c76fa31e2a0226c1d4beda5d31bbe474 Author: Johannes Berg Date: Wed Aug 22 11:49:04 2018 +0200 workqueue: re-add lockdep dependencies for flushing [ Upstream commit 87915adc3f0acdf03c776df42e308e5a155c19af ] In flush_work(), we need to create a lockdep dependency so that the following scenario is appropriately tagged as a problem: work_function() { mutex_lock(&mutex); ... } other_function() { mutex_lock(&mutex); flush_work(&work); // or cancel_work_sync(&work); } This is a problem since the work might be running and be blocked on trying to acquire the mutex. Similarly, in flush_workqueue(). These were removed after cross-release partially caught these problems, but now cross-release was reverted anyway. IMHO the removal was erroneous anyway though, since lockdep should be able to catch potential problems, not just actual ones, and cross-release would only have caught the problem when actually invoking wait_for_completion(). Fixes: fd1a5b04dfb8 ("workqueue: Remove now redundant lock acquisitions wrt. workqueue flushes") Signed-off-by: Johannes Berg Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b7a3d36d6c329bf6d78326a8e89ed65d5deea063 Author: Johannes Berg Date: Wed Aug 22 11:49:03 2018 +0200 workqueue: skip lockdep wq dependency in cancel_work_sync() [ Upstream commit d6e89786bed977f37f55ffca11e563f6d2b1e3b5 ] In cancel_work_sync(), we can only have one of two cases, even with an ordered workqueue: * the work isn't running, just cancelled before it started * the work is running, but then nothing else can be on the workqueue before it Thus, we need to skip the lockdep workqueue dependency handling, otherwise we get false positive reports from lockdep saying that we have a potential deadlock when the workqueue also has other work items with locking, e.g. work1_function() { mutex_lock(&mutex); ... } work2_function() { /* nothing */ } other_function() { queue_work(ordered_wq, &work1); queue_work(ordered_wq, &work2); mutex_lock(&mutex); cancel_work_sync(&work2); } As described above, this isn't a problem, but lockdep will currently flag it as if cancel_work_sync() was flush_work(), which *is* a problem. Signed-off-by: Johannes Berg Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 798d80a612ddb70d5c62b767227146427e14a4be Author: OGAWA Hirofumi Date: Tue Aug 21 21:59:44 2018 -0700 fat: validate ->i_start before using [ Upstream commit 0afa9626667c3659ef8bd82d42a11e39fedf235c ] On corrupted FATfs may have invalid ->i_start. To handle it, this checks ->i_start before using, and return proper error code. Link: http://lkml.kernel.org/r/87o9f8y1t5.fsf_-_@mail.parknet.co.jp Signed-off-by: OGAWA Hirofumi Reported-by: Anatoly Trosinenko Tested-by: Anatoly Trosinenko Cc: Alan Cox Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 739956488c79f23b4a603132eec107b63774e1db Author: James Morse Date: Tue Aug 21 21:54:48 2018 -0700 fs/proc/kcore.c: use __pa_symbol() for KCORE_TEXT list entries [ Upstream commit df865e8337c397471b95f51017fea559bc8abb4a ] elf_kcore_store_hdr() uses __pa() to find the physical address of KCORE_RAM or KCORE_TEXT entries exported as program headers. This trips CONFIG_DEBUG_VIRTUAL's checks, as the KCORE_TEXT entries are not in the linear map. Handle these two cases separately, using __pa_symbol() for the KCORE_TEXT entries. Link: http://lkml.kernel.org/r/20180711131944.15252-1-james.morse@arm.com Signed-off-by: James Morse Cc: Alexey Dobriyan Cc: Omar Sandoval Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 69177abd89a540f1090fc5a38a6b5b51bd966575 Author: Marc Zyngier Date: Fri Aug 24 16:06:37 2018 +0100 iommu/rockchip: Move irq request past pm_runtime_enable [ Upstream commit 1aa55ca9b14af6cfd987ce4fdaf548f7067a5d07 ] Enabling the interrupt early, before power has been applied to the device, can result in an interrupt being delivered too early if: - the IOMMU shares an interrupt with a VOP - the VOP has a pending interrupt (after a kexec, for example) In these conditions, we end-up taking the interrupt without the IOMMU being ready to handle the interrupt (not powered on). Moving the interrupt request past the pm_runtime_enable() call makes sure we can at least access the IOMMU registers. Note that this is only a partial fix, and that the VOP interrupt will still be screaming until the VOP driver kicks in, which advocates for a more synchronized interrupt enabling/disabling approach. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner Signed-off-by: Marc Zyngier Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d30de7347e2993a99a647fa5887ed227466e17ab Author: Ernesto A. Fernández Date: Thu Aug 23 17:00:25 2018 -0700 hfsplus: fix NULL dereference in hfsplus_lookup() [ Upstream commit a7ec7a4193a2eb3b5341243fc0b621c1ac9e4ec4 ] An HFS+ filesystem can be mounted read-only without having a metadata directory, which is needed to support hardlinks. But if the catalog data is corrupted, a directory lookup may still find dentries claiming to be hardlinks. hfsplus_lookup() does check that ->hidden_dir is not NULL in such a situation, but mistakenly does so after dereferencing it for the first time. Reorder this check to prevent a crash. This happens when looking up corrupted catalog data (dentry) on a filesystem with no metadata directory (this could only ever happen on a read-only mount). Wen Xu sent the replication steps in detail to the fsdevel list: https://bugzilla.kernel.org/show_bug.cgi?id=200297 Link: http://lkml.kernel.org/r/20180712215344.q44dyrhymm4ajkao@eaf Signed-off-by: Ernesto A. Fernández Reported-by: Wen Xu Cc: Viacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5a476ca109bc0043e868c7bb61221f52193eac10 Author: Marc Zyngier Date: Fri Aug 24 16:06:36 2018 +0100 iommu/rockchip: Handle errors returned from PM framework [ Upstream commit 3fc7c5c0cff3150e471f5fd12f59971c6d2c6513 ] pm_runtime_get_if_in_use can fail: either PM has been disabled altogether (-EINVAL), or the device hasn't been enabled yet (0). Sadly, the Rockchip IOMMU driver tends to conflate the two things by considering a non-zero return value as successful. This has the consequence of hiding other bugs, so let's handle this case throughout the driver, with a WARN_ON_ONCE so that we can try and work out what happened. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner Signed-off-by: Marc Zyngier Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9f01147244738aad6e758862ab3426d14d237511 Author: Arnd Bergmann Date: Tue Aug 21 21:59:34 2018 -0700 reiserfs: change j_timestamp type to time64_t [ Upstream commit 8b73ce6a4bae4fe12bcb2c361c0da4183c2e1b6f ] This uses the deprecated time_t type but is write-only, and could be removed, but as Jeff explains, having a timestamp can be usefule for post-mortem analysis in crash dumps. In order to remove one of the last instances of time_t, this changes the type to time64_t, same as j_trans_start_time. Link: http://lkml.kernel.org/r/20180622133315.221210-1-arnd@arndb.de Signed-off-by: Arnd Bergmann Cc: Jan Kara Cc: Jeff Mahoney Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df67ae0bd579b15aab9d9aaabdd7adab4247ede1 Author: Arnd Bergmann Date: Thu Aug 23 17:00:55 2018 -0700 fs/proc/vmcore.c: hide vmcoredd_mmap_dumps() for nommu builds [ Upstream commit a2036a1ef2ee91acab01a0ae4a534070691a42ec ] Without CONFIG_MMU, we get a build warning: fs/proc/vmcore.c:228:12: error: 'vmcoredd_mmap_dumps' defined but not used [-Werror=unused-function] static int vmcoredd_mmap_dumps(struct vm_area_struct *vma, unsigned long dst, The function is only referenced from an #ifdef'ed caller, so this uses the same #ifdef around it. Link: http://lkml.kernel.org/r/20180525213526.2117790-1-arnd@arndb.de Fixes: 7efe48df8a3d ("vmcore: append device dumps to vmcore as elf notes") Signed-off-by: Arnd Bergmann Cc: Ganesh Goudar Cc: "David S. Miller" Cc: Rahul Lakkireddy Cc: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0de1a99801ff7db0b2017e80b5b52ec42e09578a Author: Jann Horn Date: Tue Aug 21 22:00:58 2018 -0700 fork: don't copy inconsistent signal handler state to child [ Upstream commit 06e62a46bbba20aa5286102016a04214bb446141 ] Before this change, if a multithreaded process forks while one of its threads is changing a signal handler using sigaction(), the memcpy() in copy_sighand() can race with the struct assignment in do_sigaction(). It isn't clear whether this can cause corruption of the userspace signal handler pointer, but it definitely can cause inconsistency between different fields of struct sigaction. Take the appropriate spinlock to avoid this. I have tested that this patch prevents inconsistency between sa_sigaction and sa_flags, which is possible before this patch. Link: http://lkml.kernel.org/r/20180702145108.73189-1-jannh@google.com Signed-off-by: Jann Horn Acked-by: Michal Hocko Reviewed-by: Andrew Morton Cc: Rik van Riel Cc: "Peter Zijlstra (Intel)" Cc: Kees Cook Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 19ca1a2830e9620fc5a8b8a3287d4ca12d83ac48 Author: Laura Abbott Date: Fri Aug 17 14:43:54 2018 -0700 sunrpc: Don't use stack buffer with scatterlist [ Upstream commit 44090cc876926277329e1608bafc01b9f6da627f ] Fedora got a bug report from NFS: kernel BUG at include/linux/scatterlist.h:143! ... RIP: 0010:sg_init_one+0x7d/0x90 .. make_checksum+0x4e7/0x760 [rpcsec_gss_krb5] gss_get_mic_kerberos+0x26e/0x310 [rpcsec_gss_krb5] gss_marshal+0x126/0x1a0 [auth_rpcgss] ? __local_bh_enable_ip+0x80/0xe0 ? call_transmit_status+0x1d0/0x1d0 [sunrpc] call_transmit+0x137/0x230 [sunrpc] __rpc_execute+0x9b/0x490 [sunrpc] rpc_run_task+0x119/0x150 [sunrpc] nfs4_run_exchange_id+0x1bd/0x250 [nfsv4] _nfs4_proc_exchange_id+0x2d/0x490 [nfsv4] nfs41_discover_server_trunking+0x1c/0xa0 [nfsv4] nfs4_discover_server_trunking+0x80/0x270 [nfsv4] nfs4_init_client+0x16e/0x240 [nfsv4] ? nfs_get_client+0x4c9/0x5d0 [nfs] ? _raw_spin_unlock+0x24/0x30 ? nfs_get_client+0x4c9/0x5d0 [nfs] nfs4_set_client+0xb2/0x100 [nfsv4] nfs4_create_server+0xff/0x290 [nfsv4] nfs4_remote_mount+0x28/0x50 [nfsv4] mount_fs+0x3b/0x16a vfs_kern_mount.part.35+0x54/0x160 nfs_do_root_mount+0x7f/0xc0 [nfsv4] nfs4_try_mount+0x43/0x70 [nfsv4] ? get_nfs_version+0x21/0x80 [nfs] nfs_fs_mount+0x789/0xbf0 [nfs] ? pcpu_alloc+0x6ca/0x7e0 ? nfs_clone_super+0x70/0x70 [nfs] ? nfs_parse_mount_options+0xb40/0xb40 [nfs] mount_fs+0x3b/0x16a vfs_kern_mount.part.35+0x54/0x160 do_mount+0x1fd/0xd50 ksys_mount+0xba/0xd0 __x64_sys_mount+0x21/0x30 do_syscall_64+0x60/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe This is BUG_ON(!virt_addr_valid(buf)) triggered by using a stack allocated buffer with a scatterlist. Convert the buffer for rc4salt to be dynamically allocated instead. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1615258 Signed-off-by: Laura Abbott Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3d872bd5ae87bb19209a6e733ea46b45dda682cb Author: Ernesto A. Fernández Date: Thu Aug 23 17:00:31 2018 -0700 hfs: prevent crash on exit from failed search [ Upstream commit dc2572791d3a41bab94400af2b6bca9d71ccd303 ] hfs_find_exit() expects fd->bnode to be NULL after a search has failed. hfs_brec_insert() may instead set it to an error-valued pointer. Fix this to prevent a crash. Link: http://lkml.kernel.org/r/53d9749a029c41b4016c495fc5838c9dba3afc52.1530294815.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Cc: Anatoly Trosinenko Cc: Viacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84ac254ed28764c425a97c5af69614a8666aa005 Author: Tetsuo Handa Date: Tue Aug 21 21:59:12 2018 -0700 hfsplus: don't return 0 when fill_super() failed [ Upstream commit 7464726cb5998846306ed0a7d6714afb2e37b25d ] syzbot is reporting NULL pointer dereference at mount_fs() [1]. This is because hfsplus_fill_super() is by error returning 0 when hfsplus_fill_super() detected invalid filesystem image, and mount_bdev() is returning NULL because dget(s->s_root) == NULL if s->s_root == NULL, and mount_fs() is accessing root->d_sb because IS_ERR(root) == false if root == NULL. Fix this by returning -EINVAL when hfsplus_fill_super() detected invalid filesystem image. [1] https://syzkaller.appspot.com/bug?id=21acb6850cecbc960c927229e597158cf35f33d0 Link: http://lkml.kernel.org/r/d83ce31a-874c-dd5b-f790-41405983a5be@I-love.SAKURA.ne.jp Signed-off-by: Tetsuo Handa Reported-by: syzbot Reviewed-by: Ernesto A. Fernández Reviewed-by: Andrew Morton Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8043c90bada1f89271325c0ff765d5a40c7a6f5e Author: Ronnie Sahlberg Date: Wed Aug 22 12:19:24 2018 +1000 cifs: check if SMB2 PDU size has been padded and suppress the warning [ Upstream commit e6c47dd0da1e3a484e778046fc10da0b20606a86 ] Some SMB2/3 servers, Win2016 but possibly others too, adds padding not only between PDUs in a compound but also to the final PDU. This padding extends the PDU to a multiple of 8 bytes. Check if the unexpected length looks like this might be the case and avoid triggering the log messages for : "SMB2 server sent bad RFC1001 len %d not %d\n" Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ded39314abc0ffb4c0d9ed0c6c6a82f0e4f4d2d8 Author: Stephen Hemminger Date: Tue Aug 21 10:40:38 2018 -0700 hv_netvsc: ignore devices that are not PCI [ Upstream commit b93c1b5ac8643cc08bb74fa8ae21d6c63dfcb23d ] Registering another device with same MAC address (such as TAP, VPN or DPDK KNI) will confuse the VF autobinding logic. Restrict the search to only run if the device is known to be a PCI attached VF. Fixes: e8ff40d4bff1 ("hv_netvsc: improve VF device matching") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c56a2888ac2b16685ab82b62203e096b071a4aa5 Author: Jason Wang Date: Fri Aug 24 16:53:13 2018 +0800 vhost: correctly check the iova range when waking virtqueue [ Upstream commit 2d66f997f0545c8f7fc5cf0b49af1decb35170e7 ] We don't wakeup the virtqueue if the first byte of pending iova range is the last byte of the range we just got updated. This will lead a virtqueue to wait for IOTLB updating forever. Fixing by correct the check and wake up the virtqueue in this case. Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API") Reported-by: Peter Xu Signed-off-by: Jason Wang Reviewed-by: Peter Xu Tested-by: Peter Xu Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a6fddbba3e638c64a6a8a55a5855bb2d06cdbdad Author: Ido Schimmel Date: Fri Aug 24 15:41:35 2018 +0300 mlxsw: spectrum_switchdev: Do not leak RIFs when removing bridge [ Upstream commit 602b74eda81311dbdb5dbab08c30f789f648ebdc ] When a bridge device is removed, the VLANs are flushed from each configured port. This causes the ports to decrement the reference count on the associated FIDs (filtering identifier). If the reference count of a FID is 1 and it has a RIF (router interface), then this RIF is destroyed. However, if no port is member in the VLAN for which a RIF exists, then the RIF will continue to exist after the removal of the bridge. To reproduce: # ip link add name br0 type bridge vlan_filtering 1 # ip link set dev swp1 master br0 # ip link add link br0 name br0.10 type vlan id 10 # ip address add 192.0.2.0/24 dev br0.10 # ip link del dev br0 The RIF associated with br0.10 continues to exist. Fix this by iterating over all the bridge device uppers when it is destroyed and take care of destroying their RIFs. Fixes: 99f44bb3527b ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices") Signed-off-by: Ido Schimmel Reviewed-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 98c4cc4c81e812f6d16544c776d4a2f825e86aa5 Author: Xin Long Date: Mon Aug 27 18:38:31 2018 +0800 sctp: hold transport before accessing its asoc in sctp_transport_get_next [ Upstream commit bab1be79a5169ac748d8292b20c86d874022d7ba ] As Marcelo noticed, in sctp_transport_get_next, it is iterating over transports but then also accessing the association directly, without checking any refcnts before that, which can cause an use-after-free Read. So fix it by holding transport before accessing the association. With that, sctp_transport_hold calls can be removed in the later places. Fixes: 626d16f50f39 ("sctp: export some apis or variables for sctp_diag and reuse some for proc") Reported-by: syzbot+fe62a0c9aa6a85c6de16@syzkaller.appspotmail.com Signed-off-by: Xin Long Acked-by: Neil Horman Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit eb4f28d8f9e01854d803b0a49df824903e90be92 Author: Jakub Kicinski Date: Wed Aug 29 12:46:08 2018 -0700 nfp: wait for posted reconfigs when disabling the device [ Upstream commit 9ad716b95fd6c6be46a4f2d5936e514b5bcd744d ] To avoid leaking a running timer we need to wait for the posted reconfigs after netdev is unregistered. In common case the process of deinitializing the device will perform synchronous reconfigs which wait for posted requests, but especially with VXLAN ports being actively added and removed there can be a race condition leaving a timer running after adapter structure is freed leading to a crash. Add an explicit flush after deregistering and for a good measure a warning to check if timer is running just before structures are freed. Fixes: 3d780b926a12 ("nfp: add async reconfiguration mechanism") Signed-off-by: Jakub Kicinski Reviewed-by: Dirk van der Merwe Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ade76212f72a41c34c01c375db87bfa8d56cde5f Author: Haishuang Yan Date: Mon Aug 20 10:51:05 2018 +0800 ip6_vti: fix a null pointer deference when destroy vti6 tunnel [ Upstream commit 9c86336c15db1c48cbaddff56caf2be0a930e991 ] If load ip6_vti module and create a network namespace when set fb_tunnels_only_for_init_net to 1, then exit the namespace will cause following crash: [ 6601.677036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 6601.679057] PGD 8000000425eca067 P4D 8000000425eca067 PUD 424292067 PMD 0 [ 6601.680483] Oops: 0000 [#1] SMP PTI [ 6601.681223] CPU: 7 PID: 93 Comm: kworker/u16:1 Kdump: loaded Tainted: G E 4.18.0+ #3 [ 6601.683153] Hardware name: Fedora Project OpenStack Nova, BIOS seabios-1.7.5-11.el7 04/01/2014 [ 6601.684919] Workqueue: netns cleanup_net [ 6601.685742] RIP: 0010:vti6_exit_batch_net+0x87/0xd0 [ip6_vti] [ 6601.686932] Code: 7b 08 48 89 e6 e8 b9 ea d3 dd 48 8b 1b 48 85 db 75 ec 48 83 c5 08 48 81 fd 00 01 00 00 75 d5 49 8b 84 24 08 01 00 00 48 89 e6 <48> 8b 78 08 e8 90 ea d3 dd 49 8b 45 28 49 39 c6 4c 8d 68 d8 75 a1 [ 6601.690735] RSP: 0018:ffffa897c2737de0 EFLAGS: 00010246 [ 6601.691846] RAX: 0000000000000000 RBX: 0000000000000000 RCX: dead000000000200 [ 6601.693324] RDX: 0000000000000015 RSI: ffffa897c2737de0 RDI: ffffffff9f2ea9e0 [ 6601.694824] RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000000000000 [ 6601.696314] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8dc323c07e00 [ 6601.697812] R13: ffff8dc324a63100 R14: ffffa897c2737e30 R15: ffffa897c2737e30 [ 6601.699345] FS: 0000000000000000(0000) GS:ffff8dc33fdc0000(0000) knlGS:0000000000000000 [ 6601.701068] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6601.702282] CR2: 0000000000000008 CR3: 0000000424966002 CR4: 00000000001606e0 [ 6601.703791] Call Trace: [ 6601.704329] cleanup_net+0x1b4/0x2c0 [ 6601.705268] process_one_work+0x16c/0x370 [ 6601.706145] worker_thread+0x49/0x3e0 [ 6601.706942] kthread+0xf8/0x130 [ 6601.707626] ? rescuer_thread+0x340/0x340 [ 6601.708476] ? kthread_bind+0x10/0x10 [ 6601.709266] ret_from_fork+0x35/0x40 Reproduce: modprobe ip6_vti echo 1 > /proc/sys/net/core/fb_tunnels_only_for_init_net unshare -n exit This because ip6n->tnls_wc[0] point to fallback device in default, but in non-default namespace, ip6n->tnls_wc[0] will be NULL, so add the NULL check comparatively. Fixes: e2948e5af8ee ("ip6_vti: fix creating fallback tunnel device for vti6") Signed-off-by: Haishuang Yan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b7f172c4b69292c6b828810305baba5e7ba1ad44 Author: Haishuang Yan Date: Sun Aug 19 15:05:05 2018 +0800 ip6_vti: fix creating fallback tunnel device for vti6 [ Upstream commit e2948e5af8eeb6c945000772b7613b0323a0a203 ] When set fb_tunnels_only_for_init_net to 1, don't create fallback tunnel device for vti6 when a new namespace is created. Tested: [root@builder2 ~]# modprobe ip6_tunnel [root@builder2 ~]# modprobe ip6_vti [root@builder2 ~]# echo 1 > /proc/sys/net/core/fb_tunnels_only_for_init_net [root@builder2 ~]# unshare -n [root@builder2 ~]# ip link 1: lo: mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 Signed-off-by: Haishuang Yan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit aff7606467220a8abb3af2cd6b6d732b4f1513a0 Author: Jerome Brunet Date: Fri Aug 24 11:04:40 2018 +0200 Revert "net: stmmac: Do not keep rearming the coalesce timer in stmmac_xmit" [ Upstream commit e5133f2f1261f8ab412e7fc5e3694c9f84328f89 ] This reverts commit 4ae0169fd1b3c792b66be58995b7e6b629919ecf. This change in the handling of the coalesce timer is causing regression on (at least) amlogic platforms. Network will break down very quickly (a few seconds) after starting a download. This can easily be reproduced using iperf3 for example. The problem has been reported on the S805, S905, S912 and A113 SoCs (Realtek and Micrel PHYs) and it is likely impacting all Amlogics platforms using Gbit ethernet No problem was seen with the platform using 10/100 only PHYs (GXL internal) Reverting change brings things back to normal and allows to use network again until we better understand the problem with the coalesce timer. Cc: Jose Abreu Cc: Joao Pinto Cc: Vitor Soares Cc: Giuseppe Cavallaro Cc: Alexandre Torgue Cc: Corentin Labbe Signed-off-by: Jerome Brunet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e366979eb8f0c3ad6446abbd81bcb3d4ac569cb3 Author: Azat Khuzhin Date: Sun Aug 26 17:03:09 2018 +0300 r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices [ Upstream commit 05212ba8132b42047ab5d63d759c6f9c28e7eab5 ] I have two Ethernet adapters: r8169 0000:03:01.0 eth0: RTL8169sb/8110sb, 00:14:d1:14:2d:49, XID 10000000, IRQ 18 r8169 0000:01:00.0 eth0: RTL8168e/8111e, 64:66:b3:11:14:5d, XID 2c200000, IRQ 30 And after upgrading from linux 4.15 [1] to linux 4.18+ [2] RTL8169sb failed to receive any packets. tcpdump shows a lot of checksum mismatch. [1]: a0f79386a4968b4925da6db2d1daffd0605a4402 [2]: 0519359784328bfa92bf0931bf0cff3b58c16932 (4.19 merge window opened) I started bisecting and the found that [3] breaks it. According to [4]: "For 8110S, 8110SB, and 8110SC series, the initial value of RxConfig needs to be set after the tx/rx is enabled." So I moved rtl_init_rxcfg() after enabling tx/rs and now my adapter works (RTL8168e works too). [3]: 3559d81e76bfe3803e89f2e04cf6ef7ab4f3aace [4]: e542a2269f232d61270ceddd42b73a4348dee2bb ("r8169: adjust the RxConfig settings.") Also drop "rx" from rtl_set_rx_tx_config_registers(), since it does nothing with it already. Fixes: 3559d81e76bfe3803e89f2e04cf6ef7ab4f3aace ("r8169: simplify rtl_hw_start_8169") Cc: Heiner Kallweit Cc: David S. Miller Cc: netdev@vger.kernel.org Cc: Realtek linux nic maintainers Signed-off-by: Azat Khuzhin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0981fb60a006bf26b9954601d47621f8720d8ab9 Author: Tariq Toukan Date: Mon Sep 3 18:06:24 2018 +0300 net/mlx5: Fix SQ offset in QPs with small RQ [ Upstream commit 639505d4397b8c654a8e2616f9cb70ece40c83f9 ] Correct the formula for calculating the RQ page remainder, which should be in byte granularity. The result will be non-zero only for RQs smaller than PAGE_SIZE, as an RQ size is a power of 2. Divide this by the SQ stride (MLX5_SEND_WQE_BB) to get the SQ offset in strides granularity. Fixes: d7037ad73daa ("net/mlx5: Fix QP fragmented buffer allocation") Signed-off-by: Tariq Toukan Reviewed-by: Eran Ben Elisha Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2ff8354c2317b8c50f5565230e3ca842c4aebb6c Author: David Ahern Date: Mon Aug 20 13:02:41 2018 -0700 net/ipv6: Put lwtstate when destroying fib6_info [ Upstream commit 80f1a0f4e0cd4bfc8a74fc1c39843a6e7b206b95 ] Prior to the introduction of fib6_info lwtstate was managed by the dst code. With fib6_info releasing lwtstate needs to be done when the struct is freed. Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes") Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b24b39afa4112eb4ecb236bc20785fa507c94888 Author: David Ahern Date: Thu Aug 30 14:15:43 2018 -0700 net/ipv6: Only update MTU metric if it set [ Upstream commit 15a81b418e22a9aa4a0504471fdcb0f4ebf69b96 ] Jan reported a regression after an update to 4.18.5. In this case ipv6 default route is setup by systemd-networkd based on data from an RA. The RA contains an MTU of 1492 which is used when the route is first inserted but then systemd-networkd pushes down updates to the default route without the mtu set. Prior to the change to fib6_info, metrics such as MTU were held in the dst_entry and rt6i_pmtu in rt6_info contained an update to the mtu if any. ip6_mtu would look at rt6i_pmtu first and use it if set. If not, the value from the metrics is used if it is set and finally falling back to the idev value. After the fib6_info change metrics are contained in the fib6_info struct and there is no equivalent to rt6i_pmtu. To maintain consistency with the old behavior the new code should only reset the MTU in the metrics if the route update has it set. Fixes: d4ead6b34b67 ("net/ipv6: move metrics from dst to rt6_info") Reported-by: Jan Janssen Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6568eedbe9393a64968a5017041bbe7ad594249f Author: Hangbin Liu Date: Thu Aug 23 11:31:37 2018 +0800 net/ipv6: init ip6 anycast rt->dst.input as ip6_input [ Upstream commit d23c4b6336ef30898dcdff351f21e633e7a64930 ] Commit 6edb3c96a5f02 ("net/ipv6: Defer initialization of dst to data path") forgot to handle anycast route and init anycast rt->dst.input to ip6_forward. Fix it by setting anycast rt->dst.input back to ip6_input. Fixes: 6edb3c96a5f02 ("net/ipv6: Defer initialization of dst to data path") Signed-off-by: Hangbin Liu Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 078e7d112fbc54b78e37412d5503c8aa6f35f71a Author: Alexey Kodanev Date: Thu Aug 30 19:11:24 2018 +0300 ipv6: don't get lwtstate twice in ip6_rt_copy_init() [ Upstream commit 93bbadd6e0a2a58e49d265b9b1aa58e621b60a26 ] Commit 80f1a0f4e0cd ("net/ipv6: Put lwtstate when destroying fib6_info") partially fixed the kmemleak [1], lwtstate can be copied from fib6_info, with ip6_rt_copy_init(), and it should be done only once there. rt->dst.lwtstate is set by ip6_rt_init_dst(), at the start of the function ip6_rt_copy_init(), so there is no need to get it again at the end. With this patch, lwtstate also isn't copied from RTF_REJECT routes. [1]: unreferenced object 0xffff880b6aaa14e0 (size 64): comm "ip", pid 10577, jiffies 4295149341 (age 1273.903s) hex dump (first 32 bytes): 01 00 04 00 04 00 00 00 10 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000018664623>] lwtunnel_build_state+0x1bc/0x420 [<00000000b73aa29a>] ip6_route_info_create+0x9f7/0x1fd0 [<00000000ee2c5d1f>] ip6_route_add+0x14/0x70 [<000000008537b55c>] inet6_rtm_newroute+0xd9/0xe0 [<000000002acc50f5>] rtnetlink_rcv_msg+0x66f/0x8e0 [<000000008d9cd381>] netlink_rcv_skb+0x268/0x3b0 [<000000004c893c76>] netlink_unicast+0x417/0x5a0 [<00000000f2ab1afb>] netlink_sendmsg+0x70b/0xc30 [<00000000890ff0aa>] sock_sendmsg+0xb1/0xf0 [<00000000a2e7b66f>] ___sys_sendmsg+0x659/0x950 [<000000001e7426c8>] __sys_sendmsg+0xde/0x170 [<00000000fe411443>] do_syscall_64+0x9f/0x4a0 [<000000001be7b28b>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<000000006d21f353>] 0xffffffffffffffff Fixes: 6edb3c96a5f0 ("net/ipv6: Defer initialization of dst to data path") Signed-off-by: Alexey Kodanev Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 23f64bad173ccafd585fe2f215c1d3fda846af0a Author: Ahmad Fatoum Date: Tue Aug 21 17:35:48 2018 +0200 net: macb: Fix regression breaking non-MDIO fixed-link PHYs [ Upstream commit ab5f11055fdf8dfc3ddbd89e8e3cc550de41d1d3 ] commit 739de9a1563a ("net: macb: Reorganize macb_mii bringup") broke initializing macb on the EVB-KSZ9477 eval board. There, of_mdiobus_register was called even for the fixed-link representing the RGMII-link to the switch with the result that the driver attempts to enumerate PHYs on a non-existent MDIO bus: libphy: MACB_mii_bus: probed mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0 [snip] mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31 The "MDIO" bus registration succeeds regardless, having claimed the reset GPIO, and calling of_phy_register_fixed_link later on fails because it tries to claim the same GPIO: macb f0028000.ethernet: broken fixed-link specification Fix this by registering the fixed-link before calling mdiobus_register. Fixes: 739de9a1563a ("net: macb: Reorganize macb_mii bringup") Signed-off-by: Ahmad Fatoum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 630403ba91833c536016d6ce0116a14eda6cbeb3 Author: Xin Long Date: Mon Aug 27 18:41:32 2018 +0800 erspan: set erspan_ver to 1 by default when adding an erspan dev [ Upstream commit 84581bdae9587023cea1d139523f0ef0f28bd88d ] After erspan_ver is introudced, if erspan_ver is not set in iproute, its value will be left 0 by default. Since Commit 02f99df1875c ("erspan: fix invalid erspan version."), it has broken the traffic due to the version check in erspan_xmit if users are not aware of 'erspan_ver' param, like using an old version of iproute. To fix this compatibility problem, it sets erspan_ver to 1 by default when adding an erspan dev in erspan_setup. Note that we can't do it in ipgre_netlink_parms, as this function is also used by ipgre_changelink. Fixes: 02f99df1875c ("erspan: fix invalid erspan version.") Reported-by: Jianlin Shi Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0f6387a1087de4d594ba67e301a752aaa31082dc Author: Xin Long Date: Mon Aug 27 18:40:18 2018 +0800 sctp: remove useless start_fail from sctp_ht_iter in proc [ Upstream commit 834539e69a5fe2aab33cc777ccfd4a4fcc5b9770 ] After changing rhashtable_walk_start to return void, start_fail would never be set other value than 0, and the checking for start_fail is pointless, so remove it. Fixes: 97a6ec4ac021 ("rhashtable: Change rhashtable_walk_start to return void") Signed-off-by: Xin Long Acked-by: Neil Horman Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b68d53c36108a66ad8602f22abd76c9bab42562b Author: Haiqing Bai Date: Mon Aug 27 09:32:26 2018 +0800 tipc: fix the big/little endian issue in tipc_dest [ Upstream commit 30935198b7d0be12b1c45c328b66a7fdefb16256 ] In function tipc_dest_push, the 32bit variables 'node' and 'port' are stored separately in uppper and lower part of 64bit 'value'. Then this value is assigned to dst->value which is a union like: union { struct { u32 port; u32 node; }; u64 value; } This works on little-endian machines like x86 but fails on big-endian machines. The fix remove the 'value' stack parameter and even the 'value' member of the union in tipc_dest, assign the 'node' and 'port' member directly with the input parameter to avoid the endian issue. Fixes: a80ae5306a73 ("tipc: improve destination linked list") Signed-off-by: Zhenbo Gao Acked-by: Jon Maloy Signed-off-by: Haiqing Bai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 78d378ed13e8f83083c00266769e49ff81cd46eb Author: Dexuan Cui Date: Thu Aug 30 05:42:13 2018 +0000 hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe() [ Upstream commit e04e7a7bbd4bbabef4e1a58367e5fc9b2edc3b10 ] This patch fixes the race between netvsc_probe() and rndis_set_subchannel(), which can cause a deadlock. These are the related 3 paths which show the deadlock: path #1: Workqueue: hv_vmbus_con vmbus_onmessage_work [hv_vmbus] Call Trace: schedule schedule_preempt_disabled __mutex_lock __device_attach bus_probe_device device_add vmbus_device_register vmbus_onoffer vmbus_onmessage_work process_one_work worker_thread kthread ret_from_fork path #2: schedule schedule_preempt_disabled __mutex_lock netvsc_probe vmbus_probe really_probe __driver_attach bus_for_each_dev driver_attach_async async_run_entry_fn process_one_work worker_thread kthread ret_from_fork path #3: Workqueue: events netvsc_subchan_work [hv_netvsc] Call Trace: schedule rndis_set_subchannel netvsc_subchan_work process_one_work worker_thread kthread ret_from_fork Before path #1 finishes, path #2 can start to run, because just before the "bus_probe_device(dev);" in device_add() in path #1, there is a line "object_uevent(&dev->kobj, KOBJ_ADD);", so systemd-udevd can immediately try to load hv_netvsc and hence path #2 can start to run. Next, path #2 offloads the subchannal's initialization to a workqueue, i.e. path #3, so we can end up in a deadlock situation like this: Path #2 gets the device lock, and is trying to get the rtnl lock; Path #3 gets the rtnl lock and is waiting for all the subchannel messages to be processed; Path #1 is trying to get the device lock, but since #2 is not releasing the device lock, path #1 has to sleep; since the VMBus messages are processed one by one, this means the sub-channel messages can't be procedded, so #3 has to sleep with the rtnl lock held, and finally #2 has to sleep... Now all the 3 paths are sleeping and we hit the deadlock. With the patch, we can make sure #2 gets both the device lock and the rtnl lock together, gets its job done, and releases the locks, so #1 and #3 will not be blocked for ever. Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug") Signed-off-by: Dexuan Cui Cc: Stephen Hemminger Cc: K. Y. Srinivasan Cc: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 36b59c8e48e44b34c0929c8de269b186f3b2dadc Author: Cong Wang Date: Thu Aug 23 16:19:44 2018 -0700 tipc: fix a missing rhashtable_walk_exit() [ Upstream commit bd583fe30427500a2d0abe25724025b1cb5e2636 ] rhashtable_walk_exit() must be paired with rhashtable_walk_enter(). Fixes: 40f9f4397060 ("tipc: Fix tipc_sk_reinit race conditions") Cc: Herbert Xu Cc: Ying Xue Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f6fb6b2993ab80af9d70b5094d918df6dc41e7c3 Author: Davide Caratti Date: Mon Aug 27 22:56:22 2018 +0200 net/sched: act_pedit: fix dump of extended layered op [ Upstream commit 85eb9af182243ce9a8b72410d5321c440ac5f8d7 ] in the (rare) case of failure in nla_nest_start(), missing NULL checks in tcf_pedit_key_ex_dump() can make the following command # tc action add action pedit ex munge ip ttl set 64 dereference a NULL pointer: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 800000007d1cd067 P4D 800000007d1cd067 PUD 7acd3067 PMD 0 Oops: 0002 [#1] SMP PTI CPU: 0 PID: 3336 Comm: tc Tainted: G E 4.18.0.pedit+ #425 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:tcf_pedit_dump+0x19d/0x358 [act_pedit] Code: be 02 00 00 00 48 89 df 66 89 44 24 20 e8 9b b1 fd e0 85 c0 75 46 8b 83 c8 00 00 00 49 83 c5 08 48 03 83 d0 00 00 00 4d 39 f5 <66> 89 04 25 00 00 00 00 0f 84 81 01 00 00 41 8b 45 00 48 8d 4c 24 RSP: 0018:ffffb5d4004478a8 EFLAGS: 00010246 RAX: ffff8880fcda2070 RBX: ffff8880fadd2900 RCX: 0000000000000000 RDX: 0000000000000002 RSI: ffffb5d4004478ca RDI: ffff8880fcda206e RBP: ffff8880fb9cb900 R08: 0000000000000008 R09: ffff8880fcda206e R10: ffff8880fadd2900 R11: 0000000000000000 R12: ffff8880fd26cf40 R13: ffff8880fc957430 R14: ffff8880fc957430 R15: ffff8880fb9cb988 FS: 00007f75a537a740(0000) GS:ffff8880fda00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000007a2fa005 CR4: 00000000001606f0 Call Trace: ? __nla_reserve+0x38/0x50 tcf_action_dump_1+0xd2/0x130 tcf_action_dump+0x6a/0xf0 tca_get_fill.constprop.31+0xa3/0x120 tcf_action_add+0xd1/0x170 tc_ctl_action+0x137/0x150 rtnetlink_rcv_msg+0x263/0x2d0 ? _cond_resched+0x15/0x40 ? rtnl_calcit.isra.30+0x110/0x110 netlink_rcv_skb+0x4d/0x130 netlink_unicast+0x1a3/0x250 netlink_sendmsg+0x2ae/0x3a0 sock_sendmsg+0x36/0x40 ___sys_sendmsg+0x26f/0x2d0 ? do_wp_page+0x8e/0x5f0 ? handle_pte_fault+0x6c3/0xf50 ? __handle_mm_fault+0x38e/0x520 ? __sys_sendmsg+0x5e/0xa0 __sys_sendmsg+0x5e/0xa0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f75a4583ba0 Code: c3 48 8b 05 f2 62 2c 00 f7 db 64 89 18 48 83 cb ff eb dd 0f 1f 80 00 00 00 00 83 3d fd c3 2c 00 00 75 10 b8 2e 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ae cc 00 00 48 89 04 24 RSP: 002b:00007fff60ee7418 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fff60ee7540 RCX: 00007f75a4583ba0 RDX: 0000000000000000 RSI: 00007fff60ee7490 RDI: 0000000000000003 RBP: 000000005b842d3e R08: 0000000000000002 R09: 0000000000000000 R10: 00007fff60ee6ea0 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff60ee7554 R14: 0000000000000001 R15: 000000000066c100 Modules linked in: act_pedit(E) ip6table_filter ip6_tables iptable_filter binfmt_misc crct10dif_pclmul ext4 crc32_pclmul mbcache ghash_clmulni_intel jbd2 pcbc snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd snd_timer cryptd glue_helper snd joydev pcspkr soundcore virtio_balloon i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi virtio_net net_failover virtio_blk virtio_console failover qxl crc32c_intel drm_kms_helper syscopyarea serio_raw sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix virtio_pci libata virtio_ring i2c_core virtio floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_pedit] CR2: 0000000000000000 Like it's done for other TC actions, give up dumping pedit rules and return an error if nla_nest_start() returns NULL. Fixes: 71d0ed7079df ("net/act_pedit: Support using offset relative to the conventional network headers") Signed-off-by: Davide Caratti Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a2cea09396bded8f2c9804d052b6e868e7ae4c61 Author: Michael Chan Date: Mon Sep 3 04:23:19 2018 -0400 bnxt_en: Do not adjust max_cp_rings by the ones used by RDMA. [ Upstream commit 00fe9c326d2027f2437dea38ef0e82f9d02d94c0 ] Currently, the driver adjusts the bp->hw_resc.max_cp_rings by the number of MSIX vectors used by RDMA. There is one code path in open that needs to check the true max_cp_rings including any used by RDMA. This code is now checking for the reduced max_cp_rings which will fail when the number of cp rings is very small. To fix this in a clean way, we don't adjust max_cp_rings anymore. Instead, we add a helper bnxt_get_max_func_cp_rings_for_en() to get the reduced max_cp_rings when appropriate. Fixes: ec86f14ea506 ("bnxt_en: Add ULP calls to stop and restart IRQs.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e779d52e66d10a4cfe6af70eb05302a8a3259b43 Author: Michael Chan Date: Mon Sep 3 04:23:18 2018 -0400 bnxt_en: Clean up unused functions. [ Upstream commit ad95c27bdb930105f3eea02621bda157caf2862d ] Remove unused bnxt_subtract_ulp_resources(). Change bnxt_get_max_func_irqs() to static since it is only locally used. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 510fd03c52314571eca570fc0d019455ca1b857e Author: Vlad Buslov Date: Tue Sep 4 00:44:42 2018 +0300 net: sched: action_ife: take reference to meta module [ Upstream commit 84cb8eb26cb9ce3c79928094962a475a9d850a53 ] Recent refactoring of add_metainfo() caused use_all_metadata() to add metainfo to ife action metalist without taking reference to module. This causes warning in module_put called from ife action cleanup function. Implement add_metainfo_and_get_ops() function that returns with reference to module taken if metainfo was added successfully, and call it from use_all_metadata(), instead of calling __add_metainfo() directly. Example warning: [ 646.344393] WARNING: CPU: 1 PID: 2278 at kernel/module.c:1139 module_put+0x1cb/0x230 [ 646.352437] Modules linked in: act_meta_skbtcindex act_meta_mark act_meta_skbprio act_ife ife veth nfsv3 nfs fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c tun ebtable_filter ebtables ip6table_filter ip6_tables bridge stp llc mlx5_ib ib_uverbs ib_core intel_rapl sb_edac x86_pkg_temp_thermal mlx5_core coretemp kvm_intel kvm nfsd igb irqbypass crct10dif_pclmul devlink crc32_pclmul mei_me joydev ses crc32c_intel enclosure auth_rpcgss i2c_algo_bit ioatdma ptp mei pps_core ghash_clmulni_intel iTCO_wdt iTCO_vendor_support pcspkr dca ipmi_ssif lpc_ich target_core_mod i2c_i801 ipmi_si ipmi_devintf pcc_cpufreq wmi ipmi_msghandler nfs_acl lockd acpi_pad acpi_power_meter grace sunrpc mpt3sas raid_class scsi_transport_sas [ 646.425631] CPU: 1 PID: 2278 Comm: tc Not tainted 4.19.0-rc1+ #799 [ 646.432187] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017 [ 646.440595] RIP: 0010:module_put+0x1cb/0x230 [ 646.445238] Code: f3 66 94 02 e8 26 ff fa ff 85 c0 74 11 0f b6 1d 51 30 94 02 80 fb 01 77 60 83 e3 01 74 13 65 ff 0d 3a 83 db 73 e9 2b ff ff ff <0f> 0b e9 00 ff ff ff e8 59 01 fb ff 85 c0 75 e4 48 c7 c2 20 62 6b [ 646.464997] RSP: 0018:ffff880354d37068 EFLAGS: 00010286 [ 646.470599] RAX: 0000000000000000 RBX: ffffffffc0a52518 RCX: ffffffff8c2668db [ 646.478118] RDX: 0000000000000003 RSI: dffffc0000000000 RDI: ffffffffc0a52518 [ 646.485641] RBP: ffffffffc0a52180 R08: fffffbfff814a4a4 R09: fffffbfff814a4a3 [ 646.493164] R10: ffffffffc0a5251b R11: fffffbfff814a4a4 R12: 1ffff1006a9a6e0d [ 646.500687] R13: 00000000ffffffff R14: ffff880362bab890 R15: dead000000000100 [ 646.508213] FS: 00007f4164c99800(0000) GS:ffff88036fe40000(0000) knlGS:0000000000000000 [ 646.516961] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 646.523080] CR2: 00007f41638b8420 CR3: 0000000351df0004 CR4: 00000000001606e0 [ 646.530595] Call Trace: [ 646.533408] ? find_symbol_in_section+0x260/0x260 [ 646.538509] tcf_ife_cleanup+0x11b/0x200 [act_ife] [ 646.543695] tcf_action_cleanup+0x29/0xa0 [ 646.548078] __tcf_action_put+0x5a/0xb0 [ 646.552289] ? nla_put+0x65/0xe0 [ 646.555889] __tcf_idr_release+0x48/0x60 [ 646.560187] tcf_generic_walker+0x448/0x6b0 [ 646.564764] ? tcf_action_dump_1+0x450/0x450 [ 646.569411] ? __lock_is_held+0x84/0x110 [ 646.573720] ? tcf_ife_walker+0x10c/0x20f [act_ife] [ 646.578982] tca_action_gd+0x972/0xc40 [ 646.583129] ? tca_get_fill.constprop.17+0x250/0x250 [ 646.588471] ? mark_lock+0xcf/0x980 [ 646.592324] ? check_chain_key+0x140/0x1f0 [ 646.596832] ? debug_show_all_locks+0x240/0x240 [ 646.601839] ? memset+0x1f/0x40 [ 646.605350] ? nla_parse+0xca/0x1a0 [ 646.609217] tc_ctl_action+0x215/0x230 [ 646.613339] ? tcf_action_add+0x220/0x220 [ 646.617748] rtnetlink_rcv_msg+0x56a/0x6d0 [ 646.622227] ? rtnl_fdb_del+0x3f0/0x3f0 [ 646.626466] netlink_rcv_skb+0x18d/0x200 [ 646.630752] ? rtnl_fdb_del+0x3f0/0x3f0 [ 646.634959] ? netlink_ack+0x500/0x500 [ 646.639106] netlink_unicast+0x2d0/0x370 [ 646.643409] ? netlink_attachskb+0x340/0x340 [ 646.648050] ? _copy_from_iter_full+0xe9/0x3e0 [ 646.652870] ? import_iovec+0x11e/0x1c0 [ 646.657083] netlink_sendmsg+0x3b9/0x6a0 [ 646.661388] ? netlink_unicast+0x370/0x370 [ 646.665877] ? netlink_unicast+0x370/0x370 [ 646.670351] sock_sendmsg+0x6b/0x80 [ 646.674212] ___sys_sendmsg+0x4a1/0x520 [ 646.678443] ? copy_msghdr_from_user+0x210/0x210 [ 646.683463] ? lock_downgrade+0x320/0x320 [ 646.687849] ? debug_show_all_locks+0x240/0x240 [ 646.692760] ? do_raw_spin_unlock+0xa2/0x130 [ 646.697418] ? _raw_spin_unlock+0x24/0x30 [ 646.701798] ? __handle_mm_fault+0x1819/0x1c10 [ 646.706619] ? __pmd_alloc+0x320/0x320 [ 646.710738] ? debug_show_all_locks+0x240/0x240 [ 646.715649] ? restore_nameidata+0x7b/0xa0 [ 646.720117] ? check_chain_key+0x140/0x1f0 [ 646.724590] ? check_chain_key+0x140/0x1f0 [ 646.729070] ? __fget_light+0xbc/0xd0 [ 646.733121] ? __sys_sendmsg+0xd7/0x150 [ 646.737329] __sys_sendmsg+0xd7/0x150 [ 646.741359] ? __ia32_sys_shutdown+0x30/0x30 [ 646.746003] ? up_read+0x53/0x90 [ 646.749601] ? __do_page_fault+0x484/0x780 [ 646.754105] ? do_syscall_64+0x1e/0x2c0 [ 646.758320] do_syscall_64+0x72/0x2c0 [ 646.762353] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 646.767776] RIP: 0033:0x7f4163872150 [ 646.771713] Code: 8b 15 3c 7d 2b 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb cd 66 0f 1f 44 00 00 83 3d b9 d5 2b 00 00 75 10 b8 2e 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 be cd 00 00 48 89 04 24 [ 646.791474] RSP: 002b:00007ffdef7d6b58 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 646.799721] RAX: ffffffffffffffda RBX: 0000000000000024 RCX: 00007f4163872150 [ 646.807240] RDX: 0000000000000000 RSI: 00007ffdef7d6bd0 RDI: 0000000000000003 [ 646.814760] RBP: 000000005b8b9482 R08: 0000000000000001 R09: 0000000000000000 [ 646.822286] R10: 00000000000005e7 R11: 0000000000000246 R12: 00007ffdef7dad20 [ 646.829807] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000679bc0 [ 646.837360] irq event stamp: 6083 [ 646.841043] hardirqs last enabled at (6081): [] __call_rcu+0x17d/0x500 [ 646.849882] hardirqs last disabled at (6083): [] trace_hardirqs_off_thunk+0x1a/0x1c [ 646.859775] softirqs last enabled at (5968): [] __do_softirq+0x4a1/0x6ee [ 646.868784] softirqs last disabled at (6082): [] tcf_ife_cleanup+0x39/0x200 [act_ife] [ 646.878845] ---[ end trace b1b8c12ffe51e657 ]--- Fixes: 5ffe57da29b3 ("act_ife: fix a potential deadlock") Signed-off-by: Vlad Buslov Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e57d65cf4692a4fe2ca0f6cdb51aa22be9a4e5a1 Author: Cong Wang Date: Sun Aug 19 12:22:13 2018 -0700 act_ife: fix a potential deadlock [ Upstream commit 5ffe57da29b3802baeddaa40909682bbb4cb4d48 ] use_all_metadata() acquires read_lock(&ife_mod_lock), then calls add_metainfo() which calls find_ife_oplist() which acquires the same lock again. Deadlock! Introduce __add_metainfo() which accepts struct tcf_meta_ops *ops as an additional parameter and let its callers to decide how to find it. For use_all_metadata(), it already has ops, no need to find it again, just call __add_metainfo() directly. And, as ife_mod_lock is only needed for find_ife_oplist(), this means we can make non-atomic allocation for populate_metalist() now. Fixes: 817e9f2c5c26 ("act_ife: acquire ife_mod_lock before reading ifeoplist") Cc: Jamal Hadi Salim Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5c1dfc425994f077c606f74b5785b835f4b29ad7 Author: Cong Wang Date: Sun Aug 19 12:22:12 2018 -0700 act_ife: move tcfa_lock down to where necessary [ Upstream commit 4e407ff5cd67ec76eeeea1deec227b7982dc7f66 ] The only time we need to take tcfa_lock is when adding a new metainfo to an existing ife->metalist. We don't need to take tcfa_lock so early and so broadly in tcf_ife_init(). This means we can always take ife_mod_lock first, avoid the reverse locking ordering warning as reported by Vlad. Reported-by: Vlad Buslov Tested-by: Vlad Buslov Cc: Vlad Buslov Cc: Jamal Hadi Salim Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8563554006c576fb4bb5b3e671311f4305131535 Author: Alexey Kodanev Date: Thu Aug 23 19:49:54 2018 +0300 vti6: remove !skb->ignore_df check from vti6_xmit() [ Upstream commit 9f2895461439fda2801a7906fb4c5fb3dbb37a0a ] Before the commit d6990976af7c ("vti6: fix PMTU caching and reporting on xmit") '!skb->ignore_df' check was always true because the function skb_scrub_packet() was called before it, resetting ignore_df to zero. In the commit, skb_scrub_packet() was moved below, and now this check can be false for the packet, e.g. when sending it in the two fragments, this prevents successful PMTU updates in such case. The next attempts to send the packet lead to the same tx error. Moreover, vti6 initial MTU value relies on PMTU adjustments. This issue can be reproduced with the following LTP test script: udp_ipsec_vti.sh -6 -p ah -m tunnel -s 2000 Fixes: ccd740cbc6e0 ("vti6: Add pmtu handling to vti6_xmit.") Signed-off-by: Alexey Kodanev Acked-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 028d57cc5e4470c63c165d3690d4639ac90e270b Author: Florian Westphal Date: Thu Aug 30 14:24:29 2018 +0200 tcp: do not restart timewait timer on rst reception [ Upstream commit 63cc357f7bba6729869565a12df08441a5995d9a ] RFC 1337 says: ''Ignore RST segments in TIME-WAIT state. If the 2 minute MSL is enforced, this fix avoids all three hazards.'' So with net.ipv4.tcp_rfc1337=1, expected behaviour is to have TIME-WAIT sk expire rather than removing it instantly when a reset is received. However, Linux will also re-start the TIME-WAIT timer. This causes connect to fail when tying to re-use ports or very long delays (until syn retry interval exceeds MSL). packetdrill test case: // Demonstrate bogus rearming of TIME-WAIT timer in rfc1337 mode. `sysctl net.ipv4.tcp_rfc1337=1` 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 0.000 bind(3, ..., ...) = 0 0.000 listen(3, 1) = 0 0.100 < S 0:0(0) win 29200 0.100 > S. 0:0(0) ack 1 0.200 < . 1:1(0) ack 1 win 257 0.200 accept(3, ..., ...) = 4 // Receive first segment 0.310 < P. 1:1001(1000) ack 1 win 46 // Send one ACK 0.310 > . 1:1(0) ack 1001 // read 1000 byte 0.310 read(4, ..., 1000) = 1000 // Application writes 100 bytes 0.350 write(4, ..., 100) = 100 0.350 > P. 1:101(100) ack 1001 // ACK 0.500 < . 1001:1001(0) ack 101 win 257 // close the connection 0.600 close(4) = 0 0.600 > F. 101:101(0) ack 1001 win 244 // Our side is in FIN_WAIT_1 & waits for ack to fin 0.7 < . 1001:1001(0) ack 102 win 244 // Our side is in FIN_WAIT_2 with no outstanding data. 0.8 < F. 1001:1001(0) ack 102 win 244 0.8 > . 102:102(0) ack 1002 win 244 // Our side is now in TIME_WAIT state, send ack for fin. 0.9 < F. 1002:1002(0) ack 102 win 244 0.9 > . 102:102(0) ack 1002 win 244 // Peer reopens with in-window SYN: 1.000 < S 1000:1000(0) win 9200 // Therefore, reply with ACK. 1.000 > . 102:102(0) ack 1002 win 244 // Peer sends RST for this ACK. Normally this RST results // in tw socket removal, but rfc1337=1 setting prevents this. 1.100 < R 1002:1002(0) win 244 // second syn. Due to rfc1337=1 expect another pure ACK. 31.0 < S 1000:1000(0) win 9200 31.0 > . 102:102(0) ack 1002 win 244 // .. and another RST from peer. 31.1 < R 1002:1002(0) win 244 31.2 `echo no timer restart;ss -m -e -a -i -n -t -o state TIME-WAIT` // third syn after one minute. Time-Wait socket should have expired by now. 63.0 < S 1000:1000(0) win 9200 // so we expect a syn-ack & 3whs to proceed from here on. 63.0 > S. 0:0(0) ack 1 Without this patch, 'ss' shows restarts of tw timer and last packet is thus just another pure ack, more than one minute later. This restores the original code from commit 283fd6cf0be690a83 ("Merge in ANK networking jumbo patch") in netdev-vger-cvs.git . For some reason the else branch was removed/lost in 1f28b683339f7 ("Merge in TCP/UDP optimizations and [..]") and timer restart became unconditional. Reported-by: Michal Tesar Signed-off-by: Florian Westphal Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ad99830d972c98258077d5c24b886f81a9eeadea Author: Anthony Wong Date: Fri Aug 31 20:06:42 2018 +0800 r8169: add support for NCube 8168 network card [ Upstream commit 9fd0e09a4e86499639653243edfcb417a05c5c46 ] This card identifies itself as: Ethernet controller [0200]: NCube Device [10ff:8168] (rev 06) Subsystem: TP-LINK Technologies Co., Ltd. Device [7470:3468] Adding a new entry to rtl8169_pci_tbl makes the card work. Link: http://launchpad.net/bugs/1788730 Signed-off-by: Anthony Wong Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2b3b1f12130602fecb6c1c168a0fa760f9d64025 Author: Kai-Heng Feng Date: Mon Aug 20 12:43:51 2018 +0800 r8152: disable RX aggregation on new Dell TB16 dock [ Upstream commit 176eb614b118c96e7797f5ddefd10708c316f621 ] There's a new Dell TB16 dock with a different iSerialNumber. Apply the same fix from commit 0b1655143df0 ("r8152: disable RX aggregation on Dell TB16 dock") to this model. BugLink: https://bugs.launchpad.net/bugs/1785780 Signed-off-by: Kai-Heng Feng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5379200c84c2d7949238ce3e865a3dbddde17f22 Author: Manish Chopra Date: Thu Aug 23 13:20:52 2018 -0700 qlge: Fix netdev features configuration. [ Upstream commit 6750c87074c5b534d82fdaabb1deb45b8f1f57de ] qlge_fix_features() is not supposed to modify hardware or driver state, rather it is supposed to only fix requested fetures bits. Currently qlge_fix_features() also goes for interface down and up unnecessarily if there is not even any change in features set. This patch changes/fixes following - 1) Move reload of interface or device re-config from qlge_fix_features() to qlge_set_features(). 2) Reload of interface in qlge_set_features() only if relevant feature bit (NETIF_F_HW_VLAN_CTAG_RX) is changed. 3) Get rid of qlge_fix_features() since driver is not really required to fix any features bit. Signed-off-by: Manish Reviewed-by: Benjamin Poirier Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9c03cfa220c16c3d819c2c9b3e668196ee8dec73 Author: Kees Cook Date: Sat Aug 25 22:58:01 2018 -0700 net: sched: Fix memory exposure from short TCA_U32_SEL [ Upstream commit 98c8f125fd8a6240ea343c1aa50a1be9047791b8 ] Via u32_change(), TCA_U32_SEL has an unspecified type in the netlink policy, so max length isn't enforced, only minimum. This means nkeys (from userspace) was being trusted without checking the actual size of nla_len(), which could lead to a memory over-read, and ultimately an exposure via a call to u32_dump(). Reachability is CAP_NET_ADMIN within a namespace. Reported-by: Al Viro Cc: Jamal Hadi Salim Cc: Cong Wang Cc: Jiri Pirko Cc: "David S. Miller" Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 716fc5ce90cf6436761fe13997c90f230f7dcb3b Author: Anssi Hannula Date: Thu Aug 23 10:45:22 2018 +0300 net: macb: do not disable MDIO bus at open/close time [ Upstream commit 0da70f808029476001109b6cb076737bc04cea2e ] macb_reset_hw() is called from macb_close() and indirectly from macb_open(). macb_reset_hw() zeroes the NCR register, including the MPE (Management Port Enable) bit. This will prevent accessing any other PHYs for other Ethernet MACs on the MDIO bus, which remains registered at macb_reset_hw() time, until macb_init_hw() is called from macb_open() which sets the MPE bit again. I.e. currently the MDIO bus has a short disruption at open time and is disabled at close time until the interface is opened again. Fix that by only touching the RE and TE bits when enabling and disabling RX/TX. v2: Make macb_init_hw() NCR write a single statement. Fixes: 6c36a7074436 ("macb: Use generic PHY layer") Signed-off-by: Anssi Hannula Reviewed-by: Claudiu Beznea Tested-by: Claudiu Beznea Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5b47db7fa7b168ac210aa875c00c90c58cfc356b Author: Doug Berger Date: Tue Aug 28 12:33:15 2018 -0700 net: bcmgenet: use MAC link status for fixed phy [ Upstream commit c3c397c1f16c51601a3fac4fe0c63ad8aa85a904 ] When using the fixed PHY with GENET (e.g. MOCA) the PHY link status can be determined from the internal link status captured by the MAC. This allows the PHY state machine to use the correct link state with the fixed PHY even if MAC link event interrupts are missed when the net device is opened. Fixes: 8d88c6ebb34c ("net: bcmgenet: enable MoCA link state change detection") Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e242b5c405b9d1d352c88e6edbd1fe1872f3c712 Author: Eric Dumazet Date: Wed Aug 22 13:30:45 2018 -0700 ipv4: tcp: send zero IPID for RST and ACK sent in SYN-RECV and TIME-WAIT state [ Upstream commit 431280eebed9f5079553daf003011097763e71fd ] tcp uses per-cpu (and per namespace) sockets (net->ipv4.tcp_sk) internally to send some control packets. 1) RST packets, through tcp_v4_send_reset() 2) ACK packets in SYN-RECV and TIME-WAIT state, through tcp_v4_send_ack() These packets assert IP_DF, and also use the hashed IP ident generator to provide an IPv4 ID number. Geoff Alexander reported this could be used to build off-path attacks. These packets should not be fragmented, since their size is smaller than IPV4_MIN_MTU. Only some tunneled paths could eventually have to fragment, regardless of inner IPID. We really can use zero IPID, to address the flaw, and as a bonus, avoid a couple of atomic operations in ip_idents_reserve() Signed-off-by: Eric Dumazet Reported-by: Geoff Alexander Tested-by: Geoff Alexander Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f5c34c4a092efd3aba7f0573d207a1aab28ec2c4 Author: Cong Wang Date: Mon Sep 3 11:08:15 2018 -0700 act_ife: fix a potential use-after-free [ Upstream commit 6d784f1625ea68783cc1fb17de8f6cd3e1660c3f ] Immediately after module_put(), user could delete this module, so e->ops could be already freed before we call e->ops->release(). Fix this by moving module_put() after ops->release(). Fixes: ef6980b6becb ("introduce IFE action") Cc: Jamal Hadi Salim Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8ea7eadbef2f7103d5871016f03fc38b3adeaddb Author: Greg Kroah-Hartman Date: Sun Sep 9 10:32:43 2018 +0200 Linux 4.18.7 commit 239043b876b8dbcc4cb694a4bbc4d922f56921a3 Author: James Morse Date: Thu Aug 30 16:05:32 2018 +0100 arm64: mm: always enable CONFIG_HOLES_IN_ZONE commit f52bb98f5aded4c43e52f5ce19fb83f7261e9e73 upstream. Commit 6d526ee26ccd ("arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA") only enabled HOLES_IN_ZONE for NUMA systems because the NUMA code was choking on the missing zone for nomap pages. This problem doesn't just apply to NUMA systems. If the architecture doesn't set HAVE_ARCH_PFN_VALID, pfn_valid() will return true if the pfn is part of a valid sparsemem section. When working with multiple pages, the mm code uses pfn_valid_within() to test each page it uses within the sparsemem section is valid. On most systems memory comes in MAX_ORDER_NR_PAGES chunks which all have valid/initialised struct pages. In this case pfn_valid_within() is optimised out. Systems where this isn't true (e.g. due to nomap) should set HOLES_IN_ZONE and provide HAVE_ARCH_PFN_VALID so that mm tests each page as it works with it. Currently non-NUMA arm64 systems can't enable HOLES_IN_ZONE, leading to a VM_BUG_ON(): | page:fffffdff802e1780 is uninitialized and poisoned | raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff | raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff | page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) | ------------[ cut here ]------------ | kernel BUG at include/linux/mm.h:978! | Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [...] | CPU: 1 PID: 25236 Comm: dd Not tainted 4.18.0 #7 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 40000085 (nZcv daIf -PAN -UAO) | pc : move_freepages_block+0x144/0x248 | lr : move_freepages_block+0x144/0x248 | sp : fffffe0071177680 [...] | Process dd (pid: 25236, stack limit = 0x0000000094cc07fb) | Call trace: | move_freepages_block+0x144/0x248 | steal_suitable_fallback+0x100/0x16c | get_page_from_freelist+0x440/0xb20 | __alloc_pages_nodemask+0xe8/0x838 | new_slab+0xd4/0x418 | ___slab_alloc.constprop.27+0x380/0x4a8 | __slab_alloc.isra.21.constprop.26+0x24/0x34 | kmem_cache_alloc+0xa8/0x180 | alloc_buffer_head+0x1c/0x90 | alloc_page_buffers+0x68/0xb0 | create_empty_buffers+0x20/0x1ec | create_page_buffers+0xb0/0xf0 | __block_write_begin_int+0xc4/0x564 | __block_write_begin+0x10/0x18 | block_write_begin+0x48/0xd0 | blkdev_write_begin+0x28/0x30 | generic_perform_write+0x98/0x16c | __generic_file_write_iter+0x138/0x168 | blkdev_write_iter+0x80/0xf0 | __vfs_write+0xe4/0x10c | vfs_write+0xb4/0x168 | ksys_write+0x44/0x88 | sys_write+0xc/0x14 | el0_svc_naked+0x30/0x34 | Code: aa1303e0 90001a01 91296421 94008902 (d4210000) | ---[ end trace 1601ba47f6e883fe ]--- Remove the NUMA dependency. Link: https://www.spinics.net/lists/arm-kernel/msg671851.html Cc: Cc: Ard Biesheuvel Reported-by: Mikulas Patocka Reviewed-by: Pavel Tatashin Tested-by: Mikulas Patocka Signed-off-by: James Morse Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit a70bc6c6a6215bb2dc3f2a621d559d55323a0ead Author: Rafael J. Wysocki Date: Tue Aug 21 10:44:10 2018 +0200 cpuidle: menu: Retain tick when shallow state is selected commit 757ab15c3f4968b5a29caf3fe8b67660ce84c3cd upstream. The case addressed by commit 5ef499cd571c (cpuidle: menu: Handle stopped tick more aggressively) in the stopped tick case is present when the tick has not been stopped yet too. Namely, if only two CPU idle states, shallow state A with target residency significantly below the tick boundary and deep state B with target residency significantly above it, are available and the predicted idle duration is above the tick boundary, but below the target residency of state B, state A will be selected and the CPU may spend indefinite amount of time in it, which is not quite energy-efficient. However, if the tick has not been stopped yet and the governor is about to select a shallow idle state for the CPU even though the idle duration predicted by it is above the tick boundary, it should be fine to wake up the CPU early, so the tick can be retained then and the governor will have a chance to select a deeper state when it runs next time. [Note that when this really happens, it will make the idle duration predictor believe that the CPU might be idle longer than predicted, which will make it more likely to predict longer idle durations going forward, but that will also cause deeper idle states to be selected going forward, on average, which is what's needed here.] Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with stopped tick) Reported-by: Leo Yan Cc: 4.17+ # 4.17+: 5ef499cd571c (cpuidle: menu: Handle ...) Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 7f401f160a9c7a1ff84ba3cb9b2f636d1f5cfb6b Author: Jan Kara Date: Tue Aug 21 14:52:34 2018 +0200 udf: Fix mounting of Win7 created UDF filesystems commit ee4af50ca94f58afc3532662779b9cf80bbe27c8 upstream. Win7 is creating UDF filesystems with single partition with number 8192. Current partition descriptor scanning code does not handle this well as it incorrectly assumes that partition numbers will form mostly contiguous space of small numbers. This results in unmountable media due to errors like: UDF-fs: error (device dm-1): udf_read_tagged: tag version 0x0000 != 0x0002 || 0x0003, block 0 UDF-fs: warning (device dm-1): udf_fill_super: No fileset found Fix the problem by handling partition descriptors in a way that sparse partition numbering does not matter. Reported-and-tested-by: jean-luc malet CC: stable@vger.kernel.org Fixes: 7b78fd02fb19530fd101ae137a1f46aa466d9bb6 Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit c1ef3feca66749812aa6e76b7673de9c87240273 Author: Jeremy Cline Date: Tue Jul 31 01:37:31 2018 +0000 fs/quota: Fix spectre gadget in do_quotactl commit 7b6924d94a60c6b8c1279ca003e8744e6cd9e8b1 upstream. 'type' is user-controlled, so sanitize it after the bounds check to avoid using it in speculative execution. This covers the following potential gadgets detected with the help of smatch: * fs/ext4/super.c:5741 ext4_quota_read() warn: potential spectre issue 'sb_dqopt(sb)->files' [r] * fs/ext4/super.c:5778 ext4_quota_write() warn: potential spectre issue 'sb_dqopt(sb)->files' [r] * fs/f2fs/super.c:1552 f2fs_quota_read() warn: potential spectre issue 'sb_dqopt(sb)->files' [r] * fs/f2fs/super.c:1608 f2fs_quota_write() warn: potential spectre issue 'sb_dqopt(sb)->files' [r] * fs/quota/dquot.c:412 mark_info_dirty() warn: potential spectre issue 'sb_dqopt(sb)->info' [w] * fs/quota/dquot.c:933 dqinit_needed() warn: potential spectre issue 'dquots' [r] * fs/quota/dquot.c:2112 dquot_commit_info() warn: potential spectre issue 'dqopt->ops' [r] * fs/quota/dquot.c:2362 vfs_load_quota_inode() warn: potential spectre issue 'dqopt->files' [w] (local cap) * fs/quota/dquot.c:2369 vfs_load_quota_inode() warn: potential spectre issue 'dqopt->ops' [w] (local cap) * fs/quota/dquot.c:2370 vfs_load_quota_inode() warn: potential spectre issue 'dqopt->info' [w] (local cap) * fs/quota/quota.c:110 quota_getfmt() warn: potential spectre issue 'sb_dqopt(sb)->info' [r] * fs/quota/quota_v2.c:84 v2_check_quota_file() warn: potential spectre issue 'quota_magics' [w] * fs/quota/quota_v2.c:85 v2_check_quota_file() warn: potential spectre issue 'quota_versions' [w] * fs/quota/quota_v2.c:96 v2_read_file_info() warn: potential spectre issue 'dqopt->info' [r] * fs/quota/quota_v2.c:172 v2_write_file_info() warn: potential spectre issue 'dqopt->info' [r] Additionally, a quick inspection indicates there are array accesses with 'type' in quota_on() and quota_off() functions which are also addressed by this. Cc: Josh Poimboeuf Cc: stable@vger.kernel.org Signed-off-by: Jeremy Cline Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 7ab1035b3fc62159a80b80a21b0bf1268431c43e Author: Horia Geantă Date: Mon Aug 6 15:29:39 2018 +0300 crypto: caam/qi - fix error path in xts setkey commit ad876a18048f43b1f66f5d474b7598538668c5de upstream. xts setkey callback returns 0 on some error paths. Fix this by returning -EINVAL. Cc: # 4.12+ Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3290dec64398e829c700c4b6c083acffbe02ddd5 Author: Horia Geantă Date: Mon Aug 6 15:29:09 2018 +0300 crypto: caam/jr - fix descriptor DMA unmapping commit cc98963dbaaea93d17608641b8d6942a5327fc31 upstream. Descriptor address needs to be swapped to CPU endianness before being DMA unmapped. Cc: # 4.8+ Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam endianness") Reported-by: Laurentiu Tudor Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f39f1f81c74e6dd226d3fae7c665a2052cd3e046 Author: Horia Geantă Date: Mon Aug 6 15:29:55 2018 +0300 crypto: caam - fix DMA mapping direction for RSA forms 2 & 3 commit f1bf9e60a0779ec97de9ecdc353e1d01cdd73f43 upstream. Crypto engine needs some temporary locations in external memory for running RSA decrypt forms 2 and 3 (CRT). These are named "tmp1" and "tmp2" in the PDB. Update DMA mapping direction of tmp1 and tmp2 from TO_DEVICE to BIDIRECTIONAL, since engine needs r/w access. Cc: # 4.13+ Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2") Fixes: 4a651b122adb ("crypto: caam - add support for RSA key form 3") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 26b165edc3e43df104cacadc9e9760c812a2b202 Author: Ard Biesheuvel Date: Tue Aug 7 23:18:36 2018 +0200 crypto: arm64/sm4-ce - check for the right CPU feature bit commit 7fa885e2a22fd0f91a2c23d9275f5021f618ff5a upstream. ARMv8.2 specifies special instructions for the SM3 cryptographic hash and the SM4 symmetric cipher. While it is unlikely that a core would implement one and not the other, we should only use SM4 instructions if the SM4 CPU feature bit is set, and we currently check the SM3 feature bit instead. So fix that. Fixes: e99ce921c468 ("crypto: arm64 - add support for SM4...") Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit dce1a2c6f33996d39e5cfbd4009db176bfa629de Author: Dave Watson Date: Wed Aug 15 10:29:42 2018 -0700 crypto: aesni - Use unaligned loads from gcm_context_data commit e5b954e8d11fdde55eed35017370a3a0d8837754 upstream. A regression was reported bisecting to 1476db2d12 "Move HashKey computation from stack to gcm_context". That diff moved HashKey computation from the stack, which was explicitly aligned in the asm, to a struct provided from the C code, depending on AESNI_ALIGN_ATTR for alignment. It appears some compilers may not align this struct correctly, resulting in a crash on the movdqa instruction when attempting to encrypt or decrypt data. Fix by using unaligned loads for the HashKeys. On modern hardware there is no perf difference between the unaligned and aligned loads. All other accesses to gcm_context_data already use unaligned loads. Reported-by: Mauro Rossi Fixes: 1476db2d12 ("Move HashKey computation from stack to gcm_context") Cc: Signed-off-by: Dave Watson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 61c8901dbf430b9d8b591ecc21ad2bbe740595a4 Author: Ondrej Mosnacek Date: Wed Aug 22 08:26:31 2018 +0200 crypto: vmx - Fix sleep-in-atomic bugs commit 0522236d4f9c5ab2e79889cb020d1acbe5da416e upstream. This patch fixes sleep-in-atomic bugs in AES-CBC and AES-XTS VMX implementations. The problem is that the blkcipher_* functions should not be called in atomic context. The bugs can be reproduced via the AF_ALG interface by trying to encrypt/decrypt sufficiently large buffers (at least 64 KiB) using the VMX implementations of 'cbc(aes)' or 'xts(aes)'. Such operations then trigger BUG in crypto_yield(): [ 891.863680] BUG: sleeping function called from invalid context at include/crypto/algapi.h:424 [ 891.864622] in_atomic(): 1, irqs_disabled(): 0, pid: 12347, name: kcapi-enc [ 891.864739] 1 lock held by kcapi-enc/12347: [ 891.864811] #0: 00000000f5d42c46 (sk_lock-AF_ALG){+.+.}, at: skcipher_recvmsg+0x50/0x530 [ 891.865076] CPU: 5 PID: 12347 Comm: kcapi-enc Not tainted 4.19.0-0.rc0.git3.1.fc30.ppc64le #1 [ 891.865251] Call Trace: [ 891.865340] [c0000003387578c0] [c000000000d67ea4] dump_stack+0xe8/0x164 (unreliable) [ 891.865511] [c000000338757910] [c000000000172a58] ___might_sleep+0x2f8/0x310 [ 891.865679] [c000000338757990] [c0000000006bff74] blkcipher_walk_done+0x374/0x4a0 [ 891.865825] [c0000003387579e0] [d000000007e73e70] p8_aes_cbc_encrypt+0x1c8/0x260 [vmx_crypto] [ 891.865993] [c000000338757ad0] [c0000000006c0ee0] skcipher_encrypt_blkcipher+0x60/0x80 [ 891.866128] [c000000338757b10] [c0000000006ec504] skcipher_recvmsg+0x424/0x530 [ 891.866283] [c000000338757bd0] [c000000000b00654] sock_recvmsg+0x74/0xa0 [ 891.866403] [c000000338757c10] [c000000000b00f64] ___sys_recvmsg+0xf4/0x2f0 [ 891.866515] [c000000338757d90] [c000000000b02bb8] __sys_recvmsg+0x68/0xe0 [ 891.866631] [c000000338757e30] [c00000000000bbe4] system_call+0x5c/0x70 Fixes: 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module") Fixes: c07f5d3da643 ("crypto: vmx - Adding support for XTS") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Mosnacek Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 8d02bd8d4a6c5a9173405a0cf36751a880671235 Author: Adrian Hunter Date: Tue Aug 14 11:46:08 2018 +0300 perf auxtrace: Fix queue resize commit 99cbbe56eb8bede625f410ab62ba34673ffa7d21 upstream. When the number of queues grows beyond 32, the array of queues is resized but not all members were being copied. Fix by also copying 'tid', 'cpu' and 'set'. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Fixes: e502789302a6e ("perf auxtrace: Add helpers for queuing AUX area tracing data") Link: http://lkml.kernel.org/r/20180814084608.6563-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 5ad671c8520d49ef4d50f8d30a3f82288d9289a5 Author: Dan Williams Date: Fri Jul 13 21:50:01 2018 -0700 mm, dev_pagemap: Do not clear ->mapping on final put commit 2fa147bdbf672c53386a8f5f2c7fe358004c3ef8 upstream. MEMORY_DEVICE_FS_DAX relies on typical page semantics whereby ->mapping is only ever cleared by truncation, not final put. Without this fix dax pages may forget their mapping association at the end of every page pin event. Move this atypical behavior that HMM wants into the HMM ->page_free() callback. Cc: Cc: Jan Kara Cc: Jérôme Glisse Cc: Andrew Morton Cc: Ross Zwisler Fixes: d2c997c0f145 ("fs, dax: use page->mapping...") Signed-off-by: Dan Williams Acked-by: Jérôme Glisse Signed-off-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman commit ff1663fc9483e131f674db8b2f42f9a99460ae50 Author: Eddie.Horng Date: Fri Jul 20 15:30:00 2018 +0800 cap_inode_getsecurity: use d_find_any_alias() instead of d_find_alias() commit 355139a8dba446cc11a424cddbf7afebc3041ba1 upstream. The code in cap_inode_getsecurity(), introduced by commit 8db6c34f1dbc ("Introduce v3 namespaced file capabilities"), should use d_find_any_alias() instead of d_find_alias() do handle unhashed dentry correctly. This is needed, for example, if execveat() is called with an open but unlinked overlayfs file, because overlayfs unhashes dentry on unlink. This is a regression of real life application, first reported at https://www.spinics.net/lists/linux-unionfs/msg05363.html Below reproducer and setup can reproduce the case. const char* exec="echo"; const char *newargv[] = { "echo", "hello", NULL}; const char *newenviron[] = { NULL }; int fd, err; fd = open(exec, O_PATH); unlink(exec); err = syscall(322/*SYS_execveat*/, fd, "", newargv, newenviron, AT_EMPTY_PATH); if(err<0) fprintf(stderr, "execveat: %s\n", strerror(errno)); gcc compile into ~/test/a.out mount -t overlay -orw,lowerdir=/mnt/l,upperdir=/mnt/u,workdir=/mnt/w none /mnt/m cd /mnt/m cp /bin/echo . ~/test/a.out Expected result: hello Actually result: execveat: Invalid argument dmesg: Invalid argument reading file caps for /dev/fd/3 The 2nd reproducer and setup emulates similar case but for regular filesystem: const char* exec="echo"; int fd, err; char buf[256]; fd = open(exec, O_RDONLY); unlink(exec); err = fgetxattr(fd, "security.capability", buf, 256); if(err<0) fprintf(stderr, "fgetxattr: %s\n", strerror(errno)); gcc compile into ~/test_fgetxattr cd /tmp cp /bin/echo . ~/test_fgetxattr Result: fgetxattr: Invalid argument On regular filesystem, for example, ext4 read xattr from disk and return to execveat(), will not trigger this issue, however, the overlay attr handler pass real dentry to vfs_getxattr() will. This reproducer calls fgetxattr() with an unlinked fd, involkes vfs_getxattr() then reproduced the case that d_find_alias() in cap_inode_getsecurity() can't find the unlinked dentry. Suggested-by: Amir Goldstein Acked-by: Amir Goldstein Acked-by: Serge E. Hallyn Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities") Cc: # v4.14 Signed-off-by: Eddie Horng Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit 476738bbc96291a1a1ad22b80b324cb51ce83f9d Author: Masahiro Yamada Date: Thu Aug 16 13:36:48 2018 +0900 kconfig: fix "Can't open ..." in parallel build commit 98a4afbfafd226636cd6bb6a1208b3693daff2b1 upstream. If you run "make menuconfig" or "make nconfig" with -j option in a fresh source tree, you will see several "Can't open ..." messages: $ make -j8 menuconfig HOSTCC scripts/basic/fixdep YACC scripts/kconfig/zconf.tab.c LEX scripts/kconfig/zconf.lex.c /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg /bin/sh: 1: .: HOSTCC scripts/kconfig/lxdialog/checklist.o Can't open scripts/kconfig/.mconf-cfg /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg HOSTCC scripts/kconfig/lxdialog/inputbox.o /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg UPD scripts/kconfig/.mconf-cfg /bin/sh: 1: .: Can't open scripts/kconfig/.mconf-cfg HOSTCC scripts/kconfig/lxdialog/menubox.o HOSTCC scripts/kconfig/lxdialog/textbox.o HOSTCC scripts/kconfig/lxdialog/util.o HOSTCC scripts/kconfig/lxdialog/yesno.o HOSTCC scripts/kconfig/mconf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/mconf Correct dependencies to fix this problem. Fixes: 1c5af5cf9308 ("kconfig: refactor ncurses package checks for building mconf and nconf") Cc: linux-stable # v4.18 Reported-by: Borislav Petkov Signed-off-by: Masahiro Yamada Tested-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit a0725910f3e23569cdb88e1c726decc669ecc81a Author: Shan Hai Date: Thu Aug 23 02:02:56 2018 +0800 bcache: release dc->writeback_lock properly in bch_writeback_thread() commit 3943b040f11ed0cc6d4585fd286a623ca8634547 upstream. The writeback thread would exit with a lock held when the cache device is detached via sysfs interface, fix it by releasing the held lock before exiting the while-loop. Fixes: fadd94e05c02 (bcache: quit dc->writeback_thread when BCACHE_DEV_DETACHING is set) Signed-off-by: Shan Hai Signed-off-by: Coly Li Tested-by: Shenghui Wang Cc: stable@vger.kernel.org #4.17+ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 437d23a6792a62e22904833d42788acc65f8deb2 Author: Vishal Verma Date: Fri Aug 10 13:23:15 2018 -0600 libnvdimm: fix ars_status output length calculation commit 286e87718103acdf85f4ed323a37e4839a8a7c05 upstream. Commit efda1b5d87cb ("acpi, nfit, libnvdimm: fix / harden ars_status output length handling") Introduced additional hardening for ambiguity in the ACPI spec for ars_status output sizing. However, it had a couple of cases mixed up. Where it should have been checking for (and returning) "out_field[1] - 4" it was using "out_field[1] - 8" and vice versa. This caused a four byte discrepancy in the buffer size passed on to the command handler, and in some cases, this caused memory corruption like: ./daxdev-errors.sh: line 76: 24104 Aborted (core dumped) ./daxdev-errors $busdev $region malloc(): memory corruption Program received signal SIGABRT, Aborted. [...] #5 0x00007ffff7865a2e in calloc () from /lib64/libc.so.6 #6 0x00007ffff7bc2970 in ndctl_bus_cmd_new_ars_status (ars_cap=ars_cap@entry=0x6153b0) at ars.c:136 #7 0x0000000000401644 in check_ars_status (check=0x7fffffffdeb0, bus=0x604c20) at daxdev-errors.c:144 #8 test_daxdev_clear_error (region_name=, bus_name=) at daxdev-errors.c:332 Cc: Cc: Dave Jiang Cc: Keith Busch Cc: Lukasz Dorau Cc: Dan Williams Fixes: efda1b5d87cb ("acpi, nfit, libnvdimm: fix / harden ars_status output length handling") Signed-off-by: Vishal Verma Reviewed-by: Keith Busch Signed-of-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman commit 54ce46aa987013f18e8b894b94e0247801d3a7e2 Author: Keith Busch Date: Tue Jul 24 15:07:57 2018 -0600 libnvdimm: Use max contiguous area for namespace size commit 12e3129e29b406c41bc89231092a20d79dbf802c upstream. This patch will find the max contiguous area to determine the largest pmem namespace size that can be created. If the requested size exceeds the largest available, ENOSPC error will be returned. This fixes the allocation underrun error and wrong error return code that have otherwise been observed as the following kernel warning: WARNING: CPU: PID: at drivers/nvdimm/namespace_devs.c:913 size_store Fixes: a1f3e4d6a0c3 ("libnvdimm, region: update nd_region_available_dpa() for multi-pmem support") Cc: Signed-off-by: Keith Busch Reviewed-by: Vishal Verma Signed-off-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman commit 118cb27721f9d47773ee6220775e819b3c77f424 Author: Christian Brauner Date: Thu Jun 7 13:43:48 2018 +0200 getxattr: use correct xattr length commit 82c9a927bc5df6e06b72d206d24a9d10cced4eb5 upstream. When running in a container with a user namespace, if you call getxattr with name = "system.posix_acl_access" and size % 8 != 4, then getxattr silently skips the user namespace fixup that it normally does resulting in un-fixed-up data being returned. This is caused by posix_acl_fix_xattr_to_user() being passed the total buffer size and not the actual size of the xattr as returned by vfs_getxattr(). This commit passes the actual length of the xattr as returned by vfs_getxattr() down. A reproducer for the issue is: touch acl_posix setfacl -m user:0:rwx acl_posix and the compile: #define _GNU_SOURCE #include #include #include #include #include #include #include /* Run in user namespace with nsuid 0 mapped to uid != 0 on the host. */ int main(int argc, void **argv) { ssize_t ret1, ret2; char buf1[128], buf2[132]; int fret = EXIT_SUCCESS; char *file; if (argc < 2) { fprintf(stderr, "Please specify a file with " "\"system.posix_acl_access\" permissions set\n"); _exit(EXIT_FAILURE); } file = argv[1]; ret1 = getxattr(file, "system.posix_acl_access", buf1, sizeof(buf1)); if (ret1 < 0) { fprintf(stderr, "%s - Failed to retrieve " "\"system.posix_acl_access\" " "from \"%s\"\n", strerror(errno), file); _exit(EXIT_FAILURE); } ret2 = getxattr(file, "system.posix_acl_access", buf2, sizeof(buf2)); if (ret2 < 0) { fprintf(stderr, "%s - Failed to retrieve " "\"system.posix_acl_access\" " "from \"%s\"\n", strerror(errno), file); _exit(EXIT_FAILURE); } if (ret1 != ret2) { fprintf(stderr, "The value of \"system.posix_acl_" "access\" for file \"%s\" changed " "between two successive calls\n", file); _exit(EXIT_FAILURE); } for (ssize_t i = 0; i < ret2; i++) { if (buf1[i] == buf2[i]) continue; fprintf(stderr, "Unexpected different in byte %zd: " "%02x != %02x\n", i, buf1[i], buf2[i]); fret = EXIT_FAILURE; } if (fret == EXIT_SUCCESS) fprintf(stderr, "Test passed\n"); else fprintf(stderr, "Test failed\n"); _exit(fret); } and run: ./tester acl_posix On a non-fixed up kernel this should return something like: root@c1:/# ./t Unexpected different in byte 16: ffffffa0 != 00 Unexpected different in byte 17: ffffff86 != 00 Unexpected different in byte 18: 01 != 00 and on a fixed kernel: root@c1:~# ./t Test passed Cc: stable@vger.kernel.org Fixes: 2f6f0654ab61 ("userns: Convert vfs posix_acl support to use kuids and kgids") Link: https://bugzilla.kernel.org/show_bug.cgi?id=199945 Reported-by: Colin Watson Signed-off-by: Christian Brauner Acked-by: Serge Hallyn Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit fd13ae7e102a3e8dd4b45bd2dc12c61416331563 Author: Mikulas Patocka Date: Wed Jul 25 15:41:56 2018 +0200 udlfb: set line_length in dlfb_ops_set_par commit 0ac319b7af1bb24a33365d0ec82a2f56a59b2a78 upstream. Set the variable "line_length" in the function dlfb_ops_set_par. Without this, we get garbage if we select different videomode with fbset. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit f551b193299b4212b66fbc44652a36f54b0fe0d7 Author: Mikulas Patocka Date: Wed Jul 25 15:41:56 2018 +0200 udlfb: handle allocation failure commit 080fb5240bdcabed7387b814139c3ea172d59fc5 upstream. Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they may fail anytime. This patch fixes the udlfb driver so that when a large alloactions fails, it tries to do multiple smaller allocations. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 0b5373ea72987884547c3a88c44cf93119c014e0 Author: Mikulas Patocka Date: Wed Jul 25 15:41:55 2018 +0200 udlfb: make a local copy of fb_ops commit 2c29cfc3eaf11779176bf41475cfca49bccba11c upstream. The defio subsystem overwrites the method fb_osp->mmap. That method is stored in module's static data - and that means that if we have multiple diplaylink adapters, they will over write each other's method. In order to avoid interference between multiple adapters, we copy the fb_ops structure to a device-local memory. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit af0890aa45651a4ae37afefd29e2a0fa74c62f23 Author: Mikulas Patocka Date: Wed Jul 25 15:41:55 2018 +0200 udlfb: set optimal write delay commit bb24153a3f13dd0dbc1f8055ad97fe346d598f66 upstream. The default delay 5 jiffies is too much when the kernel is compiled with HZ=100 - it results in jumpy cursor in Xwindow. In order to find out the optimal delay, I benchmarked the driver on 1280x720x30fps video. I found out that with HZ=1000, 10ms is acceptable, but with HZ=250 or HZ=300, we need 4ms, so that the video is played without any frame skips. This patch changes the delay to this value. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 76aab4b1d8044f3b1f1dc0e6f72760dc71b00f23 Author: Mikulas Patocka Date: Wed Jul 25 15:41:55 2018 +0200 udlfb: don't switch if we are switching to the same videomode commit 564f1807379298dfdb12ed0d5b25fcb89c238527 upstream. The udlfb driver reprograms the hardware everytime the user switches the console, that makes quite unusable when working on the console. This patch makes the driver remember the videomode we are in and avoid reprogramming the hardware if we switch to the same videomode. We mask the "activate" field and the "FB_VMODE_SMOOTH_XPAN" flag when comparing the videomode, because they cause spurious switches when switching to and from the Xserver. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 1a5656245bd6d1f9b1bab1933a47a31f3d26b8b9 Author: Mikulas Patocka Date: Wed Jul 25 15:41:54 2018 +0200 udlfb: fix display corruption of the last line commit 4e705e17ce3409a1f492cfd5dadcf6a4f6075842 upstream. The displaylink hardware has such a peculiarity that it doesn't render a command until next command is received. This produces occasional corruption, such as when setting 22x11 font on the console, only the first line of the cursor will be blinking if the cursor is located at some specific columns. When we end up with a repeating pixel, the driver has a bug that it leaves one uninitialized byte after the command (and this byte is enough to flush the command and render it - thus it fixes the screen corruption), however whe we end up with a non-repeating pixel, there is no byte appended and this results in temporary screen corruption. This patch fixes the screen corruption by always appending a byte 0xAF at the end of URB. It also removes the uninitialized byte. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 27f6b46dd248ce35f264e85ef97ea152eb6004d6 Author: Mikulas Patocka Date: Wed Jul 25 15:41:54 2018 +0200 udlfb: fix semaphore value leak commit 9d0aa601e4cd9c0892f90d36e8488d79b72f4073 upstream. I observed that the performance of the udl fb driver degrades over time. On a freshly booted machine, it takes 6 seconds to do "ls -la /usr/bin"; after some time of use, the same operation takes 14 seconds. The reason is that the value of "limit_sem" decays over time. The udl driver uses a semaphore "limit_set" to specify how many free urbs are there on dlfb->urbs.list. If the count is zero, the "down" operation will sleep until some urbs are added to the freelist. In order to avoid some hypothetical deadlock, the driver will not call "up" immediately, but it will offload it to a workqueue. The problem is that if we call "schedule_delayed_work" on the same work item multiple times, the work item may only be executed once. This is happening: * some urb completes * dlfb_urb_completion adds it to the free list * dlfb_urb_completion calls schedule_delayed_work to schedule the function dlfb_release_urb_work to increase the semaphore count * as the urb is on the free list, some other task grabs it and submits it * the submitted urb completes, dlfb_urb_completion is called again * dlfb_urb_completion calls schedule_delayed_work, but the work is already scheduled, so it does nothing * finally, dlfb_release_urb_work is called, it increases the semaphore count by 1, although it should increase it by 2 So, the semaphore count is decreasing over time, and this causes gradual performance degradation. Note that in the current kernel, the "up" function may be called from interrupt and it may race with the "down" function called by another thread, so we don't have to offload the call of "up" to a workqueue at all. This patch removes the workqueue code. The patch also changes "down_interruptible" to "down" in dlfb_free_urb_list, so that we will clean up the driver properly even if a signal arrives. With this patch, the performance of udlfb no longer degrades. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org [b.zolnierkie: fix immediatelly -> immediately typo] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 1a9ec6296e18426d2e4f177b66175f479f05a134 Author: Mikulas Patocka Date: Wed Jul 25 15:41:54 2018 +0200 fb: fix lost console when the user unplugs a USB adapter commit 8c5b044299951acd91e830a688dd920477ea1eda upstream. I have a USB display adapter using the udlfb driver and I use it on an ARM board that doesn't have any graphics card. When I plug the adapter in, the console is properly displayed, however when I unplug and re-plug the adapter, the console is not displayed and I can't access it until I reboot the board. The reason is this: When the adapter is unplugged, dlfb_usb_disconnect calls unlink_framebuffer, then it waits until the reference count drops to zero and then it deallocates the framebuffer. However, the console that is attached to the framebuffer device keeps the reference count non-zero, so the framebuffer device is never destroyed. When the USB adapter is plugged again, it creates a new device /dev/fb1 and the console is not attached to it. This patch fixes the bug by unbinding the console from unlink_framebuffer. The code to unbind the console is moved from do_unregister_framebuffer to a function unbind_console. When the console is unbound, the reference count drops to zero and the udlfb driver frees the framebuffer. When the adapter is plugged back, a new framebuffer is created and the console is attached to it. Signed-off-by: Mikulas Patocka Cc: Dave Airlie Cc: Bernie Thompson Cc: Ladislav Michl Cc: stable@vger.kernel.org [b.zolnierkie: preserve old behavior for do_unregister_framebuffer()] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit f72831f9cbb64938fd2ded5bc11191c9b757b40e Author: Vignesh R Date: Mon Jun 11 11:39:56 2018 +0530 pwm: tiehrpwm: Fix disabling of output of PWMs commit 38dabd91ff0bde33352ca3cc65ef515599b77a05 upstream. pwm-tiehrpwm driver disables PWM output by putting it in low output state via active AQCSFRC register in ehrpwm_pwm_disable(). But, the AQCSFRC shadow register is not updated. Therefore, when shadow AQCSFRC register is re-enabled in ehrpwm_pwm_enable() (say to enable second PWM output), previous settings are lost as shadow register value is loaded into active register. This results in things like PWMA getting enabled automatically, when PWMB is enabled and vice versa. Fix this by updating AQCSFRC shadow register as well during ehrpwm_pwm_disable(). Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Cc: stable@vger.kernel.org Signed-off-by: Vignesh R Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit e0e08ede24c931215ed34424fe48776e7e612dfb Author: Vignesh R Date: Mon Jun 11 11:39:55 2018 +0530 pwm: tiehrpwm: Don't use emulation mode bits to control PWM output commit aa49d628f6e016bcec8c6f8e704b9b18ee697329 upstream. As per AM335x TRM SPRUH73P "15.2.2.11 ePWM Behavior During Emulation", TBCTL[15:14] only have effect during emulation suspend events (IOW, to stop PWM when debugging using a debugger). These bits have no effect on PWM output during normal running of system. Hence, remove code accessing these bits as they have no role in enabling/disabling PWMs. Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Cc: stable@vger.kernel.org Signed-off-by: Vignesh R Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 3ce08627b3e3805c3170f50dfa005f38b86fdfc2 Author: Richard Weinberger Date: Tue Jun 12 00:52:28 2018 +0200 ubifs: Fix synced_i_size calculation for xattr inodes commit 59965593205fa4044850d35ee3557cf0b7edcd14 upstream. In ubifs_jnl_update() we sync parent and child inodes to the flash, in case of xattrs, the parent inode (AKA host inode) has a non-zero data_len. Therefore we need to adjust synced_i_size too. This issue was reported by ubifs self tests unter a xattr related work load. UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: ui_size is 4, synced_i_size is 0, but inode is clean UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: i_ino 65, i_mode 0x81a4, i_size 4 Cc: Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit f9b28f9a2b7fce5c8b4383362844bc8469c1f41b Author: Richard Weinberger Date: Mon Jun 11 23:41:09 2018 +0200 ubifs: Fix directory size calculation for symlinks commit 00ee8b60102862f4daf0814d12a2ea2744fc0b9b upstream. We have to account the name of the symlink and not the target length. Fixes: ca7f85be8d6c ("ubifs: Add support for encrypted symlinks") Cc: Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit cef393ce9aea9e0a0804da9cbabb4bec78bd29fa Author: Richard Weinberger Date: Sun Jul 8 23:33:25 2018 +0200 ubifs: xattr: Don't operate on deleted inodes commit 11a6fc3dc743e22fb50f2196ec55bee5140d3c52 upstream. xattr operations can race with unlink and the following assert triggers: UBIFS assert failed in ubifs_jnl_change_xattr at 1606 (pid 6256) Fix this by checking i_nlink before working on the host inode. Cc: Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit ce0504b74d046da612f4758117eca0122c2ee225 Author: Richard Weinberger Date: Sun Jul 1 23:20:51 2018 +0200 ubifs: Check data node size before truncate commit 95a22d2084d72ea067d8323cc85677dba5d97cae upstream. Check whether the size is within bounds before using it. If the size is not correct, abort and dump the bad data node. Cc: Kees Cook Cc: Silvio Cesare Cc: stable@vger.kernel.org Fixes: 1e51764a3c2ac ("UBIFS: add new flash file system") Reported-by: Silvio Cesare Signed-off-by: Richard Weinberger Reviewed-by: Kees Cook Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit aa8298662e526f8eae1997e31689eb44852a2b0d Author: Richard Weinberger Date: Sun Jul 1 23:20:50 2018 +0200 Revert "UBIFS: Fix potential integer overflow in allocation" commit 08acbdd6fd736b90f8d725da5a0de4de2dd6de62 upstream. This reverts commit 353748a359f1821ee934afc579cf04572406b420. It bypassed the linux-mtd review process and fixes the issue not as it should. Cc: Kees Cook Cc: Silvio Cesare Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 3863ba26f2710a10e8f3626a6a8b01f5075a3b0e Author: Richard Weinberger Date: Tue Jun 12 20:49:45 2018 +0200 ubifs: Fix memory leak in lprobs self-check commit eef19816ada3abd56d9f20c88794cc2fea83ebb2 upstream. Allocate the buffer after we return early. Otherwise memory is being leaked. Cc: Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 7131c193fcc3af158bda20f144105d19e65e4cad Author: Jann Horn Date: Mon Jun 25 18:34:19 2018 +0200 userns: move user access out of the mutex commit 5820f140edef111a9ea2ef414ab2428b8cb805b1 upstream. The old code would hold the userns_state_mutex indefinitely if memdup_user_nul stalled due to e.g. a userfault region. Prevent that by moving the memdup_user_nul in front of the mutex_lock(). Note: This changes the error precedence of invalid buf/count/*ppos vs map already written / capabilities missing. Fixes: 22d917d80e84 ("userns: Rework the user_namespace adding uid/gid...") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Acked-by: Christian Brauner Acked-by: Serge Hallyn Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit 1497f1e0714accef5334237f5bbe7e300290d799 Author: Jann Horn Date: Mon Jun 25 18:34:10 2018 +0200 sys: don't hold uts_sem while accessing userspace memory commit 42a0cc3478584d4d63f68f2f5af021ddbea771fa upstream. Holding uts_sem as a writer while accessing userspace memory allows a namespace admin to stall all processes that attempt to take uts_sem. Instead, move data through stack buffers and don't access userspace memory while uts_sem is held. Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jann Horn Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit 11f44063756fa58b925f116c0a5c29f530c911f8 Author: Jacob Pan Date: Thu Jun 7 09:57:00 2018 -0700 iommu/vt-d: Fix dev iotlb pfsid use commit 1c48db44924298ad0cb5a6386b88017539be8822 upstream. PFSID should be used in the invalidation descriptor for flushing device IOTLBs on SRIOV VFs. Signed-off-by: Jacob Pan Cc: stable@vger.kernel.org Cc: "Ashok Raj" Cc: "Lu Baolu" Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit e7feba89574d2a8d599da1cd04e0e8aa19c71048 Author: Jacob Pan Date: Thu Jun 7 09:56:59 2018 -0700 iommu/vt-d: Add definitions for PFSID commit 0f725561e168485eff7277d683405c05b192f537 upstream. When SRIOV VF device IOTLB is invalidated, we need to provide the PF source ID such that IOMMU hardware can gauge the depth of invalidation queue which is shared among VFs. This is needed when device invalidation throttle (DIT) capability is supported. This patch adds bit definitions for checking and tracking PFSID. Signed-off-by: Jacob Pan Cc: stable@vger.kernel.org Cc: "Ashok Raj" Cc: "Lu Baolu" Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 3245925a8e9c4fb5f2ccb2b7c21d2cb35ce8725a Author: Dmitry Osipenko Date: Fri Jul 27 00:19:16 2018 +0300 iommu/ipmmu-vmsa: Don't register as BUS IOMMU if machine doesn't have IPMMU-VMSA commit 5c5c87411488af3cd082221e567498d813d0fe83 upstream. This fixes kernel crashing on NVIDIA Tegra if kernel is compiled in a multiplatform configuration and IPMMU-VMSA driver is enabled. Cc: # v3.20+ Signed-off-by: Dmitry Osipenko Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 2d0363ffc0ab20af3b640deac230f24ae06b032b Author: Peter Zijlstra Date: Wed Aug 22 17:30:14 2018 +0200 mm/tlb: Remove tlb_remove_table() non-concurrent condition commit a6f572084fbee8b30f91465f4a085d7a90901c57 upstream. Will noted that only checking mm_users is incorrect; we should also check mm_count in order to cover CPUs that have a lazy reference to this mm (and could do speculative TLB operations). If removing this turns out to be a performance issue, we can re-instate a more complete check, but in tlb_table_flush() eliding the call_rcu_sched(). Fixes: 267239116987 ("mm, powerpc: move the RCU page-table freeing into generic code") Reported-by: Will Deacon Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rik van Riel Acked-by: Will Deacon Cc: Nicholas Piggin Cc: David Miller Cc: Martin Schwidefsky Cc: Michael Ellerman Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6bdfc65b5062d7aa9d2134cf67697a4a11f244cf Author: David Rivshin Date: Wed Aug 1 10:17:29 2018 -0400 pwm: omap-dmtimer: Return -EPROBE_DEFER if no dmtimer platform data commit 43725feb593127b16318b871e3a9bf89a96d66cb upstream. If a pwm-omap-dmtimer is probed before the dmtimer it uses, the platform data won't be set yet. Fixes: ac30751df953 ("ARM: OMAP: pdata-quirks: Remove unused timer pdata") Cc: # 4.17+ Signed-off-by: David Rivshin Acked-by: Pavel Machek Tested-by: Pavel Machek Acked-by: Ladislav Michl Tested-by: Andreas Kemnade Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 1ba930714d12dfabb8153b7b7595683558106848 Author: Roger Quadros Date: Tue May 29 12:00:55 2018 +0300 ARM: dts: am57xx-idk: Enable dual role for USB2 port commit 5f3cc16483d40bbc609a828511ff851296fc62b6 upstream. Dual-role support was added in v4.12. We should be using it for USB2 port on the am57xx-idk. Cc: [4.16+] Reported-by: Bin Liu Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit da43c1c103c84e4651a1c4c4b0093d8f646d96e7 Author: Jon Hunter Date: Tue Jul 3 09:59:47 2018 +0100 ARM: tegra: Fix Tegra30 Cardhu PCA954x reset commit 6e1811900b6fe6f2b4665dba6bd6ed32c6b98575 upstream. On all versions of Tegra30 Cardhu, the reset signal to the NXP PCA9546 I2C mux is connected to the Tegra GPIO BB0. Currently, this pin on the Tegra is not configured as a GPIO but as a special-function IO (SFIO) that is multiplexing the pin to an I2S controller. On exiting system suspend, I2C commands sent to the PCA9546 are failing because there is no ACK. Although it is not possible to see exactly what is happening to the reset during suspend, by ensuring it is configured as a GPIO and driven high, to de-assert the reset, the failures are no longer seen. Please note that this GPIO is also used to drive the reset signal going to the camera connector on the board. However, given that there is no camera support currently for Cardhu, this should not have any impact. Fixes: 40431d16ff11 ("ARM: tegra: enable PCA9546 on Cardhu") Cc: stable@vger.kernel.org Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 1750f49b26c220ef364c1b7869f35f3ec81f001a Author: Trond Myklebust Date: Tue Aug 14 17:55:56 2018 -0400 NFSv4: Fix a sleep in atomic context in nfs4_callback_sequence() commit 8618289c46556fd4dd259a1af02ccc448032f48d upstream. We must drop the lock before we can sleep in referring_call_exists(). Reported-by: Jia-Ju Bai Fixes: 045d2a6d076a ("NFSv4.1: Delay callback processing...") Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit c8f825303e493a2489b16857b69f2e1aacb83ba1 Author: Trond Myklebust Date: Tue Aug 14 17:25:37 2018 -0400 NFSv4: Fix locking in pnfs_generic_recover_commit_reqs commit d0fbb1d8a194c0ec0180c1d073ad709e45503a43 upstream. The use of the inode->i_lock was converted to a mutex, but we forgot to remove the old inode unlock/lock() pair that allowed the layout segment to be put inside the loop. Reported-by: Jia-Ju Bai Fixes: e824f99adaaf1 ("NFSv4: Use a mutex to protect the per-inode commit...") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit b8cbfd88d1325eac0b6484f254b0ce8681fc5994 Author: Bill Baker Date: Tue Jun 19 16:24:58 2018 -0500 NFSv4 client live hangs after live data migration recovery commit 0f90be132cbf1537d87a6a8b9e80867adac892f6 upstream. After a live data migration event at the NFS server, the client may send I/O requests to the wrong server, causing a live hang due to repeated recovery events. On the wire, this will appear as an I/O request failing with NFS4ERR_BADSESSION, followed by successful CREATE_SESSION, repeatedly. NFS4ERR_BADSSESSION is returned because the session ID being used was issued by the other server and is not valid at the old server. The failure is caused by async worker threads having cached the transport (xprt) in the rpc_task structure. After the migration recovery completes, the task is redispatched and the task resends the request to the wrong server based on the old value still present in tk_xprt. The solution is to recompute the tk_xprt field of the rpc_task structure so that the request goes to the correct server. Signed-off-by: Bill Baker Reviewed-by: Chuck Lever Tested-by: Helen Chao Fixes: fb43d17210ba ("SUNRPC: Use the multipath iterator to assign a ...") Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit e16dac834b32549c4b3cb586b8e256aa76a95464 Author: Amir Goldstein Date: Fri Jul 13 17:22:24 2018 +0300 nfsd: fix leaked file lock with nfs exported overlayfs commit 64bed6cbe38bc95689fb9399872d9ce250192f90 upstream. nfsd and lockd call vfs_lock_file() to lock/unlock the inode returned by locks_inode(file). Many places in nfsd/lockd code use the inode returned by file_inode(file) for lock manipulation. With Overlayfs, file_inode() (the underlying inode) is not the same object as locks_inode() (the overlay inode). This can result in "Leaked POSIX lock" messages and eventually to a kernel crash as reported by Eddie Horng: https://marc.info/?l=linux-unionfs&m=153086643202072&w=2 Fix all the call sites in nfsd/lockd that should use locks_inode(). This is a correctness bug that manifested when overlayfs gained NFS export support in v4.16. Reported-by: Eddie Horng Tested-by: Eddie Horng Cc: Jeff Layton Fixes: 8383f1748829 ("ovl: wire up NFS export operations") Cc: stable@vger.kernel.org Signed-off-by: Amir Goldstein Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit f7169718defcf81ba5b6f32b1a324b0e3ad68b28 Author: Dan Carpenter Date: Wed Jul 4 12:59:58 2018 +0300 pnfs/blocklayout: off by one in bl_map_stripe() commit 0914bb965e38a055e9245637aed117efbe976e91 upstream. "dev->nr_children" is the number of children which were parsed successfully in bl_parse_stripe(). It could be all of them and then, in that case, it is equal to v->stripe.volumes_count. Either way, the > should be >= so that we don't go beyond the end of what we're supposed to. Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing") Signed-off-by: Dan Carpenter Reviewed-by: Christoph Hellwig Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 6ee996baf1ab28ae2f5f74f1f62e3bc488cc8f6a Author: Maciej S. Szmigiero Date: Wed Aug 15 23:56:45 2018 +0200 block, bfq: return nbytes and not zero from struct cftype .write() method commit fc8ebd01deeb12728c83381f6ec923e4a192ffd3 upstream. The value that struct cftype .write() method returns is then directly returned to userspace as the value returned by write() syscall, so it should be the number of bytes actually written (or consumed) and not zero. Returning zero from write() syscall makes programs like /bin/echo or bash spin. Signed-off-by: Maciej S. Szmigiero Fixes: e21b7a0b9887 ("block, bfq: add full hierarchical scheduling and cgroups support") Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit fbd0c9d27ccbb91c86df1f0ee453140caefea3d4 Author: Max Filippov Date: Fri Aug 10 22:21:22 2018 -0700 xtensa: increase ranges in ___invalidate_{i,d}cache_all commit fec3259c9f747c039f90e99570540114c8d81a14 upstream. Cache invalidation macros use cache line size to iterate over invalidated cache lines, assuming that all cache ways are invalidated by single instruction, but xtensa ISA recommends to not assume that for future compatibility: In some implementations all ways at index Addry-1..z are invalidated regardless of the specified way, but for future compatibility this behavior should not be assumed. Iterate over all cache ways in ___invalidate_icache_all and ___invalidate_dcache_all. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 27077422f9512f451e41f4c7d9e03fc6221ac202 Author: Max Filippov Date: Fri Aug 10 20:43:48 2018 -0700 xtensa: limit offsets in __loop_cache_{all,page} commit be75de25251f7cf3e399ca1f584716a95510d24a upstream. When building kernel for xtensa cores with big cache lines (e.g. 128 bytes or more) __loop_cache_all and __loop_cache_page may generate assembly instructions with immediate fields that are too big. This results in the following build errors: arch/xtensa/mm/misc.S: Assembler messages: arch/xtensa/mm/misc.S:464: Error: operand 2 of 'diwbi' has invalid value '256' arch/xtensa/mm/misc.S:464: Error: operand 2 of 'diwbi' has invalid value '384' arch/xtensa/kernel/head.S: Assembler messages: arch/xtensa/kernel/head.S:172: Error: operand 2 of 'diu' has invalid value '256' arch/xtensa/kernel/head.S:172: Error: operand 2 of 'diu' has invalid value '384' arch/xtensa/kernel/head.S:176: Error: operand 2 of 'iiu' has invalid value '256' arch/xtensa/kernel/head.S:176: Error: operand 2 of 'iiu' has invalid value '384' arch/xtensa/kernel/head.S:255: Error: operand 2 of 'diwb' has invalid value '256' arch/xtensa/kernel/head.S:255: Error: operand 2 of 'diwb' has invalid value '384' Add parameter max_immed to these macros and use it to limit values of immediate operands. Extract common code of these macros into the new macro __loop_cache_unroll. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 3bb34bba5624f7966e56044f6bd33e4c57447273 Author: Paul Mackerras Date: Thu Aug 23 10:08:58 2018 +1000 KVM: PPC: Book3S: Fix guest DMA when guest partially backed by THP pages commit 8cfbdbdc24815417a3ab35101ccf706b9a23ff17 upstream. Commit 76fa4975f3ed ("KVM: PPC: Check if IOMMU page is contained in the pinned physical page", 2018-07-17) added some checks to ensure that guest DMA mappings don't attempt to map more than the guest is entitled to access. However, errors in the logic mean that legitimate guest requests to map pages for DMA are being denied in some situations. Specifically, if the first page of the range passed to mm_iommu_get() is mapped with a normal page, and subsequent pages are mapped with transparent huge pages, we end up with mem->pageshift == 0. That means that the page size checks in mm_iommu_ua_to_hpa() and mm_iommu_up_to_hpa_rm() will always fail for every page in that region, and thus the guest can never map any memory in that region for DMA, typically leading to a flood of error messages like this: qemu-system-ppc64: VFIO_MAP_DMA: -22 qemu-system-ppc64: vfio_dma_map(0x10005f47780, 0x800000000000000, 0x10000, 0x7fff63ff0000) = -22 (Invalid argument) The logic errors in mm_iommu_get() are: (a) use of 'ua' not 'ua + (i << PAGE_SHIFT)' in the find_linux_pte() call (meaning that find_linux_pte() returns the pte for the first address in the range, not the address we are currently up to); (b) use of 'pageshift' as the variable to receive the hugepage shift returned by find_linux_pte() - for a normal page this gets set to 0, leading to us setting mem->pageshift to 0 when we conclude that the pte returned by find_linux_pte() didn't match the page we were looking at; (c) comparing 'compshift', which is a page order, i.e. log base 2 of the number of pages, with 'pageshift', which is a log base 2 of the number of bytes. To fix these problems, this patch introduces 'cur_ua' to hold the current user address and uses that in the find_linux_pte() call; introduces 'pteshift' to hold the hugepage shift found by find_linux_pte(); and compares 'pteshift' with 'compshift + PAGE_SHIFT' rather than 'compshift'. The patch also moves the local_irq_restore to the point after the PTE pointer returned by find_linux_pte() has been dereferenced because otherwise the PTE could change underneath us, and adds a check to avoid doing the find_linux_pte() call once mem->pageshift has been reduced to PAGE_SHIFT, as an optimization. Fixes: 76fa4975f3ed ("KVM: PPC: Check if IOMMU page is contained in the pinned physical page") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f90625c7172b469d0041161e7792b47e807e9cd2 Author: Paolo Bonzini Date: Wed Aug 22 16:43:39 2018 +0200 KVM: VMX: fixes for vmentry_l1d_flush module parameter commit 0027ff2a75f9dcf0537ac0a65c5840b0e21a4950 upstream. Two bug fixes: 1) missing entries in the l1d_param array; this can cause a host crash if an access attempts to reach the missing entry. Future-proof the get function against any overflows as well. However, the two entries VMENTER_L1D_FLUSH_EPT_DISABLED and VMENTER_L1D_FLUSH_NOT_REQUIRED must not be accepted by the parse function, so disable them there. 2) invalid values must be rejected even if the CPU does not have the bug, so test for them before checking boot_cpu_has(X86_BUG_L1TF) ... and a small refactoring, since the .cmd field is redundant with the index in the array. Reported-by: Bandan Das Cc: stable@vger.kernel.org Fixes: a7b9020b06ec6d7c3f3b0d4ef1a9eba12654f4f7 Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 09747f7004ab63c55c4f0100376fe3b3d124afa3 Author: Hans de Goede Date: Wed Aug 29 15:06:31 2018 +0200 i2c: designware: Re-init controllers with pm_disabled set on resume commit 9d9a152ebaa86a9dede4624919566483c955d0a7 upstream. On Bay Trail and Cherry Trail devices we set the pm_disabled flag for I2C busses which the OS shares with the PUNIT as these need special handling. Until now we called dev_pm_syscore_device(dev, true) for I2C controllers with this flag set to keep these I2C controllers always on. After commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation"), this no longer works. This commit modifies lpss_iosf_exit_d3_state() to only run if lpss_iosf_enter_d3_state() has ran before it, so that it does not run on a resume from hibernate (or from S3). On these systems the conditions for lpss_iosf_enter_d3_state() to run never become true, so lpss_iosf_exit_d3_state() never gets called and the 2 LPSS DMA controllers never get forced into D0 mode, instead they are left in their default automatic power-on when needed mode. The not forcing of D0 mode for the DMA controllers enables these systems to properly enter S0ix modes, which is a good thing. But after entering S0ix modes the I2C controller connected to the PMIC no longer works, leading to e.g. broken battery monitoring. The _PS3 method for this I2C controller looks like this: Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 { If ((((PMID == 0x04) || (PMID == 0x05)) || (PMID == 0x06))) { Return (Zero) } PSAT |= 0x03 Local0 = PSAT /* \_SB_.I2C5.PSAT */ } Where PMID = 0x05, so we enter the Return (Zero) path on these systems. So even if we were to not call dev_pm_syscore_device(dev, true) the I2C controller will be left in D0 rather then be switched to D3. Yet on other Bay and Cherry Trail devices S0ix is not entered unless *all* I2C controllers are in D3 mode. This combined with the I2C controller no longer working now that we reach S0ix states on these systems leads to me believing that the PUNIT itself puts the I2C controller in D3 when all other conditions for entering S0ix states are true. Since now the I2C controller is put in D3 over a suspend/resume we must re-initialize it afterwards and that does indeed fix it no longer working. This commit implements this fix by: 1) Making the suspend_late callback a no-op if pm_disabled is set and making the resume_early callback skip the clock re-enable (since it now was not disabled) while still doing the necessary I2C controller re-init. 2) Removing the dev_pm_syscore_device(dev, true) call, so that the suspend and resume callbacks are actually called. Normally this would cause the ACPI pm code to call _PS3 putting the I2C controller in D3, wreaking havoc since it is shared with the PUNIT, but in this special case the _PS3 method is a no-op so we can safely allow a "fake" suspend / resume. Fixes: 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume ...") Link: https://bugzilla.kernel.org/show_bug.cgi?id=200861 Cc: 4.15+ # 4.15+ Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 7bb7ef09b3dbcefa063ca03325aacc739e50eaaa Author: Lihua Yao Date: Wed Aug 15 23:20:35 2018 +0800 ALSA: ac97: fix unbalanced pm_runtime_enable commit 250ea7c5f56e350cdafebe6b87478b00db4f7af8 upstream. Runtime PM is enabled at ac97_bus_probe() and should be disabled at ac97_bus_remove(). Fixes: 74426fbff66e ("ALSA: ac97: add an ac97 bus") Signed-off-by: Lihua Yao Acked-by: Robert Jarzmik Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d7cff00160365d77a96e86b19152cb0f7b1e1a91 Author: Lihua Yao Date: Wed Aug 15 23:20:34 2018 +0800 ALSA: ac97: fix check of pm_runtime_get_sync failure commit d15ec0b482ff502e4e19e43d15aa5072e4290199 upstream. pm_runtime_get_sync returns negative on failure. Fixes: 74426fbff66e ("ALSA: ac97: add an ac97 bus") Signed-off-by: Lihua Yao Acked-by: Robert Jarzmik Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 52977303d99714ed20259e4ff058079335a32f33 Author: Lihua Yao Date: Wed Aug 15 20:59:46 2018 +0800 ALSA: ac97: fix device initialization in the compat layer commit c7b8170790c19293acd835dc50b8247ec207d4a3 upstream. ac97->dev is an object of 'struct device' type. It should be initialized via device_initialize() or device_register(). Fixes: 74426fbff66e ("ALSA: ac97: add an ac97 bus") Signed-off-by: Lihua Yao Tested-by: Robert Jarzmik Acked-by: Robert Jarzmik Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cd67823c9d34351a72c0e40d40e6b5dc86db2fe4 Author: zhangyi (F) Date: Tue Aug 14 10:34:42 2018 +0800 PM / sleep: wakeup: Fix build error caused by missing SRCU support commit 3df6f61fff49632492490fb6e42646b803a9958a upstream. Commit ea0212f40c6 (power: auto select CONFIG_SRCU) made the code in drivers/base/power/wakeup.c use SRCU instead of RCU, but it forgot to select CONFIG_SRCU in Kconfig, which leads to the following build error if CONFIG_SRCU is not selected somewhere else: drivers/built-in.o: In function `wakeup_source_remove': (.text+0x3c6fc): undefined reference to `synchronize_srcu' drivers/built-in.o: In function `pm_print_active_wakeup_sources': (.text+0x3c7a8): undefined reference to `__srcu_read_lock' drivers/built-in.o: In function `pm_print_active_wakeup_sources': (.text+0x3c84c): undefined reference to `__srcu_read_unlock' drivers/built-in.o: In function `device_wakeup_arm_wake_irqs': (.text+0x3d1d8): undefined reference to `__srcu_read_lock' drivers/built-in.o: In function `device_wakeup_arm_wake_irqs': (.text+0x3d228): undefined reference to `__srcu_read_unlock' drivers/built-in.o: In function `device_wakeup_disarm_wake_irqs': (.text+0x3d24c): undefined reference to `__srcu_read_lock' drivers/built-in.o: In function `device_wakeup_disarm_wake_irqs': (.text+0x3d29c): undefined reference to `__srcu_read_unlock' drivers/built-in.o:(.data+0x4158): undefined reference to `process_srcu' Fix this error by selecting CONFIG_SRCU when PM_SLEEP is enabled. Fixes: ea0212f40c6 (power: auto select CONFIG_SRCU) Cc: 4.2+ # 4.2+ Signed-off-by: zhangyi (F) [ rjw: Minor subject/changelog fixups ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 00e4955e677b80216d98556409bfe74a5cf52d75 Author: Henry Willard Date: Tue Aug 14 17:01:02 2018 -0700 cpufreq: governor: Avoid accessing invalid governor_data commit 2a3eb51e30b9ac66fe1b75877627a7e4aaeca24a upstream. If cppc_cpufreq.ko is deleted at the same time that tuned-adm is changing profiles, there is a small chance that a race can occur between cpufreq_dbs_governor_exit() and cpufreq_dbs_governor_limits() resulting in a system failure when the latter tries to use policy->governor_data that has been freed by the former. This patch uses gov_dbs_data_mutex to synchronize access. Fixes: e788892ba3cc (cpufreq: governor: Get rid of governor events) Signed-off-by: Henry Willard [ rjw: Subject, minor white space adjustment ] Cc: 4.8+ # 4.8+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f83952c647695642e3679bb09c310972024eaa17 Author: Rafael J. Wysocki Date: Tue Aug 14 12:34:40 2018 +0200 cpuidle: menu: Handle stopped tick more aggressively commit 5ef499cd571c293b74a30d77e7ef512edb6ded6b upstream. Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with stopped tick) missed the case when the target residencies of deep idle states of CPUs are above the tick boundary which may cause the CPU to get stuck in a shallow idle state for a long time. Say there are two CPU idle states available: one shallow, with the target residency much below the tick boundary and one deep, with the target residency significantly above the tick boundary. In that case, if the tick has been stopped already and the expected next timer event is relatively far in the future, the governor will assume the idle duration to be equal to TICK_USEC and it will select the idle state for the CPU accordingly. However, that will cause the shallow state to be selected even though it would have been more energy-efficient to select the deep one. To address this issue, modify the governor to always use the time till the closest timer event instead of the predicted idle duration if the latter is less than the tick period length and the tick has been stopped already. Also make it extend the search for a matching idle state if the tick is stopped to avoid settling on a shallow state if deep states with target residencies above the tick period length are available. In addition, make it always indicate that the tick should be stopped if it has been stopped already for consistency. Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with stopped tick) Reported-by: Leo Yan Acked-by: Peter Zijlstra (Intel) Cc: 4.17+ # 4.17+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit cc8ea9dd0c24240e1b44e03bd04b356086ad8493 Author: Rafael J. Wysocki Date: Thu Aug 9 19:08:34 2018 +0200 sched: idle: Avoid retaining the tick when it has been stopped commit 7059b36636beab57c3c43c62104483e5449bee95 upstream. If the tick has been stopped already, but the governor has not asked to stop it (which it can do sometimes), the idle loop should invoke tick_nohz_idle_stop_tick(), to let tick_nohz_stop_tick() take care of this case properly. Fixes: 554c8aa8ecad (sched: idle: Select idle state before stopping the tick) Cc: 4.17+ # 4.17+ Acked-by: Peter Zijlstra (Intel) Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit fe759487ee984c8ee9400b6c84841a97d42db3f1 Author: Peter Kalauskas Date: Tue Aug 21 21:54:02 2018 -0700 drivers/block/zram/zram_drv.c: fix bug storing backing_dev commit c8bd134a4bddafe5917d163eea73873932c15e83 upstream. The call to strlcpy in backing_dev_store is incorrect. It should take the size of the destination buffer instead of the size of the source buffer. Additionally, ignore the newline character (\n) when reading the new file_name buffer. This makes it possible to set the backing_dev as follows: echo /dev/sdX > /sys/block/zram0/backing_dev The reason it worked before was the fact that strlcpy() copies 'len - 1' bytes, which is strlen(buf) - 1 in our case, so it accidentally didn't copy the trailing new line symbol. Which also means that "echo -n /dev/sdX" most likely was broken. Signed-off-by: Peter Kalauskas Link: http://lkml.kernel.org/r/20180813061623.GC64836@rodete-desktop-imager.corp.google.com Acked-by: Minchan Kim Reviewed-by: Sergey Senozhatsky Cc: [4.14+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1cc1c4e06562c67a5d904685da9ca1ad204213b1 Author: Rafael J. Wysocki Date: Sun Aug 12 12:50:09 2018 +0200 ACPICA: Clear status of all events when entering sleep states commit f317c7dc12b73eb9d67fdae404563deb907dcfb7 upstream. Commit fa85015c0d95 (ACPICA: Clear status of all events when entering S5) made the sleep state entry code in ACPICA clear the status of all ACPI events when entering S5 to fix a functional regression reported against commit 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume). However, it is reported now that the regression also affects system states other than S5 on some systems and causes them to wake up from sleep prematurely. For this reason, make the code in question clear the status of all ACPI events when entering all sleep states (in addition to S5) to avoid the premature wakeups (this may cause some wakeup events to be missed in theory, but the likelihood of that is small and the change here simply restores the previous behavior of the code). Fixes: 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume) Reported-by: Paul Menzel Tested-by: Paul Menzel Cc: 4.17+ # 4.17+: fa85015c0d95 ACPICA: Clear status ... Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ab08867f08e41bd6bf58dd954334b29b7980c5b5 Author: Erik Schmauss Date: Fri Aug 10 14:42:58 2018 -0700 ACPICA: AML Parser: skip opcodes that open a scope upon parse failure commit 4a7c94c721074eafb27298d93dbcc339aa28e745 upstream. This change skips the entire length of opcodes that open a scope (Device, Scope, Processor, etc) if the creation of the op fails. The failure could be caused by various errors including AE_ALREADY_EXISTS and AE_NOT_FOUND. Reported-by: Jeremy Linton Tested-by: Jeremy Linton Signed-off-by: Erik Schmauss Cc: 4.17+ # 4.17+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 0c3339c82b9e2ac8ec0e33b49c87f6201de4c820 Author: Amir Goldstein Date: Tue Jul 17 16:05:38 2018 +0300 ovl: fix wrong use of impure dir cache in ovl_iterate() commit 67810693077afc1ebf9e1646af300436cb8103c2 upstream. Only upper dir can be impure, but if we are in the middle of iterating a lower real dir, dir could be copied up and marked impure. We only want the impure cache if we started iterating a real upper dir to begin with. Aditya Kali reported that the following reproducer hits the WARN_ON(!cache->refcount) in ovl_get_cache(): docker run --rm drupal:8.5.4-fpm-alpine \ sh -c 'cd /var/www/html/vendor/symfony && \ chown -R www-data:www-data . && ls -l .' Reported-by: Aditya Kali Tested-by: Aditya Kali Fixes: 4edb83bb1041 ('ovl: constant d_ino for non-merge dirs') Cc: # v4.14 Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 8856ca57dcb13ccf7fa6f6d1e61449256a1868a6 Author: Rafael David Tinoco Date: Fri Jul 6 14:28:33 2018 -0300 mfd: hi655x: Fix regmap area declared size for hi655x commit 6afebb70ee7a4bde106dc1a875e7ac7997248f84 upstream. Fixes https://bugs.linaro.org/show_bug.cgi?id=3903 LTP Functional tests have caused a bad paging request when triggering the regmap_read_debugfs() logic of the device PMIC Hi6553 (reading regmap/f8000000.pmic/registers file during read_all test): Unable to handle kernel paging request at virtual address ffff0 [ffff00000984e000] pgd=0000000077ffe803, pud=0000000077ffd803,0 Internal error: Oops: 96000007 [#1] SMP ... Hardware name: HiKey Development Board (DT) ... Call trace: regmap_mmio_read8+0x24/0x40 regmap_mmio_read+0x48/0x70 _regmap_bus_reg_read+0x38/0x48 _regmap_read+0x68/0x170 regmap_read+0x50/0x78 regmap_read_debugfs+0x1a0/0x308 regmap_map_read_file+0x48/0x58 full_proxy_read+0x68/0x98 __vfs_read+0x48/0x80 vfs_read+0x94/0x150 SyS_read+0x6c/0xd8 el0_svc_naked+0x30/0x34 Code: aa1e03e0 d503201f f9400280 8b334000 (39400000) Investigations have showed that, when triggered by debugfs read() handler, the mmio regmap logic was reading a bigger (16k) register area than the one mapped by devm_ioremap_resource() during hi655x-pmic probe time (4k). This commit changes hi655x's max register, according to HW specs, to be the same as the one declared in the pmic device in hi6220's dts, fixing the issue. Cc: #v4.9 #v4.14 #v4.16 #v4.17 Signed-off-by: Rafael David Tinoco Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit f8d649720924df805884eb927ca383d20324807b Author: Steven Rostedt (VMware) Date: Thu Aug 9 15:37:59 2018 -0400 uprobes: Use synchronize_rcu() not synchronize_sched() commit 016f8ffc48cb01d1e7701649c728c5d2e737d295 upstream. While debugging another bug, I was looking at all the synchronize*() functions being used in kernel/trace, and noticed that trace_uprobes was using synchronize_sched(), with a comment to synchronize with {u,ret}_probe_trace_func(). When looking at those functions, the data is protected with "rcu_read_lock()" and not with "rcu_read_lock_sched()". This is using the wrong synchronize_*() function. Link: http://lkml.kernel.org/r/20180809160553.469e1e32@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 70ed91c6ec7f8 ("tracing/uprobes: Support ftrace_event_file base multibuffer") Acked-by: Oleg Nesterov Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit ee20433f60ae34b52fb11e8f70a8f6139252eb68 Author: Kamalesh Babulal Date: Fri Jul 20 15:16:42 2018 +0530 livepatch: Validate module/old func name length commit 6e9df95b76cad18f7b217bdad7bb8a26d63b8c47 upstream. livepatch module author can pass module name/old function name with more than the defined character limit. With obj->name length greater than MODULE_NAME_LEN, the livepatch module gets loaded but waits forever on the module specified by obj->name to be loaded. It also populates a /sys directory with an untruncated object name. In the case of funcs->old_name length greater then KSYM_NAME_LEN, it would not match against any of the symbol table entries. Instead loop through the symbol table comparing them against a nonexisting function, which can be avoided. The same issues apply, to misspelled/incorrect names. At least gatekeep the modules with over the limit string length, by checking for their length during livepatch module registration. Cc: stable@vger.kernel.org Signed-off-by: Kamalesh Babulal Acked-by: Josh Poimboeuf Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 640d29c1236e3222a47b0a5460f6f24c2781c700 Author: Steven Rostedt (VMware) Date: Wed Sep 5 16:29:49 2018 -0400 printk/tracing: Do not trace printk_nmi_enter() commit d1c392c9e2a301f38998a353f467f76414e38725 upstream. I hit the following splat in my tests: ------------[ cut here ]------------ IRQs not enabled as expected WARNING: CPU: 3 PID: 0 at kernel/time/tick-sched.c:982 tick_nohz_idle_enter+0x44/0x8c Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipv6 CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.0-rc2-test+ #2 Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014 EIP: tick_nohz_idle_enter+0x44/0x8c Code: ec 05 00 00 00 75 26 83 b8 c0 05 00 00 00 75 1d 80 3d d0 36 3e c1 00 75 14 68 94 63 12 c1 c6 05 d0 36 3e c1 01 e8 04 ee f8 ff <0f> 0b 58 fa bb a0 e5 66 c1 e8 25 0f 04 00 64 03 1d 28 31 52 c1 8b EAX: 0000001c EBX: f26e7f8c ECX: 00000006 EDX: 00000007 ESI: f26dd1c0 EDI: 00000000 EBP: f26e7f40 ESP: f26e7f38 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010296 CR0: 80050033 CR2: 0813c6b0 CR3: 2f342000 CR4: 001406f0 Call Trace: do_idle+0x33/0x202 cpu_startup_entry+0x61/0x63 start_secondary+0x18e/0x1ed startup_32_smp+0x164/0x168 irq event stamp: 18773830 hardirqs last enabled at (18773829): [] trace_hardirqs_on_thunk+0xc/0x10 hardirqs last disabled at (18773830): [] trace_hardirqs_off_thunk+0xc/0x10 softirqs last enabled at (18773824): [] __do_softirq+0x25f/0x2bf softirqs last disabled at (18773767): [] call_on_stack+0x45/0x4b ---[ end trace b7c64aa79e17954a ]--- After a bit of debugging, I found what was happening. This would trigger when performing "perf" with a high NMI interrupt rate, while enabling and disabling function tracer. Ftrace uses breakpoints to convert the nops at the start of functions to calls to the function trampolines. The breakpoint traps disable interrupts and this makes calls into lockdep via the trace_hardirqs_off_thunk in the entry.S code. What happens is the following: do_idle { [interrupts enabled] [interrupts disabled] TRACE_IRQS_OFF [lockdep says irqs off] [...] TRACE_IRQS_IRET test if pt_regs say return to interrupts enabled [yes] TRACE_IRQS_ON [lockdep says irqs are on] nmi_enter() { printk_nmi_enter() [traced by ftrace] [ hit ftrace breakpoint ] TRACE_IRQS_OFF [lockdep says irqs off] [...] TRACE_IRQS_IRET [return from breakpoint] test if pt_regs say interrupts enabled [no] [iret back to interrupt] [iret back to code] tick_nohz_idle_enter() { lockdep_assert_irqs_enabled() [lockdep say no!] Although interrupts are indeed enabled, lockdep thinks it is not, and since we now do asserts via lockdep, it gives a false warning. The issue here is that printk_nmi_enter() is called before lockdep_off(), which disables lockdep (for this reason) in NMIs. By simply not allowing ftrace to see printk_nmi_enter() (via notrace annotation) we keep lockdep from getting confused. Cc: stable@vger.kernel.org Fixes: 42a0bb3f71383 ("printk/nmi: generic solution for safe printk in NMI") Acked-by: Sergey Senozhatsky Acked-by: Petr Mladek Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit cfe603dd4e39c11e48edec1b211dfd9b1895debc Author: Steven Rostedt (VMware) Date: Thu Aug 16 16:08:37 2018 -0400 tracing/blktrace: Fix to allow setting same value commit 757d9140072054528b13bbe291583d9823cde195 upstream. Masami Hiramatsu reported: Current trace-enable attribute in sysfs returns an error if user writes the same setting value as current one, e.g. # cat /sys/block/sda/trace/enable 0 # echo 0 > /sys/block/sda/trace/enable bash: echo: write error: Invalid argument # echo 1 > /sys/block/sda/trace/enable # echo 1 > /sys/block/sda/trace/enable bash: echo: write error: Device or resource busy But this is not a preferred behavior, it should ignore if new setting is same as current one. This fixes the problem as below. # cat /sys/block/sda/trace/enable 0 # echo 0 > /sys/block/sda/trace/enable # echo 1 > /sys/block/sda/trace/enable # echo 1 > /sys/block/sda/trace/enable Link: http://lkml.kernel.org/r/20180816103802.08678002@gandalf.local.home Cc: Ingo Molnar Cc: Jens Axboe Cc: linux-block@vger.kernel.org Cc: stable@vger.kernel.org Fixes: cd649b8bb830d ("blktrace: remove sysfs_blk_trace_enable_show/store()") Reported-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b0d32c7b0cdadf1ebe7953f02453c3dfa9353df5 Author: Steven Rostedt (VMware) Date: Wed Aug 1 15:40:57 2018 -0400 tracing: Do not call start/stop() functions when tracing_on does not change commit f143641bfef9a4a60c57af30de26c63057e7e695 upstream. Currently, when one echo's in 1 into tracing_on, the current tracer's "start()" function is executed, even if tracing_on was already one. This can lead to strange side effects. One being that if the hwlat tracer is enabled, and someone does "echo 1 > tracing_on" into tracing_on, the hwlat tracer's start() function is called again which will recreate another kernel thread, and make it unable to remove the old one. Link: http://lkml.kernel.org/r/1533120354-22923-1-git-send-email-erica.bugden@linutronix.de Cc: stable@vger.kernel.org Fixes: 2df8f8a6a897e ("tracing: Fix regression with irqsoff tracer and tracing_on file") Reported-by: Erica Bugden Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 187bee9b94fb2ddaea6fb703e70f41b6e1dffaed Author: Johan Hovold Date: Wed Jul 4 11:05:55 2018 +0200 rtc: omap: fix potential crash on power off commit 5c8b84f410b3819d14cb1ebf32e4b3714b5a6e0b upstream. Do not set the system power-off callback and omap power-off rtc pointer until we're done setting up our device to avoid leaving stale pointers around after a late probe error. Fixes: 97ea1906b3c2 ("rtc: omap: Support ext_wakeup configuration") Cc: stable # 4.9 Cc: Marcin Niestroj Cc: Tony Lindgren Signed-off-by: Johan Hovold Acked-by: Tony Lindgren Reviewed-by: Marcin Niestroj Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 949d4ca049eb0314d0d369ea6c5a20e242fd0e44 Author: Johan Hovold Date: Wed Jul 4 11:05:56 2018 +0200 rtc: omap: fix resource leak in registration error path commit 551757eb052986ec81cebcc6301cc1c4f8dca938 upstream. Make sure to deregister the pin controller in case rtc registration fails. Fixes: 57072758623f ("rtc: omap: switch to rtc_register_device") Cc: stable # 4.14 Cc: Alexandre Belloni Signed-off-by: Johan Hovold Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit ad7a3f8c456ffc755469056699a685ebf1a188b7 Author: Nadav Amit Date: Tue Jun 19 16:00:27 2018 -0700 vmw_balloon: fix VMCI use when balloon built into kernel commit c3cc1b0fc27508da53fe955a3b23d03964410682 upstream. Currently, when all modules, including VMCI and VMware balloon are built into the kernel, the initialization of the balloon happens before the VMCI is probed. As a result, the balloon fails to initialize the VMCI doorbell, which it uses to get asynchronous requests for balloon size changes. The problem can be seen in the logs, in the form of the following message: "vmw_balloon: failed to initialize vmci doorbell" The driver would work correctly but slightly less efficiently, probing for requests periodically. This patch changes the balloon to be initialized using late_initcall() instead of module_init() to address this issue. It does not address a situation in which VMCI is built as a module and the balloon is built into the kernel. Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI") Cc: stable@vger.kernel.org Reviewed-by: Xavier Deguillard Signed-off-by: Nadav Amit Signed-off-by: Greg Kroah-Hartman commit 32b5be5b44e966cffe4833544e8f3b634615143e Author: Nadav Amit Date: Tue Jun 19 16:00:26 2018 -0700 vmw_balloon: VMCI_DOORBELL_SET does not check status commit ce664331b2487a5d244a51cbdd8cb54f866fbe5d upstream. When vmballoon_vmci_init() sets a doorbell using VMCI_DOORBELL_SET, for some reason it does not consider the status and looks at the result. However, the hypervisor does not update the result - it updates the status. This might cause VMCI doorbell not to be enabled, resulting in degraded performance. Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI") Cc: stable@vger.kernel.org Reviewed-by: Xavier Deguillard Signed-off-by: Nadav Amit Signed-off-by: Greg Kroah-Hartman commit 45696b968345217a8fc2b661c9f476d828db8677 Author: Nadav Amit Date: Tue Jun 19 16:00:25 2018 -0700 vmw_balloon: do not use 2MB without batching commit 5081efd112560d3febb328e627176235b250d59d upstream. If the hypervisor sets 2MB batching is on, while batching is cleared, the balloon code breaks. In this case the legacy mechanism is used with 2MB page. The VM would report a 2MB page is ballooned, and the hypervisor would only take the first 4KB. While the hypervisor should not report such settings, make the code more robust by not enabling 2MB support without batching. Fixes: 365bd7ef7ec8e ("VMware balloon: Support 2m page ballooning.") Cc: stable@vger.kernel.org Reviewed-by: Xavier Deguillard Signed-off-by: Nadav Amit Signed-off-by: Greg Kroah-Hartman commit f288edefc2c61023977a45c53828e7ff6a604cc1 Author: Nadav Amit Date: Tue Jun 19 16:00:24 2018 -0700 vmw_balloon: fix inflation of 64-bit GFNs commit 09755690c6b7c1eabdc4651eb3b276f8feb1e447 upstream. When balloon batching is not supported by the hypervisor, the guest frame number (GFN) must fit in 32-bit. However, due to a bug, this check was mistakenly ignored. In practice, when total RAM is greater than 16TB, the balloon does not work currently, making this bug unlikely to happen. Fixes: ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.") Cc: stable@vger.kernel.org Reviewed-by: Xavier Deguillard Signed-off-by: Nadav Amit Signed-off-by: Greg Kroah-Hartman commit a5e6360c4322bea0d5eedc69abf5b1f4a7a0e649 Author: Greg Kroah-Hartman Date: Tue Jul 10 17:15:38 2018 +0200 eventpoll.h: wrap casts in () properly commit 45cd74cb5061781e793a098c420a7f548fdc9e7d upstream. When importing the latest copy of the kernel headers into Bionic, Christpher and Elliott noticed that the eventpoll.h casts were not wrapped in (). As it is, clang complains about macros without surrounding (), so this makes it a pain for userspace tools. So fix it up by adding another () pair, and make them line up purty by using tabs. Fixes: 65aaf87b3aa2 ("add EPOLLNVAL, annotate EPOLL... and event_poll->event") Reported-by: Christopher Ferris Reported-by: Elliott Hughes Cc: stable Cc: Thomas Gleixner Cc: Al Viro Signed-off-by: Greg Kroah-Hartman commit 5f4a5b6fed24b7d7d0cc5cea6fec05b396d927cf Author: Chanwoo Choi Date: Thu Jun 14 11:16:29 2018 +0900 extcon: Release locking when sending the notification of connector state commit 8a9dbb779fe882325b9a0238494a7afaff2eb444 upstream. Previously, extcon used the spinlock before calling the notifier_call_chain to prevent the scheduled out of task and to prevent the notification delay. When spinlock is locked for sending the notification, deadlock issue occured on the side of extcon consumer device. To fix this issue, extcon consumer device should always use the work. it is always not reasonable to use work. To fix this issue on extcon consumer device, release locking when sending the notification of connector state. Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support the notification") Cc: stable@vger.kernel.org Cc: Roger Quadros Cc: Kishon Vijay Abraham I Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit cbdfa40c8187fed5a85d8107bb49cf2ed9c98e88 Author: Lars-Peter Clausen Date: Fri Jul 27 09:42:45 2018 +0300 iio: ad9523: Fix return value for ad952x_store() commit 9a5094ca29ea9b1da301b31fd377c0c0c4c23034 upstream. A sysfs write callback function needs to either return the number of consumed characters or an error. The ad952x_store() function currently returns 0 if the input value was "0", this will signal that no characters have been consumed and the function will be called repeatedly in a loop indefinitely. Fix this by returning number of supplied characters to indicate that the whole input string has been consumed. Signed-off-by: Lars-Peter Clausen Signed-off-by: Alexandru Ardelean Fixes: cd1678f96329 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 10508adb4df01d8b9ad147db477521cef9a74092 Author: Lars-Peter Clausen Date: Mon Jun 25 11:03:07 2018 +0300 iio: ad9523: Fix displayed phase commit 5a4e33c1c53ae7d4425f7d94e60e4458a37b349e upstream. Fix the displayed phase for the ad9523 driver. Currently the most significant decimal place is dropped and all other digits are shifted one to the left. This is due to a multiplication by 10, which is not necessary, so remove it. Signed-off-by: Lars-Peter Clausen Signed-off-by: Alexandru Ardelean Fixes: cd1678f9632 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5ef899676e25bd759f8bc30bab24b6cccf5bdc9f Author: Gustavo A. R. Silva Date: Sat Jul 7 12:44:01 2018 -0500 iio: sca3000: Fix missing return in switch commit c5b974bee9d2ceae4c441ae5a01e498c2674e100 upstream. The IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY case is missing a return and will fall through to the default case and errorenously return -EINVAL. Fix this by adding in missing *return ret*. Fixes: 626f971b5b07 ("staging:iio:accel:sca3000 Add write support to the low pass filter control") Reported-by: Jonathan Cameron Signed-off-by: Gustavo A. R. Silva Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 35949ad3f2d706f39eec089b12b203b159b73cc8 Author: Dexuan Cui Date: Thu Aug 2 03:08:23 2018 +0000 Drivers: hv: vmbus: Reset the channel callback in vmbus_onoffer_rescind() commit d3b26dd7cb0e3433bfd3c1d4dcf74c6039bb49fb upstream. Before setting channel->rescind in vmbus_rescind_cleanup(), we should make sure the channel callback won't run any more, otherwise a high-level driver like pci_hyperv, which may be infinitely waiting for the host VSP's response and notices the channel has been rescinded, can't safely give up: e.g., in hv_pci_protocol_negotiation() -> wait_for_response(), it's unsafe to exit from wait_for_response() and proceed with the on-stack variable "comp_pkt" popped. The issue was originally spotted by Michael Kelley . In vmbus_close_internal(), the patch also minimizes the range protected by disabling/enabling channel->callback_event: we don't really need that for the whole function. Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Cc: stable@vger.kernel.org Cc: K. Y. Srinivasan Cc: Stephen Hemminger Cc: Michael Kelley Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit 4f8eac4396c730927b37e1c43376a3248804674d Author: Dexuan Cui Date: Tue Jun 5 13:37:52 2018 -0700 Drivers: hv: vmbus: Fix the offer_in_progress in vmbus_process_offer() commit 50229128727f7e11840ca1b2b501f880818d56b6 upstream. I didn't really hit a real bug, but just happened to spot the bug: we have decreased the counter at the beginning of vmbus_process_offer(), so we mustn't decrease it again. Fixes: 6f3d791f3006 ("Drivers: hv: vmbus: Fix rescind handling issues") Signed-off-by: Dexuan Cui Cc: stable@vger.kernel.org Cc: Stephen Hemminger Cc: K. Y. Srinivasan Cc: Stable # 4.14 and above Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit d7b108aae76c7b201b723ba80a0b5513b1f5be9c Author: Tycho Andersen Date: Fri Jul 6 10:24:57 2018 -0600 uart: fix race between uart_put_char() and uart_shutdown() commit a5ba1d95e46ecaea638ddd7cd144107c783acb5d upstream. We have reports of the following crash: PID: 7 TASK: ffff88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" #0 [ffff88085c6db710] machine_kexec at ffffffff81046239 #1 [ffff88085c6db760] crash_kexec at ffffffff810fc248 #2 [ffff88085c6db830] oops_end at ffffffff81008ae7 #3 [ffff88085c6db860] no_context at ffffffff81050b8f #4 [ffff88085c6db8b0] __bad_area_nosemaphore at ffffffff81050d75 #5 [ffff88085c6db900] bad_area_nosemaphore at ffffffff81050e83 #6 [ffff88085c6db910] __do_page_fault at ffffffff8105132e #7 [ffff88085c6db9b0] do_page_fault at ffffffff8105152c #8 [ffff88085c6db9c0] page_fault at ffffffff81a3f122 [exception RIP: uart_put_char+149] RIP: ffffffff814b67b5 RSP: ffff88085c6dba78 RFLAGS: 00010006 RAX: 0000000000000292 RBX: ffffffff827c5120 RCX: 0000000000000081 RDX: 0000000000000000 RSI: 000000000000005f RDI: ffffffff827c5120 RBP: ffff88085c6dba98 R8: 000000000000012c R9: ffffffff822ea320 R10: ffff88085fe4db04 R11: 0000000000000001 R12: ffff881059f9c000 R13: 0000000000000001 R14: 000000000000005f R15: 0000000000000fba ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #9 [ffff88085c6dbaa0] tty_put_char at ffffffff81497544 #10 [ffff88085c6dbac0] do_output_char at ffffffff8149c91c #11 [ffff88085c6dbae0] __process_echoes at ffffffff8149cb8b #12 [ffff88085c6dbb30] commit_echoes at ffffffff8149cdc2 #13 [ffff88085c6dbb60] n_tty_receive_buf_fast at ffffffff8149e49b #14 [ffff88085c6dbbc0] __receive_buf at ffffffff8149ef5a #15 [ffff88085c6dbc20] n_tty_receive_buf_common at ffffffff8149f016 #16 [ffff88085c6dbca0] n_tty_receive_buf2 at ffffffff8149f194 #17 [ffff88085c6dbcb0] flush_to_ldisc at ffffffff814a238a #18 [ffff88085c6dbd50] process_one_work at ffffffff81090be2 #19 [ffff88085c6dbe20] worker_thread at ffffffff81091b4d #20 [ffff88085c6dbeb0] kthread at ffffffff81096384 #21 [ffff88085c6dbf50] ret_from_fork at ffffffff81a3d69f​ after slogging through some dissasembly: ffffffff814b6720 : ffffffff814b6720: 55 push %rbp ffffffff814b6721: 48 89 e5 mov %rsp,%rbp ffffffff814b6724: 48 83 ec 20 sub $0x20,%rsp ffffffff814b6728: 48 89 1c 24 mov %rbx,(%rsp) ffffffff814b672c: 4c 89 64 24 08 mov %r12,0x8(%rsp) ffffffff814b6731: 4c 89 6c 24 10 mov %r13,0x10(%rsp) ffffffff814b6736: 4c 89 74 24 18 mov %r14,0x18(%rsp) ffffffff814b673b: e8 b0 8e 58 00 callq ffffffff81a3f5f0 ffffffff814b6740: 4c 8b a7 88 02 00 00 mov 0x288(%rdi),%r12 ffffffff814b6747: 45 31 ed xor %r13d,%r13d ffffffff814b674a: 41 89 f6 mov %esi,%r14d ffffffff814b674d: 49 83 bc 24 70 01 00 cmpq $0x0,0x170(%r12) ffffffff814b6754: 00 00 ffffffff814b6756: 49 8b 9c 24 80 01 00 mov 0x180(%r12),%rbx ffffffff814b675d: 00 ffffffff814b675e: 74 2f je ffffffff814b678f ffffffff814b6760: 48 89 df mov %rbx,%rdi ffffffff814b6763: e8 a8 67 58 00 callq ffffffff81a3cf10 <_raw_spin_lock_irqsave> ffffffff814b6768: 41 8b 8c 24 78 01 00 mov 0x178(%r12),%ecx ffffffff814b676f: 00 ffffffff814b6770: 89 ca mov %ecx,%edx ffffffff814b6772: f7 d2 not %edx ffffffff814b6774: 41 03 94 24 7c 01 00 add 0x17c(%r12),%edx ffffffff814b677b: 00 ffffffff814b677c: 81 e2 ff 0f 00 00 and $0xfff,%edx ffffffff814b6782: 75 23 jne ffffffff814b67a7 ffffffff814b6784: 48 89 c6 mov %rax,%rsi ffffffff814b6787: 48 89 df mov %rbx,%rdi ffffffff814b678a: e8 e1 64 58 00 callq ffffffff81a3cc70 <_raw_spin_unlock_irqrestore> ffffffff814b678f: 44 89 e8 mov %r13d,%eax ffffffff814b6792: 48 8b 1c 24 mov (%rsp),%rbx ffffffff814b6796: 4c 8b 64 24 08 mov 0x8(%rsp),%r12 ffffffff814b679b: 4c 8b 6c 24 10 mov 0x10(%rsp),%r13 ffffffff814b67a0: 4c 8b 74 24 18 mov 0x18(%rsp),%r14 ffffffff814b67a5: c9 leaveq ffffffff814b67a6: c3 retq ffffffff814b67a7: 49 8b 94 24 70 01 00 mov 0x170(%r12),%rdx ffffffff814b67ae: 00 ffffffff814b67af: 48 63 c9 movslq %ecx,%rcx ffffffff814b67b2: 41 b5 01 mov $0x1,%r13b ffffffff814b67b5: 44 88 34 0a mov %r14b,(%rdx,%rcx,1) ffffffff814b67b9: 41 8b 94 24 78 01 00 mov 0x178(%r12),%edx ffffffff814b67c0: 00 ffffffff814b67c1: 83 c2 01 add $0x1,%edx ffffffff814b67c4: 81 e2 ff 0f 00 00 and $0xfff,%edx ffffffff814b67ca: 41 89 94 24 78 01 00 mov %edx,0x178(%r12) ffffffff814b67d1: 00 ffffffff814b67d2: eb b0 jmp ffffffff814b6784 ffffffff814b67d4: 66 66 66 2e 0f 1f 84 data32 data32 nopw %cs:0x0(%rax,%rax,1) ffffffff814b67db: 00 00 00 00 00 for our build, this is crashing at: circ->buf[circ->head] = c; Looking in uart_port_startup(), it seems that circ->buf (state->xmit.buf) protected by the "per-port mutex", which based on uart_port_check() is state->port.mutex. Indeed, the lock acquired in uart_put_char() is uport->lock, i.e. not the same lock. Anyway, since the lock is not acquired, if uart_shutdown() is called, the last chunk of that function may release state->xmit.buf before its assigned to null, and cause the race above. To fix it, let's lock uport->lock when allocating/deallocating state->xmit.buf in addition to the per-port mutex. v2: switch to locking uport->lock on allocation/deallocation instead of locking the per-port mutex in uart_put_char. Note that since uport->lock is a spin lock, we have to switch the allocation to GFP_ATOMIC. v3: move the allocation outside the lock, so we can switch back to GFP_KERNEL Signed-off-by: Tycho Andersen Cc: stable Signed-off-by: Greg Kroah-Hartman commit 6cdc67be3e1211b12f3ba79ffc1af9af43aa4b63 Author: Mikulas Patocka Date: Thu Aug 16 12:23:19 2018 -0400 dm writecache: fix a crash due to reading past end of dirty_bitmap commit 1e1132ea21da6d7be92a72195204379c819cb70b upstream. wc->dirty_bitmap_size is in bytes so must multiply it by 8, not by BITS_PER_LONG, to get number of bitmap_bits. Fixes crash in find_next_bit() that was reported: https://bugzilla.kernel.org/show_bug.cgi?id=200819 Reported-by: edo.rus@gmail.com Fixes: 48debafe4f2f ("dm: add writecache target") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit d94cf7087099d59deabb13306384841333e73b19 Author: Mikulas Patocka Date: Fri Aug 10 11:23:56 2018 -0400 dm crypt: don't decrease device limits commit bc9e9cf0401f18e33b78d4c8a518661b8346baf7 upstream. dm-crypt should only increase device limits, it should not decrease them. This fixes a bug where the user could creates a crypt device with 1024 sector size on the top of scsi device that had 4096 logical block size. The limit 4096 would be lost and the user could incorrectly send 1024-I/Os to the crypt device. Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 25b25e552439ec106cb370caee39f9051843d7f9 Author: Ilya Dryomov Date: Thu Aug 9 12:38:28 2018 +0200 dm cache metadata: set dirty on all cache blocks after a crash commit 5b1fe7bec8a8d0cc547a22e7ddc2bd59acd67de4 upstream. Quoting Documentation/device-mapper/cache.txt: The 'dirty' state for a cache block changes far too frequently for us to keep updating it on the fly. So we treat it as a hint. In normal operation it will be written when the dm device is suspended. If the system crashes all cache blocks will be assumed dirty when restarted. This got broken in commit f177940a8091 ("dm cache metadata: switch to using the new cursor api for loading metadata") in 4.9, which removed the code that consulted cmd->clean_when_opened (CLEAN_SHUTDOWN on-disk flag) when loading cache blocks. This results in data corruption on an unclean shutdown with dirty cache blocks on the fast device. After the crash those blocks are considered clean and may get evicted from the cache at any time. This can be demonstrated by doing a lot of reads to trigger individual evictions, but uncache is more predictable: ### Disable auto-activation in lvm.conf to be able to do uncache in ### time (i.e. see uncache doing flushing) when the fix is applied. # xfs_io -d -c 'pwrite -b 4M -S 0xaa 0 1G' /dev/vdb # vgcreate vg_cache /dev/vdb /dev/vdc # lvcreate -L 1G -n lv_slowdev vg_cache /dev/vdb # lvcreate -L 512M -n lv_cachedev vg_cache /dev/vdc # lvcreate -L 256M -n lv_metadev vg_cache /dev/vdc # lvconvert --type cache-pool --cachemode writeback vg_cache/lv_cachedev --poolmetadata vg_cache/lv_metadev # lvconvert --type cache vg_cache/lv_slowdev --cachepool vg_cache/lv_cachedev # xfs_io -d -c 'pwrite -b 4M -S 0xbb 0 512M' /dev/mapper/vg_cache-lv_slowdev # xfs_io -d -c 'pread -v 254M 512' /dev/mapper/vg_cache-lv_slowdev | head -n 2 0fe00000: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ 0fe00010: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ # dmsetup status vg_cache-lv_slowdev 0 2097152 cache 8 27/65536 128 8192/8192 1 100 0 0 0 8192 7065 2 metadata2 writeback 2 migration_threshold 2048 smq 0 rw - ^^^^ 7065 * 64k = 441M yet to be written to the slow device # echo b >/proc/sysrq-trigger # vgchange -ay vg_cache # xfs_io -d -c 'pread -v 254M 512' /dev/mapper/vg_cache-lv_slowdev | head -n 2 0fe00000: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ 0fe00010: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ # lvconvert --uncache vg_cache/lv_slowdev Flushing 0 blocks for cache vg_cache/lv_slowdev. Logical volume "lv_cachedev" successfully removed Logical volume vg_cache/lv_slowdev is not cached. # xfs_io -d -c 'pread -v 254M 512' /dev/mapper/vg_cache-lv_slowdev | head -n 2 0fe00000: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ 0fe00010: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ This is the case with both v1 and v2 cache pool metatata formats. After applying this patch: # vgchange -ay vg_cache # xfs_io -d -c 'pread -v 254M 512' /dev/mapper/vg_cache-lv_slowdev | head -n 2 0fe00000: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ 0fe00010: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ # lvconvert --uncache vg_cache/lv_slowdev Flushing 3724 blocks for cache vg_cache/lv_slowdev. ... Flushing 71 blocks for cache vg_cache/lv_slowdev. Logical volume "lv_cachedev" successfully removed Logical volume vg_cache/lv_slowdev is not cached. # xfs_io -d -c 'pread -v 254M 512' /dev/mapper/vg_cache-lv_slowdev | head -n 2 0fe00000: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ 0fe00010: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ Cc: stable@vger.kernel.org Fixes: f177940a8091 ("dm cache metadata: switch to using the new cursor api for loading metadata") Signed-off-by: Ilya Dryomov Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 7bbb3231d6f7ad24df56b003e7951b5c62a0ea6b Author: Mike Snitzer Date: Thu Aug 2 16:08:52 2018 -0400 dm cache metadata: save in-core policy_hint_size to on-disk superblock commit fd2fa95416188a767a63979296fa3e169a9ef5ec upstream. policy_hint_size starts as 0 during __write_initial_superblock(). It isn't until the policy is loaded that policy_hint_size is set in-core (cmd->policy_hint_size). But it never got recorded in the on-disk superblock because __commit_transaction() didn't deal with transfering the in-core cmd->policy_hint_size to the on-disk superblock. The in-core cmd->policy_hint_size gets initialized by metadata_open()'s __begin_transaction_flags() which re-reads all superblock fields. Because the superblock's policy_hint_size was never properly stored, when the cache was created, hints_array_available() would always return false when re-activating a previously created cache. This means __load_mappings() always considered the hints invalid and never made use of the hints (these hints served to optimize). Another detremental side-effect of this oversight is the cache_check utility would fail with: "invalid hint width: 0" Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit f308e9fbe04f78aa571701f8efe7895c73034fc8 Author: Hou Tao Date: Thu Aug 2 16:18:24 2018 +0800 dm thin: stop no_space_timeout worker when switching to write-mode commit 75294442d896f2767be34f75aca7cc2b0d01301f upstream. Now both check_for_space() and do_no_space_timeout() will read & write pool->pf.error_if_no_space. If these functions run concurrently, as shown in the following case, the default setting of "queue_if_no_space" can get lost. precondition: * error_if_no_space = false (aka "queue_if_no_space") * pool is in Out-of-Data-Space (OODS) mode * no_space_timeout worker has been queued CPU 0: CPU 1: // delete a thin device process_delete_mesg() // check_for_space() invoked by commit() set_pool_mode(pool, PM_WRITE) pool->pf.error_if_no_space = \ pt->requested_pf.error_if_no_space // timeout, pool is still in OODS mode do_no_space_timeout // "queue_if_no_space" config is lost pool->pf.error_if_no_space = true pool->pf.mode = new_mode Fix it by stopping no_space_timeout worker when switching to write mode. Fixes: bcc696fac11f ("dm thin: stay in out-of-data-space mode once no_space_timeout expires") Cc: stable@vger.kernel.org Signed-off-by: Hou Tao Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0da098366e8cf2bd5343786caaf93cd6e218cc1f Author: Mikulas Patocka Date: Tue Jul 3 20:13:25 2018 +0200 dm integrity: change 'suspending' variable from bool to int commit c21b16392701543d61e366dca84e15fe7f0cf0cf upstream. Early alpha processors can't write a byte or short atomically - they read 8 bytes, modify the byte or two bytes in registers and write back 8 bytes. The modification of the variable "suspending" may race with modification of the variable "failed". Fix this by changing "suspending" to an int. Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 6d7bd0a68a4a0d29769cefa610024cb00d6d6a8f Author: Tomas Bortoli Date: Fri Jul 20 11:27:30 2018 +0200 net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree() commit 430ac66eb4c5b5c4eb846b78ebf65747510b30f1 upstream. The patch adds the flush in p9_mux_poll_stop() as it the function used by p9_conn_destroy(), in turn called by p9_fd_close() to stop the async polling associated with the data regarding the connection. Link: http://lkml.kernel.org/r/20180720092730.27104-1-tomasbortoli@gmail.com Signed-off-by: Tomas Bortoli Reported-by: syzbot+39749ed7d9ef6dfb23f6@syzkaller.appspotmail.com To: Eric Van Hensbergen To: Ron Minnich To: Latchesar Ionkov Cc: Yiwen Jiang Cc: stable@vger.kernel.org Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit fe7e153d956438101a5078ba3fa76a2a0b524e16 Author: Tomas Bortoli Date: Tue Jul 10 00:29:43 2018 +0200 net/9p/client.c: version pointer uninitialized commit 7913690dcc5e18e235769fd87c34143072f5dbea upstream. The p9_client_version() does not initialize the version pointer. If the call to p9pdu_readf() returns an error and version has not been allocated in p9pdu_readf(), then the program will jump to the "error" label and will try to free the version pointer. If version is not initialized, free() will be called with uninitialized, garbage data and will provoke a crash. Link: http://lkml.kernel.org/r/20180709222943.19503-1-tomasbortoli@gmail.com Signed-off-by: Tomas Bortoli Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com Reviewed-by: Jun Piao Reviewed-by: Yiwen Jiang Cc: Eric Van Hensbergen Cc: Ron Minnich Cc: Latchesar Ionkov Signed-off-by: Andrew Morton Cc: stable@vger.kernel.org Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 372ed5efc9333ebc2a312de2129d9ac1990ef803 Author: jiangyiwen Date: Fri Aug 3 12:11:34 2018 +0800 9p/virtio: fix off-by-one error in sg list bounds check commit 23cba9cbde0bba05d772b335fe5f66aa82b9ad19 upstream. Because the value of limit is VIRTQUEUE_NUM, if index is equal to limit, it will cause sg array out of bounds, so correct the judgement of BUG_ON. Link: http://lkml.kernel.org/r/5B63D5F6.6080109@huawei.com Signed-off-by: Yiwen Jiang Reported-By: Dan Carpenter Acked-by: Jun Piao Cc: stable@vger.kernel.org Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit ba74c64c00a5ecfde1f28f3bb711f93f1da1bc1b Author: piaojun Date: Wed Jul 25 11:13:16 2018 +0800 fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed commit 3111784bee81591ea2815011688d28b65df03627 upstream. In my testing, v9fs_fid_xattr_set will return successfully even if the backend ext4 filesystem has no space to store xattr key-value. That will cause inconsistent behavior between front end and back end. The reason is that lsetxattr will be triggered by p9_client_clunk, and unfortunately we did not catch the error. This patch will catch the error to notify upper caller. p9_client_clunk (in 9p) p9_client_rpc(clnt, P9_TCLUNK, "d", fid->fid); v9fs_clunk (in qemu) put_fid free_fid v9fs_xattr_fid_clunk v9fs_co_lsetxattr s->ops->lsetxattr ext4_xattr_user_set (in host ext4 filesystem) Link: http://lkml.kernel.org/r/5B57EACC.2060900@huawei.com Signed-off-by: Jun Piao Cc: Eric Van Hensbergen Cc: Ron Minnich Cc: Latchesar Ionkov Cc: Andrew Morton Cc: stable@vger.kernel.org Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit db6cb8a7c4585d82014cbacb450614d9f4e14968 Author: Tomas Bortoli Date: Fri Jul 27 13:05:58 2018 +0200 9p: fix multiple NULL-pointer-dereferences commit 10aa14527f458e9867cf3d2cc6b8cb0f6704448b upstream. Added checks to prevent GPFs from raising. Link: http://lkml.kernel.org/r/20180727110558.5479-1-tomasbortoli@gmail.com Signed-off-by: Tomas Bortoli Reported-by: syzbot+1a262da37d3bead15c39@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit a34932007267df1d080caf8e68a0c2086979baff Author: Bart Van Assche Date: Tue Jun 26 08:39:36 2018 -0700 RDMA/rxe: Set wqe->status correctly if an unexpected response is received commit 61b717d041b1976530f68f8b539b2e3a7dd8e39c upstream. Every function that returns COMPST_ERROR must set wqe->status to another value than IB_WC_SUCCESS before returning COMPST_ERROR. Fix the only code path for which this is not yet the case. Signed-off-by: Bart Van Assche Cc: Reviewed-by: Yuval Shaia Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 8a3f37b0da74add0a655430fc83ef65d175ffba6 Author: Bart Van Assche Date: Mon Jul 2 14:08:45 2018 -0700 ib_srpt: Fix a use-after-free in __srpt_close_all_ch() commit 14d15c2b278011056482eb015dff89f9cbf2b841 upstream. BUG: KASAN: use-after-free in srpt_set_enabled+0x1a9/0x1e0 [ib_srpt] Read of size 4 at addr ffff8801269d23f8 by task check/29726 CPU: 4 PID: 29726 Comm: check Not tainted 4.18.0-rc2-dbg+ #4 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0xa4/0xf5 print_address_description+0x6f/0x270 kasan_report+0x241/0x360 __asan_load4+0x78/0x80 srpt_set_enabled+0x1a9/0x1e0 [ib_srpt] srpt_tpg_enable_store+0xb8/0x120 [ib_srpt] configfs_write_file+0x14e/0x1d0 [configfs] __vfs_write+0xd2/0x3b0 vfs_write+0x101/0x270 ksys_write+0xab/0x120 __x64_sys_write+0x43/0x50 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f235cfe6154 Fixes: aaf45bd83eba ("IB/srpt: Detect session shutdown reliably") Signed-off-by: Bart Van Assche Cc: Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 41cc5e9aff78e2e634b7a5a8b9ccf983b79fe94b Author: Bart Van Assche Date: Mon Jul 2 14:08:18 2018 -0700 ib_srpt: Fix a use-after-free in srpt_close_ch() commit 995250959d22fc341b5424e3343b0ce5df672461 upstream. Avoid that KASAN reports the following: BUG: KASAN: use-after-free in srpt_close_ch+0x4f/0x1b0 [ib_srpt] Read of size 4 at addr ffff880151180cb8 by task check/4681 CPU: 15 PID: 4681 Comm: check Not tainted 4.18.0-rc2-dbg+ #4 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0xa4/0xf5 print_address_description+0x6f/0x270 kasan_report+0x241/0x360 __asan_load4+0x78/0x80 srpt_close_ch+0x4f/0x1b0 [ib_srpt] srpt_set_enabled+0xf7/0x1e0 [ib_srpt] srpt_tpg_enable_store+0xb8/0x120 [ib_srpt] configfs_write_file+0x14e/0x1d0 [configfs] __vfs_write+0xd2/0x3b0 vfs_write+0x101/0x270 ksys_write+0xab/0x120 __x64_sys_write+0x43/0x50 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: aaf45bd83eba ("IB/srpt: Detect session shutdown reliably") Signed-off-by: Bart Van Assche Cc: Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 2ea037fe87b1bc306ee0693b05206558ae24ef7a Author: Leon Romanovsky Date: Wed Aug 1 14:25:41 2018 -0700 RDMA/mlx5: Fix shift overflow in mlx5_ib_create_wq commit 0dfe452241f4904de497aef01ad2f609ccb9be90 upstream. [ 61.182439] UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/qp.c:5366:34 [ 61.183673] shift exponent 4294967288 is too large for 32-bit type 'unsigned int' [ 61.185530] CPU: 0 PID: 639 Comm: qp Not tainted 4.18.0-rc1-00037-g4aa1d69a9c60-dirty #96 [ 61.186981] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 [ 61.188315] Call Trace: [ 61.188661] dump_stack+0xc7/0x13b [ 61.190427] ubsan_epilogue+0x9/0x49 [ 61.190899] __ubsan_handle_shift_out_of_bounds+0x1ea/0x22f [ 61.197040] mlx5_ib_create_wq+0x1c99/0x1d50 [ 61.206632] ib_uverbs_ex_create_wq+0x499/0x820 [ 61.213892] ib_uverbs_write+0x77e/0xae0 [ 61.248018] vfs_write+0x121/0x3b0 [ 61.249831] ksys_write+0xa1/0x120 [ 61.254024] do_syscall_64+0x7c/0x2a0 [ 61.256178] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 61.259211] RIP: 0033:0x7f54bab70e99 [ 61.262125] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 [ 61.268678] RSP: 002b:00007ffe1541c318 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 61.271076] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f54bab70e99 [ 61.273795] RDX: 0000000000000070 RSI: 0000000020000240 RDI: 0000000000000003 [ 61.276982] RBP: 00007ffe1541c330 R08: 00000000200078e0 R09: 0000000000000002 [ 61.280035] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004005c0 [ 61.283279] R13: 00007ffe1541c420 R14: 0000000000000000 R15: 0000000000000000 Cc: # 4.7 Fixes: 79b20a6c3014 ("IB/mlx5: Add receive Work Queue verbs") Cc: syzkaller Reported-by: Noa Osherovich Signed-off-by: Leon Romanovsky Signed-off-by: Kees Cook Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit c34579cc3ea70c039cd4fa91241028e0dbb9d2f8 Author: Jason Gunthorpe Date: Wed Aug 1 14:25:39 2018 -0700 overflow.h: Add arithmetic shift helper commit 0c66847793d1982d1083dc6f7adad60fa265ce9c upstream. Add shift_overflow() helper to assist driver authors in ensuring that shift operations don't cause overflows or other odd conditions. Signed-off-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky [kees: tweaked comments and commit log, dropped unneeded assignment] Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 74d835f7fdf7db06a105908a213f8c126c8586ec Author: Bart Van Assche Date: Tue Jun 26 15:24:48 2018 -0700 IB/srpt: Support HCAs with more than two ports commit e620ebfc228dcbef7519e3d16f43c6c6f1a1d0cb upstream. Since there are adapters that have four ports, increase the size of the srpt_device.port[] array. This patch avoids that the following warning is hit with quad port Chelsio adapters: WARN_ON(sdev->device->phys_port_cnt > ARRAY_SIZE(sdev->port)); Reported-by: Steve Wise Signed-off-by: Bart Van Assche Cc: Steve Wise Cc: Christoph Hellwig Cc: Reviewed-by: Steve Wise Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 32a46b60c50ef36078f04428436f76c253c90aed Author: Bart Van Assche Date: Tue Jul 10 10:31:59 2018 -0700 IB/srpt: Fix srpt_cm_req_recv() error path (2/2) commit 6869e0004fe16184acd6488f0c637e0081a84a8a upstream. If a login request was received through the RDMA/CM and if an error occurs during login, clear rdma_cm_id->context instead of ib_cm_id->context. Fixes: 63cf1a902c9d ("IB/srpt: Add RDMA/CM support") Signed-off-by: Bart Van Assche Cc: Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e46df54477b4402a2ccd43810066b779f9800dd5 Author: Bart Van Assche Date: Tue Jul 10 10:31:58 2018 -0700 IB/srpt: Fix srpt_cm_req_recv() error path (1/2) commit 847462de3a0aabc5343a1e338537f69a03bb61af upstream. Once a target session has been allocated, if an error occurs, the session must be freed. Since it is not safe to call blocking code from the context of an connection manager callback, trigger target session release in this case by calling srpt_close_ch(). Fixes: db7683d7deb2 ("IB/srpt: Fix login-related race conditions") Signed-off-by: Bart Van Assche Cc: Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 103a3a62e0fbe718f2c85f029544163f332d19d3 Author: Jason Gunthorpe Date: Tue Aug 14 15:33:52 2018 -0600 IB/mlx5: Fix leaking stack memory to userspace commit 0625b4ba1a5d4703c7fb01c497bd6c156908af00 upstream. mlx5_ib_create_qp_resp was never initialized and only the first 4 bytes were written. Fixes: 41d902cb7c32 ("RDMA/mlx5: Fix definition of mlx5_ib_create_qp_resp") Cc: Acked-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e48fd87e93e1cac29e4a33b74bb15090884ca5a0 Author: Parav Pandit Date: Sun Jul 8 13:40:30 2018 +0300 IB/mlx5: Honor cnt_set_id_valid flag instead of set_id commit 921c0f5ba58e4064deb18b4985a202508fc5527f upstream. It is incorrect to depend on set_id value to know if counters were allocated or not. set_id_valid field is set to true when counters were allocated. Therefore, use set_id_valid while deciding to free counters. Cc: # 4.15 Fixes: aac4492ef23a ("IB/mlx5: Update counter implementation for dual port RoCE") Signed-off-by: Parav Pandit Reviewed-by: Daniel Jurgens Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 7ab793382972585c8ea83349c3a8720976328f2b Author: Frederic Barrat Date: Mon Jun 18 14:14:36 2018 +0200 ocxl: Fix page fault handler in case of fault on dying process commit d497ebf5fb3a026c0817f8c96cde578787f24093 upstream. If a process exits without doing proper cleanup, there's a window where an opencapi device can try to access the memory of the dying process and may trigger a page fault. That's an expected scenario and the ocxl driver holds a reference on the mm_struct of the process until the opencapi device is notified of the process exiting. However, if mm_users is already at 0, i.e. the address space of the process has already been destroyed, the driver shouldn't try resolving the page fault, as it will fail, but it can also try accessing already freed data. It is fixed by only calling the bottom half of the page fault handler if mm_users is greater than 0 and get a reference on mm_users instead of mm_count. Otherwise, we can safely return a translation fault to the device, as its associated memory context is being removed. The opencapi device will be properly cleaned up shortly after when closing the file descriptors. Fixes: 5ef3166e8a32 ("ocxl: Driver code for 'generic' opencapi devices") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Frederic Barrat Reviewed-By: Alastair D'Silva Acked-by: Andrew Donnellan Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 9833940072b306c368652fd046107930319ac9b4 Author: Vaibhav Jain Date: Wed Jul 4 20:58:33 2018 +0530 cxl: Fix wrong comparison in cxl_adapter_context_get() commit ef6cb5f1a048fdf91ccee6d63d2bfa293338502d upstream. Function atomic_inc_unless_negative() returns a bool to indicate success/failure. However cxl_adapter_context_get() wrongly compares the return value against '>=0' which will always be true. The patch fixes this comparison to '==0' there by also fixing this compile time warning: drivers/misc/cxl/main.c:290 cxl_adapter_context_get() warn: 'atomic_inc_unless_negative(&adapter->contexts_num)' is unsigned Fixes: 70b565bbdb91 ("cxl: Prevent adapter reset if an active context exists") Cc: stable@vger.kernel.org # v4.9+ Reported-by: Dan Carpenter Signed-off-by: Vaibhav Jain Acked-by: Andrew Donnellan Acked-by: Frederic Barrat Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 6757519a48caee1f390c451811d3a222babc82b2 Author: Benjamin Herrenschmidt Date: Fri Aug 17 17:30:39 2018 +1000 powerpc/powernv/pci: Work around races in PCI bridge enabling commit db2173198b9513f7add8009f225afa1f1c79bcc6 upstream. The generic code is racy when multiple children of a PCI bridge try to enable it simultaneously. This leads to drivers trying to access a device through a not-yet-enabled bridge, and this EEH errors under various circumstances when using parallel driver probing. There is work going on to fix that properly in the PCI core but it will take some time. x86 gets away with it because (outside of hotplug), the BIOS enables all the bridges at boot time. This patch does the same thing on powernv by enabling all bridges that have child devices at boot time, thus avoiding subsequent races. It's suitable for backporting to stable and distros, while the proper PCI fix will probably be significantly more invasive. Signed-off-by: Benjamin Herrenschmidt Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 96f829b77bf15dc59b55aa9e8a3dfd4d953133c4 Author: Luke Dashjr Date: Thu Aug 16 21:36:26 2018 +0000 powerpc64/ftrace: Include ftrace.h needed for enable/disable calls commit d6ee76d3d37d156c479348821574b6f99d6472a1 upstream. this_cpu_disable_ftrace and this_cpu_enable_ftrace are inlines in ftrace.h Without it included, the build fails. Fixes: a4bc64d305af ("powerpc64/ftrace: Disable ftrace during kvm entry/exit") Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Luke Dashjr Acked-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit d4e41dc984f2d6899b6cdc35eafa9cd55ae287f5 Author: Christophe Leroy Date: Tue Aug 21 13:03:23 2018 +0000 powerpc/nohash: fix pte_access_permitted() commit 810e9f86f36f59f1d6f6710220c49afe0c705f38 upstream. Commit 5769beaf180a8 ("powerpc/mm: Add proper pte access check helper for other platforms") replaced generic pte_access_permitted() by an arch specific one. The generic one is defined as (pte_present(pte) && (!(write) || pte_write(pte))) The arch specific one is open coded checking that _PAGE_USER and _PAGE_WRITE (_PAGE_RW) flags are set, but lacking to check that _PAGE_RO and _PAGE_PRIVILEGED are unset, leading to a useless test on targets like the 8xx which defines _PAGE_RW and _PAGE_USER as 0. Commit 5fa5b16be5b31 ("powerpc/mm/hugetlb: Use pte_access_permitted for hugetlb access check") replaced some tests performed with pte helpers by a call to pte_access_permitted(), leading to the same issue. This patch rewrites powerpc/nohash pte_access_permitted() using pte helpers. Fixes: 5769beaf180a8 ("powerpc/mm: Add proper pte access check helper for other platforms") Fixes: 5fa5b16be5b31 ("powerpc/mm/hugetlb: Use pte_access_permitted for hugetlb access check") Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Christophe Leroy Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit bb691eafb6df6544afbbd013d0d9e6dbd3a08456 Author: Ram Pai Date: Tue Jul 17 06:51:07 2018 -0700 powerpc/pkeys: Preallocate execute-only key commit a4fcc877d4e18b5efe26e93f08f0cfd4e278c7d9 upstream. execute-only key is allocated dynamically. This is a problem. When a thread implicitly creates an execute-only key, and resets the UAMOR for that key, the UAMOR value does not percolate to all the other threads. Any other thread may ignorantly change the permissions on the key. This can cause the key to be not execute-only for that thread. Preallocate the execute-only key and ensure that no thread can change the permission of the key, by resetting the corresponding bit in UAMOR. Fixes: 5586cf61e108 ("powerpc: introduce execute-only pkey") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Ram Pai Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 44d146b99b08dc762a5a58de2f470ea96f9321f2 Author: Ram Pai Date: Tue Jul 17 06:51:06 2018 -0700 powerpc/pkeys: Fix calculation of total pkeys. commit fe6a2804e65969a574377bdb3605afb79e6091a9 upstream. Total number of pkeys calculation is off by 1. Fix it. Fixes: 4fb158f65ac5 ("powerpc: track allocation status of all pkeys") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Ram Pai Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 5e2727bf84c5da3651b245e9655dde61d748dc97 Author: Ram Pai Date: Tue Jul 17 06:51:05 2018 -0700 powerpc/pkeys: Save the pkey registers before fork commit c76662e825f507b98938dc3bb141c4505bd4968c upstream. When a thread forks the contents of AMR, IAMR, UAMOR registers in the newly forked thread are not inherited. Save the registers before forking, for content of those registers to be automatically copied into the new thread. Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Ram Pai Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 0d86f534567280bc801083e9783c97da5ee18c64 Author: Ram Pai Date: Tue Jul 17 06:51:04 2018 -0700 powerpc/pkeys: key allocation/deallocation must not change pkey registers commit 4a4a5e5d2aadc793be95024f454cf511d115b62d upstream. Key allocation and deallocation has the side effect of programming the UAMOR/AMR/IAMR registers. This is wrong, since its the responsibility of the application and not that of the kernel, to modify the permission on the key. Do not modify the pkey registers at key allocation/deallocation. This patch also fixes a bug where a sys_pkey_free() resets the UAMOR bits of the key, thus making its permissions unmodifiable from user space. Later if the same key gets reallocated from a different thread this thread will no longer be able to change the permissions on the key. Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem") Cc: stable@vger.kernel.org # v4.16+ Reviewed-by: Thiago Jung Bauermann Signed-off-by: Ram Pai Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 72ebe30452ef05746a51daf587830b7f4a2fc3b2 Author: Ram Pai Date: Tue Jul 17 06:51:03 2018 -0700 powerpc/pkeys: Deny read/write/execute by default commit de113256f8c1c24d8c79ae388bf2a5abd70f7577 upstream. Deny all permissions on all keys, with some exceptions. pkey-0 must allow all permissions, or else everything comes to a screaching halt. Execute-only key must allow execute permission. Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Ram Pai Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 8ed3d6a901789cbe6c4f4d47fa31af112a189ddc Author: Ram Pai Date: Tue Jul 17 06:51:02 2018 -0700 powerpc/pkeys: Give all threads control of their key permissions commit a57a04c76e06822e4377831611364c846b7202ca upstream. Currently in a multithreaded application, a key allocated by one thread is not usable by other threads. By "not usable" we mean that other threads are unable to change the access permissions for that key for themselves. When a new key is allocated in one thread, the corresponding UAMOR bits for that thread get enabled, however the UAMOR bits for that key for all other threads remain disabled. Other threads have no way to set permissions on the key, and the current default permissions are that read/write is enabled for all keys, which means the key has no effect for other threads. Although that may be the desired behaviour in some circumstances, having all threads able to control their permissions for the key is more flexible. The current behaviour also differs from the x86 behaviour, which is problematic for users. To fix this, enable the UAMOR bits for all keys, at process creation (in start_thread(), ie exec time). Since the contents of UAMOR are inherited at fork, all threads are capable of modifying the permissions on any key. This is technically an ABI break on powerpc, but pkey support is fairly new on powerpc and not widely used, and this brings us into line with x86. Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem") Cc: stable@vger.kernel.org # v4.16+ Tested-by: Florian Weimer Signed-off-by: Ram Pai [mpe: Reword some of the changelog] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 174f12c1f3ef5aa6cac58791295afb83c22d5cf1 Author: Mahesh Salgaonkar Date: Tue Aug 7 19:46:46 2018 +0530 powerpc/pseries: Fix endianness while restoring of r3 in MCE handler. commit cd813e1cd7122f2c261dce5b54d1e0c97f80e1a5 upstream. During Machine Check interrupt on pseries platform, register r3 points RTAS extended event log passed by hypervisor. Since hypervisor uses r3 to pass pointer to rtas log, it stores the original r3 value at the start of the memory (first 8 bytes) pointed by r3. Since hypervisor stores this info and rtas log is in BE format, linux should make sure to restore r3 value in correct endian format. Without this patch when MCE handler, after recovery, returns to code that that caused the MCE may end up with Data SLB access interrupt for invalid address followed by kernel panic or hang. Severe Machine check interrupt [Recovered] NIP [d00000000ca301b8]: init_module+0x1b8/0x338 [bork_kernel] Initiator: CPU Error type: SLB [Multihit] Effective address: d00000000ca70000 cpu 0xa: Vector: 380 (Data SLB Access) at [c0000000fc7775b0] pc: c0000000009694c0: vsnprintf+0x80/0x480 lr: c0000000009698e0: vscnprintf+0x20/0x60 sp: c0000000fc777830 msr: 8000000002009033 dar: a803a30c000000d0 current = 0xc00000000bc9ef00 paca = 0xc00000001eca5c00 softe: 3 irq_happened: 0x01 pid = 8860, comm = insmod vscnprintf+0x20/0x60 vprintk_emit+0xb4/0x4b0 vprintk_func+0x5c/0xd0 printk+0x38/0x4c init_module+0x1c0/0x338 [bork_kernel] do_one_initcall+0x54/0x230 do_init_module+0x8c/0x248 load_module+0x12b8/0x15b0 sys_finit_module+0xa8/0x110 system_call+0x58/0x6c --- Exception: c00 (System Call) at 00007fff8bda0644 SP (7fffdfbfe980) is in userspace This patch fixes this issue. Fixes: a08a53ea4c97 ("powerpc/le: Enable RTAS events support") Cc: stable@vger.kernel.org # v3.15+ Reviewed-by: Nicholas Piggin Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 8bfd9029bc79825c15a6569fb18cbdd5195eba44 Author: Nicholas Piggin Date: Fri Jul 27 21:48:17 2018 +1000 powerpc/64s: Fix page table fragment refcount race vs speculative references commit 4231aba000f5a4583dd9f67057aadb68c3eca99d upstream. The page table fragment allocator uses the main page refcount racily with respect to speculative references. A customer observed a BUG due to page table page refcount underflow in the fragment allocator. This can be caused by the fragment allocator set_page_count stomping on a speculative reference, and then the speculative failure handler decrements the new reference, and the underflow eventually pops when the page tables are freed. Fix this by using a dedicated field in the struct page for the page table fragment allocator. Fixes: 5c1f6ee9a31c ("powerpc: Reduce PTE table memory wastage") Cc: stable@vger.kernel.org # v3.10+ Reviewed-by: Aneesh Kumar K.V Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 7c0850fb2b60d2f1bc7580b273021aea10a9aec1 Author: Hari Bathini Date: Tue Aug 7 02:12:45 2018 +0530 powerpc/fadump: handle crash memory ranges array index overflow commit 1bd6a1c4b80a28d975287630644e6b47d0f977a5 upstream. Crash memory ranges is an array of memory ranges of the crashing kernel to be exported as a dump via /proc/vmcore file. The size of the array is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since commit 142b45a72e22 ("memblock: Add array resizing support"). On large memory systems with a few DLPAR operations, the memblock memory regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such systems, registering fadump results in crash or other system failures like below: task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000 NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180 REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+) MSR: 8000000000009033 CR: 22004484 XER: 20000000 CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0 ... NIP [c000000000047df4] smp_send_reschedule+0x24/0x80 LR [c0000000000f9e58] resched_curr+0x138/0x160 Call Trace: resched_curr+0x138/0x160 (unreliable) check_preempt_curr+0xc8/0xf0 ttwu_do_wakeup+0x38/0x150 try_to_wake_up+0x224/0x4d0 __wake_up_common+0x94/0x100 ep_poll_callback+0xac/0x1c0 __wake_up_common+0x94/0x100 __wake_up_sync_key+0x70/0xa0 sock_def_readable+0x58/0xa0 unix_stream_sendmsg+0x2dc/0x4c0 sock_sendmsg+0x68/0xa0 ___sys_sendmsg+0x2cc/0x2e0 __sys_sendmsg+0x5c/0xc0 SyS_socketcall+0x36c/0x3f0 system_call+0x3c/0x100 as array index overflow is not checked for while setting up crash memory ranges causing memory corruption. To resolve this issue, dynamically allocate memory for crash memory ranges and resize it incrementally, in units of pagesize, on hitting array size limit. Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.") Cc: stable@vger.kernel.org # v3.4+ Signed-off-by: Hari Bathini Reviewed-by: Mahesh Salgaonkar [mpe: Just use PAGE_SIZE directly, fixup variable placement] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ec4ad94be6cef5961605f9de81f9d024657e6a3f Author: Yannik Sembritzki Date: Thu Aug 16 14:05:23 2018 +0100 Fix kexec forbidding kernels signed with keys in the secondary keyring to boot commit ea93102f32244e3f45c8b26260be77ed0cc1d16c upstream. The split of .system_keyring into .builtin_trusted_keys and .secondary_trusted_keys broke kexec, thereby preventing kernels signed by keys which are now in the secondary keyring from being kexec'd. Fix this by passing VERIFY_USE_SECONDARY_KEYRING to verify_pefile_signature(). Fixes: d3bfe84129f6 ("certs: Add a secondary system keyring that can be added to dynamically") Signed-off-by: Yannik Sembritzki Signed-off-by: David Howells Cc: kexec@lists.infradead.org Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 54fb49e87c233a5ee7f7b5a29243a0489b5ae9ae Author: Yannik Sembritzki Date: Thu Aug 16 14:05:10 2018 +0100 Replace magic for trusting the secondary keyring with #define commit 817aef260037f33ee0f44c17fe341323d3aebd6d upstream. Replace the use of a magic number that indicates that verify_*_signature() should use the secondary keyring with a symbol. Signed-off-by: Yannik Sembritzki Signed-off-by: David Howells Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 686baf538b8c372452c037a30ab1772e08e795bc Author: Gustavo A. R. Silva Date: Thu Jul 26 12:11:39 2018 -0500 mailbox: xgene-slimpro: Fix potential NULL pointer dereference commit 3512a18cbd8d09e22a790540cb9624c3c49827ba upstream. There is a potential execution path in which function platform_get_resource() returns NULL. If this happens, we will end up having a NULL pointer dereference. Fix this by replacing devm_ioremap with devm_ioremap_resource, which has the NULL check and the memory region request. This code was detected with the help of Coccinelle. Cc: stable@vger.kernel.org Fixes: f700e84f417b ("mailbox: Add support for APM X-Gene platform mailbox driver") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Jassi Brar Signed-off-by: Greg Kroah-Hartman commit 71849f9c7c5500d0ed250b0fb3adf31833fff2bf Author: Javier Martinez Canillas Date: Sun Jun 10 16:43:02 2018 -0400 media: Revert "[media] tvp5150: fix pad format frame height" commit 1831af092308aa5a59ae61e47494e441c8be6b93 upstream. This reverts commit 0866df8dffd514185bfab0d205db76e4c02cf1e4. The v4l uAPI documentation [0] makes clear that in the case of interlaced video (i.e: field is V4L2_FIELD_ALTERNATE) the height refers to the number of lines in the field and not the number of lines in the full frame (which is twice the field height for interlaced formats). So the original height calculation was correct, and it shouldn't had been changed by the mentioned commit. [0]:https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/subdev-formats.html Fixes: 0866df8dffd5 ("[media] tvp5150: fix pad format frame height") Signed-off-by: Javier Martinez Canillas Cc: # for v4.12 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit a0e70000075e1649bc1c0928213fa1a99b80438d Author: Daniel Mack Date: Wed Jun 27 20:58:45 2018 +0200 libertas: fix suspend and resume for SDIO connected cards commit 7444a8092906ed44c09459780c56ba57043e39b1 upstream. Prior to commit 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM callbacks from the sdio bus"), the MMC core used to call into the power management functions of SDIO clients itself and removed the card if the return code was non-zero. IOW, the mmc handled errors gracefully and didn't upchain them to the pm core. Since this change, the mmc core relies on generic power management functions which treat all errors as a reason to cancel the suspend immediately. This causes suspend attempts to fail when the libertas driver is loaded. To fix this, power down the card explicitly in if_sdio_suspend() when we know we're about to lose power and return success. Also set a flag in these cases, and power up the card again in if_sdio_resume(). Fixes: 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM callbacks from the sdio bus") Cc: Signed-off-by: Daniel Mack Reviewed-by: Chris Ball Reviewed-by: Ulf Hansson Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 9be8dc35bceb7e9e41600ca0cd3168025035779e Author: Michel Dänzer Date: Wed Jul 4 17:14:05 2018 +0200 dma-buf: Move BUG_ON from _add_shared_fence to _add_shared_inplace commit 7f43ef9f0d98abbc0eb5e697628ec06756bf60a9 upstream. Fixes the BUG_ON spuriously triggering under the following circumstances: * reservation_object_reserve_shared is called with shared_count == shared_max - 1, so obj->staged is freed in preparation of an in-place update. * reservation_object_add_shared_fence is called with the first fence, after which shared_count == shared_max. * reservation_object_add_shared_fence is called with a follow-up fence from the same context. In the second reservation_object_add_shared_fence call, the BUG_ON triggers. However, nothing bad would happen in reservation_object_add_shared_inplace, since both fences are from the same context, so they only occupy a single slot. Prevent this by moving the BUG_ON to where an overflow would actually happen (e.g. if a buggy caller didn't call reservation_object_reserve_shared before). v2: * Fix description of breaking scenario (Christian König) * Add bugzilla reference Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/106418 Reviewed-by: Chris Wilson # v1 Reviewed-by: Christian König # v1 Signed-off-by: Michel Dänzer Signed-off-by: Sumit Semwal Link: https://patchwork.freedesktop.org/patch/msgid/20180704151405.10357-1-michel@daenzer.net Signed-off-by: Greg Kroah-Hartman commit e561eea4a42407fdde07f84fd3b0d995a5f13586 Author: John Johansen Date: Sat Sep 1 01:57:52 2018 -0700 apparmor: fix bad debug check in apparmor_secid_to_secctx() commit edf4e7b7b9104b58fddfcd073bd7dcc1585d5326 upstream. apparmor_secid_to_secctx() has a bad debug statement tripping on a condition handle by the code. When kconfig SECURITY_APPARMOR_DEBUG is enabled the debug WARN_ON will trip when **secdata is NULL resulting in the following trace. ------------[ cut here ]------------ AppArmor WARN apparmor_secid_to_secctx: ((!secdata)): WARNING: CPU: 0 PID: 14826 at security/apparmor/secid.c:82 apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 14826 Comm: syz-executor1 Not tainted 4.19.0-rc1+ #193 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Code: c7 c7 40 66 58 87 e8 6a 6d 0f fe 0f 0b e9 6c fe ff ff e8 3e aa 44 fe 48 c7 c6 80 67 58 87 48 c7 c7 a0 65 58 87 e8 4b 6d 0f fe <0f> 0b e9 3f fe ff ff 48 89 df e8 fc a7 83 fe e9 ed fe ff ff bb f4 RSP: 0018:ffff8801ba1bed10 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8801ba1beed0 RCX: ffffc9000227e000 RDX: 0000000000018482 RSI: ffffffff8163ac01 RDI: 0000000000000001 RBP: ffff8801ba1bed30 R08: ffff8801b80ec080 R09: ffffed003b603eca R10: ffffed003b603eca R11: ffff8801db01f657 R12: 0000000000000001 R13: 0000000000000000 R14: 0000000000000000 R15: ffff8801ba1beed0 security_secid_to_secctx+0x63/0xc0 security/security.c:1314 ctnetlink_secctx_size net/netfilter/nf_conntrack_netlink.c:621 [inline] ctnetlink_nlmsg_size net/netfilter/nf_conntrack_netlink.c:659 [inline] ctnetlink_conntrack_event+0x303/0x1470 net/netfilter/nf_conntrack_netlink.c:706 nf_conntrack_eventmask_report+0x55f/0x930 net/netfilter/nf_conntrack_ecache.c:151 nf_conntrack_event_report include/net/netfilter/nf_conntrack_ecache.h:112 [inline] nf_ct_delete+0x33c/0x5d0 net/netfilter/nf_conntrack_core.c:601 nf_ct_iterate_cleanup+0x48c/0x5e0 net/netfilter/nf_conntrack_core.c:1892 nf_ct_iterate_cleanup_net+0x23c/0x2d0 net/netfilter/nf_conntrack_core.c:1974 ctnetlink_flush_conntrack net/netfilter/nf_conntrack_netlink.c:1226 [inline] ctnetlink_del_conntrack+0x66c/0x850 net/netfilter/nf_conntrack_netlink.c:1258 nfnetlink_rcv_msg+0xd88/0x1070 net/netfilter/nfnetlink.c:228 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454 nfnetlink_rcv+0x1c0/0x4d0 net/netfilter/nfnetlink.c:560 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 __sys_sendmsg+0x11d/0x290 net/socket.c:2152 __do_sys_sendmsg net/socket.c:2161 [inline] __se_sys_sendmsg net/socket.c:2159 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f7bc6e03c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7bc6e046d4 RCX: 0000000000457089 RDX: 0000000000000000 RSI: 0000000020d65000 RDI: 0000000000000003 RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000004d4588 R14: 00000000004c8d5c R15: 0000000000000000 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. CC: #4.18 Fixes: c092921219d2 ("apparmor: add support for mapping secids and using secctxes") Reported-by: syzbot+21016130b0580a9de3b5@syzkaller.appspotmail.com Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit ac89e9c33de32967c046dd8ef07c3ae36e024e98 Author: Bart Van Assche Date: Thu Aug 9 07:53:38 2018 -0700 block: Ensure that a request queue is dissociated from the cgroup controller commit 24ecc3585348b616993a3c4d6dc2c6b8007e358c upstream. Several block drivers call alloc_disk() followed by put_disk() if something fails before device_add_disk() is called without calling blk_cleanup_queue(). Make sure that also for this scenario a request queue is dissociated from the cgroup controller. This patch avoids that loading the parport_pc, paride and pf drivers triggers the following kernel crash: BUG: KASAN: null-ptr-deref in pi_init+0x42e/0x580 [paride] Read of size 4 at addr 0000000000000008 by task modprobe/744 Call Trace: dump_stack+0x9a/0xeb kasan_report+0x139/0x350 pi_init+0x42e/0x580 [paride] pf_init+0x2bb/0x1000 [pf] do_one_initcall+0x8e/0x405 do_init_module+0xd9/0x2f2 load_module+0x3ab4/0x4700 SYSC_finit_module+0x176/0x1a0 do_syscall_64+0xee/0x2b0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 Reported-by: Alexandru Moise <00moses.alexander00@gmail.com> Fixes: a063057d7c73 ("block: Fix a race between request queue removal and the block cgroup controller") # v4.17 Signed-off-by: Bart Van Assche Tested-by: Alexandru Moise <00moses.alexander00@gmail.com> Reviewed-by: Johannes Thumshirn Cc: Tejun Heo Cc: Christoph Hellwig Cc: Ming Lei Cc: Alexandru Moise <00moses.alexander00@gmail.com> Cc: Joseph Qi Cc: Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d367a6927ffd3cb4af62f450fe11e81dcb8c0297 Author: Bart Van Assche Date: Thu Aug 9 07:53:37 2018 -0700 block: Introduce blk_exit_queue() commit 4cf6324b17e96b7b7ab4021c6929500934d46750 upstream. This patch does not change any functionality. Signed-off-by: Bart Van Assche Reviewed-by: Johannes Thumshirn Cc: Christoph Hellwig Cc: Ming Lei Cc: Omar Sandoval Cc: Alexandru Moise <00moses.alexander00@gmail.com> Cc: Joseph Qi Cc: Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d9ef3176a3981f554c84f28cb459b6572b9c8925 Author: Bart Van Assche Date: Thu Aug 9 07:53:36 2018 -0700 blkcg: Introduce blkg_root_lookup() commit 6bad9b210a228d2fe0e0efe26d9b115348529cee upstream. This new function will be used in a later patch to verify whether a queue has been dissociated from the cgroup controller before being released. Signed-off-by: Bart Van Assche Cc: Tejun Heo Cc: Christoph Hellwig Cc: Ming Lei Cc: Omar Sandoval Cc: Johannes Thumshirn Cc: Alexandru Moise <00moses.alexander00@gmail.com> Cc: Joseph Qi Cc: Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0c2e7eb1a4c30ab48ec810ce9e610bc44f69a9d9 Author: Ming Lei Date: Mon Jul 30 20:02:19 2018 +0800 block: really disable runtime-pm for blk-mq commit b233f127042dba991229e3882c6217c80492f6ef upstream. Runtime PM isn't ready for blk-mq yet, and commit 765e40b675a9 ("block: disable runtime-pm for blk-mq") tried to disable it. Unfortunately, it can't take effect in that way since user space still can switch it on via 'echo auto > /sys/block/sdN/device/power/control'. This patch disables runtime-pm for blk-mq really by pm_runtime_disable() and fixes all kinds of PM related kernel crash. Cc: Tomas Janousek Cc: Przemek Socha Cc: Alan Stern Cc: Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Tested-by: Patrick Steinhardt Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cde67159df4d6faab6816f7847219eb2b29f3c8b Author: xiao jin Date: Mon Jul 30 14:11:12 2018 +0800 block: blk_init_allocated_queue() set q->fq as NULL in the fail case commit 54648cf1ec2d7f4b6a71767799c45676a138ca24 upstream. We find the memory use-after-free issue in __blk_drain_queue() on the kernel 4.14. After read the latest kernel 4.18-rc6 we think it has the same problem. Memory is allocated for q->fq in the blk_init_allocated_queue(). If the elevator init function called with error return, it will run into the fail case to free the q->fq. Then the __blk_drain_queue() uses the same memory after the free of the q->fq, it will lead to the unpredictable event. The patch is to set q->fq as NULL in the fail case of blk_init_allocated_queue(). Fixes: commit 7c94e1c157a2 ("block: introduce blk_flush_queue to drive flush machinery") Cc: Reviewed-by: Ming Lei Reviewed-by: Bart Van Assche Signed-off-by: xiao jin Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4bc5673119807e1ae57060558178b1a2925102df Author: Mikulas Patocka Date: Tue Jul 3 13:34:22 2018 -0400 block: fix infinite loop if the device loses discard capability commit b88aef36b87c9787a4db724923ec4f57dfd513f3 upstream. If __blkdev_issue_discard is in progress and a device mapper device is reloaded with a table that doesn't support discard, q->limits.max_discard_sectors is set to zero. This results in infinite loop in __blkdev_issue_discard. This patch checks if max_discard_sectors is zero and aborts with -EOPNOTSUPP. Signed-off-by: Mikulas Patocka Tested-by: Zdenek Kabelac Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d3949a0a13419c987d7f4d2d1d51ce68099acba7 Author: Markus Stockhausen Date: Fri Jul 27 09:09:53 2018 -0600 readahead: stricter check for bdi io_pages commit dc30b96ab6d569060741572cf30517d3179429a8 upstream. ondemand_readahead() checks bdi->io_pages to cap the maximum pages that need to be processed. This works until the readit section. If we would do an async only readahead (async size = sync size) and target is at beginning of window we expand the pages by another get_next_ra_size() pages. Btrace for large reads shows that kernel always issues a doubled size read at the beginning of processing. Add an additional check for io_pages in the lower part of the func. The fix helps devices that hard limit bio pages and rely on proper handling of max_hw_read_sectors (e.g. older FusionIO cards). For that reason it could qualify for stable. Fixes: 9491ae4a ("mm: don't cap request size based on read-ahead setting") Cc: stable@vger.kernel.org Signed-off-by: Markus Stockhausen stockhausen@collogia.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3a9bc441b671ea1837a632c702f360ca7f3e1665 Author: Sergei Shtylyov Date: Wed Aug 22 21:28:01 2018 +0300 mmc: renesas_sdhi_internal_dmac: fix #define RST_RESERVED_BITS commit 9faf870e559a710c44e747ba20383ea82d8ac5d2 upstream. The DM_CM_RST register actually has bits 0-31 defaulting to 1s and bits 32-63 defaulting to 0s -- fix off-by-one in #define RST_RESERVED_BITS. Signed-off-by: Sergei Shtylyov Reviewed-by: Wolfram Sang Fixes: 2a68ea7896e3 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 74b83d076cdf03a3317172cb1c3909723162e8e5 Author: Sergei Shtylyov Date: Wed Aug 22 21:22:26 2018 +0300 mmc: renesas_sdhi_internal_dmac: mask DMAC interrupts commit d2332f887ddfba50fee93b8e1736376517c2df0c upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It turned out that U-Boot left the SDHI DMA interrupts enabled while the Linux driver didn't use those. Masking those interrupts in renesas_sdhi_internal_dmac_request_dma() gets rid of both issues... Signed-off-by: Sergei Shtylyov Reviewed-by: Wolfram Sang Fixes: 2a68ea7896e3 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cf8871c4121ccd17f0502a3910d3c6742823f376 Author: Adrian Hunter Date: Tue Aug 21 15:05:55 2018 +0300 mmc: block: Fix unsupported parallel dispatch of requests commit 26caddf274cf1e89fd4ce44ab2b8dbc7a7f97681 upstream. The mmc block driver does not support parallel dispatch of requests. In normal circumstances, all requests are anyway funneled through a single work item, so parallel dispatch never happens. However it can happen if there is no elevator. Fix that by detecting if a dispatch is in progress and returning busy (BLK_STS_RESOURCE) in that case Fixes: 81196976ed94 ("mmc: block: Add blk-mq support") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e27421b3b394c8b8d9ff3dcfe27504927ef853c6 Author: Janek Kotas Date: Mon Jun 4 11:24:44 2018 +0000 spi: cadence: Change usleep_range() to udelay(), for atomic context commit 931c4e9a72ae91d59c5332ffb6812911a749da8e upstream. The path "spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()" added a usleep_range() function call, which cannot be used in atomic context. However the cdns_spi_fill_tx_fifo() function can be called during an interrupt which may result in a kernel panic: BUG: scheduling while atomic: grep/561/0x00010002 Modules linked in: Preemption disabled at: [] wait_for_common+0x48/0x178 CPU: 0 PID: 561 Comm: grep Not tainted 4.17.0 #1 Hardware name: Cadence CSP (DT) Call trace: dump_backtrace+0x0/0x198 show_stack+0x14/0x20 dump_stack+0x8c/0xac __schedule_bug+0x6c/0xb8 __schedule+0x570/0x5d8 schedule+0x34/0x98 schedule_hrtimeout_range_clock+0x98/0x110 schedule_hrtimeout_range+0x10/0x18 usleep_range+0x64/0x98 cdns_spi_fill_tx_fifo+0x70/0xb0 cdns_spi_irq+0xd0/0xe0 __handle_irq_event_percpu+0x9c/0x128 handle_irq_event_percpu+0x34/0x88 handle_irq_event+0x48/0x78 handle_fasteoi_irq+0xbc/0x1b0 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x84/0xf8 gic_handle_irq+0xc4/0x180 This patch replaces the function call with udelay() which can be used in an atomic context, like an interrupt. Signed-off-by: Jan Kotas Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit db597647506d14f853dbc70c7b7e485322434421 Author: Krzysztof Kozlowski Date: Fri Jun 29 13:33:09 2018 +0200 spi: spi-fsl-dspi: Fix imprecise abort on VF500 during probe commit d8ffee2f551a627ffb7b216e2da322cb9a037f77 upstream. Registers of DSPI should not be accessed before enabling its clock. On Toradex Colibri VF50 on Iris carrier board this could be seen during bootup as imprecise abort: Unhandled fault: imprecise external abort (0x1c06) at 0x00000000 Internal error: : 1c06 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.39-dirty #97 Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) Backtrace: [<804166a8>] (regmap_write) from [<80466b5c>] (dspi_probe+0x1f0/0x8dc) [<8046696c>] (dspi_probe) from [<8040107c>] (platform_drv_probe+0x54/0xb8) [<80401028>] (platform_drv_probe) from [<803ff53c>] (driver_probe_device+0x280/0x2f8) [<803ff2bc>] (driver_probe_device) from [<803ff674>] (__driver_attach+0xc0/0xc4) [<803ff5b4>] (__driver_attach) from [<803fd818>] (bus_for_each_dev+0x70/0xa4) [<803fd7a8>] (bus_for_each_dev) from [<803fee74>] (driver_attach+0x24/0x28) [<803fee50>] (driver_attach) from [<803fe980>] (bus_add_driver+0x1a0/0x218) [<803fe7e0>] (bus_add_driver) from [<803fffe8>] (driver_register+0x80/0x100) [<803fff68>] (driver_register) from [<80400fdc>] (__platform_driver_register+0x48/0x50) [<80400f94>] (__platform_driver_register) from [<8091cf7c>] (fsl_dspi_driver_init+0x1c/0x20) [<8091cf60>] (fsl_dspi_driver_init) from [<8010195c>] (do_one_initcall+0x4c/0x174) [<80101910>] (do_one_initcall) from [<80900e8c>] (kernel_init_freeable+0x144/0x1d8) [<80900d48>] (kernel_init_freeable) from [<805ff6a8>] (kernel_init+0x10/0x114) [<805ff698>] (kernel_init) from [<80107be8>] (ret_from_fork+0x14/0x2c) Cc: Fixes: 5ee67b587a2b ("spi: dspi: clear SPI_SR before enable interrupt") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3b45f480496c8b9b6a984681cbca63b815280df4 Author: Mika Westerberg Date: Thu Jun 28 13:52:23 2018 +0300 spi: pxa2xx: Add support for Intel Ice Lake commit 22d71a5097ec7059b6cbbee678a4f88484695941 upstream. Intel Ice Lake SPI host controller follows the Intel Cannon Lake but the PCI IDs are different. Add the new PCI IDs to the driver supported devices list. Signed-off-by: Mika Westerberg Signed-off-by: Jarkko Nikula Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e52c91662cef2084536af400021780df2f101d41 Author: Bartosz Golaszewski Date: Fri Aug 10 11:13:52 2018 +0200 spi: davinci: fix a NULL pointer dereference commit 563a53f3906a6b43692498e5b3ae891fac93a4af upstream. On non-OF systems spi->controlled_data may be NULL. This causes a NULL pointer derefence on dm365-evm. Signed-off-by: Bartosz Golaszewski Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b84ea5862258d690f5e93c1fffdbdb491d1f6ac9 Author: Chirantan Ekbote Date: Mon Jul 16 17:35:29 2018 -0700 9p/net: Fix zero-copy path in the 9p virtio transport commit d28c756caee6e414d9ba367d0b92da24145af2a8 upstream. The zero-copy optimization when reading or writing large chunks of data is quite useful. However, the 9p messages created through the zero-copy write path have an incorrect message size: it should be the size of the header + size of the data being written but instead it's just the size of the header. This only works if the server ignores the size field of the message and otherwise breaks the framing of the protocol. Fix this by re-writing the message size field with the correct value. Tested by running `dd if=/dev/zero of=out bs=4k count=1` inside a virtio-9p mount. Link: http://lkml.kernel.org/r/20180717003529.114368-1-chirantan@chromium.org Signed-off-by: Chirantan Ekbote Reviewed-by: Greg Kurz Tested-by: Greg Kurz Cc: Dylan Reid Cc: Guenter Roeck Cc: stable@vger.kernel.org Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 8c37a4ca229d3708c7c730de54821c17971f220c Author: Alexander Aring Date: Mon Jul 2 16:32:03 2018 -0400 net: mac802154: tx: expand tailroom if necessary commit f9c52831133050c6b82aa8b6831c92da2bbf2a0b upstream. This patch is necessary if case of AF_PACKET or other socket interface which I am aware of it and didn't allocated the necessary room. Reported-by: David Palma Reported-by: Rabi Narayan Sahoo Cc: stable@vger.kernel.org Signed-off-by: Alexander Aring Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 6ce27549cc147e8d7e481f863780b49d6bac5695 Author: Alexander Aring Date: Sat Jul 14 12:52:10 2018 -0400 net: 6lowpan: fix reserved space for single frames commit ac74f87c789af40936a80131c4759f3e72579c3a upstream. This patch fixes patch add handling to take care tail and headroom for single 6lowpan frames. We need to be sure we have a skb with the right head and tailroom for single frames. This patch do it by using skb_copy_expand() if head and tailroom is not enough allocated by upper layer. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195059 Reported-by: David Palma Reported-by: Rabi Narayan Sahoo Cc: stable@vger.kernel.org Signed-off-by: Alexander Aring Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 832fa8183637a5a9e4f595a6eb0125220021fdf5 Author: Boqun Feng Date: Fri Jun 15 12:06:31 2018 -0700 rcu: Make expedited GPs handle CPU 0 being offline commit fcc63543650150629c8a873cbef3578770acecd9 upstream. Currently, the parallelized initialization of expedited grace periods uses the workqueue associated with each rcu_node structure's ->grplo field. This works fine unless that CPU is offline. This commit therefore uses the CPU corresponding to the lowest-numbered online CPU, or just queues the work on WORK_CPU_UNBOUND if there are no online CPUs corresponding to this rcu_node structure. Note that this patch uses cpu_is_offline() instead of the usual approach of checking bits in the rcu_node structure's ->qsmaskinitnext field. This is safe because preemption is disabled across both the cpu_is_offline() check and the call to queue_work_on(). Signed-off-by: Boqun Feng [ paulmck: Disable preemption to close offline race window. ] Signed-off-by: Paul E. McKenney [ paulmck: Apply Peter Zijlstra feedback on CPU selection. ] Tested-by: Aneesh Kumar K.V Signed-off-by: Greg Kroah-Hartman