linux-stable.git, branch v6.6.60

Linux 6.6.60

2024-11-08T15:28:28+00:00

Link: https://lore.kernel.org/r/20241106120308.841299741@linuxfoundation.org
Tested-by: SeongJae Park 
Tested-by: Shuah Khan 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Peter Schneider 
Tested-by: Takeshi Ogasawara 
Tested-by: Jon Hunter 
Tested-by: Florian Fainelli 
Tested-by: Ron Economos 
Tested-by: Hardik Garg 
Signed-off-by: Greg Kroah-Hartman

fs/ntfs3: Sequential field availability check in mi_enum_attr()

2024-11-08T15:28:28+00:00

commit 090f612756a9720ec18b0b130e28be49839d7cb5 upstream.

The code is slightly reformatted to consistently check field availability
without duplication.

Fixes: 556bdf27c2dd ("ntfs3: Add bounds checking to mi_enum_attr()")
Signed-off-by: Konstantin Komarov 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Add null checks for 'stream' and 'plane' before dereferencing

2024-11-08T15:28:28+00:00

commit 15c2990e0f0108b9c3752d7072a97d45d4283aea upstream.

This commit adds null checks for the 'stream' and 'plane' variables in
the dcn30_apply_idle_power_optimizations function. These variables were
previously assumed to be null at line 922, but they were used later in
the code without checking if they were null. This could potentially lead
to a null pointer dereference, which would cause a crash.

The null checks ensure that 'stream' and 'plane' are not null before
they are used, preventing potential crashes.

Fixes the below static smatch checker:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed 'stream' could be null (see line 922)
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed 'plane' could be null (see line 922)

Cc: Tom Chung 
Cc: Nicholas Kazlauskas 
Cc: Bhawanpreet Lakha 
Cc: Rodrigo Siqueira 
Cc: Roman Li 
Cc: Hersen Wu 
Cc: Alex Hung 
Cc: Aurabindo Pillai 
Cc: Harry Wentland 
Signed-off-by: Srinivasan Shanmugam 
Reviewed-by: Aurabindo Pillai 
Signed-off-by: Alex Deucher 
[Xiangyu: Modified file path to backport this commit]
Signed-off-by: Xiangyu Chen 
Signed-off-by: Greg Kroah-Hartman

ASoC: SOF: ipc4-control: Add support for ALSA enum control

2024-11-08T15:28:27+00:00

commit 07a866a41982c896dc46476f57d209a200602946 upstream.

Enum controls use generic param_id and a generic struct where the data
is passed to the firmware.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Bard Liao 
Reviewed-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20230919103115.30783-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ASoC: SOF: ipc4-control: Add support for ALSA switch control

2024-11-08T15:28:27+00:00

commit 4a2fd607b7ca6128ee3532161505da7624197f55 upstream.

Volume controls with a max value of 1 are switches.
Switch controls use generic param_id and a generic struct where the data
is passed to the firmware.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Bard Liao 
Reviewed-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20230919103115.30783-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ASoC: SOF: ipc4-topology: Add definition for generic switch/enum control

2024-11-08T15:28:27+00:00

commit 060a07cd9bc69eba2da33ed96b1fa69ead60bab1 upstream.

Currently IPC4 has no notion of a switch or enum type of control which is
a generic concept in ALSA.

The generic support for these control types will be as follows:
- large config is used to send the channel-value par array
- param_id of a SWITCH type is 200
- param_id of an ENUM type is 201

Each module need to support a switch or/and enum must handle these
universal param_ids.
The message payload is described by struct sof_ipc4_control_msg_payload.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Bard Liao 
Reviewed-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20230919103115.30783-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

SUNRPC: Remove BUG_ON call sites

2024-11-08T15:28:27+00:00

commit 789ce196a31dd13276076762204bee87df893e53 upstream.

There is no need to take down the whole system for these assertions.

I'd rather not attempt a heroic save here, as some bug has occurred
that has left the transport data structures in an unknown state.
Just warn and then leak the left-over resources.

Acked-by: Christian Brauner 
Reviewed-by: NeilBrown 
Reviewed-by: Jeff Layton 
Signed-off-by: Chuck Lever 
Signed-off-by: Dominique Martinet 
Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: winbond: fix w25q128 regression

2024-11-08T15:28:27+00:00

commit d35df77707bf5ae1221b5ba1c8a88cf4fcdd4901 upstream.

Commit 83e824a4a595 ("mtd: spi-nor: Correct flags for Winbond w25q128")
removed the flags for non-SFDP devices. It was assumed that it wasn't in
use anymore. This wasn't true. Add the no_sfdp_flags as well as the size
again.

We add the additional flags for dual and quad read because they have
been reported to work properly by Hartmut using both older and newer
versions of this flash, the similar flashes with 64Mbit and 256Mbit
already have these flags and because it will (luckily) trigger our
legacy SFDP parsing, so newer versions with SFDP support will still get
the parameters from the SFDP tables.

Reported-by: Hartmut Birr 
Closes: https://lore.kernel.org/r/CALxbwRo_-9CaJmt7r7ELgu+vOcgk=xZcGHobnKf=oT2=u4d4aA@mail.gmail.com/
Fixes: 83e824a4a595 ("mtd: spi-nor: Correct flags for Winbond w25q128")
Reviewed-by: Linus Walleij 
Signed-off-by: Michael Walle 
Acked-by: Tudor Ambarus 
Reviewed-by: Esben Haabendal 
Reviewed-by: Pratyush Yadav 
Signed-off-by: Pratyush Yadav 
Link: https://lore.kernel.org/r/20240621120929.2670185-1-mwalle@kernel.org
Link: https://lore.kernel.org/r/20240621120929.2670185-1-mwalle@kernel.org
[Backported to v6.6 - vastly different due to upstream changes]
Reviewed-by: Tudor Ambarus 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

mm: don't install PMD mappings when THPs are disabled by the hw/process/vma

2024-11-08T15:28:27+00:00

commit 2b0f922323ccfa76219bcaacd35cd50aeaa13592 upstream.

We (or rather, readahead logic :) ) might be allocating a THP in the
pagecache and then try mapping it into a process that explicitly disabled
THP: we might end up installing PMD mappings.

This is a problem for s390x KVM, which explicitly remaps all PMD-mapped
THPs to be PTE-mapped in s390_enable_sie()->thp_split_mm(), before
starting the VM.

For example, starting a VM backed on a file system with large folios
supported makes the VM crash when the VM tries accessing such a mapping
using KVM.

Is it also a problem when the HW disabled THP using
TRANSPARENT_HUGEPAGE_UNSUPPORTED?  At least on x86 this would be the case
without X86_FEATURE_PSE.

In the future, we might be able to do better on s390x and only disallow
PMD mappings -- what s390x and likely TRANSPARENT_HUGEPAGE_UNSUPPORTED
really wants.  For now, fix it by essentially performing the same check as
would be done in __thp_vma_allowable_orders() or in shmem code, where this
works as expected, and disallow PMD mappings, making us fallback to PTE
mappings.

Link: https://lkml.kernel.org/r/20241011102445.934409-3-david@redhat.com
Fixes: 793917d997df ("mm/readahead: Add large folio readahead")
Signed-off-by: David Hildenbrand 
Reported-by: Leo Fu 
Tested-by: Thomas Huth 
Cc: Thomas Huth 
Cc: Matthew Wilcox (Oracle) 
Cc: Ryan Roberts 
Cc: Christian Borntraeger 
Cc: Janosch Frank 
Cc: Claudio Imbrenda 
Cc: Hugh Dickins 
Cc: Kefeng Wang 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: David Hildenbrand 
Signed-off-by: Greg Kroah-Hartman

mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()

2024-11-08T15:28:27+00:00

commit 963756aac1f011d904ddd9548ae82286d3a91f96 upstream.

Patch series "mm: don't install PMD mappings when THPs are disabled by the
hw/process/vma".

During testing, it was found that we can get PMD mappings in processes
where THP (and more precisely, PMD mappings) are supposed to be disabled.
While it works as expected for anon+shmem, the pagecache is the
problematic bit.

For s390 KVM this currently means that a VM backed by a file located on
filesystem with large folio support can crash when KVM tries accessing the
problematic page, because the readahead logic might decide to use a
PMD-sized THP and faulting it into the page tables will install a PMD
mapping, something that s390 KVM cannot tolerate.

This might also be a problem with HW that does not support PMD mappings,
but I did not try reproducing it.

Fix it by respecting the ways to disable THPs when deciding whether we can
install a PMD mapping.  khugepaged should already be taking care of not
collapsing if THPs are effectively disabled for the hw/process/vma.


This patch (of 2):

Add vma_thp_disabled() and thp_disabled_by_hw() helpers to be shared by
shmem_allowable_huge_orders() and __thp_vma_allowable_orders().

[david@redhat.com: rename to vma_thp_disabled(), split out thp_disabled_by_hw() ]
Link: https://lkml.kernel.org/r/20241011102445.934409-2-david@redhat.com
Fixes: 793917d997df ("mm/readahead: Add large folio readahead")
Signed-off-by: Kefeng Wang 
Signed-off-by: David Hildenbrand 
Reported-by: Leo Fu 
Tested-by: Thomas Huth 
Reviewed-by: Ryan Roberts 
Cc: Boqiao Fu 
Cc: Christian Borntraeger 
Cc: Claudio Imbrenda 
Cc: Hugh Dickins 
Cc: Janosch Frank 
Cc: Matthew Wilcox 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: David Hildenbrand 
Signed-off-by: Greg Kroah-Hartman