Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Kernel: Merge Linux 6.6.63 Update #4

Closed
wants to merge 946 commits into from
Closed

Kernel: Merge Linux 6.6.63 Update #4

wants to merge 946 commits into from

Conversation

qaz6750
Copy link
Owner

@qaz6750 qaz6750 commented Nov 30, 2024

No description provided.

geertu and others added 30 commits November 14, 2024 13:19
@geertu @gregkh
arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-…
771bd4d 
…excavator

[ Upstream commit 577b576 ]

There are no DT bindings and driver support for a "rockchip,rt5651"
codec.  Replace "rockchip,rt5651" by "realtek,rt5651", which matches the
"simple-audio-card,name" property in the "rt5651-sound" node.

Fixes: 0a3c78e ("arm64: dts: rockchip: Add support for rk3399 excavator main board")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/abc6c89811b3911785601d6d590483eacb145102.1727358193.git.geert+renesas@glider.be
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@diederikdehaas @gregkh
arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328
f1da910 
[ Upstream commit de50a7e ]

The "synopsys,dw-hdmi.yaml" binding specifies that the interrupts
property of the hdmi node has 'maxItems: 1', so the hdmi node in
rk3328.dtsi having 2 is incorrect.

Paragraph 1.3 ("System Interrupt connection") of the RK3328 TRM v1.1
page 16 and 17 define the following hdmi related interrupts:
-  67 hdmi_intr
- 103 hdmi_intr_wakeup

The difference of 32 is due to a different base used in the TRM.

The RK3399 (which uses the same binding) has '23: hdmi_irq' and
'24: hdmi_wakeup_irq' according to its TRM (page 19).
The RK3568 (also same binding) has '76: hdmi_wakeup' and '77: hdmi'
according to page 17 of its TRM.
In both cases the non-wakeup IRQ was used, so use that too for rk3328.

Helped-by: Heiko Stuebner <heiko@sntech.de>
Fixes: 725e351 ("arm64: dts: rockchip: add rk3328 display nodes")
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20241008113344.23957-3-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@diederikdehaas @gregkh
arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node
4d580a5 
[ Upstream commit 87299d6 ]

The "brcm,bluetooth.yaml" binding has 'device-wakeup-gpios' and
'host-wakeup-gpios' property names, not '*-wake-gpios'.
Fix the incorrect property names.

Note that the "realtek,bluetooth.yaml" binding does use the
'*-wake-gpios' property names.

Fixes: d449121 ("arm64: dts: rockchip: Add Pine64 PineNote board")
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20241008113344.23957-4-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@diederikdehaas @gregkh
arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes
08e7938 
[ Upstream commit 2b6a3f8 ]

For most compatibles, the "brcm,bluetooth.yaml" binding doesn't allow
the 'reset-gpios' property, but there is a 'shutdown-gpios' property.

Page 12 of the AzureWave-CM256SM datasheet (v1.9) has the following wrt
pin 34 'BT_REG_ON' (connected to GPIO0_C4_d on the PineNote):

  Used by PMU to power up or power down the internal regulators used
  by the Bluetooth section. Also, when deasserted, this pin holds the
  Bluetooth section in reset. This pin has an internal 200k ohm pull
  down resistor that is enabled by default.

So it is safe to replace 'reset-gpios' with 'shutdown-gpios'.

Fixes: d449121 ("arm64: dts: rockchip: Add Pine64 PineNote board")
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20241008113344.23957-5-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg3…
54d80a6 
…53p/v

[ Upstream commit f94b934 ]

We want to control pins, not beer mugs, so rename pintctrl-names to the
expected pinctrl-names.

This was not affecting functionality, because the i2c2 controller
already had a set of pinctrl properties.

Fixes: 523adb5 ("arm64: dts: rockchip: add Anbernic RG353P and RG503")
Fixes: 1e141cf ("arm64: dts: rockchip: add Anbernic RG353V and RG353VS")
Cc: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-2-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo
55907bd 
[ Upstream commit 2fa98dc ]

The expected clock-name is different, and extclk also is deprecated
in favor of txco for clocks that are not crystals.

The wakeup gpio properties are named differently too, when changing
from vendor-tree to mainline. So fix those to match the binding.

Fixes: 2e0537b ("arm64: dts: rockchip: Add dts for rockchip rk3566 box demo board")
Cc: Andy Yan <andyshrk@163.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-4-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards
87759aa 
[ Upstream commit ea74528 ]

The expected clock-name is different, and extclk also is deprecated
in favor of txco for clocks that are not crystals.

So fix it to match the binding.

Fixes: c72235c ("arm64: dts: rockchip: Add on-board WiFi/BT support for Rock960 boards")
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-5-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@jin-eld @gregkh
arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus
d0a08ab 
[ Upstream commit b8c0287 ]

The R2S Plus is basically an R2S with additional eMMC.

The eMMC configuration for the DTS has been extracted and copied from
rk3328-nanopi-r2.dts, v2017.09 branch from the friendlyarm/uboot-rockchip
repository.

Signed-off-by: Sergey Bostandzhyan <jin@mediatomb.cc>
Link: https://lore.kernel.org/r/20240814170048.23816-2-jin@mediatomb.cc
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Stable-dep-of: 1b67021 ("arm64: dts: rockchip: Remove undocumented supports-emmc property")
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
arm64: dts: rockchip: Remove undocumented supports-emmc property
d09940e 
[ Upstream commit 1b67021 ]

supports-emmc is an undocumented property that slipped into the mainline
kernel devicetree for some boards. Drop it.

Fixes: c484cf9 ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard")
Cc: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Fixes: b8c0287 ("arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus")
Cc: Sergey Bostandzhyan <jin@mediatomb.cc>
Fixes: 8d94da5 ("arm64: dts: rockchip: Add EmbedFire LubanCat 1")
Cc: Wenhao Cui <lasstp5011@gmail.com>
Fixes: cdf46cd ("arm64: dts: rockchip: Add dts for EmbedFire rk3568 LubanCat 2")
Cc: Andy Yan <andyshrk@163.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-6-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion
d0beaf4 
[ Upstream commit 5ed9658 ]

All Theobroma boards use a ti,amc6821 as fan controller.
It normally runs in an automatically controlled way and while it may be
possible to use it as part of a dt-based thermal management, this is
not yet specified in the binding, nor implemented in any kernel.

Newer boards already don't contain that #cooling-cells property, but
older ones do. So remove them for now, they can be re-added if thermal
integration gets implemented in the future.

There are two further occurences in v6.12-rc in px30-ringneck and
rk3399-puma, but those already get removed by the i2c-mux conversion
scheduled for 6.13 . As the undocumented property is in the kernel so
long, I opted for not causing extra merge conflicts between 6.12 and 6.13

Fixes: d99a02b ("arm64: dts: rockchip: add RK3368-uQ7 (Lion) SoM")
Cc: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-7-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc
e243514 
[ Upstream commit 3a53a71 ]

There are two LEDs on the board, power and user events.
Currently both are assigned undocumented IR(-remote)
triggers that are probably only part of the vendor-kernel.

To make dtbs check happier, assign the power-led to a generic
default-on trigger and the user led to the documented rc-feedback
trigger that should mostly match its current usage.

Fixes: 4403e12 ("arm64: dts: rockchip: Add devicetree for board roc-rk3308-cc")
Cc: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-8-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2…
f8181c5 
…s-plus

[ Upstream commit b1f8d3b ]

num-slots was not part of the dw-mmc binding and the last slipage of
one of them seeping in from the vendor kernel was removed way back in
2017. Somehow the nanopi-r2s-plus managed to smuggle another on in the
kernel, so remove that as well.

Fixes: b8c0287 ("arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus")
Cc: Sergey Bostandzhyan <jin@mediatomb.cc>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-9-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@tq-steina @gregkh
arm64: dts: imx8qxp: Add VPU subsystem file
ad0a938 
[ Upstream commit 6bcd8b2 ]

imx8qxp re-uses imx8qm VPU subsystem file, but it has different base
addresses. Also imx8qxp has only two VPU cores, delete vpu_vore2 and
mu2_m0 accordingly.

Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Stable-dep-of: eed2d8e ("arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs")
Signed-off-by: Sasha Levin <sashal@kernel.org>
@tq-steina @gregkh
arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs
5cfe961 
[ Upstream commit eed2d8e ]

imx8-ss-vpu only contained imx8qxp IRQ numbers, only mu2_m0 uses the
correct imx8qm IRQ number, as imx8qxp lacks this MU.
Fix this by providing imx8qm IRQ numbers in the main imx8-ss-vpu.dtsi
and override the IRQ numbers in SoC-specific imx8qxp-ss-vpu.dtsi, similar
to reg property for VPU core devices.

Fixes: 0d9968d ("arm64: dts: freescale: imx8q: add imx vpu codec entries")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@MrVan @gregkh
arm64: dts: imx8mp: correct sdhc ipg clk
8106155 
[ Upstream commit eab6ba2 ]

The ipg clk for sdhc sources from IPG_CLK_ROOT per i.MX 8M Plus
Applications Processor Reference Manual, Table 5-2. System Clocks.

Fixes: 6d9b8d2 ("arm64: dts: freescale: Add i.MX8MP dtsi support")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@gregkh
firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()
15b17bb 
[ Upstream commit 2954160 ]

The scmi_dev->name is released prematurely in __scmi_device_destroy(),
which causes slab-use-after-free when accessing scmi_dev->name in
scmi_bus_notifier(). So move the release of scmi_dev->name to
scmi_device_release() to avoid slab-use-after-free.

  |  BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec
  |  Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1
  |
  |  CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1
  |  Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT)
  |  Call trace:
  |   dump_backtrace+0x94/0x114
  |   show_stack+0x18/0x24
  |   dump_stack_lvl+0x48/0x60
  |   print_report+0xf4/0x5b0
  |   kasan_report+0xa4/0xec
  |   __asan_report_load1_noabort+0x20/0x2c
  |   strncmp+0xe4/0xec
  |   scmi_bus_notifier+0x5c/0x54c
  |   notifier_call_chain+0xb4/0x31c
  |   blocking_notifier_call_chain+0x68/0x9c
  |   bus_notify+0x54/0x78
  |   device_del+0x1bc/0x840
  |   device_unregister+0x20/0xb4
  |   __scmi_device_destroy+0xac/0x280
  |   scmi_device_destroy+0x94/0xd0
  |   scmi_chan_setup+0x524/0x750
  |   scmi_probe+0x7fc/0x1508
  |   platform_probe+0xc4/0x19c
  |   really_probe+0x32c/0x99c
  |   __driver_probe_device+0x15c/0x3c4
  |   driver_probe_device+0x5c/0x170
  |   __driver_attach+0x1c8/0x440
  |   bus_for_each_dev+0xf4/0x178
  |   driver_attach+0x3c/0x58
  |   bus_add_driver+0x234/0x4d4
  |   driver_register+0xf4/0x3c0
  |   __platform_driver_register+0x60/0x88
  |   scmi_driver_init+0xb0/0x104
  |   do_one_initcall+0xb4/0x664
  |   kernel_init_freeable+0x3c8/0x894
  |   kernel_init+0x24/0x1e8
  |   ret_from_fork+0x10/0x20
  |
  |  Allocated by task 1:
  |   kasan_save_stack+0x2c/0x54
  |   kasan_set_track+0x2c/0x40
  |   kasan_save_alloc_info+0x24/0x34
  |   __kasan_kmalloc+0xa0/0xb8
  |   __kmalloc_node_track_caller+0x6c/0x104
  |   kstrdup+0x48/0x84
  |   kstrdup_const+0x34/0x40
  |   __scmi_device_create.part.0+0x8c/0x408
  |   scmi_device_create+0x104/0x370
  |   scmi_chan_setup+0x2a0/0x750
  |   scmi_probe+0x7fc/0x1508
  |   platform_probe+0xc4/0x19c
  |   really_probe+0x32c/0x99c
  |   __driver_probe_device+0x15c/0x3c4
  |   driver_probe_device+0x5c/0x170
  |   __driver_attach+0x1c8/0x440
  |   bus_for_each_dev+0xf4/0x178
  |   driver_attach+0x3c/0x58
  |   bus_add_driver+0x234/0x4d4
  |   driver_register+0xf4/0x3c0
  |   __platform_driver_register+0x60/0x88
  |   scmi_driver_init+0xb0/0x104
  |   do_one_initcall+0xb4/0x664
  |   kernel_init_freeable+0x3c8/0x894
  |   kernel_init+0x24/0x1e8
  |   ret_from_fork+0x10/0x20
  |
  |  Freed by task 1:
  |   kasan_save_stack+0x2c/0x54
  |   kasan_set_track+0x2c/0x40
  |   kasan_save_free_info+0x38/0x5c
  |   __kasan_slab_free+0xe8/0x164
  |   __kmem_cache_free+0x11c/0x230
  |   kfree+0x70/0x130
  |   kfree_const+0x20/0x40
  |   __scmi_device_destroy+0x70/0x280
  |   scmi_device_destroy+0x94/0xd0
  |   scmi_chan_setup+0x524/0x750
  |   scmi_probe+0x7fc/0x1508
  |   platform_probe+0xc4/0x19c
  |   really_probe+0x32c/0x99c
  |   __driver_probe_device+0x15c/0x3c4
  |   driver_probe_device+0x5c/0x170
  |   __driver_attach+0x1c8/0x440
  |   bus_for_each_dev+0xf4/0x178
  |   driver_attach+0x3c/0x58
  |   bus_add_driver+0x234/0x4d4
  |   driver_register+0xf4/0x3c0
  |   __platform_driver_register+0x60/0x88
  |   scmi_driver_init+0xb0/0x104
  |   do_one_initcall+0xb4/0x664
  |   kernel_init_freeable+0x3c8/0x894
  |   kernel_init+0x24/0x1e8
  |   ret_from_fork+0x10/0x20

Fixes: ee7a9c9 ("firmware: arm_scmi: Add support for multiple device per protocol")
Signed-off-by: Xinqi Zhang <quic_xinqzhan@quicinc.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Message-Id: <20241016-fix-arm-scmi-slab-use-after-free-v2-1-1783685ef90d@quicinc.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro
6900713 
[ Upstream commit 3577d5e ]

The patch adding display support for the pinephone pro introduced two
regulators that contain pinctrl-names props but no pinctrl-assignments.

Looks like someone forgot the pinctrl settings, so remove the orphans
for now, until that changes.

Fixes: 3e987e1 ("arm64: dts: rockchip: Add internal display support to rk3399-pinephone-pro")
Cc: Martijn Braam <martijn@brixit.nl>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Ondrej Jirman <megi@xff.cz>
Reviewed-by: Ondrej Jirman <megi@xff.cz>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-11-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
ARM: dts: rockchip: fix rk3036 acodec node
f3d09c2 
[ Upstream commit c720685 ]

The acodec node is not conformant to the binding.

Set the correct nodename, use the correct compatible, add the needed
#sound-dai-cells and sort the rockchip,grf below clocks properties
as expected.

Fixes: faea098 ("ARM: dts: rockchip: add core rk3036 dtsi")
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-12-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
ARM: dts: rockchip: drop grf reference from rk3036 hdmi
0f4e827 
[ Upstream commit 1580ccb ]

Neither the binding nor the driver implementation specify/use the grf
reference provided in the rk3036. And neither does the newer rk3128
user of the hdmi controller. So drop the rockchip,grf property.

Fixes: b7217cf ("ARM: dts: rockchip: add hdmi device node for rk3036")
Cc: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-13-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
ARM: dts: rockchip: Fix the spi controller on rk3036
1a22d37 
[ Upstream commit 8bade1a ]

Compatible and clock names did not match the existing binding.
So set the correct values and re-order+rename the clocks.

It looks like no rk3036 board did use the spi controller so far,
so this was never detected on a running device yet.

Fixes: f629fcf ("ARM: dts: rockchip: support the spi for rk3036")
Cc: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-14-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@mmind @gregkh
ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin
9510652 
[ Upstream commit 77a9a7f ]

Both the node name as well as the compatible were not named
according to the binding expectations, fix that.

Fixes: 47bf3a5 ("ARM: dts: rockchip: add the sound setup for rk3036-kylin board")
Cc: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-15-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@diederikdehaas @gregkh
arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes
24a7ac9 
[ Upstream commit 0884652 ]

Paragraph "3.4 Power up Timing Sequence" of the AzureWave-CM256SM
datasheet mentions the following about the BT_REG_ON pin, which is
connected to GPIO0_C4_d:

  When this pin is low and WL_REG_ON is high,
  the BT section is in reset.

Therefor set that pin to GPIO_ACTIVE_HIGH so that it can be pulled low
for a reset.
If set to GPIO_ACTIVE_LOW, the following errors are observed:

  Bluetooth: hci0: command 0x0c03 tx timeout
  Bluetooth: hci0: BCM: Reset failed (-110)

So fix the GPIO polarity by setting it to ACTIVE_HIGH.
This also matches what other devices with the same BT device have.

Fixes: 2b6a3f8 ("arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes")
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20241018145053.11928-2-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@gregkh
HID: core: zero-initialize the report buffer
9d9f5c7 
[ Upstream commit 177f25d ]

Since the report buffer is used by all kinds of drivers in various ways, let's
zero-initialize it during allocation to make sure that it can't be ever used
to leak kernel memory via specially-crafted report.

Fixes: 27ce405 ("HID: fix data access in implement()")
Reported-by: Benoît Sevens <bsevens@google.com>
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@bugfood @gregkh
platform/x86/amd/pmc: Detect when STB is not available
7a3ed3f 
[ Upstream commit bceec87 ]

Loading the amd_pmc module as:

    amd_pmc enable_stb=1

...can result in the following messages in the kernel ring buffer:

    amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff
    ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff
    WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340

Further debugging reveals that this occurs when the requests for
S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0,
indicating that the STB is inaccessible. To prevent the ioremap
warning and provide clarity to the user, handle the invalid address
and display an error message.

Link: https://lore.kernel.org/platform-driver-x86/c588ff5d-3e04-4549-9a86-284b9b4419ba@amd.com
Fixes: 3d7d407 ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature")
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Corey Hickey <bugfood-c@fatooh.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20241028180241.1341624-1-bugfood-ml@fatooh.org
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@neilbrown @gregkh
sunrpc: handle -ENOTCONN in xs_tcp_setup_socket()
d428de9 
[ Upstream commit 10f0740 ]

xs_tcp_finish_connecting() can return -ENOTCONN but the switch statement
in xs_tcp_setup_socket() treats that as an unhandled error.

If we treat it as a known error it would propagate back to
call_connect_status() which does handle that error code.  This appears
to be the intention of the commit (given below) which added -ENOTCONN as
a return status for xs_tcp_finish_connecting().

So add -ENOTCONN to the switch statement as an error to pass through to
the caller.

Link: https://bugzilla.suse.com/show_bug.cgi?id=1231050
Link: https://access.redhat.com/discussions/3434091
Fixes: 01d37c4 ("SUNRPC: xprt_connect() don't abort the task if the transport isn't bound")
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@neilbrown @gregkh
NFSv3: only use NFS timeout for MOUNT when protocols are compatible
351f033 
[ Upstream commit 6e2a103 ]

If a timeout is specified in the mount options, it currently applies to
both the NFS protocol and (with v3) the MOUNT protocol.  This is
sensible when they both use the same underlying protocol, or those
protocols are compatible w.r.t timeouts as RDMA and TCP are.

However if, for example, NFS is using TCP and MOUNT is using UDP then
using the same timeout doesn't make much sense.

If you
   mount -o vers=3,proto=tcp,mountproto=udp,timeo=600,retrans=5 \
      server:/path /mountpoint

then the timeo=600 which was intended for the NFS/TCP request will
apply to the MOUNT/UDP requests with the result that there will only be
one request sent (because UDP has a maximum timeout of 60 seconds).
This is not what a reasonable person might expect.

This patch disables the sharing of timeout information in cases where
the underlying protocols are not compatible.

Fixes: c9301cb ("nfs: hornor timeo and retrans option when mounting NFSv3")
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@gregkh
nfs: avoid i_lock contention in nfs_clear_invalid_mapping
6173b0b 
[ Upstream commit 867da60 ]

Multi-threaded buffered reads to the same file exposed significant
inode spinlock contention in nfs_clear_invalid_mapping().

Eliminate this spinlock contention by checking flags without locking,
instead using smp_rmb and smp_load_acquire accordingly, but then take
spinlock and double-check these inode flags.

Also refactor nfs_set_cache_invalid() slightly to use
smp_store_release() to pair with nfs_clear_invalid_mapping()'s
smp_load_acquire().

While this fix is beneficial for all multi-threaded buffered reads
issued by an NFS client, this issue was identified in the context of
surprisingly low LOCALIO performance with 4K multi-threaded buffered
read IO.  This fix dramatically speeds up LOCALIO performance:

before: read: IOPS=1583k, BW=6182MiB/s (6482MB/s)(121GiB/20002msec)
after:  read: IOPS=3046k, BW=11.6GiB/s (12.5GB/s)(232GiB/20001msec)

Fixes: 17dfeb9 ("NFS: Fix races in nfs_revalidate_mapping")
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@gregkh
security/keys: fix slab-out-of-bounds in key_task_permission
3e79ad1 
[ Upstream commit 4a74da0 ]

KASAN reports an out of bounds read:
BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36
BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]
BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410
security/keys/permission.c:54
Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362

CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15
Call Trace:
 __dump_stack lib/dump_stack.c:82 [inline]
 dump_stack+0x107/0x167 lib/dump_stack.c:123
 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400
 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560
 kasan_report+0x3a/0x50 mm/kasan/report.c:585
 __kuid_val include/linux/uidgid.h:36 [inline]
 uid_eq include/linux/uidgid.h:63 [inline]
 key_task_permission+0x394/0x410 security/keys/permission.c:54
 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793

This issue was also reported by syzbot.

It can be reproduced by following these steps(more details [1]):
1. Obtain more than 32 inputs that have similar hashes, which ends with the
   pattern '0xxxxxxxe6'.
2. Reboot and add the keys obtained in step 1.

The reproducer demonstrates how this issue happened:
1. In the search_nested_keyrings function, when it iterates through the
   slots in a node(below tag ascend_to_node), if the slot pointer is meta
   and node->back_pointer != NULL(it means a root), it will proceed to
   descend_to_node. However, there is an exception. If node is the root,
   and one of the slots points to a shortcut, it will be treated as a
   keyring.
2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.
   However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as
   ASSOC_ARRAY_PTR_SUBTYPE_MASK.
3. When 32 keys with the similar hashes are added to the tree, the ROOT
   has keys with hashes that are not similar (e.g. slot 0) and it splits
   NODE A without using a shortcut. When NODE A is filled with keys that
   all hashes are xxe6, the keys are similar, NODE A will split with a
   shortcut. Finally, it forms the tree as shown below, where slot 6 points
   to a shortcut.

                      NODE A
              +------>+---+
      ROOT    |       | 0 | xxe6
      +---+   |       +---+
 xxxx | 0 | shortcut  :   : xxe6
      +---+   |       +---+
 xxe6 :   :   |       |   | xxe6
      +---+   |       +---+
      | 6 |---+       :   : xxe6
      +---+           +---+
 xxe6 :   :           | f | xxe6
      +---+           +---+
 xxe6 | f |
      +---+

4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,
   it may be mistakenly transferred to a key*, leading to a read
   out-of-bounds read.

To fix this issue, one should jump to descend_to_node if the ptr is a
shortcut, regardless of whether the node is root or not.

[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/

[jarkko: tweaked the commit message a bit to have an appropriate closes
 tag.]
Fixes: b2a4df2 ("KEYS: Expand the capacity of a keyring")
Reported-by: syzbot+5b415c07907a2990d1a3@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/
Signed-off-by: Chen Ridong <chenridong@huawei.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@gregkh
regulator: rtq2208: Fix uninitialized use of regulator_config
9b7c040 
[ Upstream commit 2feb023 ]

Fix rtq2208 driver uninitialized use to cause kernel error.

Fixes: 85a11f5 ("regulator: rtq2208: Add Richtek RTQ2208 SubPMIC")
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://patch.msgid.link/00d691cfcc0eae9ce80a37b62e99851e8fdcffe2.1729829243.git.cy_huang@richtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@gregkh
net: enetc: set MAC address to the VF net_device
d4c52c6 
[ Upstream commit badccd4 ]

The MAC address of VF can be configured through the mailbox mechanism of
ENETC, but the previous implementation forgot to set the MAC address in
net_device, resulting in the SMAC of the sent frames still being the old
MAC address. Since the MAC address in the hardware has been changed, Rx
cannot receive frames with the DMAC address as the new MAC address. The
most obvious phenomenon is that after changing the MAC address, we can
see that the MAC address of eno0vf0 has not changed through the "ifconfig
eno0vf0" command and the IP address cannot be obtained .

root@ls1028ardb:~# ifconfig eno0vf0 down
root@ls1028ardb:~# ifconfig eno0vf0 hw ether 00:04:9f:3a:4d:56 up
root@ls1028ardb:~# ifconfig eno0vf0
eno0vf0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 66:36:2c:3b:87:76  txqueuelen 1000  (Ethernet)
        RX packets 794  bytes 69239 (69.2 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11  bytes 2226 (2.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Fixes: beb74ac ("enetc: Add vf to pf messaging support")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Link: https://patch.msgid.link/20241029090406.841836-1-wei.fang@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mchehab and others added 24 commits November 22, 2024 15:38
@mchehab @gregkh
media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set
db12e87 
commit a4aebaf upstream.

When CONFIG_DVB_DYNAMIC_MINORS, ret is not initialized, and a
semaphore is left at the wrong state, in case of errors.

Make the code simpler and avoid mistakes by having just one error
check logic used weather DVB_DYNAMIC_MINORS is used or not.

Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202410201717.ULWWdJv8-lkp@intel.com/
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/9e067488d8935b8cf00959764a1fa5de85d65725.1730926254.git.mchehab+huawei@kernel.org
Cc: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@daimngo @gregkh
NFSD: initialize copy->cp_clp early in nfsd4_copy for use by trace point
74115b3 
[ Upstream commit 15d1975 ]

Prepare for adding server copy trace points.

Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
Tested-by: Chen Hanxiao <chenhx.fnst@fujitsu.com>
Stable-dep-of: 9ed666e ("NFSD: Async COPY result needs to return a write verifier")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@chucklever @gregkh
NFSD: Async COPY result needs to return a write verifier
20a10c7 
[ Upstream commit 9ed666e ]

Currently, when NFSD handles an asynchronous COPY, it returns a
zero write verifier, relying on the subsequent CB_OFFLOAD callback
to pass the write verifier and a stable_how4 value to the client.

However, if the CB_OFFLOAD never arrives at the client (for example,
if a network partition occurs just as the server sends the
CB_OFFLOAD operation), the client will never receive this verifier.
Thus, if the client sends a follow-up COMMIT, there is no way for
the client to assess the COMMIT result.

The usual recovery for a missing CB_OFFLOAD is for the client to
send an OFFLOAD_STATUS operation, but that operation does not carry
a write verifier in its result. Neither does it carry a stable_how4
value, so the client /must/ send a COMMIT in this case -- which will
always fail because currently there's still no write verifier in the
COPY result.

Thus the server needs to return a normal write verifier in its COPY
result even if the COPY operation is to be performed asynchronously.

If the server recognizes the callback stateid in subsequent
OFFLOAD_STATUS operations, then obviously it has not restarted, and
the write verifier the client received in the COPY result is still
valid and can be used to assess a COMMIT of the copied data, if one
is needed.

Reviewed-by: Jeff Layton <jlayton@kernel.org>
[ cel: adjusted to apply to origin/linux-6.6.y ]
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@chucklever @gregkh
NFSD: Limit the number of concurrent async COPY operations
ae26798 
[ Upstream commit aadc3bb ]

Nothing appears to limit the number of concurrent async COPY
operations that clients can start. In addition, AFAICT each async
COPY can copy an unlimited number of 4MB chunks, so can run for a
long time. Thus IMO async COPY can become a DoS vector.

Add a restriction mechanism that bounds the number of concurrent
background COPY operations. Start simple and try to be fair -- this
patch implements a per-namespace limit.

An async COPY request that occurs while this limit is exceeded gets
NFS4ERR_DELAY. The requesting client can choose to send the request
again after a delay or fall back to a traditional read/write style
copy.

If there is need to make the mechanism more sophisticated, we can
visit that in future patches.

Cc: stable@vger.kernel.org
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Link: https://nvd.nist.gov/vuln/detail/CVE-2024-49974
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@chucklever @gregkh
NFSD: Initialize struct nfsd4_copy earlier
421f1a2 
[ Upstream commit 63fab04 ]

Ensure the refcount and async_copies fields are initialized early.
cleanup_async_copy() will reference these fields if an error occurs
in nfsd4_copy(). If they are not correctly initialized, at the very
least, a refcount underflow occurs.

Reported-by: Olga Kornievskaia <okorniev@redhat.com>
Fixes: aadc3bb ("NFSD: Limit the number of concurrent async COPY operations")
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Tested-by: Olga Kornievskaia <okorniev@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@chucklever @gregkh
NFSD: Never decrement pending_async_copies on error
fb79d68 
[ Upstream commit 8286f8b ]

The error flow in nfsd4_copy() calls cleanup_async_copy(), which
already decrements nn->pending_async_copies.

Reported-by: Olga Kornievskaia <okorniev@redhat.com>
Fixes: aadc3bb ("NFSD: Limit the number of concurrent async COPY operations")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@geliangtang @gregkh
mptcp: define more local variables sk
762ca2d 
commit 14cb0e0 upstream.

'(struct sock *)msk' is used several times in mptcp_nl_cmd_announce(),
mptcp_nl_cmd_remove() or mptcp_userspace_pm_set_flags() in pm_userspace.c,
it's worth adding a local variable sk to point it.

Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231025-send-net-next-20231025-v1-8-db8f25f798eb@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stable-dep-of: 06afe09 ("mptcp: add userspace_pm_lookup_addr_by_id helper")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@gregkh
mptcp: add userspace_pm_lookup_addr_by_id helper
aa2b28d 
commit 06afe09 upstream.

Corresponding __lookup_addr_by_id() helper in the in-kernel netlink PM,
this patch adds a new helper mptcp_userspace_pm_lookup_addr_by_id() to
lookup the address entry with the given id on the userspace pm local
address list.

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Stable-dep-of: f642c5c ("mptcp: hold pm lock when deleting entry")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@gregkh
mptcp: update local address flags when setting it
ac56c5e 
commit e026631 upstream.

Just like in-kernel pm, when userspace pm does set_flags, it needs to send
out MP_PRIO signal, and also modify the flags of the corresponding address
entry in the local address list. This patch implements the missing logic.

Traverse all address entries on userspace_pm_local_addr_list to find the
local address entry, if bkup is true, set the flags of this entry with
FLAG_BACKUP, otherwise, clear FLAG_BACKUP.

Fixes: 892f396 ("mptcp: netlink: issue MP_PRIO signals from userspace PMs")
Cc: stable@vger.kernel.org
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20241112-net-mptcp-misc-6-12-pm-v1-1-b835580cefa8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ Conflicts in pm_userspace.c, because commit 6a42477 ("mptcp:
  update set_flags interfaces"), is not in this version, and causes too
  many conflicts when backporting it. The same code can still be added
  at the same place, before sending the ACK. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@gregkh
mptcp: hold pm lock when deleting entry
416001b 
commit f642c5c upstream.

When traversing userspace_pm_local_addr_list and deleting an entry from
it in mptcp_pm_nl_remove_doit(), msk->pm.lock should be held.

This patch holds this lock before mptcp_userspace_pm_lookup_addr_by_id()
and releases it after list_move() in mptcp_pm_nl_remove_doit().

Fixes: d9a4594 ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
Cc: stable@vger.kernel.org
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20241112-net-mptcp-misc-6-12-pm-v1-2-b835580cefa8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@gregkh
mptcp: drop lookup_by_id in lookup_addr
fc3c732 
commit af250c2 upstream.

When the lookup_by_id parameter of __lookup_addr() is true, it's the same
as __lookup_addr_by_id(), it can be replaced by __lookup_addr_by_id()
directly. So drop this parameter, let __lookup_addr() only looks up address
on the local address list by comparing addresses in it, not address ids.

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://lore.kernel.org/r/20240305-upstream-net-next-20240304-mptcp-misc-cleanup-v1-4-c436ba5e569b@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stable-dep-of: db3eab8 ("mptcp: pm: use _rcu variant under rcu_read_lock")
[ Conflicts in pm_netlink.c, because commit 6a42477 ("mptcp: update
  set_flags interfaces") is not in this version, and causes too many
  conflicts when backporting it. The conflict is easy to resolve: addr
  is a pointer here here in mptcp_pm_nl_set_flags(), the rest of the
  code is the same. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@matttbe @gregkh
mptcp: pm: use _rcu variant under rcu_read_lock
3bc4569 
commit db3eab8 upstream.

In mptcp_pm_create_subflow_or_signal_addr(), rcu_read_(un)lock() are
used as expected to iterate over the list of local addresses, but
list_for_each_entry() was used instead of list_for_each_entry_rcu() in
__lookup_addr(). It is important to use this variant which adds the
required READ_ONCE() (and diagnostic checks if enabled).

Because __lookup_addr() is also used in mptcp_pm_nl_set_flags() where it
is called under the pernet->lock and not rcu_read_lock(), an extra
condition is then passed to help the diagnostic checks making sure
either the associated spin lock or the RCU lock is held.

Fixes: 86e39e0 ("mptcp: keep track of local endpoint still available for each msk")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20241112-net-mptcp-misc-6-12-pm-v1-3-b835580cefa8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@gregkh
drm/amd/pm: Vangogh: Fix kernel memory out of bounds write
f111de0 
commit 4aa923a upstream.

KASAN reports that the GPU metrics table allocated in
vangogh_tables_init() is not large enough for the memset done in
smu_cmn_init_soft_gpu_metrics(). Condensed report follows:

[   33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu]
[   33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067
...
[   33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G        W          6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544
[   33.861816] Tainted: [W]=WARN
[   33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023
[   33.861822] Call Trace:
[   33.861826]  <TASK>
[   33.861829]  dump_stack_lvl+0x66/0x90
[   33.861838]  print_report+0xce/0x620
[   33.861853]  kasan_report+0xda/0x110
[   33.862794]  kasan_check_range+0xfd/0x1a0
[   33.862799]  __asan_memset+0x23/0x40
[   33.862803]  smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.863306]  vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.864257]  vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.865682]  amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.866160]  amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.867135]  dev_attr_show+0x43/0xc0
[   33.867147]  sysfs_kf_seq_show+0x1f1/0x3b0
[   33.867155]  seq_read_iter+0x3f8/0x1140
[   33.867173]  vfs_read+0x76c/0xc50
[   33.867198]  ksys_read+0xfb/0x1d0
[   33.867214]  do_syscall_64+0x90/0x160
...
[   33.867353] Allocated by task 378 on cpu 7 at 22.794876s:
[   33.867358]  kasan_save_stack+0x33/0x50
[   33.867364]  kasan_save_track+0x17/0x60
[   33.867367]  __kasan_kmalloc+0x87/0x90
[   33.867371]  vangogh_init_smc_tables+0x3f9/0x840 [amdgpu]
[   33.867835]  smu_sw_init+0xa32/0x1850 [amdgpu]
[   33.868299]  amdgpu_device_init+0x467b/0x8d90 [amdgpu]
[   33.868733]  amdgpu_driver_load_kms+0x19/0xf0 [amdgpu]
[   33.869167]  amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu]
[   33.869608]  local_pci_probe+0xda/0x180
[   33.869614]  pci_device_probe+0x43f/0x6b0

Empirically we can confirm that the former allocates 152 bytes for the
table, while the latter memsets the 168 large block.

Root cause appears that when GPU metrics tables for v2_4 parts were added
it was not considered to enlarge the table to fit.

The fix in this patch is rather "brute force" and perhaps later should be
done in a smarter way, by extracting and consolidating the part version to
size logic to a common helper, instead of brute forcing the largest
possible allocation. Nevertheless, for now this works and fixes the out of
bounds write.

v2:
 * Drop impossible v3_0 case. (Mario)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Fixes: 41cec40 ("drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to acquire gpu_metrics")
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Evan Quan <evan.quan@amd.com>
Cc: Wenyou Yang <WenYou.Yang@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20241025145639.19124-1-tursulin@igalia.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0880f58)
Cc: stable@vger.kernel.org # v6.6+
Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@ericvh @gregkh
fs/9p: fix uninitialized values during inode evict
3a741b8 
[ Upstream commit 6630036 ]

If an iget fails due to not being able to retrieve information
from the server then the inode structure is only partially
initialized.  When the inode gets evicted, references to
uninitialized structures (like fscache cookies) were being
made.

This patch checks for a bad_inode before doing anything other
than clearing the inode from the cache.  Since the inode is
bad, it shouldn't have any state associated with it that needs
to be written back (and there really isn't a way to complete
those anyways).

Reported-by: syzbot+eb83fe1cce5833cd66a0@syzkaller.appspotmail.com
Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[Xiangyu: CVE-2024-36923 Minor conflict resolution ]
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@geo-stark @gregkh
leds: mlxreg: Use devm_mutex_init() for mutex initialization
172ffd2 
commit efc347b upstream.

In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.

Signed-off-by: George Stark <gnstark@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240411161032.609544-8-gnstark@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
[ Resolve minor conflicts to fix CVE-2024-42129 ]
Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@lorenzo-stoakes @gregkh
mm: avoid unsafe VMA hook invocation when error arises on mmap hook
cd3ed99 
[ Upstream commit 3dd6ed3 ]

Patch series "fix error handling in mmap_region() and refactor
(hotfixes)", v4.

mmap_region() is somewhat terrifying, with spaghetti-like control flow and
numerous means by which issues can arise and incomplete state, memory
leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late
in the process of mapping a VMA, which forms the basis of recently
observed issues with resource leaks and observable inconsistent state.

This series goes to great lengths to simplify how mmap_region() works and
to avoid unwinding errors late on in the process of setting up the VMA for
the new mapping, and equally avoids such operations occurring while the
VMA is in an inconsistent state.

The patches in this series comprise the minimal changes required to
resolve existing issues in mmap_region() error handling, in order that
they can be hotfixed and backported.  There is additionally a follow up
series which goes further, separated out from the v1 series and sent and
updated separately.

This patch (of 5):

After an attempted mmap() fails, we are no longer in a situation where we
can safely interact with VMA hooks.  This is currently not enforced,
meaning that we need complicated handling to ensure we do not incorrectly
call these hooks.

We can avoid the whole issue by treating the VMA as suspect the moment
that the file->f_ops->mmap() function reports an error by replacing
whatever VMA operations were installed with a dummy empty set of VMA
operations.

We do so through a new helper function internal to mm - mmap_file() -
which is both more logically named than the existing call_mmap() function
and correctly isolates handling of the vm_op reassignment to mm.

All the existing invocations of call_mmap() outside of mm are ultimately
nested within the call_mmap() from mm, which we now replace.

It is therefore safe to leave call_mmap() in place as a convenience
    function (and to avoid churn).  The invokers are:

     ovl_file_operations -> mmap -> ovl_mmap() -> backing_file_mmap()
    coda_file_operations -> mmap -> coda_file_mmap()
     shm_file_operations -> shm_mmap()
shm_file_operations_huge -> shm_mmap()
            dma_buf_fops -> dma_buf_mmap_internal -> i915_dmabuf_ops
                            -> i915_gem_dmabuf_mmap()

None of these callers interact with vm_ops or mappings in a problematic
way on error, quickly exiting out.

Link: https://lkml.kernel.org/r/cover.1730224667.git.lorenzo.stoakes@oracle.com
Link: https://lkml.kernel.org/r/d41fd763496fd0048a962f3fd9407dc72dd4fd86.1730224667.git.lorenzo.stoakes@oracle.com
Fixes: deb0f65 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reported-by: Jann Horn <jannh@google.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Jann Horn <jannh@google.com>
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Helge Deller <deller@gmx.de>
Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@lorenzo-stoakes @gregkh
mm: unconditionally close VMAs on error
a97fe68 
[ Upstream commit 4080ef1 ]

Incorrect invocation of VMA callbacks when the VMA is no longer in a
consistent state is bug prone and risky to perform.

With regards to the important vm_ops->close() callback We have gone to
great lengths to try to track whether or not we ought to close VMAs.

Rather than doing so and risking making a mistake somewhere, instead
unconditionally close and reset vma->vm_ops to an empty dummy operations
set with a NULL .close operator.

We introduce a new function to do so - vma_close() - and simplify existing
vms logic which tracked whether we needed to close or not.

This simplifies the logic, avoids incorrect double-calling of the .close()
callback and allows us to update error paths to simply call vma_close()
unconditionally - making VMA closure idempotent.

Link: https://lkml.kernel.org/r/28e89dda96f68c505cb6f8e9fc9b57c3e9f74b42.1730224667.git.lorenzo.stoakes@oracle.com
Fixes: deb0f65 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reported-by: Jann Horn <jannh@google.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reviewed-by: Jann Horn <jannh@google.com>
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Helge Deller <deller@gmx.de>
Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@lorenzo-stoakes @gregkh
mm: refactor map_deny_write_exec()
3a6d8d3 
[ Upstream commit 0fb4a7a ]

Refactor the map_deny_write_exec() to not unnecessarily require a VMA
parameter but rather to accept VMA flags parameters, which allows us to
use this function early in mmap_region() in a subsequent commit.

While we're here, we refactor the function to be more readable and add
some additional documentation.

Link: https://lkml.kernel.org/r/6be8bb59cd7c68006ebb006eb9d8dc27104b1f70.1730224667.git.lorenzo.stoakes@oracle.com
Fixes: deb0f65 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reported-by: Jann Horn <jannh@google.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Jann Horn <jannh@google.com>
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Helge Deller <deller@gmx.de>
Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@lorenzo-stoakes @gregkh
mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling
04b7efa 
[ Upstream commit 5baf8b0 ]

Currently MTE is permitted in two circumstances (desiring to use MTE
having been specified by the VM_MTE flag) - where MAP_ANONYMOUS is
specified, as checked by arch_calc_vm_flag_bits() and actualised by
setting the VM_MTE_ALLOWED flag, or if the file backing the mapping is
shmem, in which case we set VM_MTE_ALLOWED in shmem_mmap() when the mmap
hook is activated in mmap_region().

The function that checks that, if VM_MTE is set, VM_MTE_ALLOWED is also
set is the arm64 implementation of arch_validate_flags().

Unfortunately, we intend to refactor mmap_region() to perform this check
earlier, meaning that in the case of a shmem backing we will not have
invoked shmem_mmap() yet, causing the mapping to fail spuriously.

It is inappropriate to set this architecture-specific flag in general mm
code anyway, so a sensible resolution of this issue is to instead move the
check somewhere else.

We resolve this by setting VM_MTE_ALLOWED much earlier in do_mmap(), via
the arch_calc_vm_flag_bits() call.

This is an appropriate place to do this as we already check for the
MAP_ANONYMOUS case here, and the shmem file case is simply a variant of
the same idea - we permit RAM-backed memory.

This requires a modification to the arch_calc_vm_flag_bits() signature to
pass in a pointer to the struct file associated with the mapping, however
this is not too egregious as this is only used by two architectures anyway
- arm64 and parisc.

So this patch performs this adjustment and removes the unnecessary
assignment of VM_MTE_ALLOWED in shmem_mmap().

[akpm@linux-foundation.org: fix whitespace, per Catalin]
Link: https://lkml.kernel.org/r/ec251b20ba1964fb64cf1607d2ad80c47f3873df.1730224667.git.lorenzo.stoakes@oracle.com
Fixes: deb0f65 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Jann Horn <jannh@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Helge Deller <deller@gmx.de>
Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@lorenzo-stoakes @gregkh
mm: resolve faulty mmap_region() error path behaviour
bdc136e 
[ Upstream commit 5de1950 ]

The mmap_region() function is somewhat terrifying, with spaghetti-like
control flow and numerous means by which issues can arise and incomplete
state, memory leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late
in the process of mapping a VMA, which forms the basis of recently
observed issues with resource leaks and observable inconsistent state.

Taking advantage of previous patches in this series we move a number of
checks earlier in the code, simplifying things by moving the core of the
logic into a static internal function __mmap_region().

Doing this allows us to perform a number of checks up front before we do
any real work, and allows us to unwind the writable unmap check
unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE
validation unconditionally also.

We move a number of things here:

1. We preallocate memory for the iterator before we call the file-backed
   memory hook, allowing us to exit early and avoid having to perform
   complicated and error-prone close/free logic. We carefully free
   iterator state on both success and error paths.

2. The enclosing mmap_region() function handles the mapping_map_writable()
   logic early. Previously the logic had the mapping_map_writable() at the
   point of mapping a newly allocated file-backed VMA, and a matching
   mapping_unmap_writable() on success and error paths.

   We now do this unconditionally if this is a file-backed, shared writable
   mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however
   doing so does not invalidate the seal check we just performed, and we in
   any case always decrement the counter in the wrapper.

   We perform a debug assert to ensure a driver does not attempt to do the
   opposite.

3. We also move arch_validate_flags() up into the mmap_region()
   function. This is only relevant on arm64 and sparc64, and the check is
   only meaningful for SPARC with ADI enabled. We explicitly add a warning
   for this arch if a driver invalidates this check, though the code ought
   eventually to be fixed to eliminate the need for this.

With all of these measures in place, we no longer need to explicitly close
the VMA on error paths, as we place all checks which might fail prior to a
call to any driver mmap hook.

This eliminates an entire class of errors, makes the code easier to reason
about and more robust.

Link: https://lkml.kernel.org/r/6e0becb36d2f5472053ac5d544c0edfe9b899e25.1730224667.git.lorenzo.stoakes@oracle.com
Fixes: deb0f65 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reported-by: Jann Horn <jannh@google.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Mark Brown <broonie@kernel.org>
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Helge Deller <deller@gmx.de>
Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@sjp38 @gregkh
mm/damon/core: check apply interval in damon_do_apply_schemes()
b0fb954 
commit e9e3db6 upstream.

kdamond_apply_schemes() checks apply intervals of schemes and avoid
further applying any schemes if no scheme passed its apply interval.
However, the following schemes applying function, damon_do_apply_schemes()
iterates all schemes without the apply interval check.  As a result, the
shortest apply interval is applied to all schemes.  Fix the problem by
checking the apply interval in damon_do_apply_schemes().

Link: https://lkml.kernel.org/r/20240205201306.88562-1-sj@kernel.org
Fixes: 42f994b ("mm/damon/core: implement scheme-specific apply interval")
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: <stable@vger.kernel.org>	[6.7.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@sjp38 @gregkh
mm/damon/core: handle zero schemes apply interval
6cba27a 
commit 8e7bde6 upstream.

DAMON's logics to determine if this is the time to apply damos schemes
assumes next_apply_sis is always set larger than current
passed_sample_intervals.  And therefore assume continuously incrementing
passed_sample_intervals will make it reaches to the next_apply_sis in
future.  The logic hence does apply the scheme and update next_apply_sis
only if passed_sample_intervals is same to next_apply_sis.

If Schemes apply interval is set as zero, however, next_apply_sis is set
same to current passed_sample_intervals, respectively.  And
passed_sample_intervals is incremented before doing the next_apply_sis
check.  Hence, next_apply_sis becomes larger than next_apply_sis, and the
logic says it is not the time to apply schemes and update next_apply_sis.
In other words, DAMON stops applying schemes until passed_sample_intervals
overflows.

Based on the documents and the common sense, a reasonable behavior for
such inputs would be applying the schemes for every sampling interval.
Handle the case by removing the assumption.

Link: https://lkml.kernel.org/r/20241031183757.49610-3-sj@kernel.org
Fixes: 42f994b ("mm/damon/core: implement scheme-specific apply interval")
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: <stable@vger.kernel.org>	[6.7.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@sjp38 @gregkh
mm/damon/core: copy nr_accesses when splitting region
62aec1e 
commit 1f3730f upstream.

Regions split function ('damon_split_region_at()') is called at the
beginning of an aggregation interval, and when DAMOS applying the actions
and charging quota.  Because 'nr_accesses' fields of all regions are reset
at the beginning of each aggregation interval, and DAMOS was applying the
action at the end of each aggregation interval, there was no need to copy
the 'nr_accesses' field to the split-out region.

However, commit 42f994b ("mm/damon/core: implement scheme-specific
apply interval") made DAMOS applies action on its own timing interval.
Hence, 'nr_accesses' should also copied to split-out regions, but the
commit didn't.  Fix it by copying it.

Link: https://lkml.kernel.org/r/20231119171529.66863-1-sj@kernel.org
Fixes: 42f994b ("mm/damon/core: implement scheme-specific apply interval")
Signed-off-by: SeongJae Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@gregkh
Linux 6.6.63
bff3e13 
Link: https://lore.kernel.org/r/20241120125629.623666563@linuxfoundation.org
Tested-by: Mark Brown <broonie@kernel.org>
Tested-by: SeongJae Park <sj@kernel.org>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Ron Economos <re@w6rz.net>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Hardik Garg hargar@linux.microsoft.com=0A=
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: kernelci.org bot <bot@kernelci.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
qaz6750 added a commit that referenced this pull request Nov 30, 2024
@qaz6750
Kernel: Merge Linux 6.6.63 Update (#4)
c53dd31 
commit bff3e13adb72656356111d2549d8be7c872d6e15
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Nov 22 15:38:37 2024 +0100

    Linux 6.6.63

    Link: https://lore.kernel.org/r/20241120125629.623666563@linuxfoundation.org
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Hardik Garg hargar@linux.microsoft.com=0A=
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62aec1e925996a358dbfc08daf5ec26243bbafd0
Author: SeongJae Park <sj@kernel.org>
Date:   Sun Nov 19 17:15:28 2023 +0000

    mm/damon/core: copy nr_accesses when splitting region

    commit 1f3730fd9e8d4d77fb99c60d0e6ad4b1104e7e04 upstream.

    Regions split function ('damon_split_region_at()') is called at the
    beginning of an aggregation interval, and when DAMOS applying the actions
    and charging quota.  Because 'nr_accesses' fields of all regions are reset
    at the beginning of each aggregation interval, and DAMOS was applying the
    action at the end of each aggregation interval, there was no need to copy
    the 'nr_accesses' field to the split-out region.

    However, commit 42f994b71404 ("mm/damon/core: implement scheme-specific
    apply interval") made DAMOS applies action on its own timing interval.
    Hence, 'nr_accesses' should also copied to split-out regions, but the
    commit didn't.  Fix it by copying it.

    Link: https://lkml.kernel.org/r/20231119171529.66863-1-sj@kernel.org
    Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cba27abb6695b1facdd58a6480c611e3b41f1cb
Author: SeongJae Park <sj@kernel.org>
Date:   Thu Oct 31 11:37:57 2024 -0700

    mm/damon/core: handle zero schemes apply interval

    commit 8e7bde615f634a82a44b1f3d293c049fd3ef9ca9 upstream.

    DAMON's logics to determine if this is the time to apply damos schemes
    assumes next_apply_sis is always set larger than current
    passed_sample_intervals.  And therefore assume continuously incrementing
    passed_sample_intervals will make it reaches to the next_apply_sis in
    future.  The logic hence does apply the scheme and update next_apply_sis
    only if passed_sample_intervals is same to next_apply_sis.

    If Schemes apply interval is set as zero, however, next_apply_sis is set
    same to current passed_sample_intervals, respectively.  And
    passed_sample_intervals is incremented before doing the next_apply_sis
    check.  Hence, next_apply_sis becomes larger than next_apply_sis, and the
    logic says it is not the time to apply schemes and update next_apply_sis.
    In other words, DAMON stops applying schemes until passed_sample_intervals
    overflows.

    Based on the documents and the common sense, a reasonable behavior for
    such inputs would be applying the schemes for every sampling interval.
    Handle the case by removing the assumption.

    Link: https://lkml.kernel.org/r/20241031183757.49610-3-sj@kernel.org
    Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>	[6.7.x]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0fb9543b1198b797afe08c03699e90828ca8074
Author: SeongJae Park <sj@kernel.org>
Date:   Mon Feb 5 12:13:06 2024 -0800

    mm/damon/core: check apply interval in damon_do_apply_schemes()

    commit e9e3db69966d5e9e6f7e7d017b407c0025180fe5 upstream.

    kdamond_apply_schemes() checks apply intervals of schemes and avoid
    further applying any schemes if no scheme passed its apply interval.
    However, the following schemes applying function, damon_do_apply_schemes()
    iterates all schemes without the apply interval check.  As a result, the
    shortest apply interval is applied to all schemes.  Fix the problem by
    checking the apply interval in damon_do_apply_schemes().

    Link: https://lkml.kernel.org/r/20240205201306.88562-1-sj@kernel.org
    Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>	[6.7.x]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdc136e2b05fabcd780fe5f165d154eb779dfcb0
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:58 2024 +0000

    mm: resolve faulty mmap_region() error path behaviour

    [ Upstream commit 5de195060b2e251a835f622759550e6202167641 ]

    The mmap_region() function is somewhat terrifying, with spaghetti-like
    control flow and numerous means by which issues can arise and incomplete
    state, memory leaks and other unpleasantness can occur.

    A large amount of the complexity arises from trying to handle errors late
    in the process of mapping a VMA, which forms the basis of recently
    observed issues with resource leaks and observable inconsistent state.

    Taking advantage of previous patches in this series we move a number of
    checks earlier in the code, simplifying things by moving the core of the
    logic into a static internal function __mmap_region().

    Doing this allows us to perform a number of checks up front before we do
    any real work, and allows us to unwind the writable unmap check
    unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE
    validation unconditionally also.

    We move a number of things here:

    1. We preallocate memory for the iterator before we call the file-backed
       memory hook, allowing us to exit early and avoid having to perform
       complicated and error-prone close/free logic. We carefully free
       iterator state on both success and error paths.

    2. The enclosing mmap_region() function handles the mapping_map_writable()
       logic early. Previously the logic had the mapping_map_writable() at the
       point of mapping a newly allocated file-backed VMA, and a matching
       mapping_unmap_writable() on success and error paths.

       We now do this unconditionally if this is a file-backed, shared writable
       mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however
       doing so does not invalidate the seal check we just performed, and we in
       any case always decrement the counter in the wrapper.

       We perform a debug assert to ensure a driver does not attempt to do the
       opposite.

    3. We also move arch_validate_flags() up into the mmap_region()
       function. This is only relevant on arm64 and sparc64, and the check is
       only meaningful for SPARC with ADI enabled. We explicitly add a warning
       for this arch if a driver invalidates this check, though the code ought
       eventually to be fixed to eliminate the need for this.

    With all of these measures in place, we no longer need to explicitly close
    the VMA on error paths, as we place all checks which might fail prior to a
    call to any driver mmap hook.

    This eliminates an entire class of errors, makes the code easier to reason
    about and more robust.

    Link: https://lkml.kernel.org/r/6e0becb36d2f5472053ac5d544c0edfe9b899e25.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Tested-by: Mark Brown <broonie@kernel.org>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04b7efa421dc64417967ede47a88af5aca2bf578
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:57 2024 +0000

    mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling

    [ Upstream commit 5baf8b037debf4ec60108ccfeccb8636d1dbad81 ]

    Currently MTE is permitted in two circumstances (desiring to use MTE
    having been specified by the VM_MTE flag) - where MAP_ANONYMOUS is
    specified, as checked by arch_calc_vm_flag_bits() and actualised by
    setting the VM_MTE_ALLOWED flag, or if the file backing the mapping is
    shmem, in which case we set VM_MTE_ALLOWED in shmem_mmap() when the mmap
    hook is activated in mmap_region().

    The function that checks that, if VM_MTE is set, VM_MTE_ALLOWED is also
    set is the arm64 implementation of arch_validate_flags().

    Unfortunately, we intend to refactor mmap_region() to perform this check
    earlier, meaning that in the case of a shmem backing we will not have
    invoked shmem_mmap() yet, causing the mapping to fail spuriously.

    It is inappropriate to set this architecture-specific flag in general mm
    code anyway, so a sensible resolution of this issue is to instead move the
    check somewhere else.

    We resolve this by setting VM_MTE_ALLOWED much earlier in do_mmap(), via
    the arch_calc_vm_flag_bits() call.

    This is an appropriate place to do this as we already check for the
    MAP_ANONYMOUS case here, and the shmem file case is simply a variant of
    the same idea - we permit RAM-backed memory.

    This requires a modification to the arch_calc_vm_flag_bits() signature to
    pass in a pointer to the struct file associated with the mapping, however
    this is not too egregious as this is only used by two architectures anyway
    - arm64 and parisc.

    So this patch performs this adjustment and removes the unnecessary
    assignment of VM_MTE_ALLOWED in shmem_mmap().

    [akpm@linux-foundation.org: fix whitespace, per Catalin]
    Link: https://lkml.kernel.org/r/ec251b20ba1964fb64cf1607d2ad80c47f3873df.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a6d8d3f199827f017b1eabde10437957bd23c6d
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:56 2024 +0000

    mm: refactor map_deny_write_exec()

    [ Upstream commit 0fb4a7ad270b3b209e510eb9dc5b07bf02b7edaf ]

    Refactor the map_deny_write_exec() to not unnecessarily require a VMA
    parameter but rather to accept VMA flags parameters, which allows us to
    use this function early in mmap_region() in a subsequent commit.

    While we're here, we refactor the function to be more readable and add
    some additional documentation.

    Link: https://lkml.kernel.org/r/6be8bb59cd7c68006ebb006eb9d8dc27104b1f70.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Jann Horn <jannh@google.com>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a97fe6889b25648b7d990d83bf63b2f0e1f1c545
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:55 2024 +0000

    mm: unconditionally close VMAs on error

    [ Upstream commit 4080ef1579b2413435413988d14ac8c68e4d42c8 ]

    Incorrect invocation of VMA callbacks when the VMA is no longer in a
    consistent state is bug prone and risky to perform.

    With regards to the important vm_ops->close() callback We have gone to
    great lengths to try to track whether or not we ought to close VMAs.

    Rather than doing so and risking making a mistake somewhere, instead
    unconditionally close and reset vma->vm_ops to an empty dummy operations
    set with a NULL .close operator.

    We introduce a new function to do so - vma_close() - and simplify existing
    vms logic which tracked whether we needed to close or not.

    This simplifies the logic, avoids incorrect double-calling of the .close()
    callback and allows us to update error paths to simply call vma_close()
    unconditionally - making VMA closure idempotent.

    Link: https://lkml.kernel.org/r/28e89dda96f68c505cb6f8e9fc9b57c3e9f74b42.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Jann Horn <jannh@google.com>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd3ed99fca8ca713a6d532ca9d5cab4737a2f98c
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:54 2024 +0000

    mm: avoid unsafe VMA hook invocation when error arises on mmap hook

    [ Upstream commit 3dd6ed34ce1f2356a77fb88edafb5ec96784e3cf ]

    Patch series "fix error handling in mmap_region() and refactor
    (hotfixes)", v4.

    mmap_region() is somewhat terrifying, with spaghetti-like control flow and
    numerous means by which issues can arise and incomplete state, memory
    leaks and other unpleasantness can occur.

    A large amount of the complexity arises from trying to handle errors late
    in the process of mapping a VMA, which forms the basis of recently
    observed issues with resource leaks and observable inconsistent state.

    This series goes to great lengths to simplify how mmap_region() works and
    to avoid unwinding errors late on in the process of setting up the VMA for
    the new mapping, and equally avoids such operations occurring while the
    VMA is in an inconsistent state.

    The patches in this series comprise the minimal changes required to
    resolve existing issues in mmap_region() error handling, in order that
    they can be hotfixed and backported.  There is additionally a follow up
    series which goes further, separated out from the v1 series and sent and
    updated separately.

    This patch (of 5):

    After an attempted mmap() fails, we are no longer in a situation where we
    can safely interact with VMA hooks.  This is currently not enforced,
    meaning that we need complicated handling to ensure we do not incorrectly
    call these hooks.

    We can avoid the whole issue by treating the VMA as suspect the moment
    that the file->f_ops->mmap() function reports an error by replacing
    whatever VMA operations were installed with a dummy empty set of VMA
    operations.

    We do so through a new helper function internal to mm - mmap_file() -
    which is both more logically named than the existing call_mmap() function
    and correctly isolates handling of the vm_op reassignment to mm.

    All the existing invocations of call_mmap() outside of mm are ultimately
    nested within the call_mmap() from mm, which we now replace.

    It is therefore safe to leave call_mmap() in place as a convenience
        function (and to avoid churn).  The invokers are:

         ovl_file_operations -> mmap -> ovl_mmap() -> backing_file_mmap()
        coda_file_operations -> mmap -> coda_file_mmap()
         shm_file_operations -> shm_mmap()
    shm_file_operations_huge -> shm_mmap()
                dma_buf_fops -> dma_buf_mmap_internal -> i915_dmabuf_ops
                                -> i915_gem_dmabuf_mmap()

    None of these callers interact with vm_ops or mappings in a problematic
    way on error, quickly exiting out.

    Link: https://lkml.kernel.org/r/cover.1730224667.git.lorenzo.stoakes@oracle.com
    Link: https://lkml.kernel.org/r/d41fd763496fd0048a962f3fd9407dc72dd4fd86.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Jann Horn <jannh@google.com>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 172ffd26a5af13e951d0e82df7cfc5a95b04fa80
Author: George Stark <gnstark@salutedevices.com>
Date:   Thu Apr 11 19:10:31 2024 +0300

    leds: mlxreg: Use devm_mutex_init() for mutex initialization

    commit efc347b9efee1c2b081f5281d33be4559fa50a16 upstream.

    In this driver LEDs are registered using devm_led_classdev_register()
    so they are automatically unregistered after module's remove() is done.
    led_classdev_unregister() calls module's led_set_brightness() to turn off
    the LEDs and that callback uses mutex which was destroyed already
    in module's remove() so use devm API instead.

    Signed-off-by: George Stark <gnstark@salutedevices.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20240411161032.609544-8-gnstark@salutedevices.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    [ Resolve minor conflicts to fix CVE-2024-42129 ]
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a741b80b3457f079cf637e47800fb7bf8038ad6
Author: Eric Van Hensbergen <ericvh@kernel.org>
Date:   Tue Nov 19 11:43:17 2024 +0800

    fs/9p: fix uninitialized values during inode evict

    [ Upstream commit 6630036b7c228f57c7893ee0403e92c2db2cd21d ]

    If an iget fails due to not being able to retrieve information
    from the server then the inode structure is only partially
    initialized.  When the inode gets evicted, references to
    uninitialized structures (like fscache cookies) were being
    made.

    This patch checks for a bad_inode before doing anything other
    than clearing the inode from the cache.  Since the inode is
    bad, it shouldn't have any state associated with it that needs
    to be written back (and there really isn't a way to complete
    those anyways).

    Reported-by: syzbot+eb83fe1cce5833cd66a0@syzkaller.appspotmail.com
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [Xiangyu: CVE-2024-36923 Minor conflict resolution ]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f111de0f010308949254ee1cc45df8e6b8e1d7d4
Author: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Date:   Fri Oct 25 15:56:39 2024 +0100

    drm/amd/pm: Vangogh: Fix kernel memory out of bounds write

    commit 4aa923a6e6406b43566ef6ac35a3d9a3197fa3e8 upstream.

    KASAN reports that the GPU metrics table allocated in
    vangogh_tables_init() is not large enough for the memset done in
    smu_cmn_init_soft_gpu_metrics(). Condensed report follows:

    [   33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu]
    [   33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067
    ...
    [   33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G        W          6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544
    [   33.861816] Tainted: [W]=WARN
    [   33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023
    [   33.861822] Call Trace:
    [   33.861826]  <TASK>
    [   33.861829]  dump_stack_lvl+0x66/0x90
    [   33.861838]  print_report+0xce/0x620
    [   33.861853]  kasan_report+0xda/0x110
    [   33.862794]  kasan_check_range+0xfd/0x1a0
    [   33.862799]  __asan_memset+0x23/0x40
    [   33.862803]  smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.863306]  vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.864257]  vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.865682]  amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.866160]  amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.867135]  dev_attr_show+0x43/0xc0
    [   33.867147]  sysfs_kf_seq_show+0x1f1/0x3b0
    [   33.867155]  seq_read_iter+0x3f8/0x1140
    [   33.867173]  vfs_read+0x76c/0xc50
    [   33.867198]  ksys_read+0xfb/0x1d0
    [   33.867214]  do_syscall_64+0x90/0x160
    ...
    [   33.867353] Allocated by task 378 on cpu 7 at 22.794876s:
    [   33.867358]  kasan_save_stack+0x33/0x50
    [   33.867364]  kasan_save_track+0x17/0x60
    [   33.867367]  __kasan_kmalloc+0x87/0x90
    [   33.867371]  vangogh_init_smc_tables+0x3f9/0x840 [amdgpu]
    [   33.867835]  smu_sw_init+0xa32/0x1850 [amdgpu]
    [   33.868299]  amdgpu_device_init+0x467b/0x8d90 [amdgpu]
    [   33.868733]  amdgpu_driver_load_kms+0x19/0xf0 [amdgpu]
    [   33.869167]  amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu]
    [   33.869608]  local_pci_probe+0xda/0x180
    [   33.869614]  pci_device_probe+0x43f/0x6b0

    Empirically we can confirm that the former allocates 152 bytes for the
    table, while the latter memsets the 168 large block.

    Root cause appears that when GPU metrics tables for v2_4 parts were added
    it was not considered to enlarge the table to fit.

    The fix in this patch is rather "brute force" and perhaps later should be
    done in a smarter way, by extracting and consolidating the part version to
    size logic to a common helper, instead of brute forcing the largest
    possible allocation. Nevertheless, for now this works and fixes the out of
    bounds write.

    v2:
     * Drop impossible v3_0 case. (Mario)

    Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
    Fixes: 41cec40bc9ba ("drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to acquire gpu_metrics")
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Evan Quan <evan.quan@amd.com>
    Cc: Wenyou Yang <WenYou.Yang@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20241025145639.19124-1-tursulin@igalia.com
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)
    Cc: stable@vger.kernel.org # v6.6+
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bc4569a727d776819c2fd413098882798974aae
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Mon Nov 18 19:27:24 2024 +0100

    mptcp: pm: use _rcu variant under rcu_read_lock

    commit db3eab8110bc0520416101b6a5b52f44a43fb4cf upstream.

    In mptcp_pm_create_subflow_or_signal_addr(), rcu_read_(un)lock() are
    used as expected to iterate over the list of local addresses, but
    list_for_each_entry() was used instead of list_for_each_entry_rcu() in
    __lookup_addr(). It is important to use this variant which adds the
    required READ_ONCE() (and diagnostic checks if enabled).

    Because __lookup_addr() is also used in mptcp_pm_nl_set_flags() where it
    is called under the pernet->lock and not rcu_read_lock(), an extra
    condition is then passed to help the diagnostic checks making sure
    either the associated spin lock or the RCU lock is held.

    Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20241112-net-mptcp-misc-6-12-pm-v1-3-b835580cefa8@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc3c73284d2ebd2bb6327e0c22d13b3802487370
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Mon Nov 18 19:27:23 2024 +0100

    mptcp: drop lookup_by_id in lookup_addr

    commit af250c27ea1c404e210fc3a308b20f772df584d6 upstream.

    When the lookup_by_id parameter of __lookup_addr() is true, it's the same
    as __lookup_addr_by_id(), it can be replaced by __lookup_addr_by_id()
    directly. So drop this parameter, let __lookup_addr() only looks up address
    on the local address list by comparing addresses in it, not address ids.

    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240305-upstream-net-next-20240304-mptcp-misc-cleanup-v1-4-c436ba5e569b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: db3eab8110bc ("mptcp: pm: use _rcu variant under rcu_read_lock")
    [ Conflicts in pm_netlink.c, because commit 6a42477fe449 ("mptcp: update
      set_flags interfaces") is not in this version, and causes too many
      conflicts when backporting it. The conflict is easy to resolve: addr
      is a pointer here here in mptcp_pm_nl_set_flags(), the rest of the
      code is the same. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 416001b0412f7fb1ace54457f55b95f080376cbe
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Mon Nov 18 19:27:22 2024 +0100

    mptcp: hold pm lock when deleting entry

    commit f642c5c4d528d11bd78b6c6f84f541cd3c0bea86 upstream.

    When traversing userspace_pm_local_addr_list and deleting an entry from
    it in mptcp_pm_nl_remove_doit(), msk->pm.lock should be held.

    This patch holds this lock before mptcp_userspace_pm_lookup_addr_by_id()
    and releases it after list_move() in mptcp_pm_nl_remove_doit().

    Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20241112-net-mptcp-misc-6-12-pm-v1-2-b835580cefa8@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac56c5e80e1f3297c54780c70da7ba85cc516b51
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Mon Nov 18 19:27:21 2024 +0100

    mptcp: update local address flags when setting it

    commit e0266319413d5d687ba7b6df7ca99e4b9724a4f2 upstream.

    Just like in-kernel pm, when userspace pm does set_flags, it needs to send
    out MP_PRIO signal, and also modify the flags of the corresponding address
    entry in the local address list. This patch implements the missing logic.

    Traverse all address entries on userspace_pm_local_addr_list to find the
    local address entry, if bkup is true, set the flags of this entry with
    FLAG_BACKUP, otherwise, clear FLAG_BACKUP.

    Fixes: 892f396c8e68 ("mptcp: netlink: issue MP_PRIO signals from userspace PMs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20241112-net-mptcp-misc-6-12-pm-v1-1-b835580cefa8@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_userspace.c, because commit 6a42477fe449 ("mptcp:
      update set_flags interfaces"), is not in this version, and causes too
      many conflicts when backporting it. The same code can still be added
      at the same place, before sending the ACK. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa2b28ddcc260bfdda568a5b82dcf6b6e3bc5245
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Mon Nov 18 19:27:20 2024 +0100

    mptcp: add userspace_pm_lookup_addr_by_id helper

    commit 06afe09091ee69dc7ab058b4be9917ae59cc81e5 upstream.

    Corresponding __lookup_addr_by_id() helper in the in-kernel netlink PM,
    this patch adds a new helper mptcp_userspace_pm_lookup_addr_by_id() to
    lookup the address entry with the given id on the userspace pm local
    address list.

    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: f642c5c4d528 ("mptcp: hold pm lock when deleting entry")
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 762ca2d2e3c764787ffe820357873760b70dde6a
Author: Geliang Tang <geliang.tang@suse.com>
Date:   Mon Nov 18 19:27:19 2024 +0100

    mptcp: define more local variables sk

    commit 14cb0e0bf39bd10429ba14e9e2f905f1144226fc upstream.

    '(struct sock *)msk' is used several times in mptcp_nl_cmd_announce(),
    mptcp_nl_cmd_remove() or mptcp_userspace_pm_set_flags() in pm_userspace.c,
    it's worth adding a local variable sk to point it.

    Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: Geliang Tang <geliang.tang@suse.com>
    Signed-off-by: Mat Martineau <martineau@kernel.org>
    Link: https://lore.kernel.org/r/20231025-send-net-next-20231025-v1-8-db8f25f798eb@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 06afe09091ee ("mptcp: add userspace_pm_lookup_addr_by_id helper")
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb79d68a36e21960341ccab07d1ac06d93830321
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Nov 18 16:14:13 2024 -0500

    NFSD: Never decrement pending_async_copies on error

    [ Upstream commit 8286f8b622990194207df9ab852e0f87c60d35e9 ]

    The error flow in nfsd4_copy() calls cleanup_async_copy(), which
    already decrements nn->pending_async_copies.

    Reported-by: Olga Kornievskaia <okorniev@redhat.com>
    Fixes: aadc3bbea163 ("NFSD: Limit the number of concurrent async COPY operations")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 421f1a2a1afb47d88de09457ef7687e1df7bc997
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Nov 18 16:14:12 2024 -0500

    NFSD: Initialize struct nfsd4_copy earlier

    [ Upstream commit 63fab04cbd0f96191b6e5beedc3b643b01c15889 ]

    Ensure the refcount and async_copies fields are initialized early.
    cleanup_async_copy() will reference these fields if an error occurs
    in nfsd4_copy(). If they are not correctly initialized, at the very
    least, a refcount underflow occurs.

    Reported-by: Olga Kornievskaia <okorniev@redhat.com>
    Fixes: aadc3bbea163 ("NFSD: Limit the number of concurrent async COPY operations")
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Tested-by: Olga Kornievskaia <okorniev@redhat.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae267989b7b7933dfedcd26468d0a88fc3a9da9e
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Nov 18 16:14:11 2024 -0500

    NFSD: Limit the number of concurrent async COPY operations

    [ Upstream commit aadc3bbea163b6caaaebfdd2b6c4667fbc726752 ]

    Nothing appears to limit the number of concurrent async COPY
    operations that clients can start. In addition, AFAICT each async
    COPY can copy an unlimited number of 4MB chunks, so can run for a
    long time. Thus IMO async COPY can become a DoS vector.

    Add a restriction mechanism that bounds the number of concurrent
    background COPY operations. Start simple and try to be fair -- this
    patch implements a per-namespace limit.

    An async COPY request that occurs while this limit is exceeded gets
    NFS4ERR_DELAY. The requesting client can choose to send the request
    again after a delay or fall back to a traditional read/write style
    copy.

    If there is need to make the mechanism more sophisticated, we can
    visit that in future patches.

    Cc: stable@vger.kernel.org
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Link: https://nvd.nist.gov/vuln/detail/CVE-2024-49974
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20a10c78ac3a8b608dca7c42bd6a982b192f55dd
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Nov 18 16:14:10 2024 -0500

    NFSD: Async COPY result needs to return a write verifier

    [ Upstream commit 9ed666eba4e0a2bb8ffaa3739d830b64d4f2aaad ]

    Currently, when NFSD handles an asynchronous COPY, it returns a
    zero write verifier, relying on the subsequent CB_OFFLOAD callback
    to pass the write verifier and a stable_how4 value to the client.

    However, if the CB_OFFLOAD never arrives at the client (for example,
    if a network partition occurs just as the server sends the
    CB_OFFLOAD operation), the client will never receive this verifier.
    Thus, if the client sends a follow-up COMMIT, there is no way for
    the client to assess the COMMIT result.

    The usual recovery for a missing CB_OFFLOAD is for the client to
    send an OFFLOAD_STATUS operation, but that operation does not carry
    a write verifier in its result. Neither does it carry a stable_how4
    value, so the client /must/ send a COMMIT in this case -- which will
    always fail because currently there's still no write verifier in the
    COPY result.

    Thus the server needs to return a normal write verifier in its COPY
    result even if the COPY operation is to be performed asynchronously.

    If the server recognizes the callback stateid in subsequent
    OFFLOAD_STATUS operations, then obviously it has not restarted, and
    the write verifier the client received in the COPY result is still
    valid and can be used to assess a COMMIT of the copied data, if one
    is needed.

    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    [ cel: adjusted to apply to origin/linux-6.6.y ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74115b3e41c7ed88d53dce9c6091b38c02de02f9
Author: Dai Ngo <dai.ngo@oracle.com>
Date:   Mon Nov 18 16:14:09 2024 -0500

    NFSD: initialize copy->cp_clp early in nfsd4_copy for use by trace point

    [ Upstream commit 15d1975b7279693d6f09398e0e2e31aca2310275 ]

    Prepare for adding server copy trace points.

    Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
    Tested-by: Chen Hanxiao <chenhx.fnst@fujitsu.com>
    Stable-dep-of: 9ed666eba4e0 ("NFSD: Async COPY result needs to return a write verifier")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db12e874e1a202206c734d89920e4aa9e290efa2
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date:   Wed Nov 6 21:50:55 2024 +0100

    media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set

    commit a4aebaf6e6efff548b01a3dc49b4b9074751c15b upstream.

    When CONFIG_DVB_DYNAMIC_MINORS, ret is not initialized, and a
    semaphore is left at the wrong state, in case of errors.

    Make the code simpler and avoid mistakes by having just one error
    check logic used weather DVB_DYNAMIC_MINORS is used or not.

    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/r/202410201717.ULWWdJv8-lkp@intel.com/
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Link: https://lore.kernel.org/r/9e067488d8935b8cf00959764a1fa5de85d65725.1730926254.git.mchehab+huawei@kernel.org
    Cc: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efb258ec337f34962606620fe0f77808edf9f92d
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Mon Nov 4 18:52:55 2024 +0100

    lib/buildid: Fix build ID parsing logic

    The parse_build_id_buf does not account Elf32_Nhdr header size
    when getting the build id data pointer and returns wrong build
    id data as result.

    This is problem only for stable trees that merged c83a80d8b84f
    fix, the upstream build id code was refactored and returns proper
    build id.

    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Fixes: c83a80d8b84f ("lib/buildid: harden build ID parsing logic")
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c623f5692a0f9e77c2e2aea487b353fd235306d
Author: Umang Jain <umang.jain@ideasonboard.com>
Date:   Wed Oct 16 18:32:24 2024 +0530

    staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation

    [ Upstream commit 404b739e895522838f1abdc340c554654d671dde ]

    The struct vchiq_arm_state 'platform_state' is currently allocated
    dynamically using kzalloc(). Unfortunately, it is never freed and is
    subjected to memory leaks in the error handling paths of the probe()
    function.

    To address the issue, use device resource management helper
    devm_kzalloc(), to ensure cleanup after its allocation.

    Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/20241016130225.61024-2-umang.jain@ideasonboard.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6dee8f99c69068480e88121cbd38c267b0b60e08
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Fri Jun 21 15:19:53 2024 +0200

    staging: vchiq_arm: Get the rid off struct vchiq_2835_state

    [ Upstream commit 4e2766102da632f26341d5539519b0abf73df887 ]

    The whole benefit of this encapsulating struct is questionable.
    It just stores a flag to signalize the init state of vchiq_arm_state.
    Beside the fact this flag is set too soon, the access to uninitialized
    members should be avoided. So initialize vchiq_arm_state properly before
    assign it directly to vchiq_state.

    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://lore.kernel.org/r/20240621131958.98208-6-wahrenst@gmx.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 404b739e8955 ("staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6bfed8babc1a3d1be4bc671adcd583616225997d
Author: SeongJae Park <sj@kernel.org>
Date:   Thu Oct 31 11:37:56 2024 -0700

    mm/damon/core: handle zero {aggregation,ops_update} intervals

    [ Upstream commit 3488af0970445ff5532c7e8dc5e6456b877aee5e ]

    Patch series "mm/damon/core: fix handling of zero non-sampling intervals".

    DAMON's internal intervals accounting logic is not correctly handling
    non-sampling intervals of zero values for a wrong assumption.  This could
    cause unexpected monitoring behavior, and even result in infinite hang of
    DAMON sysfs interface user threads in case of zero aggregation interval.
    Fix those by updating the intervals accounting logic.  For details of the
    root case and solutions, please refer to commit messages of fixes.

    This patch (of 2):

    DAMON's logics to determine if this is the time to do aggregation and ops
    update assumes next_{aggregation,ops_update}_sis are always set larger
    than current passed_sample_intervals.  And therefore it further assumes
    continuously incrementing passed_sample_intervals every sampling interval
    will make it reaches to the next_{aggregation,ops_update}_sis in future.
    The logic therefore make the action and update
    next_{aggregation,ops_updaste}_sis only if passed_sample_intervals is same
    to the counts, respectively.

    If Aggregation interval or Ops update interval are zero, however,
    next_aggregation_sis or next_ops_update_sis are set same to current
    passed_sample_intervals, respectively.  And passed_sample_intervals is
    incremented before doing the next_{aggregation,ops_update}_sis check.
    Hence, passed_sample_intervals becomes larger than
    next_{aggregation,ops_update}_sis, and the logic says it is not the time
    to do the action and update next_{aggregation,ops_update}_sis forever,
    until an overflow happens.  In other words, DAMON stops doing aggregations
    or ops updates effectively forever, and users cannot get monitoring
    results.

    Based on the documents and the common sense, a reasonable behavior for
    such inputs is doing an aggregation and an ops update for every sampling
    interval.  Handle the case by removing the assumption.

    Note that this could incur particular real issue for DAMON sysfs interface
    users, in case of zero Aggregation interval.  When user starts DAMON with
    zero Aggregation interval and asks online DAMON parameter tuning via DAMON
    sysfs interface, the request is handled by the aggregation callback.
    Until the callback finishes the work, the user who requested the online
    tuning just waits.  Hence, the user will be stuck until the
    passed_sample_intervals overflows.

    Link: https://lkml.kernel.org/r/20241031183757.49610-1-sj@kernel.org
    Link: https://lkml.kernel.org/r/20241031183757.49610-2-sj@kernel.org
    Fixes: 4472edf63d66 ("mm/damon/core: use number of passed access sampling as a timer")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>	[6.7.x]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 973739c945217020fefc709c62fb1cc5585dc5ad
Author: SeongJae Park <sj@kernel.org>
Date:   Sat Sep 16 02:09:40 2023 +0000

    mm/damon/core: implement scheme-specific apply interval

    [ Upstream commit 42f994b71404b17abcd6b170de7a6aa95ffe5d4a ]

    DAMON-based operation schemes are applied for every aggregation interval.
    That was mainly because schemes were using nr_accesses, which be complete
    to be used for every aggregation interval.  However, the schemes are now
    using nr_accesses_bp, which is updated for each sampling interval in a way
    that reasonable to be used.  Therefore, there is no reason to apply
    schemes for each aggregation interval.

    The unnecessary alignment with aggregation interval was also making some
    use cases of DAMOS tricky.  Quotas setting under long aggregation interval
    is one such example.  Suppose the aggregation interval is ten seconds, and
    there is a scheme having CPU quota 100ms per 1s.  The scheme will actually
    uses 100ms per ten seconds, since it cannobe be applied before next
    aggregation interval.  The feature is working as intended, but the results
    might not that intuitive for some users.  This could be fixed by updating
    the quota to 1s per 10s.  But, in the case, the CPU usage of DAMOS could
    look like spikes, and would actually make a bad effect to other
    CPU-sensitive workloads.

    Implement a dedicated timing interval for each DAMON-based operation
    scheme, namely apply_interval.  The interval will be sampling interval
    aligned, and each scheme will be applied for its apply_interval.  The
    interval is set to 0 by default, and it means the scheme should use the
    aggregation interval instead.  This avoids old users getting any
    behavioral difference.

    Link: https://lkml.kernel.org/r/20230916020945.47296-5-sj@kernel.org
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 3488af097044 ("mm/damon/core: handle zero {aggregation,ops_update} intervals")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a326fbc8f72a320051f27328d4d4e7abdfe68d7
Author: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Date:   Tue Nov 5 08:40:23 2024 -0700

    drm/amd/display: Adjust VSDB parser for replay feature

    commit 16dd2825c23530f2259fc671960a3a65d2af69bd upstream.

    At some point, the IEEE ID identification for the replay check in the
    AMD EDID was added. However, this check causes the following
    out-of-bounds issues when using KASAN:

    [   27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu]
    [   27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383

    ...

    [   27.821207] Memory state around the buggy address:
    [   27.821215]  ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   27.821224]  ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   27.821243]                    ^
    [   27.821250]  ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   27.821259]  ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   27.821268] ==================================================================

    This is caused because the ID extraction happens outside of the range of
    the edid lenght. This commit addresses this issue by considering the
    amd_vsdb_block size.

    Cc: ChiaHsuan Chung <chiahsuan.chung@amd.com>
    Reviewed-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e91cd9a34171171c83d462256626c6a8deec2a0
Author: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Date:   Tue Nov 12 10:11:42 2024 -0600

    drm/amd: Fix initialization mistake for NBIO 7.7.0

    commit 7013a8268d311fded6c7a6528fc1de82668e75f6 upstream.

    There is a strapping issue on NBIO 7.7.0 that can lead to spurious PME
    events while in the D0 state.

    Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Link: https://lore.kernel.org/r/20241112161142.28974-1-mario.limonciello@amd.com
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 447a54a0f79c9a409ceaa17804bdd2e0206397b9)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16abd7ce81e4fedd058035d4644b3882af16732d
Author: Dave Airlie <airlied@redhat.com>
Date:   Wed Nov 13 05:57:03 2024 +1000

    nouveau: fw: sync dma after setup is called.

    commit 21ec425eaf2cb7c0371f7683f81ad7d9679b6eb5 upstream.

    When this code moved to non-coherent allocator the sync was put too
    early for some firmwares which called the setup function, move the
    sync down after the setup function.

    Reported-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
    Tested-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Fixes: 9b340aeb26d5 ("nouveau/firmware: use dma non-coherent allocator")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241114004603.3095485-1-airlied@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fc228ab5d38a026eae7183a5f74a4fac43d9b6a
Author: Peng Fan <peng.fan@nxp.com>
Date:   Fri Nov 1 18:12:51 2024 +0800

    pmdomain: imx93-blk-ctrl: correct remove path

    commit f7c7c5aa556378a2c8da72c1f7f238b6648f95fb upstream.

    The check condition should be 'i < bc->onecell_data.num_domains', not
    'bc->onecell_data.num_domains' which will make the look never finish
    and cause kernel panic.

    Also disable runtime to address
    "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"

    Fixes: e9aa77d413c9 ("soc: imx: add i.MX93 media blk ctrl driver")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
    Cc: stable@vger.kernel.org
    Message-ID: <20241101101252.1448466-1-peng.fan@oss.nxp.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a312ed8f9b232b61ed824365e737af4fcff38fe
Author: Francesco Dolcini <francesco.dolcini@toradex.com>
Date:   Thu Sep 26 16:12:46 2024 +0200

    drm/bridge: tc358768: Fix DSI command tx

    commit 32c4514455b2b8fde506f8c0962f15c7e4c26f1d upstream.

    Wait for the command transmission to be completed in the DSI transfer
    function polling for the dc_start bit to go back to idle state after the
    transmission is started.

    This is documented in the datasheet and failures to do so lead to
    commands corruption.

    Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20240926141246.48282-1-francesco@dolcini.it
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240926141246.48282-1-francesco@dolcini.it
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 930f99a21e7f13a8c72e850fb478ad69e2566ecd
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Thu Nov 7 01:42:40 2024 +0000

    mmc: sunxi-mmc: Fix A100 compatible description

    commit 85b580afc2c215394e08974bf033de9face94955 upstream.

    It turns out that the Allwinner A100/A133 SoC only supports 8K DMA
    blocks (13 bits wide), for both the SD/SDIO and eMMC instances.
    And while this alone would make a trivial fix, the H616 falls back to
    the A100 compatible string, so we have to now match the H616 compatible
    string explicitly against the description advertising 64K DMA blocks.

    As the A100 is now compatible with the D1 description, let the A100
    compatible string point to that block instead, and introduce an explicit
    match against the H616 string, pointing to the old description.
    Also remove the redundant setting of clk_delays to NULL on the way.

    Fixes: 3536b82e5853 ("mmc: sunxi: add support for A100 mmc controller")
    Cc: stable@vger.kernel.org
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Tested-by: Parthiban Nallathambi <parthiban@linumiz.com>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Message-ID: <20241107014240.24669-1-andre.przywara@arm.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56de724c58c07a7ca3aac027cfd2ccb184ed9e4e
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Sun Nov 10 12:46:36 2024 +0100

    Revert "mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K"

    commit 1635e407a4a64d08a8517ac59ca14ad4fc785e75 upstream.

    The commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages
    bigger than 4K") increased the max_req_size, even for 4K pages, causing
    various issues:
    - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566
    - Panic booting the kernel/rootfs from an SD card on StarFive JH7100
    - "swiotlb buffer is full" and data corruption on StarFive JH7110

    At this stage no fix have been found, so it's probably better to just
    revert the change.

    This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.

    Cc: stable@vger.kernel.org
    Cc: Sam Protsenko <semen.protsenko@linaro.org>
    Fixes: 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K")
    Closes: https://lore.kernel.org/linux-mmc/614692b4-1dbe-31b8-a34d-cb6db1909bb7@w6rz.net/
    Closes: https://lore.kernel.org/linux-mmc/CAC8uq=Ppnmv98mpa1CrWLawWoPnu5abtU69v-=G-P7ysATQ2Pw@mail.gmail.com/
    Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
    Message-ID: <20241110114700.622372-1-aurelien@aurel32.net>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32fc8cedcba673096694804a908a2d95110113f5
Author: Huacai Chen <chenhuacai@loongson.cn>
Date:   Tue Nov 12 16:35:39 2024 +0800

    LoongArch: Make KASAN work with 5-level page-tables

    commit a410656643ce4844ba9875aa4e87a7779308259b upstream.

    Make KASAN work with 5-level page-tables, including:
    1. Implement and use __pgd_none() and kasan_p4d_offset().
    2. As done in kasan_pmd_populate() and kasan_pte_populate(), restrict
       the loop conditions of kasan_p4d_populate() and kasan_pud_populate()
       to avoid unnecessary population.

    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4457bc909d1e1dc9d614c739f06bcb9f15111873
Author: Huacai Chen <chenhuacai@loongson.cn>
Date:   Tue Nov 12 16:35:39 2024 +0800

    LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits

    commit 227ca9f6f6aeb8aa8f0c10430b955f1fe2aeab91 upstream.

    If PGDIR_SIZE is too large for cpu_vabits, KASAN_SHADOW_END will
    overflow UINTPTR_MAX because KASAN_SHADOW_START/KASAN_SHADOW_END are
    aligned up by PGDIR_SIZE. And then the overflowed KASAN_SHADOW_END looks
    like a user space address.

    For example, PGDIR_SIZE of CONFIG_4KB_4LEVEL is 2^39, which is too large
    for Loongson-2K series whose cpu_vabits = 39.

    Since CONFIG_4KB_4LEVEL is completely legal for CPUs with cpu_vabits <=
    39, we just disable KASAN via early return in kasan_init(). Otherwise we
    get a boot failure.

    Moreover, we change KASAN_SHADOW_END from the first address after KASAN
    shadow area to the last address in KASAN shadow area, in order to avoid
    the end address exactly overflow to 0 (which is a legal case). We don't
    need to worry about alignment because pgd_addr_end() can handle it.

    Cc: stable@vger.kernel.org
    Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f04125eb9eb594e35e5fad85933c5dab76d61e42
Author: Huacai Chen <chenhuacai@loongson.cn>
Date:   Tue Nov 12 16:35:36 2024 +0800

    LoongArch: Fix early_numa_add_cpu() usage for FDT systems

    commit 30cec747d6bf2c3e915c075d76d9712e54cde0a6 upstream.

    early_numa_add_cpu() applies on physical CPU id rather than logical CPU
    id, so use cpuid instead of cpu.

    Cc: stable@vger.kernel.org
    Fixes: 3de9c42d02a79a5 ("LoongArch: Add all CPUs enabled by fdt to NUMA node 0")
    Reported-by: Bibo Mao <maobibo@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0e4765740040c44039282057ecacd7435d1d2ba
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Thu Nov 7 01:07:33 2024 +0900

    nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint

    commit 2026559a6c4ce34db117d2db8f710fe2a9420d5a upstream.

    When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty()
    may cause a NULL pointer dereference, or a general protection fault when
    KASAN is enabled.

    This happens because, since the tracepoint was added in
    mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev
    regardless of whether the buffer head has a pointer to a block_device
    structure.

    In the current implementation, nilfs_grab_buffer(), which grabs a buffer
    to read (or create) a block of metadata, including b-tree node blocks,
    does not set the block device, but instead does so only if the buffer is
    not in the "uptodate" state for each of its caller block reading
    functions.  However, if the uptodate flag is set on a folio/page, and the
    buffer heads are detached from it by try_to_free_buffers(), and new buffer
    heads are then attached by create_empty_buffers(), the uptodate flag may
    be restored to each buffer without the block device being set to
    bh->b_bdev, and mark_buffer_dirty() may be called later in that state,
    resulting in the bug mentioned above.

    Fix this issue by making nilfs_grab_buffer() always set the block device
    of the super block structure to the buffer head, regardless of the state
    of the buffer's uptodate flag.

    Link: https://lkml.kernel.org/r/20241106160811.3316-3-konishi.ryusuke@gmail.com
    Fixes: 5305cb830834 ("block: add block_{touch|dirty}_buffer tracepoint")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Ubisectech Sirius <bugreport@valiantsec.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 672668e0208f684f1430ab66a4d650a9de6f372e
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Wed Nov 6 12:21:00 2024 +0300

    ocfs2: fix UBSAN warning in ocfs2_verify_volume()

    commit 23aab037106d46e6168ce1214a958ce9bf317f2e upstream.

    Syzbot has reported the following splat triggered by UBSAN:

    UBSAN: shift-out-of-bounds in fs/ocfs2/super.c:2336:10
    shift exponent 32768 is too large for 32-bit type 'int'
    CPU: 2 UID: 0 PID: 5255 Comm: repro Not tainted 6.12.0-rc4-syzkaller-00047-gc2ee9f594da8 #0
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x241/0x360
     ? __pfx_dump_stack_lvl+0x10/0x10
     ? __pfx__printk+0x10/0x10
     ? __asan_memset+0x23/0x50
     ? lockdep_init_map_type+0xa1/0x910
     __ubsan_handle_shift_out_of_bounds+0x3c8/0x420
     ocfs2_fill_super+0xf9c/0x5750
     ? __pfx_ocfs2_fill_super+0x10/0x10
     ? __pfx_validate_chain+0x10/0x10
     ? __pfx_validate_chain+0x10/0x10
     ? validate_chain+0x11e/0x5920
     ? __lock_acquire+0x1384/0x2050
     ? __pfx_validate_chain+0x10/0x10
     ? string+0x26a/0x2b0
     ? widen_string+0x3a/0x310
     ? string+0x26a/0x2b0
     ? bdev_name+0x2b1/0x3c0
     ? pointer+0x703/0x1210
     ? __pfx_pointer+0x10/0x10
     ? __pfx_format_decode+0x10/0x10
     ? __lock_acquire+0x1384/0x2050
     ? vsnprintf+0x1ccd/0x1da0
     ? snprintf+0xda/0x120
     ? __pfx_lock_release+0x10/0x10
     ? do_raw_spin_lock+0x14f/0x370
     ? __pfx_snprintf+0x10/0x10
     ? set_blocksize+0x1f9/0x360
     ? sb_set_blocksize+0x98/0xf0
     ? setup_bdev_super+0x4e6/0x5d0
     mount_bdev+0x20c/0x2d0
     ? __pfx_ocfs2_fill_super+0x10/0x10
     ? __pfx_mount_bdev+0x10/0x10
     ? vfs_parse_fs_string+0x190/0x230
     ? __pfx_vfs_parse_fs_string+0x10/0x10
     legacy_get_tree+0xf0/0x190
     ? __pfx_ocfs2_mount+0x10/0x10
     vfs_get_tree+0x92/0x2b0
     do_new_mount+0x2be/0xb40
     ? __pfx_do_new_mount+0x10/0x10
     __se_sys_mount+0x2d6/0x3c0
     ? __pfx___se_sys_mount+0x10/0x10
     ? do_syscall_64+0x100/0x230
     ? __x64_sys_mount+0x20/0xc0
     do_syscall_64+0xf3/0x230
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f37cae96fda
    Code: 48 8b 0d 51 ce 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1e ce 0c 00 f7 d8 64 89 01 48
    RSP: 002b:00007fff6c1aa228 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
    RAX: ffffffffffffffda RBX: 00007fff6c1aa240 RCX: 00007f37cae96fda
    RDX: 00000000200002c0 RSI: 0000000020000040 RDI: 00007fff6c1aa240
    RBP: 0000000000000004 R08: 00007fff6c1aa280 R09: 0000000000000000
    R10: 00000000000008c0 R11: 0000000000000206 R12: 00000000000008c0
    R13: 00007fff6c1aa280 R14: 0000000000000003 R15: 0000000001000000
     </TASK>

    For a really damaged superblock, the value of 'i_super.s_blocksize_bits'
    may exceed the maximum possible shift for an underlying 'int'.  So add an
    extra check whether the aforementioned field represents the valid block
    size, which is 512 bytes, 1K, 2K, or 4K.

    Link: https://lkml.kernel.org/r/20241106092100.2661330-1-dmantipov@yandex.ru
    Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Reported-by: syzbot+56f7cd1abe4b8e475180@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=56f7cd1abe4b8e475180
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 037108f03ed45cdba7bdbad01b4a92847d64898f
Author: Maksym Glubokiy <maxgl.kernel@gmail.com>
Date:   Tue Nov 12 17:48:15 2024 +0200

    ALSA: hda/realtek: fix mute/micmute LEDs for a HP…
@qaz6750 qaz6750 closed this Nov 30, 2024
qaz6750 added a commit that referenced this pull request Nov 30, 2024
@qaz6750
Kernel: Merge Linux 6.6.63 Update (#4)
2ac8e58 
commit bff3e13adb72656356111d2549d8be7c872d6e15
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Nov 22 15:38:37 2024 +0100

    Linux 6.6.63

    Link: https://lore.kernel.org/r/20241120125629.623666563@linuxfoundation.org
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Hardik Garg hargar@linux.microsoft.com=0A=
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62aec1e925996a358dbfc08daf5ec26243bbafd0
Author: SeongJae Park <sj@kernel.org>
Date:   Sun Nov 19 17:15:28 2023 +0000

    mm/damon/core: copy nr_accesses when splitting region

    commit 1f3730fd9e8d4d77fb99c60d0e6ad4b1104e7e04 upstream.

    Regions split function ('damon_split_region_at()') is called at the
    beginning of an aggregation interval, and when DAMOS applying the actions
    and charging quota.  Because 'nr_accesses' fields of all regions are reset
    at the beginning of each aggregation interval, and DAMOS was applying the
    action at the end of each aggregation interval, there was no need to copy
    the 'nr_accesses' field to the split-out region.

    However, commit 42f994b71404 ("mm/damon/core: implement scheme-specific
    apply interval") made DAMOS applies action on its own timing interval.
    Hence, 'nr_accesses' should also copied to split-out regions, but the
    commit didn't.  Fix it by copying it.

    Link: https://lkml.kernel.org/r/20231119171529.66863-1-sj@kernel.org
    Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cba27abb6695b1facdd58a6480c611e3b41f1cb
Author: SeongJae Park <sj@kernel.org>
Date:   Thu Oct 31 11:37:57 2024 -0700

    mm/damon/core: handle zero schemes apply interval

    commit 8e7bde615f634a82a44b1f3d293c049fd3ef9ca9 upstream.

    DAMON's logics to determine if this is the time to apply damos schemes
    assumes next_apply_sis is always set larger than current
    passed_sample_intervals.  And therefore assume continuously incrementing
    passed_sample_intervals will make it reaches to the next_apply_sis in
    future.  The logic hence does apply the scheme and update next_apply_sis
    only if passed_sample_intervals is same to next_apply_sis.

    If Schemes apply interval is set as zero, however, next_apply_sis is set
    same to current passed_sample_intervals, respectively.  And
    passed_sample_intervals is incremented before doing the next_apply_sis
    check.  Hence, next_apply_sis becomes larger than next_apply_sis, and the
    logic says it is not the time to apply schemes and update next_apply_sis.
    In other words, DAMON stops applying schemes until passed_sample_intervals
    overflows.

    Based on the documents and the common sense, a reasonable behavior for
    such inputs would be applying the schemes for every sampling interval.
    Handle the case by removing the assumption.

    Link: https://lkml.kernel.org/r/20241031183757.49610-3-sj@kernel.org
    Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>	[6.7.x]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0fb9543b1198b797afe08c03699e90828ca8074
Author: SeongJae Park <sj@kernel.org>
Date:   Mon Feb 5 12:13:06 2024 -0800

    mm/damon/core: check apply interval in damon_do_apply_schemes()

    commit e9e3db69966d5e9e6f7e7d017b407c0025180fe5 upstream.

    kdamond_apply_schemes() checks apply intervals of schemes and avoid
    further applying any schemes if no scheme passed its apply interval.
    However, the following schemes applying function, damon_do_apply_schemes()
    iterates all schemes without the apply interval check.  As a result, the
    shortest apply interval is applied to all schemes.  Fix the problem by
    checking the apply interval in damon_do_apply_schemes().

    Link: https://lkml.kernel.org/r/20240205201306.88562-1-sj@kernel.org
    Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>	[6.7.x]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdc136e2b05fabcd780fe5f165d154eb779dfcb0
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:58 2024 +0000

    mm: resolve faulty mmap_region() error path behaviour

    [ Upstream commit 5de195060b2e251a835f622759550e6202167641 ]

    The mmap_region() function is somewhat terrifying, with spaghetti-like
    control flow and numerous means by which issues can arise and incomplete
    state, memory leaks and other unpleasantness can occur.

    A large amount of the complexity arises from trying to handle errors late
    in the process of mapping a VMA, which forms the basis of recently
    observed issues with resource leaks and observable inconsistent state.

    Taking advantage of previous patches in this series we move a number of
    checks earlier in the code, simplifying things by moving the core of the
    logic into a static internal function __mmap_region().

    Doing this allows us to perform a number of checks up front before we do
    any real work, and allows us to unwind the writable unmap check
    unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE
    validation unconditionally also.

    We move a number of things here:

    1. We preallocate memory for the iterator before we call the file-backed
       memory hook, allowing us to exit early and avoid having to perform
       complicated and error-prone close/free logic. We carefully free
       iterator state on both success and error paths.

    2. The enclosing mmap_region() function handles the mapping_map_writable()
       logic early. Previously the logic had the mapping_map_writable() at the
       point of mapping a newly allocated file-backed VMA, and a matching
       mapping_unmap_writable() on success and error paths.

       We now do this unconditionally if this is a file-backed, shared writable
       mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however
       doing so does not invalidate the seal check we just performed, and we in
       any case always decrement the counter in the wrapper.

       We perform a debug assert to ensure a driver does not attempt to do the
       opposite.

    3. We also move arch_validate_flags() up into the mmap_region()
       function. This is only relevant on arm64 and sparc64, and the check is
       only meaningful for SPARC with ADI enabled. We explicitly add a warning
       for this arch if a driver invalidates this check, though the code ought
       eventually to be fixed to eliminate the need for this.

    With all of these measures in place, we no longer need to explicitly close
    the VMA on error paths, as we place all checks which might fail prior to a
    call to any driver mmap hook.

    This eliminates an entire class of errors, makes the code easier to reason
    about and more robust.

    Link: https://lkml.kernel.org/r/6e0becb36d2f5472053ac5d544c0edfe9b899e25.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Tested-by: Mark Brown <broonie@kernel.org>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04b7efa421dc64417967ede47a88af5aca2bf578
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:57 2024 +0000

    mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling

    [ Upstream commit 5baf8b037debf4ec60108ccfeccb8636d1dbad81 ]

    Currently MTE is permitted in two circumstances (desiring to use MTE
    having been specified by the VM_MTE flag) - where MAP_ANONYMOUS is
    specified, as checked by arch_calc_vm_flag_bits() and actualised by
    setting the VM_MTE_ALLOWED flag, or if the file backing the mapping is
    shmem, in which case we set VM_MTE_ALLOWED in shmem_mmap() when the mmap
    hook is activated in mmap_region().

    The function that checks that, if VM_MTE is set, VM_MTE_ALLOWED is also
    set is the arm64 implementation of arch_validate_flags().

    Unfortunately, we intend to refactor mmap_region() to perform this check
    earlier, meaning that in the case of a shmem backing we will not have
    invoked shmem_mmap() yet, causing the mapping to fail spuriously.

    It is inappropriate to set this architecture-specific flag in general mm
    code anyway, so a sensible resolution of this issue is to instead move the
    check somewhere else.

    We resolve this by setting VM_MTE_ALLOWED much earlier in do_mmap(), via
    the arch_calc_vm_flag_bits() call.

    This is an appropriate place to do this as we already check for the
    MAP_ANONYMOUS case here, and the shmem file case is simply a variant of
    the same idea - we permit RAM-backed memory.

    This requires a modification to the arch_calc_vm_flag_bits() signature to
    pass in a pointer to the struct file associated with the mapping, however
    this is not too egregious as this is only used by two architectures anyway
    - arm64 and parisc.

    So this patch performs this adjustment and removes the unnecessary
    assignment of VM_MTE_ALLOWED in shmem_mmap().

    [akpm@linux-foundation.org: fix whitespace, per Catalin]
    Link: https://lkml.kernel.org/r/ec251b20ba1964fb64cf1607d2ad80c47f3873df.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a6d8d3f199827f017b1eabde10437957bd23c6d
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:56 2024 +0000

    mm: refactor map_deny_write_exec()

    [ Upstream commit 0fb4a7ad270b3b209e510eb9dc5b07bf02b7edaf ]

    Refactor the map_deny_write_exec() to not unnecessarily require a VMA
    parameter but rather to accept VMA flags parameters, which allows us to
    use this function early in mmap_region() in a subsequent commit.

    While we're here, we refactor the function to be more readable and add
    some additional documentation.

    Link: https://lkml.kernel.org/r/6be8bb59cd7c68006ebb006eb9d8dc27104b1f70.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Jann Horn <jannh@google.com>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a97fe6889b25648b7d990d83bf63b2f0e1f1c545
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:55 2024 +0000

    mm: unconditionally close VMAs on error

    [ Upstream commit 4080ef1579b2413435413988d14ac8c68e4d42c8 ]

    Incorrect invocation of VMA callbacks when the VMA is no longer in a
    consistent state is bug prone and risky to perform.

    With regards to the important vm_ops->close() callback We have gone to
    great lengths to try to track whether or not we ought to close VMAs.

    Rather than doing so and risking making a mistake somewhere, instead
    unconditionally close and reset vma->vm_ops to an empty dummy operations
    set with a NULL .close operator.

    We introduce a new function to do so - vma_close() - and simplify existing
    vms logic which tracked whether we needed to close or not.

    This simplifies the logic, avoids incorrect double-calling of the .close()
    callback and allows us to update error paths to simply call vma_close()
    unconditionally - making VMA closure idempotent.

    Link: https://lkml.kernel.org/r/28e89dda96f68c505cb6f8e9fc9b57c3e9f74b42.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Jann Horn <jannh@google.com>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd3ed99fca8ca713a6d532ca9d5cab4737a2f98c
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:54 2024 +0000

    mm: avoid unsafe VMA hook invocation when error arises on mmap hook

    [ Upstream commit 3dd6ed34ce1f2356a77fb88edafb5ec96784e3cf ]

    Patch series "fix error handling in mmap_region() and refactor
    (hotfixes)", v4.

    mmap_region() is somewhat terrifying, with spaghetti-like control flow and
    numerous means by which issues can arise and incomplete state, memory
    leaks and other unpleasantness can occur.

    A large amount of the complexity arises from trying to handle errors late
    in the process of mapping a VMA, which forms the basis of recently
    observed issues with resource leaks and observable inconsistent state.

    This series goes to great lengths to simplify how mmap_region() works and
    to avoid unwinding errors late on in the process of setting up the VMA for
    the new mapping, and equally avoids such operations occurring while the
    VMA is in an inconsistent state.

    The patches in this series comprise the minimal changes required to
    resolve existing issues in mmap_region() error handling, in order that
    they can be hotfixed and backported.  There is additionally a follow up
    series which goes further, separated out from the v1 series and sent and
    updated separately.

    This patch (of 5):

    After an attempted mmap() fails, we are no longer in a situation where we
    can safely interact with VMA hooks.  This is currently not enforced,
    meaning that we need complicated handling to ensure we do not incorrectly
    call these hooks.

    We can avoid the whole issue by treating the VMA as suspect the moment
    that the file->f_ops->mmap() function reports an error by replacing
    whatever VMA operations were installed with a dummy empty set of VMA
    operations.

    We do so through a new helper function internal to mm - mmap_file() -
    which is both more logically named than the existing call_mmap() function
    and correctly isolates handling of the vm_op reassignment to mm.

    All the existing invocations of call_mmap() outside of mm are ultimately
    nested within the call_mmap() from mm, which we now replace.

    It is therefore safe to leave call_mmap() in place as a convenience
        function (and to avoid churn).  The invokers are:

         ovl_file_operations -> mmap -> ovl_mmap() -> backing_file_mmap()
        coda_file_operations -> mmap -> coda_file_mmap()
         shm_file_operations -> shm_mmap()
    shm_file_operations_huge -> shm_mmap()
                dma_buf_fops -> dma_buf_mmap_internal -> i915_dmabuf_ops
                                -> i915_gem_dmabuf_mmap()

    None of these callers interact with vm_ops or mappings in a problematic
    way on error, quickly exiting out.

    Link: https://lkml.kernel.org/r/cover.1730224667.git.lorenzo.stoakes@oracle.com
    Link: https://lkml.kernel.org/r/d41fd763496fd0048a962f3fd9407dc72dd4fd86.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Jann Horn <jannh@google.com>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 172ffd26a5af13e951d0e82df7cfc5a95b04fa80
Author: George Stark <gnstark@salutedevices.com>
Date:   Thu Apr 11 19:10:31 2024 +0300

    leds: mlxreg: Use devm_mutex_init() for mutex initialization

    commit efc347b9efee1c2b081f5281d33be4559fa50a16 upstream.

    In this driver LEDs are registered using devm_led_classdev_register()
    so they are automatically unregistered after module's remove() is done.
    led_classdev_unregister() calls module's led_set_brightness() to turn off
    the LEDs and that callback uses mutex which was destroyed already
    in module's remove() so use devm API instead.

    Signed-off-by: George Stark <gnstark@salutedevices.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20240411161032.609544-8-gnstark@salutedevices.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    [ Resolve minor conflicts to fix CVE-2024-42129 ]
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a741b80b3457f079cf637e47800fb7bf8038ad6
Author: Eric Van Hensbergen <ericvh@kernel.org>
Date:   Tue Nov 19 11:43:17 2024 +0800

    fs/9p: fix uninitialized values during inode evict

    [ Upstream commit 6630036b7c228f57c7893ee0403e92c2db2cd21d ]

    If an iget fails due to not being able to retrieve information
    from the server then the inode structure is only partially
    initialized.  When the inode gets evicted, references to
    uninitialized structures (like fscache cookies) were being
    made.

    This patch checks for a bad_inode before doing anything other
    than clearing the inode from the cache.  Since the inode is
    bad, it shouldn't have any state associated with it that needs
    to be written back (and there really isn't a way to complete
    those anyways).

    Reported-by: syzbot+eb83fe1cce5833cd66a0@syzkaller.appspotmail.com
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [Xiangyu: CVE-2024-36923 Minor conflict resolution ]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f111de0f010308949254ee1cc45df8e6b8e1d7d4
Author: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Date:   Fri Oct 25 15:56:39 2024 +0100

    drm/amd/pm: Vangogh: Fix kernel memory out of bounds write

    commit 4aa923a6e6406b43566ef6ac35a3d9a3197fa3e8 upstream.

    KASAN reports that the GPU metrics table allocated in
    vangogh_tables_init() is not large enough for the memset done in
    smu_cmn_init_soft_gpu_metrics(). Condensed report follows:

    [   33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu]
    [   33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067
    ...
    [   33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G        W          6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544
    [   33.861816] Tainted: [W]=WARN
    [   33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023
    [   33.861822] Call Trace:
    [   33.861826]  <TASK>
    [   33.861829]  dump_stack_lvl+0x66/0x90
    [   33.861838]  print_report+0xce/0x620
    [   33.861853]  kasan_report+0xda/0x110
    [   33.862794]  kasan_check_range+0xfd/0x1a0
    [   33.862799]  __asan_memset+0x23/0x40
    [   33.862803]  smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.863306]  vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.864257]  vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.865682]  amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.866160]  amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
    [   33.867135]  dev_attr_show+0x43/0xc0
    [   33.867147]  sysfs_kf_seq_show+0x1f1/0x3b0
    [   33.867155]  seq_read_iter+0x3f8/0x1140
    [   33.867173]  vfs_read+0x76c/0xc50
    [   33.867198]  ksys_read+0xfb/0x1d0
    [   33.867214]  do_syscall_64+0x90/0x160
    ...
    [   33.867353] Allocated by task 378 on cpu 7 at 22.794876s:
    [   33.867358]  kasan_save_stack+0x33/0x50
    [   33.867364]  kasan_save_track+0x17/0x60
    [   33.867367]  __kasan_kmalloc+0x87/0x90
    [   33.867371]  vangogh_init_smc_tables+0x3f9/0x840 [amdgpu]
    [   33.867835]  smu_sw_init+0xa32/0x1850 [amdgpu]
    [   33.868299]  amdgpu_device_init+0x467b/0x8d90 [amdgpu]
    [   33.868733]  amdgpu_driver_load_kms+0x19/0xf0 [amdgpu]
    [   33.869167]  amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu]
    [   33.869608]  local_pci_probe+0xda/0x180
    [   33.869614]  pci_device_probe+0x43f/0x6b0

    Empirically we can confirm that the former allocates 152 bytes for the
    table, while the latter memsets the 168 large block.

    Root cause appears that when GPU metrics tables for v2_4 parts were added
    it was not considered to enlarge the table to fit.

    The fix in this patch is rather "brute force" and perhaps later should be
    done in a smarter way, by extracting and consolidating the part version to
    size logic to a common helper, instead of brute forcing the largest
    possible allocation. Nevertheless, for now this works and fixes the out of
    bounds write.

    v2:
     * Drop impossible v3_0 case. (Mario)

    Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
    Fixes: 41cec40bc9ba ("drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to acquire gpu_metrics")
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Evan Quan <evan.quan@amd.com>
    Cc: Wenyou Yang <WenYou.Yang@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20241025145639.19124-1-tursulin@igalia.com
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)
    Cc: stable@vger.kernel.org # v6.6+
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bc4569a727d776819c2fd413098882798974aae
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Mon Nov 18 19:27:24 2024 +0100

    mptcp: pm: use _rcu variant under rcu_read_lock

    commit db3eab8110bc0520416101b6a5b52f44a43fb4cf upstream.

    In mptcp_pm_create_subflow_or_signal_addr(), rcu_read_(un)lock() are
    used as expected to iterate over the list of local addresses, but
    list_for_each_entry() was used instead of list_for_each_entry_rcu() in
    __lookup_addr(). It is important to use this variant which adds the
    required READ_ONCE() (and diagnostic checks if enabled).

    Because __lookup_addr() is also used in mptcp_pm_nl_set_flags() where it
    is called under the pernet->lock and not rcu_read_lock(), an extra
    condition is then passed to help the diagnostic checks making sure
    either the associated spin lock or the RCU lock is held.

    Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20241112-net-mptcp-misc-6-12-pm-v1-3-b835580cefa8@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc3c73284d2ebd2bb6327e0c22d13b3802487370
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Mon Nov 18 19:27:23 2024 +0100

    mptcp: drop lookup_by_id in lookup_addr

    commit af250c27ea1c404e210fc3a308b20f772df584d6 upstream.

    When the lookup_by_id parameter of __lookup_addr() is true, it's the same
    as __lookup_addr_by_id(), it can be replaced by __lookup_addr_by_id()
    directly. So drop this parameter, let __lookup_addr() only looks up address
    on the local address list by comparing addresses in it, not address ids.

    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240305-upstream-net-next-20240304-mptcp-misc-cleanup-v1-4-c436ba5e569b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: db3eab8110bc ("mptcp: pm: use _rcu variant under rcu_read_lock")
    [ Conflicts in pm_netlink.c, because commit 6a42477fe449 ("mptcp: update
      set_flags interfaces") is not in this version, and causes too many
      conflicts when backporting it. The conflict is easy to resolve: addr
      is a pointer here here in mptcp_pm_nl_set_flags(), the rest of the
      code is the same. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 416001b0412f7fb1ace54457f55b95f080376cbe
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Mon Nov 18 19:27:22 2024 +0100

    mptcp: hold pm lock when deleting entry

    commit f642c5c4d528d11bd78b6c6f84f541cd3c0bea86 upstream.

    When traversing userspace_pm_local_addr_list and deleting an entry from
    it in mptcp_pm_nl_remove_doit(), msk->pm.lock should be held.

    This patch holds this lock before mptcp_userspace_pm_lookup_addr_by_id()
    and releases it after list_move() in mptcp_pm_nl_remove_doit().

    Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20241112-net-mptcp-misc-6-12-pm-v1-2-b835580cefa8@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac56c5e80e1f3297c54780c70da7ba85cc516b51
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Mon Nov 18 19:27:21 2024 +0100

    mptcp: update local address flags when setting it

    commit e0266319413d5d687ba7b6df7ca99e4b9724a4f2 upstream.

    Just like in-kernel pm, when userspace pm does set_flags, it needs to send
    out MP_PRIO signal, and also modify the flags of the corresponding address
    entry in the local address list. This patch implements the missing logic.

    Traverse all address entries on userspace_pm_local_addr_list to find the
    local address entry, if bkup is true, set the flags of this entry with
    FLAG_BACKUP, otherwise, clear FLAG_BACKUP.

    Fixes: 892f396c8e68 ("mptcp: netlink: issue MP_PRIO signals from userspace PMs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20241112-net-mptcp-misc-6-12-pm-v1-1-b835580cefa8@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_userspace.c, because commit 6a42477fe449 ("mptcp:
      update set_flags interfaces"), is not in this version, and causes too
      many conflicts when backporting it. The same code can still be added
      at the same place, before sending the ACK. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa2b28ddcc260bfdda568a5b82dcf6b6e3bc5245
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Mon Nov 18 19:27:20 2024 +0100

    mptcp: add userspace_pm_lookup_addr_by_id helper

    commit 06afe09091ee69dc7ab058b4be9917ae59cc81e5 upstream.

    Corresponding __lookup_addr_by_id() helper in the in-kernel netlink PM,
    this patch adds a new helper mptcp_userspace_pm_lookup_addr_by_id() to
    lookup the address entry with the given id on the userspace pm local
    address list.

    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: f642c5c4d528 ("mptcp: hold pm lock when deleting entry")
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 762ca2d2e3c764787ffe820357873760b70dde6a
Author: Geliang Tang <geliang.tang@suse.com>
Date:   Mon Nov 18 19:27:19 2024 +0100

    mptcp: define more local variables sk

    commit 14cb0e0bf39bd10429ba14e9e2f905f1144226fc upstream.

    '(struct sock *)msk' is used several times in mptcp_nl_cmd_announce(),
    mptcp_nl_cmd_remove() or mptcp_userspace_pm_set_flags() in pm_userspace.c,
    it's worth adding a local variable sk to point it.

    Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: Geliang Tang <geliang.tang@suse.com>
    Signed-off-by: Mat Martineau <martineau@kernel.org>
    Link: https://lore.kernel.org/r/20231025-send-net-next-20231025-v1-8-db8f25f798eb@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 06afe09091ee ("mptcp: add userspace_pm_lookup_addr_by_id helper")
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb79d68a36e21960341ccab07d1ac06d93830321
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Nov 18 16:14:13 2024 -0500

    NFSD: Never decrement pending_async_copies on error

    [ Upstream commit 8286f8b622990194207df9ab852e0f87c60d35e9 ]

    The error flow in nfsd4_copy() calls cleanup_async_copy(), which
    already decrements nn->pending_async_copies.

    Reported-by: Olga Kornievskaia <okorniev@redhat.com>
    Fixes: aadc3bbea163 ("NFSD: Limit the number of concurrent async COPY operations")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 421f1a2a1afb47d88de09457ef7687e1df7bc997
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Nov 18 16:14:12 2024 -0500

    NFSD: Initialize struct nfsd4_copy earlier

    [ Upstream commit 63fab04cbd0f96191b6e5beedc3b643b01c15889 ]

    Ensure the refcount and async_copies fields are initialized early.
    cleanup_async_copy() will reference these fields if an error occurs
    in nfsd4_copy(). If they are not correctly initialized, at the very
    least, a refcount underflow occurs.

    Reported-by: Olga Kornievskaia <okorniev@redhat.com>
    Fixes: aadc3bbea163 ("NFSD: Limit the number of concurrent async COPY operations")
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Tested-by: Olga Kornievskaia <okorniev@redhat.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae267989b7b7933dfedcd26468d0a88fc3a9da9e
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Nov 18 16:14:11 2024 -0500

    NFSD: Limit the number of concurrent async COPY operations

    [ Upstream commit aadc3bbea163b6caaaebfdd2b6c4667fbc726752 ]

    Nothing appears to limit the number of concurrent async COPY
    operations that clients can start. In addition, AFAICT each async
    COPY can copy an unlimited number of 4MB chunks, so can run for a
    long time. Thus IMO async COPY can become a DoS vector.

    Add a restriction mechanism that bounds the number of concurrent
    background COPY operations. Start simple and try to be fair -- this
    patch implements a per-namespace limit.

    An async COPY request that occurs while this limit is exceeded gets
    NFS4ERR_DELAY. The requesting client can choose to send the request
    again after a delay or fall back to a traditional read/write style
    copy.

    If there is need to make the mechanism more sophisticated, we can
    visit that in future patches.

    Cc: stable@vger.kernel.org
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Link: https://nvd.nist.gov/vuln/detail/CVE-2024-49974
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20a10c78ac3a8b608dca7c42bd6a982b192f55dd
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Nov 18 16:14:10 2024 -0500

    NFSD: Async COPY result needs to return a write verifier

    [ Upstream commit 9ed666eba4e0a2bb8ffaa3739d830b64d4f2aaad ]

    Currently, when NFSD handles an asynchronous COPY, it returns a
    zero write verifier, relying on the subsequent CB_OFFLOAD callback
    to pass the write verifier and a stable_how4 value to the client.

    However, if the CB_OFFLOAD never arrives at the client (for example,
    if a network partition occurs just as the server sends the
    CB_OFFLOAD operation), the client will never receive this verifier.
    Thus, if the client sends a follow-up COMMIT, there is no way for
    the client to assess the COMMIT result.

    The usual recovery for a missing CB_OFFLOAD is for the client to
    send an OFFLOAD_STATUS operation, but that operation does not carry
    a write verifier in its result. Neither does it carry a stable_how4
    value, so the client /must/ send a COMMIT in this case -- which will
    always fail because currently there's still no write verifier in the
    COPY result.

    Thus the server needs to return a normal write verifier in its COPY
    result even if the COPY operation is to be performed asynchronously.

    If the server recognizes the callback stateid in subsequent
    OFFLOAD_STATUS operations, then obviously it has not restarted, and
    the write verifier the client received in the COPY result is still
    valid and can be used to assess a COMMIT of the copied data, if one
    is needed.

    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    [ cel: adjusted to apply to origin/linux-6.6.y ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74115b3e41c7ed88d53dce9c6091b38c02de02f9
Author: Dai Ngo <dai.ngo@oracle.com>
Date:   Mon Nov 18 16:14:09 2024 -0500

    NFSD: initialize copy->cp_clp early in nfsd4_copy for use by trace point

    [ Upstream commit 15d1975b7279693d6f09398e0e2e31aca2310275 ]

    Prepare for adding server copy trace points.

    Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
    Tested-by: Chen Hanxiao <chenhx.fnst@fujitsu.com>
    Stable-dep-of: 9ed666eba4e0 ("NFSD: Async COPY result needs to return a write verifier")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db12e874e1a202206c734d89920e4aa9e290efa2
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date:   Wed Nov 6 21:50:55 2024 +0100

    media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set

    commit a4aebaf6e6efff548b01a3dc49b4b9074751c15b upstream.

    When CONFIG_DVB_DYNAMIC_MINORS, ret is not initialized, and a
    semaphore is left at the wrong state, in case of errors.

    Make the code simpler and avoid mistakes by having just one error
    check logic used weather DVB_DYNAMIC_MINORS is used or not.

    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/r/202410201717.ULWWdJv8-lkp@intel.com/
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Link: https://lore.kernel.org/r/9e067488d8935b8cf00959764a1fa5de85d65725.1730926254.git.mchehab+huawei@kernel.org
    Cc: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efb258ec337f34962606620fe0f77808edf9f92d
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Mon Nov 4 18:52:55 2024 +0100

    lib/buildid: Fix build ID parsing logic

    The parse_build_id_buf does not account Elf32_Nhdr header size
    when getting the build id data pointer and returns wrong build
    id data as result.

    This is problem only for stable trees that merged c83a80d8b84f
    fix, the upstream build id code was refactored and returns proper
    build id.

    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Fixes: c83a80d8b84f ("lib/buildid: harden build ID parsing logic")
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c623f5692a0f9e77c2e2aea487b353fd235306d
Author: Umang Jain <umang.jain@ideasonboard.com>
Date:   Wed Oct 16 18:32:24 2024 +0530

    staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation

    [ Upstream commit 404b739e895522838f1abdc340c554654d671dde ]

    The struct vchiq_arm_state 'platform_state' is currently allocated
    dynamically using kzalloc(). Unfortunately, it is never freed and is
    subjected to memory leaks in the error handling paths of the probe()
    function.

    To address the issue, use device resource management helper
    devm_kzalloc(), to ensure cleanup after its allocation.

    Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/20241016130225.61024-2-umang.jain@ideasonboard.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6dee8f99c69068480e88121cbd38c267b0b60e08
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Fri Jun 21 15:19:53 2024 +0200

    staging: vchiq_arm: Get the rid off struct vchiq_2835_state

    [ Upstream commit 4e2766102da632f26341d5539519b0abf73df887 ]

    The whole benefit of this encapsulating struct is questionable.
    It just stores a flag to signalize the init state of vchiq_arm_state.
    Beside the fact this flag is set too soon, the access to uninitialized
    members should be avoided. So initialize vchiq_arm_state properly before
    assign it directly to vchiq_state.

    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://lore.kernel.org/r/20240621131958.98208-6-wahrenst@gmx.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 404b739e8955 ("staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6bfed8babc1a3d1be4bc671adcd583616225997d
Author: SeongJae Park <sj@kernel.org>
Date:   Thu Oct 31 11:37:56 2024 -0700

    mm/damon/core: handle zero {aggregation,ops_update} intervals

    [ Upstream commit 3488af0970445ff5532c7e8dc5e6456b877aee5e ]

    Patch series "mm/damon/core: fix handling of zero non-sampling intervals".

    DAMON's internal intervals accounting logic is not correctly handling
    non-sampling intervals of zero values for a wrong assumption.  This could
    cause unexpected monitoring behavior, and even result in infinite hang of
    DAMON sysfs interface user threads in case of zero aggregation interval.
    Fix those by updating the intervals accounting logic.  For details of the
    root case and solutions, please refer to commit messages of fixes.

    This patch (of 2):

    DAMON's logics to determine if this is the time to do aggregation and ops
    update assumes next_{aggregation,ops_update}_sis are always set larger
    than current passed_sample_intervals.  And therefore it further assumes
    continuously incrementing passed_sample_intervals every sampling interval
    will make it reaches to the next_{aggregation,ops_update}_sis in future.
    The logic therefore make the action and update
    next_{aggregation,ops_updaste}_sis only if passed_sample_intervals is same
    to the counts, respectively.

    If Aggregation interval or Ops update interval are zero, however,
    next_aggregation_sis or next_ops_update_sis are set same to current
    passed_sample_intervals, respectively.  And passed_sample_intervals is
    incremented before doing the next_{aggregation,ops_update}_sis check.
    Hence, passed_sample_intervals becomes larger than
    next_{aggregation,ops_update}_sis, and the logic says it is not the time
    to do the action and update next_{aggregation,ops_update}_sis forever,
    until an overflow happens.  In other words, DAMON stops doing aggregations
    or ops updates effectively forever, and users cannot get monitoring
    results.

    Based on the documents and the common sense, a reasonable behavior for
    such inputs is doing an aggregation and an ops update for every sampling
    interval.  Handle the case by removing the assumption.

    Note that this could incur particular real issue for DAMON sysfs interface
    users, in case of zero Aggregation interval.  When user starts DAMON with
    zero Aggregation interval and asks online DAMON parameter tuning via DAMON
    sysfs interface, the request is handled by the aggregation callback.
    Until the callback finishes the work, the user who requested the online
    tuning just waits.  Hence, the user will be stuck until the
    passed_sample_intervals overflows.

    Link: https://lkml.kernel.org/r/20241031183757.49610-1-sj@kernel.org
    Link: https://lkml.kernel.org/r/20241031183757.49610-2-sj@kernel.org
    Fixes: 4472edf63d66 ("mm/damon/core: use number of passed access sampling as a timer")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>	[6.7.x]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 973739c945217020fefc709c62fb1cc5585dc5ad
Author: SeongJae Park <sj@kernel.org>
Date:   Sat Sep 16 02:09:40 2023 +0000

    mm/damon/core: implement scheme-specific apply interval

    [ Upstream commit 42f994b71404b17abcd6b170de7a6aa95ffe5d4a ]

    DAMON-based operation schemes are applied for every aggregation interval.
    That was mainly because schemes were using nr_accesses, which be complete
    to be used for every aggregation interval.  However, the schemes are now
    using nr_accesses_bp, which is updated for each sampling interval in a way
    that reasonable to be used.  Therefore, there is no reason to apply
    schemes for each aggregation interval.

    The unnecessary alignment with aggregation interval was also making some
    use cases of DAMOS tricky.  Quotas setting under long aggregation interval
    is one such example.  Suppose the aggregation interval is ten seconds, and
    there is a scheme having CPU quota 100ms per 1s.  The scheme will actually
    uses 100ms per ten seconds, since it cannobe be applied before next
    aggregation interval.  The feature is working as intended, but the results
    might not that intuitive for some users.  This could be fixed by updating
    the quota to 1s per 10s.  But, in the case, the CPU usage of DAMOS could
    look like spikes, and would actually make a bad effect to other
    CPU-sensitive workloads.

    Implement a dedicated timing interval for each DAMON-based operation
    scheme, namely apply_interval.  The interval will be sampling interval
    aligned, and each scheme will be applied for its apply_interval.  The
    interval is set to 0 by default, and it means the scheme should use the
    aggregation interval instead.  This avoids old users getting any
    behavioral difference.

    Link: https://lkml.kernel.org/r/20230916020945.47296-5-sj@kernel.org
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 3488af097044 ("mm/damon/core: handle zero {aggregation,ops_update} intervals")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a326fbc8f72a320051f27328d4d4e7abdfe68d7
Author: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Date:   Tue Nov 5 08:40:23 2024 -0700

    drm/amd/display: Adjust VSDB parser for replay feature

    commit 16dd2825c23530f2259fc671960a3a65d2af69bd upstream.

    At some point, the IEEE ID identification for the replay check in the
    AMD EDID was added. However, this check causes the following
    out-of-bounds issues when using KASAN:

    [   27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu]
    [   27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383

    ...

    [   27.821207] Memory state around the buggy address:
    [   27.821215]  ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   27.821224]  ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   27.821243]                    ^
    [   27.821250]  ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   27.821259]  ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   27.821268] ==================================================================

    This is caused because the ID extraction happens outside of the range of
    the edid lenght. This commit addresses this issue by considering the
    amd_vsdb_block size.

    Cc: ChiaHsuan Chung <chiahsuan.chung@amd.com>
    Reviewed-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e91cd9a34171171c83d462256626c6a8deec2a0
Author: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Date:   Tue Nov 12 10:11:42 2024 -0600

    drm/amd: Fix initialization mistake for NBIO 7.7.0

    commit 7013a8268d311fded6c7a6528fc1de82668e75f6 upstream.

    There is a strapping issue on NBIO 7.7.0 that can lead to spurious PME
    events while in the D0 state.

    Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Link: https://lore.kernel.org/r/20241112161142.28974-1-mario.limonciello@amd.com
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 447a54a0f79c9a409ceaa17804bdd2e0206397b9)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16abd7ce81e4fedd058035d4644b3882af16732d
Author: Dave Airlie <airlied@redhat.com>
Date:   Wed Nov 13 05:57:03 2024 +1000

    nouveau: fw: sync dma after setup is called.

    commit 21ec425eaf2cb7c0371f7683f81ad7d9679b6eb5 upstream.

    When this code moved to non-coherent allocator the sync was put too
    early for some firmwares which called the setup function, move the
    sync down after the setup function.

    Reported-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
    Tested-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Fixes: 9b340aeb26d5 ("nouveau/firmware: use dma non-coherent allocator")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241114004603.3095485-1-airlied@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fc228ab5d38a026eae7183a5f74a4fac43d9b6a
Author: Peng Fan <peng.fan@nxp.com>
Date:   Fri Nov 1 18:12:51 2024 +0800

    pmdomain: imx93-blk-ctrl: correct remove path

    commit f7c7c5aa556378a2c8da72c1f7f238b6648f95fb upstream.

    The check condition should be 'i < bc->onecell_data.num_domains', not
    'bc->onecell_data.num_domains' which will make the look never finish
    and cause kernel panic.

    Also disable runtime to address
    "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"

    Fixes: e9aa77d413c9 ("soc: imx: add i.MX93 media blk ctrl driver")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
    Cc: stable@vger.kernel.org
    Message-ID: <20241101101252.1448466-1-peng.fan@oss.nxp.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a312ed8f9b232b61ed824365e737af4fcff38fe
Author: Francesco Dolcini <francesco.dolcini@toradex.com>
Date:   Thu Sep 26 16:12:46 2024 +0200

    drm/bridge: tc358768: Fix DSI command tx

    commit 32c4514455b2b8fde506f8c0962f15c7e4c26f1d upstream.

    Wait for the command transmission to be completed in the DSI transfer
    function polling for the dc_start bit to go back to idle state after the
    transmission is started.

    This is documented in the datasheet and failures to do so lead to
    commands corruption.

    Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20240926141246.48282-1-francesco@dolcini.it
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240926141246.48282-1-francesco@dolcini.it
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 930f99a21e7f13a8c72e850fb478ad69e2566ecd
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Thu Nov 7 01:42:40 2024 +0000

    mmc: sunxi-mmc: Fix A100 compatible description

    commit 85b580afc2c215394e08974bf033de9face94955 upstream.

    It turns out that the Allwinner A100/A133 SoC only supports 8K DMA
    blocks (13 bits wide), for both the SD/SDIO and eMMC instances.
    And while this alone would make a trivial fix, the H616 falls back to
    the A100 compatible string, so we have to now match the H616 compatible
    string explicitly against the description advertising 64K DMA blocks.

    As the A100 is now compatible with the D1 description, let the A100
    compatible string point to that block instead, and introduce an explicit
    match against the H616 string, pointing to the old description.
    Also remove the redundant setting of clk_delays to NULL on the way.

    Fixes: 3536b82e5853 ("mmc: sunxi: add support for A100 mmc controller")
    Cc: stable@vger.kernel.org
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Tested-by: Parthiban Nallathambi <parthiban@linumiz.com>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Message-ID: <20241107014240.24669-1-andre.przywara@arm.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56de724c58c07a7ca3aac027cfd2ccb184ed9e4e
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Sun Nov 10 12:46:36 2024 +0100

    Revert "mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K"

    commit 1635e407a4a64d08a8517ac59ca14ad4fc785e75 upstream.

    The commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages
    bigger than 4K") increased the max_req_size, even for 4K pages, causing
    various issues:
    - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566
    - Panic booting the kernel/rootfs from an SD card on StarFive JH7100
    - "swiotlb buffer is full" and data corruption on StarFive JH7110

    At this stage no fix have been found, so it's probably better to just
    revert the change.

    This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.

    Cc: stable@vger.kernel.org
    Cc: Sam Protsenko <semen.protsenko@linaro.org>
    Fixes: 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K")
    Closes: https://lore.kernel.org/linux-mmc/614692b4-1dbe-31b8-a34d-cb6db1909bb7@w6rz.net/
    Closes: https://lore.kernel.org/linux-mmc/CAC8uq=Ppnmv98mpa1CrWLawWoPnu5abtU69v-=G-P7ysATQ2Pw@mail.gmail.com/
    Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
    Message-ID: <20241110114700.622372-1-aurelien@aurel32.net>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32fc8cedcba673096694804a908a2d95110113f5
Author: Huacai Chen <chenhuacai@loongson.cn>
Date:   Tue Nov 12 16:35:39 2024 +0800

    LoongArch: Make KASAN work with 5-level page-tables

    commit a410656643ce4844ba9875aa4e87a7779308259b upstream.

    Make KASAN work with 5-level page-tables, including:
    1. Implement and use __pgd_none() and kasan_p4d_offset().
    2. As done in kasan_pmd_populate() and kasan_pte_populate(), restrict
       the loop conditions of kasan_p4d_populate() and kasan_pud_populate()
       to avoid unnecessary population.

    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4457bc909d1e1dc9d614c739f06bcb9f15111873
Author: Huacai Chen <chenhuacai@loongson.cn>
Date:   Tue Nov 12 16:35:39 2024 +0800

    LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits

    commit 227ca9f6f6aeb8aa8f0c10430b955f1fe2aeab91 upstream.

    If PGDIR_SIZE is too large for cpu_vabits, KASAN_SHADOW_END will
    overflow UINTPTR_MAX because KASAN_SHADOW_START/KASAN_SHADOW_END are
    aligned up by PGDIR_SIZE. And then the overflowed KASAN_SHADOW_END looks
    like a user space address.

    For example, PGDIR_SIZE of CONFIG_4KB_4LEVEL is 2^39, which is too large
    for Loongson-2K series whose cpu_vabits = 39.

    Since CONFIG_4KB_4LEVEL is completely legal for CPUs with cpu_vabits <=
    39, we just disable KASAN via early return in kasan_init(). Otherwise we
    get a boot failure.

    Moreover, we change KASAN_SHADOW_END from the first address after KASAN
    shadow area to the last address in KASAN shadow area, in order to avoid
    the end address exactly overflow to 0 (which is a legal case). We don't
    need to worry about alignment because pgd_addr_end() can handle it.

    Cc: stable@vger.kernel.org
    Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f04125eb9eb594e35e5fad85933c5dab76d61e42
Author: Huacai Chen <chenhuacai@loongson.cn>
Date:   Tue Nov 12 16:35:36 2024 +0800

    LoongArch: Fix early_numa_add_cpu() usage for FDT systems

    commit 30cec747d6bf2c3e915c075d76d9712e54cde0a6 upstream.

    early_numa_add_cpu() applies on physical CPU id rather than logical CPU
    id, so use cpuid instead of cpu.

    Cc: stable@vger.kernel.org
    Fixes: 3de9c42d02a79a5 ("LoongArch: Add all CPUs enabled by fdt to NUMA node 0")
    Reported-by: Bibo Mao <maobibo@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0e4765740040c44039282057ecacd7435d1d2ba
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Thu Nov 7 01:07:33 2024 +0900

    nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint

    commit 2026559a6c4ce34db117d2db8f710fe2a9420d5a upstream.

    When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty()
    may cause a NULL pointer dereference, or a general protection fault when
    KASAN is enabled.

    This happens because, since the tracepoint was added in
    mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev
    regardless of whether the buffer head has a pointer to a block_device
    structure.

    In the current implementation, nilfs_grab_buffer(), which grabs a buffer
    to read (or create) a block of metadata, including b-tree node blocks,
    does not set the block device, but instead does so only if the buffer is
    not in the "uptodate" state for each of its caller block reading
    functions.  However, if the uptodate flag is set on a folio/page, and the
    buffer heads are detached from it by try_to_free_buffers(), and new buffer
    heads are then attached by create_empty_buffers(), the uptodate flag may
    be restored to each buffer without the block device being set to
    bh->b_bdev, and mark_buffer_dirty() may be called later in that state,
    resulting in the bug mentioned above.

    Fix this issue by making nilfs_grab_buffer() always set the block device
    of the super block structure to the buffer head, regardless of the state
    of the buffer's uptodate flag.

    Link: https://lkml.kernel.org/r/20241106160811.3316-3-konishi.ryusuke@gmail.com
    Fixes: 5305cb830834 ("block: add block_{touch|dirty}_buffer tracepoint")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Ubisectech Sirius <bugreport@valiantsec.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 672668e0208f684f1430ab66a4d650a9de6f372e
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Wed Nov 6 12:21:00 2024 +0300

    ocfs2: fix UBSAN warning in ocfs2_verify_volume()

    commit 23aab037106d46e6168ce1214a958ce9bf317f2e upstream.

    Syzbot has reported the following splat triggered by UBSAN:

    UBSAN: shift-out-of-bounds in fs/ocfs2/super.c:2336:10
    shift exponent 32768 is too large for 32-bit type 'int'
    CPU: 2 UID: 0 PID: 5255 Comm: repro Not tainted 6.12.0-rc4-syzkaller-00047-gc2ee9f594da8 #0
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x241/0x360
     ? __pfx_dump_stack_lvl+0x10/0x10
     ? __pfx__printk+0x10/0x10
     ? __asan_memset+0x23/0x50
     ? lockdep_init_map_type+0xa1/0x910
     __ubsan_handle_shift_out_of_bounds+0x3c8/0x420
     ocfs2_fill_super+0xf9c/0x5750
     ? __pfx_ocfs2_fill_super+0x10/0x10
     ? __pfx_validate_chain+0x10/0x10
     ? __pfx_validate_chain+0x10/0x10
     ? validate_chain+0x11e/0x5920
     ? __lock_acquire+0x1384/0x2050
     ? __pfx_validate_chain+0x10/0x10
     ? string+0x26a/0x2b0
     ? widen_string+0x3a/0x310
     ? string+0x26a/0x2b0
     ? bdev_name+0x2b1/0x3c0
     ? pointer+0x703/0x1210
     ? __pfx_pointer+0x10/0x10
     ? __pfx_format_decode+0x10/0x10
     ? __lock_acquire+0x1384/0x2050
     ? vsnprintf+0x1ccd/0x1da0
     ? snprintf+0xda/0x120
     ? __pfx_lock_release+0x10/0x10
     ? do_raw_spin_lock+0x14f/0x370
     ? __pfx_snprintf+0x10/0x10
     ? set_blocksize+0x1f9/0x360
     ? sb_set_blocksize+0x98/0xf0
     ? setup_bdev_super+0x4e6/0x5d0
     mount_bdev+0x20c/0x2d0
     ? __pfx_ocfs2_fill_super+0x10/0x10
     ? __pfx_mount_bdev+0x10/0x10
     ? vfs_parse_fs_string+0x190/0x230
     ? __pfx_vfs_parse_fs_string+0x10/0x10
     legacy_get_tree+0xf0/0x190
     ? __pfx_ocfs2_mount+0x10/0x10
     vfs_get_tree+0x92/0x2b0
     do_new_mount+0x2be/0xb40
     ? __pfx_do_new_mount+0x10/0x10
     __se_sys_mount+0x2d6/0x3c0
     ? __pfx___se_sys_mount+0x10/0x10
     ? do_syscall_64+0x100/0x230
     ? __x64_sys_mount+0x20/0xc0
     do_syscall_64+0xf3/0x230
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f37cae96fda
    Code: 48 8b 0d 51 ce 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1e ce 0c 00 f7 d8 64 89 01 48
    RSP: 002b:00007fff6c1aa228 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
    RAX: ffffffffffffffda RBX: 00007fff6c1aa240 RCX: 00007f37cae96fda
    RDX: 00000000200002c0 RSI: 0000000020000040 RDI: 00007fff6c1aa240
    RBP: 0000000000000004 R08: 00007fff6c1aa280 R09: 0000000000000000
    R10: 00000000000008c0 R11: 0000000000000206 R12: 00000000000008c0
    R13: 00007fff6c1aa280 R14: 0000000000000003 R15: 0000000001000000
     </TASK>

    For a really damaged superblock, the value of 'i_super.s_blocksize_bits'
    may exceed the maximum possible shift for an underlying 'int'.  So add an
    extra check whether the aforementioned field represents the valid block
    size, which is 512 bytes, 1K, 2K, or 4K.

    Link: https://lkml.kernel.org/r/20241106092100.2661330-1-dmantipov@yandex.ru
    Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Reported-by: syzbot+56f7cd1abe4b8e475180@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=56f7cd1abe4b8e475180
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 037108f03ed45cdba7bdbad01b4a92847d64898f
Author: Maksym Glubokiy <maxgl.kernel@gmail.com>
Date:   Tue Nov 12 17:48:15 2024 +0200

    ALSA: hda/realtek: fix mute/micmute LEDs for a HP…
qaz6750 pushed a commit that referenced this pull request Jan 17, 2025
@gregkh
sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers
2d2b19e 
[ Upstream commit fd7b4f9 ]

When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the
object_is_on_stack() function may produce incorrect results due to the
presence of tags in the obj pointer, while the stack pointer does not have
tags.  This discrepancy can lead to incorrect stack object detection and
subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled.

Example of the warning:

ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4
Hardware name: linux,dummy-virt (DT)
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __debug_object_init+0x330/0x364
lr : __debug_object_init+0x330/0x364
sp : ffff800082ea7b40
x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534
x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0
x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418
x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000
x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e
x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e
x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800
x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001
x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4
x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050
Call trace:
 __debug_object_init+0x330/0x364
 debug_object_init_on_stack+0x30/0x3c
 schedule_hrtimeout_range_clock+0xac/0x26c
 schedule_hrtimeout+0x1c/0x30
 wait_task_inactive+0x1d4/0x25c
 kthread_bind_mask+0x28/0x98
 init_rescuer+0x1e8/0x280
 workqueue_init+0x1a0/0x3cc
 kernel_init_freeable+0x118/0x200
 kernel_init+0x28/0x1f0
 ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated.
------------[ cut here ]------------

Link: https://lkml.kernel.org/r/20241113042544.19095-1-qun-wei.lin@mediatek.com
Signed-off-by: Qun-Wei Lin <qun-wei.lin@mediatek.com>
Cc: Andrew Yang <andrew.yang@mediatek.com>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: Casper Li <casper.li@mediatek.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chinwen Chang <chinwen.chang@mediatek.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ Resolve line conflicts ]
Signed-off-by: Wenshan Lan <jetlan9@163.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
qaz6750 pushed a commit that referenced this pull request Jan 17, 2025
@alessandrocarminati @gregkh
mm/kmemleak: fix sleeping function called from invalid context at pri…
86d946f 
…nt message

commit cddc76b upstream.

Address a bug in the kernel that triggers a "sleeping function called from
invalid context" warning when /sys/kernel/debug/kmemleak is printed under
specific conditions:
- CONFIG_PREEMPT_RT=y
- Set SELinux as the LSM for the system
- Set kptr_restrict to 1
- kmemleak buffer contains at least one item

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 136, name: cat
preempt_count: 1, expected: 0
RCU nest depth: 2, expected: 2
6 locks held by cat/136:
 #0: ffff32e64bcbf950 (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0xb8/0xe30
 #1: ffffafe6aaa9dea0 (scan_mutex){+.+.}-{3:3}, at: kmemleak_seq_start+0x34/0x128
 #3: ffff32e6546b1cd0 (&object->lock){....}-{2:2}, at: kmemleak_seq_show+0x3c/0x1e0
 #4: ffffafe6aa8d8560 (rcu_read_lock){....}-{1:2}, at: has_ns_capability_noaudit+0x8/0x1b0
 #5: ffffafe6aabbc0f8 (notif_lock){+.+.}-{2:2}, at: avc_compute_av+0xc4/0x3d0
irq event stamp: 136660
hardirqs last  enabled at (136659): [<ffffafe6a80fd7a0>] _raw_spin_unlock_irqrestore+0xa8/0xd8
hardirqs last disabled at (136660): [<ffffafe6a80fd85c>] _raw_spin_lock_irqsave+0x8c/0xb0
softirqs last  enabled at (0): [<ffffafe6a5d50b28>] copy_process+0x11d8/0x3df8
softirqs last disabled at (0): [<0000000000000000>] 0x0
Preemption disabled at:
[<ffffafe6a6598a4c>] kmemleak_seq_show+0x3c/0x1e0
CPU: 1 UID: 0 PID: 136 Comm: cat Tainted: G            E      6.11.0-rt7+ #34
Tainted: [E]=UNSIGNED_MODULE
Hardware name: linux,dummy-virt (DT)
Call trace:
 dump_backtrace+0xa0/0x128
 show_stack+0x1c/0x30
 dump_stack_lvl+0xe8/0x198
 dump_stack+0x18/0x20
 rt_spin_lock+0x8c/0x1a8
 avc_perm_nonode+0xa0/0x150
 cred_has_capability.isra.0+0x118/0x218
 selinux_capable+0x50/0x80
 security_capable+0x7c/0xd0
 has_ns_capability_noaudit+0x94/0x1b0
 has_capability_noaudit+0x20/0x30
 restricted_pointer+0x21c/0x4b0
 pointer+0x298/0x760
 vsnprintf+0x330/0xf70
 seq_printf+0x178/0x218
 print_unreferenced+0x1a4/0x2d0
 kmemleak_seq_show+0xd0/0x1e0
 seq_read_iter+0x354/0xe30
 seq_read+0x250/0x378
 full_proxy_read+0xd8/0x148
 vfs_read+0x190/0x918
 ksys_read+0xf0/0x1e0
 __arm64_sys_read+0x70/0xa8
 invoke_syscall.constprop.0+0xd4/0x1d8
 el0_svc+0x50/0x158
 el0t_64_sync+0x17c/0x180

%pS and %pK, in the same back trace line, are redundant, and %pS can void
%pK service in certain contexts.

%pS alone already provides the necessary information, and if it cannot
resolve the symbol, it falls back to printing the raw address voiding
the original intent behind the %pK.

Additionally, %pK requires a privilege check CAP_SYSLOG enforced through
the LSM, which can trigger a "sleeping function called from invalid
context" warning under RT_PREEMPT kernels when the check occurs in an
atomic context. This issue may also affect other LSMs.

This change avoids the unnecessary privilege check and resolves the
sleeping function warning without any loss of information.

Link: https://lkml.kernel.org/r/20241217142032.55793-1-acarmina@redhat.com
Fixes: 3a6f33d ("mm/kmemleak: use %pK to display kernel pointers in backtrace")
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Clément Léger <clement.leger@bootlin.com>
Cc: Alessandro Carminati <acarmina@redhat.com>
Cc: Eric Chanudet <echanude@redhat.com>
Cc: Gabriele Paoloni <gpaoloni@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
qaz6750 pushed a commit that referenced this pull request Jan 17, 2025
@Seiji-Nishikawa @gregkh
mm: vmscan: account for free pages to prevent infinite Loop in thrott…
1ff2302 
…le_direct_reclaim()

commit 6aaced5 upstream.

The task sometimes continues looping in throttle_direct_reclaim() because
allow_direct_reclaim(pgdat) keeps returning false.

 #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac
 #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c
 #2 [ffff80002cb6f990] schedule at ffff800008abc50c
 #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550
 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68
 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660
 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98
 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8
 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974
 gregkh#9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4

At this point, the pgdat contains the following two zones:

        NODE: 4  ZONE: 0  ADDR: ffff00817fffe540  NAME: "DMA32"
          SIZE: 20480  MIN/LOW/HIGH: 11/28/45
          VM_STAT:
                NR_FREE_PAGES: 359
        NR_ZONE_INACTIVE_ANON: 18813
          NR_ZONE_ACTIVE_ANON: 0
        NR_ZONE_INACTIVE_FILE: 50
          NR_ZONE_ACTIVE_FILE: 0
          NR_ZONE_UNEVICTABLE: 0
        NR_ZONE_WRITE_PENDING: 0
                     NR_MLOCK: 0
                    NR_BOUNCE: 0
                   NR_ZSPAGES: 0
            NR_FREE_CMA_PAGES: 0

        NODE: 4  ZONE: 1  ADDR: ffff00817fffec00  NAME: "Normal"
          SIZE: 8454144  PRESENT: 98304  MIN/LOW/HIGH: 68/166/264
          VM_STAT:
                NR_FREE_PAGES: 146
        NR_ZONE_INACTIVE_ANON: 94668
          NR_ZONE_ACTIVE_ANON: 3
        NR_ZONE_INACTIVE_FILE: 735
          NR_ZONE_ACTIVE_FILE: 78
          NR_ZONE_UNEVICTABLE: 0
        NR_ZONE_WRITE_PENDING: 0
                     NR_MLOCK: 0
                    NR_BOUNCE: 0
                   NR_ZSPAGES: 0
            NR_FREE_CMA_PAGES: 0

In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of
inactive/active file-backed pages calculated in zone_reclaimable_pages()
based on the result of zone_page_state_snapshot() is zero.

Additionally, since this system lacks swap, the calculation of inactive/
active anonymous pages is skipped.

        crash> p nr_swap_pages
        nr_swap_pages = $1937 = {
          counter = 0
        }

As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to
the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having
free pages significantly exceeding the high watermark.

The problem is that the pgdat->kswapd_failures hasn't been incremented.

        crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures
        $1935 = 0x0

This is because the node deemed balanced.  The node balancing logic in
balance_pgdat() evaluates all zones collectively.  If one or more zones
(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the
entire node is deemed balanced.  This causes balance_pgdat() to exit early
before incrementing the kswapd_failures, as it considers the overall
memory state acceptable, even though some zones (like ZONE_NORMAL) remain
under significant pressure.


The patch ensures that zone_reclaimable_pages() includes free pages
(NR_FREE_PAGES) in its calculation when no other reclaimable pages are
available (e.g., file-backed or anonymous pages).  This change prevents
zones like ZONE_DMA32, which have sufficient free pages, from being
mistakenly deemed unreclaimable.  By doing so, the patch ensures proper
node balancing, avoids masking pressure on other zones like ZONE_NORMAL,
and prevents infinite loops in throttle_direct_reclaim() caused by
allow_direct_reclaim(pgdat) repeatedly returning false.


The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused
by a node being incorrectly deemed balanced despite pressure in certain
zones, such as ZONE_NORMAL.  This issue arises from
zone_reclaimable_pages() returning 0 for zones without reclaimable file-
backed or anonymous pages, causing zones like ZONE_DMA32 with sufficient
free pages to be skipped.

The lack of swap or reclaimable pages results in ZONE_DMA32 being ignored
during reclaim, masking pressure in other zones.  Consequently,
pgdat->kswapd_failures remains 0 in balance_pgdat(), preventing fallback
mechanisms in allow_direct_reclaim() from being triggered, leading to an
infinite loop in throttle_direct_reclaim().

This patch modifies zone_reclaimable_pages() to account for free pages
(NR_FREE_PAGES) when no other reclaimable pages exist.  This ensures zones
with sufficient free pages are not skipped, enabling proper balancing and
reclaim behavior.

[akpm@linux-foundation.org: coding-style cleanups]
Link: https://lkml.kernel.org/r/20241130164346.436469-1-snishika@redhat.com
Link: https://lkml.kernel.org/r/20241130161236.433747-2-snishika@redhat.com
Fixes: 5a1c84b ("mm: remove reclaim and compaction retry approximations")
Signed-off-by: Seiji Nishikawa <snishika@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.