November 2024 - Linux-stable-mirror

please revert backport of 44c76825d6eefee9eb7ce06c38e1a6632ac7eb7d

by Kees Cook

Hi stable tree maintainers, Please revert the backports of 44c76825d6ee ("x86: Increase brk randomness entropy for 64-bit systems") namely: 5.4: 03475167fda50b8511ef620a27409b08365882e1 5.10: 25d31baf922c1ee987efd6fcc9c7d4ab539c66b4 5.15: 06cb3463aa58906cfff72877eb7f50cb26e9ca93 6.1: b0cde867b80a5e81fcbc0383e138f5845f2005ee 6.6: 1a45994fb218d93dec48a3a86f68283db61e0936 There seems to be a bad interaction between this change and older PIE-built qemu-user-static (for aarch64) binaries[1]. Investigation continues to see if this will need to be reverted from 6.6, 6.11, and mainline. But for now, it's clearly a problem for older kernels with older qemu. Thanks! -Kees [1] https://lore.kernel.org/all/202411201000.F3313C02@keescook/ -- Kees Cook

4 months, 2 weeks

5
6
0 0

[PATCH v2 0/2] drm/msm/dpu: two fixes targeting 6.11

by Dmitry Baryshkov

Leonard Lausen reported an issue with suspend/resume of the sc7180 devices. Fix the WB atomic check, which caused the issue. Also make sure that DPU debugging logs are always directed to the drm_debug / DRIVER so that usual drm.debug masks work in an expected way. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- Changes in v2: - Reworked the writeback to just drop the connector->status check. - Expanded commit message for the debugging patch. - Link to v1: https://lore.kernel.org/r/20240709-dpu-fix-wb-v1-0-448348bfd4cb@linaro.org --- Dmitry Baryshkov (2): drm/msm/dpu1: don't choke on disabling the writeback connector drm/msm/dpu: don't play tricks with debug macros drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 14 ++------------ drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 3 --- 2 files changed, 2 insertions(+), 15 deletions(-) --- base-commit: 668d33c9ff922c4590c58754ab064aaf53c387dd change-id: 20240709-dpu-fix-wb-6cd57e3eb182 Best regards, -- Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>

4 months, 2 weeks

5
19
0 0

[PATCH v2] mm: Respect mmap hint address when aligning for THP

by Kalesh Singh

Commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") updated __get_unmapped_area() to align the start address for the VMA to a PMD boundary if CONFIG_TRANSPARENT_HUGEPAGE=y. It does this by effectively looking up a region that is of size, request_size + PMD_SIZE, and aligning up the start to a PMD boundary. Commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit") opted out of this for 32bit due to regressions in mmap base randomization. Commit d4148aeab412 ("mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes") restricted this to only mmap sizes that are multiples of the PMD_SIZE due to reported regressions in some performance benchmarks -- which seemed mostly due to the reduced spatial locality of related mappings due to the forced PMD-alignment. Another unintended side effect has emerged: When a user specifies an mmap hint address, the THP alignment logic modifies the behavior, potentially ignoring the hint even if a sufficiently large gap exists at the requested hint location. Example Scenario: Consider the following simplified virtual address (VA) space: ... 0x200000-0x400000 --- VMA A 0x400000-0x600000 --- Hole 0x600000-0x800000 --- VMA B ... A call to mmap() with hint=0x400000 and len=0x200000 behaves differently: - Before THP alignment: The requested region (size 0x200000) fits into the gap at 0x400000, so the hint is respected. - After alignment: The logic searches for a region of size 0x400000 (len + PMD_SIZE) starting at 0x400000. This search fails due to the mapping at 0x600000 (VMA B), and the hint is ignored, falling back to arch_get_unmapped_area[_topdown](). In general the hint is effectively ignored, if there is any existing mapping in the below range: [mmap_hint + mmap_size, mmap_hint + mmap_size + PMD_SIZE) This changes the semantics of mmap hint; from ""Respect the hint if a sufficiently large gap exists at the requested location" to "Respect the hint only if an additional PMD-sized gap exists beyond the requested size". This has performance implications for allocators that allocate their heap using mmap but try to keep it "as contiguous as possible" by using the end of the exisiting heap as the address hint. With the new behavior it's more likely to get a much less contiguous heap, adding extra fragmentation and performance overhead. To restore the expected behavior; don't use thp_get_unmapped_area_vmflags() when the user provided a hint address, for anonymous mappings. Note: As, Yang Shi, pointed out: the issue still remains for filesystems which are using thp_get_unmapped_area() for their get_unmapped_area() op. It is unclear what worklaods will regress for if we ignore THP alignment when the hint address is provided for such file backed mappings -- so this fix will be handled separately. Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Yang Shi <yang(a)os.amperecomputing.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Hans Boehm <hboehm(a)google.com> Cc: Lokesh Gidra <lokeshgidra(a)google.com> Cc: <stable(a)vger.kernel.org> Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com> Reviewed-by: Rik van Riel <riel(a)surriel.com> Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> --- Changes in v2: - Clarify the handling of file backed mappings, as highlighted by Yang - Collect Vlastimil's and Rik's Reviewed-by's mm/mmap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/mmap.c b/mm/mmap.c index 79d541f1502b..2f01f1a8e304 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -901,6 +901,7 @@ __get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, if (get_area) { addr = get_area(file, addr, len, pgoff, flags); } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) + && !addr /* no hint */ && IS_ALIGNED(len, PMD_SIZE)) { /* Ensures that larger anonymous mappings are THP aligned. */ addr = thp_get_unmapped_area_vmflags(file, addr, len, base-commit: 2d5404caa8c7bb5c4e0435f94b28834ae5456623 -- 2.47.0.338.g60cca15819-goog

4 months, 2 weeks

4
4
0 0

[PATCH v2] ARM: dts: dra7: Add bus_dma_limit for l4 cfg bus

by Romain Naour

From: Romain Naour <romain.naour(a)skf.com> A bus_dma_limit was added for l3 bus by commit cfb5d65f2595 ("ARM: dts: dra7: Add bus_dma_limit for L3 bus") to fix an issue observed only with SATA on DRA7-EVM with 4GB RAM and CONFIG_ARM_LPAE enabled. Since kernel 5.13, the SATA issue can be reproduced again following the SATA node move from L3 bus to L4_cfg in commit 8af15365a368 ("ARM: dts: Configure interconnect target module for dra7 sata"). Fix it by adding an empty dma-ranges property to l4_cfg and segment@100000 nodes (parent device tree node of SATA controller) to inherit the 2GB dma ranges limit from l3 bus node. Note: A similar fix was applied for PCIe controller by commit 90d4d3f4ea45 ("ARM: dts: dra7: Fix bus_dma_limit for PCIe"). Fixes: 8af15365a368 ("ARM: dts: Configure interconnect target module for dra7 sata"). Link: https://lore.kernel.org/linux-omap/c583e1bb-f56b-4489-8012-ce742e85f233@smi… Cc: <stable(a)vger.kernel.org> # 5.13 Signed-off-by: Romain Naour <romain.naour(a)skf.com> --- v2: add stable tag --- arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi index 6e67d99832ac..ba7fdaae9c6e 100644 --- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi +++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi @@ -12,6 +12,7 @@ &l4_cfg { /* 0x4a000000 */ ranges = <0x00000000 0x4a000000 0x100000>, /* segment 0 */ <0x00100000 0x4a100000 0x100000>, /* segment 1 */ <0x00200000 0x4a200000 0x100000>; /* segment 2 */ + dma-ranges; segment@0 { /* 0x4a000000 */ compatible = "simple-pm-bus"; @@ -557,6 +558,7 @@ segment@100000 { /* 0x4a100000 */ <0x0007e000 0x0017e000 0x001000>, /* ap 124 */ <0x00059000 0x00159000 0x001000>, /* ap 125 */ <0x0005a000 0x0015a000 0x001000>; /* ap 126 */ + dma-ranges; target-module@2000 { /* 0x4a102000, ap 27 3c.0 */ compatible = "ti,sysc"; -- 2.45.0

4 months, 2 weeks

2
1
0 0

[PATCH] cpufreq: fix using cpufreq-dt as module

by Andreas Kemnade

E.g. omap2plus_defconfig compiles cpufreq-dt as module. As there is no module alias nor a module_init(), cpufreq-dt-platdev will not be used and therefore on several omap platforms there is no cpufreq. Enforce builtin compile of cpufreq-dt-platdev to make it effective. Fixes: 3b062a086984 ("cpufreq: dt-platdev: Support building as module") Cc: stable(a)vger.kernel.org Signed-off-by: Andreas Kemnade <andreas(a)kemnade.info> --- drivers/cpufreq/Kconfig | 2 +- drivers/cpufreq/cpufreq-dt-platdev.c | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 2561b215432a8..4547adf5d2a7d 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -218,7 +218,7 @@ config CPUFREQ_DT If in doubt, say N. config CPUFREQ_DT_PLATDEV - tristate "Generic DT based cpufreq platdev driver" + bool "Generic DT based cpufreq platdev driver" depends on OF help This adds a generic DT based cpufreq platdev driver for frequency diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c index 18942bfe9c95f..78ad3221fe077 100644 --- a/drivers/cpufreq/cpufreq-dt-platdev.c +++ b/drivers/cpufreq/cpufreq-dt-platdev.c @@ -234,5 +234,3 @@ static int __init cpufreq_dt_platdev_init(void) sizeof(struct cpufreq_dt_platform_data))); } core_initcall(cpufreq_dt_platdev_init); -MODULE_DESCRIPTION("Generic DT based cpufreq platdev driver"); -MODULE_LICENSE("GPL"); -- 2.39.2

4 months, 2 weeks

3
4
0 0

[PATCH] nvme-pci: Remove O2 Queue Depth quirk

by Gwendal Grignou

PCI_DEVICE(0x1217, 0x8760) (O2 Micro, Inc. FORESEE E2M2 NVMe SSD) is a NMVe to eMMC bridge, that can be used with different eMMC memory devices. The NVMe device name contains the eMMC device name, for instance: `BAYHUB SanDisk-DA4128-91904055-128GB` The bridge is known to work with many eMMC devices, we need to limit the queue depth once we know which eMMC device is behind the bridge. Fixes: commit 83bdfcbdbe5d ("nvme-pci: qdepth 1 quirk") Cc: stable(a)vger.kernel.org Signed-off-by: Gwendal Grignou <gwendal(a)chromium.org> --- drivers/nvme/host/pci.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 4b9fda0b1d9a3..1c908e129fddf 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3448,8 +3448,6 @@ static const struct pci_device_id nvme_id_table[] = { NVME_QUIRK_BOGUS_NID, }, { PCI_VDEVICE(REDHAT, 0x0010), /* Qemu emulated controller */ .driver_data = NVME_QUIRK_BOGUS_NID, }, - { PCI_DEVICE(0x1217, 0x8760), /* O2 Micro 64GB Steam Deck */ - .driver_data = NVME_QUIRK_QDEPTH_ONE }, { PCI_DEVICE(0x126f, 0x2262), /* Silicon Motion generic */ .driver_data = NVME_QUIRK_NO_DEEPEST_PS | NVME_QUIRK_BOGUS_NID, }, -- 2.47.0.163.g1226f6d8fa-goog

4 months, 2 weeks

5
7
0 0

drm/amd/display: Pass pwrseq inst for backlight and ABM

by Alex Deucher

Hi Greg, Sasha, Please cherry pick upstream commit b17ef04bf3a4 ("drm/amd/display: Pass pwrseq inst for backlight and ABM") to stable kernel 6.6.x and newer. This fixes broken backlight adjustment on some AMD platforms with eDP panels. Thanks, Alex

4 months, 2 weeks

3
7
0 0

[PATCH v2 0/2] PCI: endpoint: fix bug for an API and simplify another API

by Zijun Hu

This patch series is to fix bug for API devm_pci_epc_destroy() and simplify API pci_epc_get(). Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- Changes in v2: - Correct tile and commit message for patch 1/2. - Add one more patch 2/2 to simplify API pci_epc_get(). - Link to v1: https://lore.kernel.org/r/20241020-pci-epc-core_fix-v1-1-3899705e3537@quici… --- Zijun Hu (2): PCI: endpoint: Fix that API devm_pci_epc_destroy() fails to destroy the EPC device PCI: endpoint: Simplify API pci_epc_get() implementation drivers/pci/endpoint/pci-epc-core.c | 23 +++++++---------------- 1 file changed, 7 insertions(+), 16 deletions(-) --- base-commit: 11066801dd4b7c4d75fce65c812723a80c1481ae change-id: 20241020-pci-epc-core_fix-a92512fa9d19 Best regards, -- Zijun Hu <quic_zijuhu(a)quicinc.com>

4 months, 2 weeks

1
2
0 0

[PATCH 6.1/5.15/5.10/5.4] udf: fix null-ptr-deref if sb_getblk() fails

by Jakub Acs

commit 32f123a3f342 ("udf: Fold udf_getblk() into udf_bread()"), fixes a null-ptr-deref bug as a side effect. Backport the null-ptr-deref fixing aspect of the aforementioned commit. Closes: https://syzkaller.appspot.com/bug?extid=a38e34ca637c224f4a79 Signed-off-by: Jakub Acs <acsjakub(a)amazon.de> --- fs/udf/inode.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/udf/inode.c b/fs/udf/inode.c index d7d6ccd0af06..4f505a366da9 100644 --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -380,6 +380,10 @@ static struct buffer_head *udf_getblk(struct inode *inode, udf_pblk_t block, *err = udf_get_block(inode, block, &dummy, create); if (!*err && buffer_mapped(&dummy)) { bh = sb_getblk(inode->i_sb, dummy.b_blocknr); + if (!bh) { + *err = -ENOMEM; + return NULL; + } if (buffer_new(&dummy)) { lock_buffer(bh); memset(bh->b_data, 0x00, inode->i_sb->s_blocksize); base-commit: e4d90d63d385228b1e0bcf31cc15539bbbc28f7f -- 2.40.1

4 months, 2 weeks

4
7
0 0

[PATCH v5.10.277] wifi: mac80211: Avoid address calculations via out of bounds array indexing

by Hardik Gohil

From: Kenton Groombridge <concord(a)gentoo.org> [ Upstream commit 2663d0462eb32ae7c9b035300ab6b1523886c718 ] req->n_channels must be set before req->channels[] can be used. This patch fixes one of the issues encountered in [1]. [ 83.964255] UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:364:4 [ 83.964258] index 0 is out of range for type 'struct ieee80211_channel *[]' [...] [ 83.964264] Call Trace: [ 83.964267] <TASK> [ 83.964269] dump_stack_lvl+0x3f/0xc0 [ 83.964274] __ubsan_handle_out_of_bounds+0xec/0x110 [ 83.964278] ieee80211_prep_hw_scan+0x2db/0x4b0 [ 83.964281] __ieee80211_start_scan+0x601/0x990 [ 83.964291] nl80211_trigger_scan+0x874/0x980 [ 83.964295] genl_family_rcv_msg_doit+0xe8/0x160 [ 83.964298] genl_rcv_msg+0x240/0x270 [...] [1] https://bugzilla.kernel.org/show_bug.cgi?id=218810 Co-authored-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Kenton Groombridge <concord(a)gentoo.org> Link: https://msgid.link/20240605152218.236061-1-concord@gentoo.org Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> [Xiangyu: Modified to apply on 6.1.y and 6.6.y] Signed-off-by: Xiangyu Chen <xiangyu.chen(a)windriver.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hardik Gohil <hgohil(a)mvista.com> --- net/mac80211/scan.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c index be5d02c..bcbbb9f 100644 --- a/net/mac80211/scan.c +++ b/net/mac80211/scan.c @@ -351,7 +351,8 @@ static bool ieee80211_prep_hw_scan(struct ieee80211_sub_if_data *sdata) struct cfg80211_scan_request *req; struct cfg80211_chan_def chandef; u8 bands_used = 0; - int i, ielen, n_chans; + int i, ielen; + u32 *n_chans; u32 flags = 0; req = rcu_dereference_protected(local->scan_req, @@ -361,34 +362,34 @@ static bool ieee80211_prep_hw_scan(struct ieee80211_sub_if_data *sdata) return false; if (ieee80211_hw_check(&local->hw, SINGLE_SCAN_ON_ALL_BANDS)) { + local->hw_scan_req->req.n_channels = req->n_channels; + for (i = 0; i < req->n_channels; i++) { local->hw_scan_req->req.channels[i] = req->channels[i]; bands_used |= BIT(req->channels[i]->band); } - - n_chans = req->n_channels; } else { do { if (local->hw_scan_band == NUM_NL80211_BANDS) return false; - n_chans = 0; + n_chans = &local->hw_scan_req->req.n_channels; + *n_chans = 0; for (i = 0; i < req->n_channels; i++) { if (req->channels[i]->band != local->hw_scan_band) continue; - local->hw_scan_req->req.channels[n_chans] = + local->hw_scan_req->req.channels[(*n_chans)++] = req->channels[i]; - n_chans++; + bands_used |= BIT(req->channels[i]->band); } local->hw_scan_band++; - } while (!n_chans); + } while (!*n_chans); } - local->hw_scan_req->req.n_channels = n_chans; ieee80211_prepare_scan_chandef(&chandef, req->scan_width); if (req->flags & NL80211_SCAN_FLAG_MIN_PREQ_CONTENT) -- 2.7.4

4 months, 2 weeks

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024