- Oct 05, 2022
-
-
Marc Kleine-Budde authored
commit 81d192c2 upstream. As Jacob noticed, the optimization introduced in 387da6bc ("can: c_can: cache frames to operate as a true FIFO") doesn't properly work on C_CAN, but on D_CAN IP cores. The exact reasons are still unknown. For now disable caching if CAN frames in the TX path for C_CAN cores. Fixes: 387da6bc ("can: c_can: cache frames to operate as a true FIFO") Link: https://lore.kernel.org/all/20220928083354.1062321-1-mkl@pengutronix.de Link: https://lore.kernel.org/all/15a8084b-9617-2da1-6704-d7e39d60643b@gmail.com Reported-by: Jacob Kroon <jacob.kroon@gmail.com> Tested-by: Jacob Kroon <jacob.kroon@gmail.com> Cc: stable@vger.kernel.org # v5.15 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sebastian Krzyszkowiak authored
commit e62563db upstream. Both i.MX6 and i.MX8 reference manuals list 0xBF8 as SNVS_HPVIDR1 (chapters 57.9 and 6.4.5 respectively). Without this, trying to read the revision number results in 0 on all revisions, causing the i.MX6 quirk to apply on all platforms, which in turn causes the driver to synthesise power button release events instead of passing the real one as they happen even on platforms like i.MX8 where that's not wanted. Fixes: 1a26c920 ("Input: snvs_pwrkey - send key events for i.MX6 S, DL and Q") Tested-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/4599101.ElGaqSPkdT@pliszka Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Frank Wunderlich authored
commit 797666cd upstream. Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2. Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Cc: stable@vger.kernel.org Acked-by: Bjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20220926150740.6684-3-linux@fw-web.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mario Limonciello authored
commit 31f87f70 upstream. If any software has interacted with the USB4 registers before the Linux USB4 CM runs, it may have modified the plug events delay. It has been observed that if this value too large, it's possible that hotplugged devices will negotiate a fallback mode instead in Linux. To prevent this, explicitly align the plug events delay with the USB4 spec value of 10ms. Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
commit 415ba26c upstream. Sink only devices do not have any source capabilities, so the driver should not warn about that. Also DRP (Dual Role Power) capable devices, such as USB Type-C docking stations, do not return any source capabilities unless they are plugged to a power supply themselves. Fixes: 1f4642b7 ("usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4") Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Cc: <stable@vger.kernel.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20220922145924.80667-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hongling Zeng authored
commit 0fb9703a upstream. The UAS mode of Thinkplus(0x17ef, 0x3899) is reported to influence performance and trigger kernel panic on several platforms with the following error message: [ 39.702439] xhci_hcd 0000:0c:00.3: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 39.702442] xhci_hcd 0000:0c:00.3: @000000026c61f810 00000000 00000000 1b000000 05038000 [ 720.545894][13] Workqueue: usb_hub_wq hub_event [ 720.550971][13] ffff88026c143c38 0000000000016300 ffff8802755bb900 ffff880 26cb80000 [ 720.559673][13] ffff88026c144000 ffff88026ca88100 0000000000000000 ffff880 26cb80000 [ 720.568374][13] ffff88026cb80000 ffff88026c143c50 ffffffff8186ae25 ffff880 26ca880f8 [ 720.577076][13] Call Trace: [ 720.580201][13] [<ffffffff8186ae25>] schedule+0x35/0x80 [ 720.586137][13] [<ffffffff8186b0ce>] schedule_preempt_disabled+0xe/0x10 [ 720.593623][13] [<ffffffff8186cb94>] __mutex_lock_slowpath+0x164/0x1e0 [ 720.601012][13] [<ffffffff8186cc3f>] mutex_lock+0x2f/0x40 [ 720.607141][13] [<ffffffff8162b8e9>] usb_disconnect+0x59/0x290 Falling back to USB mass storage can solve this problem, so ignore UAS function of this chip. Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Link: https://lore.kernel.org/r/1663902249837086.19.seg@mailgw Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hongling Zeng authored
commit e00b488e upstream. The UAS mode of Hiksemi USB_HDD is reported to fail to work on several platforms with the following error message, then after re-connecting the device will be offlined and not working at all. [ 592.518442][ 2] sd 8:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD [ 592.527575][ 2] sd 8:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 03 6f 88 00 00 04 00 00 [ 592.536330][ 2] sd 8:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD [ 592.545266][ 2] sd 8:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 07 44 1a 88 00 00 08 00 These disks have a broken uas implementation, the tag field of the status iu-s is not set properly,so we need to fall-back to usb-storage. Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Link: https://lore.kernel.org/r/1663901185-21067-1-git-send-email-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hongling Zeng authored
commit a625a4b8 upstream. The UAS mode of Hiksemi is reported to fail to work on several platforms with the following error message, then after re-connecting the device will be offlined and not working at all. [ 592.518442][ 2] sd 8:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD [ 592.527575][ 2] sd 8:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 03 6f 88 00 00 04 00 00 [ 592.536330][ 2] sd 8:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD [ 592.545266][ 2] sd 8:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 07 44 1a 88 00 00 08 00 These disks have a broken uas implementation, the tag field of the status iu-s is not set properly,so we need to fall-back to usb-storage. Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Link: https://lore.kernel.org/r/1663901173-21020-1-git-send-email-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
William Breathitt Gray authored
[ Upstream commit 2bc54aaa ] IRQ trigger configuration is skipped if it has already been set before; however, the IRQ line still needs to be OR'd to irq_enabled because irq_enabled is reset for every events_configure call. This patch moves the irq_enabled OR operation update to before the irq_trigger check so that IRQ line enablement is not skipped. Fixes: c95cc0d9 ("counter: 104-quad-8: Fix persistent enabled events bug") Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20220815122301.2750-1-william.gray@linaro.org/ Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/179eed11eaf225dbd908993b510df0c8f67b1230.1663844776.git.william.gray@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
William Breathitt Gray authored
[ Upstream commit daae1ee5 ] Reduce magic numbers and improve code readability by implementing and utilizing named register data structures. Link: https://lore.kernel.org/r/20220707171709.36010-1-william.gray@linaro.org/ Cc: Syed Nayyar Waris <syednwaris@gmail.com> Tested-by: Fred Eckert <Frede@cmslaser.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/285fdc7c03892251f50bdbf2c28c19998243a6a3.1657813472.git.william.gray@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 2bc54aaa ("counter: 104-quad-8: Fix skipped IRQ lines during events configuration") Signed-off-by: Sasha Levin <sashal@kernel.org>
-
William Breathitt Gray authored
[ Upstream commit b6e9cded ] This driver doesn't need to access I/O ports directly via inb()/outb() and friends. This patch abstracts such access by calling ioport_map() to enable the use of more typical ioread8()/iowrite8() I/O memory accessor calls. Link: https://lore.kernel.org/r/861c003318dce3d2bef4061711643bb04f5ec14f.1652201921.git.william.gray@linaro.org Cc: Syed Nayyar Waris <syednwaris@gmail.com> Suggested-by: David Laight <David.Laight@ACULAB.COM> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/e971b897cacfac4cb2eca478f5533d2875f5cadd.1657813472.git.william.gray@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 2bc54aaa ("counter: 104-quad-8: Fix skipped IRQ lines during events configuration") Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Adrian Hunter authored
[ Upstream commit ca76d7d2 ] With mixed per-thread and (system-wide) per-cpu maps, the "any cpu" value -1 must be skipped when setting CPU mask bits. Prior to commit cbd7bfc7 ("tools/perf: Fix out of bound access to cpu mask array") the invalid setting went unnoticed, but since then it causes perf record to fail with an error. Example: Before: $ perf record -e intel_pt// --per-thread uname Failed to initialize parallel data streaming masks After: $ perf record -e intel_pt// --per-thread uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.068 MB perf.data ] Fixes: ae4f8ae1 ("libperf evlist: Allow mixing per-thread and per-cpu mmaps") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220915122612.81738-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Athira Rajeev authored
[ Upstream commit cbd7bfc7 ] The cpu mask init code in "record__mmap_cpu_mask_init" function access "bits" array part of "struct mmap_cpu_mask". The size of this array is the value from cpu__max_cpu().cpu. This array is used to contain the cpumask value for each cpu. While setting bit for each cpu, it calls "set_bit" function which access index in "bits" array. If we provide a command line option to -C which is greater than the number of CPU's present in the system, the set_bit could access an array member which is out-of the array size. This is because currently, there is no boundary check for the CPU. This will result in seg fault: <<>> ./perf record -C 12341234 ls Perf can support 2048 CPUs. Consider raising MAX_NR_CPUS Segmentation fault (core dumped) <<>> Debugging with gdb, points to function flow as below: <<>> set_bit record__mmap_cpu_mask_init record__init_thread_default_masks record__init_thread_masks cmd_record <<>> Fix this by adding boundary check for the array. After the patch: <<>> ./perf record -C 12341234 ls Perf can support 2048 CPUs. Consider raising MAX_NR_CPUS Failed to initialize parallel data streaming masks <<>> With this fix, if -C is given a non-exsiting CPU, perf record will fail with: <<>> ./perf record -C 50 ls Failed to initialize parallel data streaming masks <<>> Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Athira Jajeev <atrajeev@linux.vnet.ibm.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kajol Jain <kjain@linux.ibm.com> Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Link: https://lore.kernel.org/r/20220905141929.7171-2-atrajeev@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Stable-dep-of: ca76d7d2 ("perf record: Fix cpu mask bit setting for mixed mmaps") Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Heiko Stuebner authored
[ Upstream commit 2a2018c3 ] Both basic extensions of SVPBMT and ZICBOM depend on CONFIG_MMU. Make the T-Head errata implementations of the similar functionality also depend on it to prevent build errors. Fixes: a35707c3 ("riscv: add memory-type errata for T-Head") Fixes: d20ec752 ("riscv: implement cache-management errata for T-Head SoCs") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Guo Ren <guoren@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220907154932.2858518-1-heiko@sntech.de Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
- Oct 04, 2022
-
-
Greg Kroah-Hartman authored
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit a0f7cdd6 which is commit 822e5ae7 upstream. This is part of a series of i915 patches that were backported to 5.19.12 but found to be incomplete and caused problems on many systems so they are being reverted. Reported-by: Jerry Ling <jiling@cern.ch> Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Sasha Levin <sashal@kernel.org> Link: https://lore.kernel.org/all/55905860-adf9-312c-69cc-491ac8ce1a8b@cern.ch/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit ad719d5c which is commit 75bd0d5e upstream. This is part of a series of i915 patches that were backported to 5.19.12 but found to be incomplete and caused problems on many systems so they are being reverted. Reported-by: Jerry Ling <jiling@cern.ch> Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Sasha Levin <sashal@kernel.org> Link: https://lore.kernel.org/all/55905860-adf9-312c-69cc-491ac8ce1a8b@cern.ch/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit 5da3f1bf which is commit c3fbcf60 upstream. This is part of a series of i915 patches that were backported to 5.19.12 but found to be incomplete and caused problems on many systems so they are being reverted. Reported-by: Jerry Ling <jiling@cern.ch> Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Sasha Levin <sashal@kernel.org> Link: https://lore.kernel.org/all/55905860-adf9-312c-69cc-491ac8ce1a8b@cern.ch/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit 2af21ae8 which is commit c2fdb424 upstream. This is part of a series of i915 patches that were backported to 5.19.12 but found to be incomplete and caused problems on many systems so they are being reverted. Reported-by: Jerry Ling <jiling@cern.ch> Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Sasha Levin <sashal@kernel.org> Link: https://lore.kernel.org/all/55905860-adf9-312c-69cc-491ac8ce1a8b@cern.ch/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit fc6aff98 which is commit 3cf05076 upstream. This is part of a series of i915 patches that were backported to 5.19.12 but found to be incomplete and caused problems on many systems so they are being reverted. Reported-by: Jerry Ling <jiling@cern.ch> Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Sasha Levin <sashal@kernel.org> Link: https://lore.kernel.org/all/55905860-adf9-312c-69cc-491ac8ce1a8b@cern.ch/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit d9d2625d which is commit 607f4176 upstream. This is part of a series of i915 patches that were backported to 5.19.12 but found to be incomplete and caused problems on many systems so they are being reverted. Reported-by: Jerry Ling <jiling@cern.ch> Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Sasha Levin <sashal@kernel.org> Link: https://lore.kernel.org/all/55905860-adf9-312c-69cc-491ac8ce1a8b@cern.ch/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit f6bb739e which is commit 13393f65 upstream. This is part of a series of i915 patches that were backported to 5.19.12 but found to be incomplete and caused problems on many systems so they are being reverted. Reported-by: Jerry Ling <jiling@cern.ch> Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sasha Levin <sashal@kernel.org> Link: https://lore.kernel.org/all/55905860-adf9-312c-69cc-491ac8ce1a8b@cern.ch/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit 0d0f5ca7 which is commit 5c57c099 upstream. This is part of a series of i915 patches that were backported to 5.19.12 but found to be incomplete and caused problems on many systems so they are being reverted. Reported-by: Jerry Ling <jiling@cern.ch> Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Sasha Levin <sashal@kernel.org> Link: https://lore.kernel.org/all/55905860-adf9-312c-69cc-491ac8ce1a8b@cern.ch/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Sep 28, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220926100806.522017616@linuxfoundation.org Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Fenil Jain <fkjainco@gmail.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Zan Aziz <zanaziz313@gmail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit 613c5a85 upstream. Currently the Orlov inode allocator searches for free inodes for a directory only in flex block groups with at most inodes_per_group/16 more directory inodes than average per flex block group. However with growing size of flex block group this becomes unnecessarily strict. Scale allowed difference from average directory count per flex block group with flex block group size as we do with other metrics. Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Cc: stable@kernel.org Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220908092136.11770-3-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit a078dff8 upstream. Variable 'grp' may be left uninitialized if there's no group with suitable average fragment size (or larger). Fix the problem by initializing it earlier. Link: https://lore.kernel.org/r/20220922091542.pkhedytey7wzp5fi@quack3 Fixes: 83e80a6e ("ext4: use buckets for cr 1 block scan instead of rbtree") Cc: stable@kernel.org Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Christoph Hellwig authored
commit 4c66a326 upstream. This reverts commit a09b3140 . Dusty Mabe reported consistent hang during CoreOS shutdown with a MD RAID1 setup. Although apparently similar hangs happened before, and this patch most likely is not the root cause it made it much more severe. Revert it until we can figure out what is going on with the md driver. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220919144049.978907-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit 83e80a6e upstream. Using rbtree for sorting groups by average fragment size is relatively expensive (needs rbtree update on every block freeing or allocation) and leads to wide spreading of allocations because selection of block group is very sentitive both to changes in free space and amount of blocks allocated. Furthermore selecting group with the best matching average fragment size is not necessary anyway, even more so because the variability of fragment sizes within a group is likely large so average is not telling much. We just need a group with large enough average fragment size so that we have high probability of finding large enough free extent and we don't want average fragment size to be too big so that we are likely to find free extent only somewhat larger than what we need. So instead of maintaing rbtree of groups sorted by fragment size keep bins (lists) or groups where average fragment size is in the interval [2^i, 2^(i+1)). This structure requires less updates on block allocation / freeing, generally avoids chaotic spreading of allocations into block groups, and still is able to quickly (even faster that the rbtree) provide a block group which is likely to have a suitably sized free space extent. This patch reduces number of block groups used when untarring archive with medium sized files (size somewhat above 64k which is default mballoc limit for avoiding locality group preallocation) to about half and thus improves write speeds for eMMC flash significantly. Fixes: 196e402a ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Link: https://lore.kernel.org/r/20220908092136.11770-5-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit a9f2a293 upstream. Curently we don't use any preallocation when a file is already closed when allocating blocks (from writeback code when converting delayed allocation). However for small files, using locality group preallocation is actually desirable as that is not specific to a particular file. Rather it is a method to pack small files together to reduce fragmentation and for that the fact the file is closed is actually even stronger hint the file would benefit from packing. So change the logic to allow locality group preallocation in this case. Fixes: 196e402a ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Link: https://lore.kernel.org/r/20220908092136.11770-4-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit 1940265e upstream. mb_set_largest_free_order() updates lists containing groups with largest chunk of free space of given order. The way it updates it leads to always moving the group to the tail of the list. Thus allocations looking for free space of given order effectively end up cycling through all groups (and due to initialization in last to first order). This spreads allocations among block groups which reduces performance for rotating disks or low-end flash media. Change mb_set_largest_free_order() to only update lists if the order of the largest free chunk in the group changed. Fixes: 196e402a ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Link: https://lore.kernel.org/r/20220908092136.11770-2-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit 4fca50d4 upstream. One of the side-effects of mb_optimize_scan was that the optimized functions to select next group to try were called even before we tried the goal group. As a result we no longer allocate files close to corresponding inodes as well as we don't try to expand currently allocated extent in the same group. This results in reaim regression with workfile.disk workload of upto 8% with many clients on my test machine: baseline mb_optimize_scan Hmean disk-1 2114.16 ( 0.00%) 2099.37 ( -0.70%) Hmean disk-41 87794.43 ( 0.00%) 83787.47 * -4.56%* Hmean disk-81 148170.73 ( 0.00%) 135527.05 * -8.53%* Hmean disk-121 177506.11 ( 0.00%) 166284.93 * -6.32%* Hmean disk-161 220951.51 ( 0.00%) 207563.39 * -6.06%* Hmean disk-201 208722.74 ( 0.00%) 203235.59 ( -2.63%) Hmean disk-241 222051.60 ( 0.00%) 217705.51 ( -1.96%) Hmean disk-281 252244.17 ( 0.00%) 241132.72 * -4.41%* Hmean disk-321 255844.84 ( 0.00%) 245412.84 * -4.08%* Also this is causing huge regression (time increased by a factor of 5 or so) when untarring archive with lots of small files on some eMMC storage cards. Fix the problem by making sure we try goal group first. Fixes: 196e402a ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/all/20220727105123.ckwrhbilzrxqpt24@quack3/ Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220908092136.11770-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Theodore Ts'o authored
commit 80fa46d6 upstream. This patch avoids threads live-locking for hours when a large number threads are competing over the last few free extents as they blocks getting added and removed from preallocation pools. From our bug reporter: A reliable way for triggering this has multiple writers continuously write() to files when the filesystem is full, while small amounts of space are freed (e.g. by truncating a large file -1MiB at a time). In the local filesystem, this can be done by simply not checking the return code of write (0) and/or the error (ENOSPACE) that is set. Over NFS with an async mount, even clients with proper error checking will behave this way since the linux NFS client implementation will not propagate the server errors [the write syscalls immediately return success] until the file handle is closed. This leads to a situation where NFS clients send a continuous stream of WRITE rpcs which result in ERRNOSPACE -- but since the client isn't seeing this, the stream of writes continues at maximum network speed. When some space does appear, multiple writers will all attempt to claim it for their current write. For NFS, we may see dozens to hundreds of threads that do this. The real-world scenario of this is database backup tooling (in particular, github.com/mdkent/percona-xtrabackup) which may write large files (>1TiB) to NFS for safe keeping. Some temporary files are written, rewound, and read back -- all before closing the file handle (the temp file is actually unlinked, to trigger automatic deletion on close/crash.) An application like this operating on an async NFS mount will not see an error code until TiB have been written/read. The lockup was observed when running this database backup on large filesystems (64 TiB in this case) with a high number of block groups and no free space. Fragmentation is generally not a factor in this filesystem (~thousands of large files, mostly contiguous except for the parts written while the filesystem is at capacity.) Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luís Henriques authored
commit 29a5b8a1 upstream. When walking through an inode extents, the ext4_ext_binsearch_idx() function assumes that the extent header has been previously validated. However, there are no checks that verify that the number of entries (eh->eh_entries) is non-zero when depth is > 0. And this will lead to problems because the EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this: [ 135.245946] ------------[ cut here ]------------ [ 135.247579] kernel BUG at fs/ext4/extents.c:2258! [ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4 [ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 [ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0 [ 135.256475] Code: [ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246 [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023 [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c [ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024 [ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000 [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0 [ 135.277952] Call Trace: [ 135.278635] <TASK> [ 135.279247] ? preempt_count_add+0x6d/0xa0 [ 135.280358] ? percpu_counter_add_batch+0x55/0xb0 [ 135.281612] ? _raw_read_unlock+0x18/0x30 [ 135.282704] ext4_map_blocks+0x294/0x5a0 [ 135.283745] ? xa_load+0x6f/0xa0 [ 135.284562] ext4_mpage_readpages+0x3d6/0x770 [ 135.285646] read_pages+0x67/0x1d0 [ 135.286492] ? folio_add_lru+0x51/0x80 [ 135.287441] page_cache_ra_unbounded+0x124/0x170 [ 135.288510] filemap_get_pages+0x23d/0x5a0 [ 135.289457] ? path_openat+0xa72/0xdd0 [ 135.290332] filemap_read+0xbf/0x300 [ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40 [ 135.292192] new_sync_read+0x103/0x170 [ 135.293014] vfs_read+0x15d/0x180 [ 135.293745] ksys_read+0xa1/0xe0 [ 135.294461] do_syscall_64+0x3c/0x80 [ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0 This patch simply adds an extra check in __ext4_ext_check(), verifying that eh_entries is not 0 when eh_depth is > 0. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215941 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216283 Cc: Baokun Li <libaokun1@huawei.com> Cc: stable@kernel.org Signed-off-by: Luís Henriques <lhenriques@suse.de> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Baokun Li <libaokun1@huawei.com> Link: https://lore.kernel.org/r/20220822094235.2690-1-lhenriques@suse.de Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Williams authored
commit 67feaba4 upstream. The "hmem" platform-devices that are created to represent the platform-advertised "Soft Reserved" memory ranges end up inserting a resource that causes the iomem_resource tree to look like this: 340000000-43fffffff : hmem.0 340000000-43fffffff : Soft Reserved 340000000-43fffffff : dax0.0 This is because insert_resource() reparents ranges when they completely intersect an existing range. This matters because code that uses region_intersects() to scan for a given IORES_DESC will only check that top-level 'hmem.0' resource and not the 'Soft Reserved' descendant. So, to support EINJ (via einj_error_inject()) to inject errors into memory hosted by a dax-device, be sure to describe the memory as IORES_DESC_SOFT_RESERVED. This is a follow-on to: commit b13a3e5f ("ACPI: APEI: Fix _EINJ vs EFI_MEMORY_SP") ...that fixed EINJ support for "Soft Reserved" ranges in the first instance. Fixes: 262b45ae ("x86/efi: EFI soft reservation to E820 enumeration") Reported-by: Ricardo Sandoval Torres <ricardo.sandoval.torres@intel.com> Tested-by: Ricardo Sandoval Torres <ricardo.sandoval.torres@intel.com> Cc: <stable@vger.kernel.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Omar Avelar <omar.avelar@intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Mark Gross <markgross@kernel.org> Link: https://lore.kernel.org/r/166397075670.389916.7435722208896316387.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nick Desaulniers authored
[ Upstream commit 32ef9e50 ] Alexey reported that the fraction of unknown filename instances in kallsyms grew from ~0.3% to ~10% recently; Bill and Greg tracked it down to assembler defined symbols, which regressed as a result of: commit b8a90923 ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") In that commit, I allude to restoring debug info for assembler defined symbols in a follow up patch, but it seems I forgot to do so in commit a66049e2 ("Kbuild: make DWARF version a choice") Link: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=31bf18645d98b4d3d7357353be840e320649a67d Fixes: b8a90923 ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") Reported-by: Alexey Alexandrov <aalexand@google.com> Reported-by: Bill Wendling <morbo@google.com> Reported-by: Greg Thelen <gthelen@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Nick Desaulniers authored
[ Upstream commit 61f2b7c7 ] Dmitrii, Fangrui, and Mashahiro note: Before GCC 11 and Clang 12 -gsplit-dwarf implicitly uses -g2. Fix CONFIG_DEBUG_INFO_SPLIT for gcc-11+ & clang-12+ which now need -g specified in order for -gsplit-dwarf to work at all. -gsplit-dwarf has been mutually exclusive with -g since support for CONFIG_DEBUG_INFO_SPLIT was introduced in commit 866ced95 ("kbuild: Support split debug info v4") I don't think it ever needed to be. Link: https://lore.kernel.org/lkml/20220815013317.26121-1-dmitrii.bundin.a@gmail.com/ Link: https://lore.kernel.org/lkml/CAK7LNARPAmsJD5XKAw7m_X2g7Fi-CAAsWDQiP7+ANBjkg7R7ng@mail.gmail.com/ Link: https://reviews.llvm.org/D80391 Cc: Andi Kleen <ak@linux.intel.com> Reported-by: Dmitrii Bundin <dmitrii.bundin.a@gmail.com> Reported-by: Fangrui Song <maskray@google.com> Reported-by: Masahiro Yamada <masahiroy@kernel.org> Suggested-by: Dmitrii Bundin <dmitrii.bundin.a@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: 32ef9e50 ("Makefile.debug: re-enable debug info for .S files") Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Masahiro Yamada authored
[ Upstream commit 2154aca2 ] Commit e9088629 ("certs: make system keyring depend on x509 parser") is not the right fix because x509_load_certificate_list() can be modular. The combination of CONFIG_SYSTEM_TRUSTED_KEYRING=y and CONFIG_X509_CERTIFICATE_PARSER=m still results in the following error: LD .tmp_vmlinux.kallsyms1 ld: certs/system_keyring.o: in function `load_system_certificate_list': system_keyring.c:(.init.text+0x8c): undefined reference to `x509_load_certificate_list' make: *** [Makefile:1169: vmlinux] Error 1 Fixes: e9088629 ("certs: make system keyring depend on x509 parser") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Alex Deucher authored
[ Upstream commit abbc7a3d ] Some asics still support non-atomic code paths. Fixes: 66f99628 ("drm/amdgpu: use dirty framebuffer helper") Reported-by: Arthur Marsh <arthur.marsh@internode.on.net> Reviewed-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Dan Carpenter authored
[ Upstream commit b7af938f ] A couple years back we went through the kernel an automatically converted size calculations to use struct_size() instead. The struct_size() calculation is protected against integer overflows. However it does not make sense to use the result from struct_size() for additional math operations as that would negate any safeness. Fixes: 1f3b69b6 ("i2c: mux: Use struct_size() in devm_kzalloc()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Peter Rosin <peda@axentia.se> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Asmaa Mnebhi authored
[ Upstream commit 37f071ec ] The i2c-mlxbf.c driver is currently broken because there is a bug in the calculation of the frequency. core_f, core_r and core_od are components read from hardware registers and are used to compute the frequency used to compute different timing parameters. The shifting mechanism used to get core_f, core_r and core_od is wrong. Use FIELD_GET to mask and shift the bitfields properly. Fixes: b5b5b320 (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC) Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com> Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-