January 2024 - Linux-stable-mirror

duplicate 'drm/amd: Enable PCIe PME from D3' in stable branches

by Jonathan Gray

The latest releases of 6.1.y, 6.6.y and 6.7.y introduce a duplicate commit of 'drm/amd: Enable PCIe PME from D3'. For example on the 6.6.y branch: commit 847e6947afd3c46623172d2eabcfc2481ee8668e Author: Mario Limonciello <mario.limonciello(a)amd.com> AuthorDate: Fri Nov 24 09:56:32 2023 -0600 Commit: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CommitDate: Thu Jan 25 15:35:45 2024 -0800 drm/amd: Enable PCIe PME from D3 commit bd1f6a31e7762ebc99b97f3eda5e5ea3708fa792 upstream. When dGPU is put into BOCO it may be in D3cold but still able send PME on display hotplug event. For this to work it must be enabled as wake source from D3. When runpm is enabled use pci_wake_from_d3() to mark wakeup as enabled by default. Cc: stable(a)vger.kernel.org # 6.1+ Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 2c35036e4ba2..635b58553583 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -2197,6 +2197,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, pci_wake_from_d3(pdev, TRUE); + pci_wake_from_d3(pdev, TRUE); + /* * For runpm implemented via BACO, PMFW will handle the * timing for BACO in and out: commit 49227bea27ebcd260f0c94a3055b14bbd8605c5e Author: Mario Limonciello <mario.limonciello(a)amd.com> AuthorDate: Fri Nov 24 09:56:32 2023 -0600 Commit: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CommitDate: Fri Dec 8 08:52:17 2023 +0100 drm/amd: Enable PCIe PME from D3 commit 6967741d26c87300a51b5e50d4acd104bc1a9759 upstream. When dGPU is put into BOCO it may be in D3cold but still able send PME on display hotplug event. For this to work it must be enabled as wake source from D3. When runpm is enabled use pci_wake_from_d3() to mark wakeup as enabled by default. Cc: stable(a)vger.kernel.org # 6.1+ Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 81edf66dbea8..2c35036e4ba2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -2195,6 +2195,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, pm_runtime_mark_last_busy(ddev->dev); pm_runtime_put_autosuspend(ddev->dev); + pci_wake_from_d3(pdev, TRUE); + /* * For runpm implemented via BACO, PMFW will handle the * timing for BACO in and out:

11 months, 2 weeks

3
2
0 0

[PATCH] drm/ttm: Make sure the mapped tt pages are decrypted when needed

by Zack Rusin

From: Zack Rusin <zackr(a)vmware.com> Some drivers require the mapped tt pages to be decrypted. In an ideal world this would have been handled by the dma layer, but the TTM page fault handling would have to be rewritten to able to do that. A side-effect of the TTM page fault handling is using a dma allocation per order (via ttm_pool_alloc_page) which makes it impossible to just trivially use dma_mmap_attrs. As a result ttm has to be very careful about trying to make its pgprot for the mapped tt pages match what the dma layer thinks it is. At the ttm layer it's possible to deduce the requirement to have tt pages decrypted by checking whether coherent dma allocations have been requested and the system is running with confidential computing technologies. This approach isn't ideal but keeping TTM matching DMAs expectations for the page properties is in general fragile, unfortunately proper fix would require a rewrite of TTM's page fault handling. Fixes vmwgfx with SEV enabled. Signed-off-by: Zack Rusin <zackr(a)vmware.com> Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem") Cc: Christian König <christian.koenig(a)amd.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # v5.14+ --- drivers/gpu/drm/ttm/ttm_bo_util.c | 13 +++++++++++-- drivers/gpu/drm/ttm/ttm_tt.c | 7 +++++++ include/drm/ttm/ttm_tt.h | 9 ++++++++- 3 files changed, 26 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index fd9fd3d15101..0b3f4267130c 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -294,7 +294,13 @@ pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct ttm_resource *res, enum ttm_caching caching; man = ttm_manager_type(bo->bdev, res->mem_type); - caching = man->use_tt ? bo->ttm->caching : res->bus.caching; + if (man->use_tt) { + caching = bo->ttm->caching; + if (bo->ttm->page_flags & TTM_TT_FLAG_DECRYPTED) + tmp = pgprot_decrypted(tmp); + } else { + caching = res->bus.caching; + } return ttm_prot_from_caching(caching, tmp); } @@ -337,6 +343,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo, .no_wait_gpu = false }; struct ttm_tt *ttm = bo->ttm; + struct ttm_resource_manager *man = + ttm_manager_type(bo->bdev, bo->resource->mem_type); pgprot_t prot; int ret; @@ -346,7 +354,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo, if (ret) return ret; - if (num_pages == 1 && ttm->caching == ttm_cached) { + if (num_pages == 1 && ttm->caching == ttm_cached && + !(man->use_tt && (ttm->page_flags & TTM_TT_FLAG_DECRYPTED))) { /* * We're mapping a single page, and the desired * page protection is consistent with the bo. diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index e0a77671edd6..02dcb728e29c 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -81,6 +81,13 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool zero_alloc) pr_err("Illegal buffer object type\n"); return -EINVAL; } + /* + * When using dma_alloc_coherent with memory encryption the + * mapped TT pages need to be decrypted or otherwise the drivers + * will end up sending encrypted mem to the gpu. + */ + if (bdev->pool.use_dma_alloc && cc_platform_has(CC_ATTR_MEM_ENCRYPT)) + page_flags |= TTM_TT_FLAG_DECRYPTED; bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags); if (unlikely(bo->ttm == NULL)) diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h index a4eff85b1f44..2b9d856ff388 100644 --- a/include/drm/ttm/ttm_tt.h +++ b/include/drm/ttm/ttm_tt.h @@ -79,6 +79,12 @@ struct ttm_tt { * page_flags = TTM_TT_FLAG_EXTERNAL | * TTM_TT_FLAG_EXTERNAL_MAPPABLE; * + * TTM_TT_FLAG_DECRYPTED: The mapped ttm pages should be marked as + * not encrypted. The framework will try to match what the dma layer + * is doing, but note that it is a little fragile because ttm page + * fault handling abuses the DMA api a bit and dma_map_attrs can't be + * used to assure pgprot always matches. + * * TTM_TT_FLAG_PRIV_POPULATED: TTM internal only. DO NOT USE. This is * set by TTM after ttm_tt_populate() has successfully returned, and is * then unset when TTM calls ttm_tt_unpopulate(). @@ -87,8 +93,9 @@ struct ttm_tt { #define TTM_TT_FLAG_ZERO_ALLOC BIT(1) #define TTM_TT_FLAG_EXTERNAL BIT(2) #define TTM_TT_FLAG_EXTERNAL_MAPPABLE BIT(3) +#define TTM_TT_FLAG_DECRYPTED BIT(4) -#define TTM_TT_FLAG_PRIV_POPULATED BIT(4) +#define TTM_TT_FLAG_PRIV_POPULATED BIT(5) uint32_t page_flags; /** @num_pages: Number of pages in the page array. */ uint32_t num_pages; -- 2.39.2

11 months, 2 weeks

6
10
0 0

[PATCH RESEND v2] arm: marvell: Fix maxium->maxim typo in brownstone dts

by Duje Mihanović

Fix an obvious spelling error in the PMIC compatible in the MMP2 Brownstone DTS file. Without this, the PMIC would never probe. Fixes: 58f1193e6210 ("mfd: max8925: Add dts") Cc: <stable(a)vger.kernel.org> Signed-off-by: Duje Mihanović <duje.mihanovic(a)skole.hr> --- Changes in v2: - Address maintainer comments: - Add Fixes: and Cc: tags - Change "for" to "in" in subject - Emphasize PMIC's inability to probe without patch - Link to v1: https://lore.kernel.org/r/20230804-brownstone-typo-fix-v1-1-4832d84c0509@sk… --- arch/arm/boot/dts/marvell/mmp2-brownstone.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/marvell/mmp2-brownstone.dts b/arch/arm/boot/dts/marvell/mmp2-brownstone.dts index 04f1ae1382e7..bc64348b8218 100644 --- a/arch/arm/boot/dts/marvell/mmp2-brownstone.dts +++ b/arch/arm/boot/dts/marvell/mmp2-brownstone.dts @@ -28,7 +28,7 @@ &uart3 { &twsi1 { status = "okay"; pmic: max8925@3c { - compatible = "maxium,max8925"; + compatible = "maxim,max8925"; reg = <0x3c>; interrupts = <1>; interrupt-parent = <&intcmux4>; --- base-commit: 2ccdd1b13c591d306f0401d98dedc4bdcd02b421 change-id: 20230804-brownstone-typo-fix-f5b16c47d865 Best regards, -- Duje Mihanović <duje.mihanovic(a)skole.hr>

11 months, 2 weeks

2
3
0 0

[PATCH v2 1/2] net: stmmac: do not clear TBS enable bit on link up/down

by Esben Haabendal

With the dma conf being reallocated on each call to stmmac_open(), any information in there is lost, unless we specifically handle it. The STMMAC_TBS_EN bit is set when adding an etf qdisc, and the etf qdisc therefore would stop working when link was set down and then back up. Fixes: ba39b344e924 ("net: ethernet: stmicro: stmmac: generate stmmac dma conf before open") Cc: stable(a)vger.kernel.org Signed-off-by: Esben Haabendal <esben(a)geanix.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index b334eb16da23..25519952f754 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3932,6 +3932,9 @@ static int __stmmac_open(struct net_device *dev, priv->rx_copybreak = STMMAC_RX_COPYBREAK; buf_sz = dma_conf->dma_buf_sz; + for (int i = 0; i < MTL_MAX_TX_QUEUES; i++) + if (priv->dma_conf.tx_queue[i].tbs & STMMAC_TBS_EN) + dma_conf->tx_queue[i].tbs = priv->dma_conf.tx_queue[i].tbs; memcpy(&priv->dma_conf, dma_conf, sizeof(*dma_conf)); stmmac_reset_queues_param(priv); -- 2.43.0

11 months, 2 weeks

1
0
0 0

[merged mm-stable] mm-thp_get_unmapped_area-must-honour-topdown-preference.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: thp_get_unmapped_area must honour topdown preference has been removed from the -mm tree. Its filename was mm-thp_get_unmapped_area-must-honour-topdown-preference.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Ryan Roberts <ryan.roberts(a)arm.com> Subject: mm: thp_get_unmapped_area must honour topdown preference Date: Tue, 23 Jan 2024 17:14:20 +0000 The addition of commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused the "virtual_address_range" mm selftest to start failing on arm64. Let's fix that regression. There were 2 visible problems when running the test; 1) it takes much longer to execute, and 2) the test fails. Both are related: The (first part of the) test allocates as many 1GB anonymous blocks as it can in the low 256TB of address space, passing NULL as the addr hint to mmap. Before the faulty patch, all allocations were abutted and contained in a single, merged VMA. However, after this patch, each allocation is in its own VMA, and there is a 2M gap between each VMA. This causes the 2 problems in the test: 1) mmap becomes MUCH slower because there are so many VMAs to check to find a new 1G gap. 2) mmap fails once it hits the VMA limit (/proc/sys/vm/max_map_count). Hitting this limit then causes a subsequent calloc() to fail, which causes the test to fail. The problem is that arm64 (unlike x86) selects ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT. But __thp_get_unmapped_area() allocates len+2M then always aligns to the bottom of the discovered gap. That causes the 2M hole. Fix this by detecting cases where we can still achive the alignment goal when moved to the top of the allocated area, if configured to prefer top-down allocation. While we are at it, fix thp_get_unmapped_area's use of pgoff, which should always be zero for anonymous mappings. Prior to the faulty change, while it was possible for user space to pass in pgoff!=0, the old mm->get_unmapped_area() handler would not use it. thp_get_unmapped_area() does use it, so let's explicitly zero it before calling the handler. This should also be the correct behavior for arches that define their own get_unmapped_area() handler. Link: https://lkml.kernel.org/r/20240123171420.3970220-1-ryan.roberts@arm.com Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") Closes: https://lore.kernel.org/linux-mm/1e8f5ac7-54ce-433a-ae53-81522b2320e1@arm.c… Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Reviewed-by: Yang Shi <shy828301(a)gmail.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 10 ++++++++-- mm/mmap.c | 6 ++++-- 2 files changed, 12 insertions(+), 4 deletions(-) --- a/mm/huge_memory.c~mm-thp_get_unmapped_area-must-honour-topdown-preference +++ a/mm/huge_memory.c @@ -810,7 +810,7 @@ static unsigned long __thp_get_unmapped_ { loff_t off_end = off + len; loff_t off_align = round_up(off, size); - unsigned long len_pad, ret; + unsigned long len_pad, ret, off_sub; if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall()) return 0; @@ -839,7 +839,13 @@ static unsigned long __thp_get_unmapped_ if (ret == addr) return addr; - ret += (off - ret) & (size - 1); + off_sub = (off - ret) & (size - 1); + + if (current->mm->get_unmapped_area == arch_get_unmapped_area_topdown && + !off_sub) + return ret + size; + + ret += off_sub; return ret; } --- a/mm/mmap.c~mm-thp_get_unmapped_area-must-honour-topdown-preference +++ a/mm/mmap.c @@ -1825,15 +1825,17 @@ get_unmapped_area(struct file *file, uns /* * mmap_region() will call shmem_zero_setup() to create a file, * so use shmem's get_unmapped_area in case it can be huge. - * do_mmap() will clear pgoff, so match alignment. */ - pgoff = 0; get_area = shmem_get_unmapped_area; } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { /* Ensures that larger anonymous mappings are THP aligned. */ get_area = thp_get_unmapped_area; } + /* Always treat pgoff as zero for anonymous memory. */ + if (!file) + pgoff = 0; + addr = get_area(file, addr, len, pgoff, flags); if (IS_ERR_VALUE(addr)) return addr; _ Patches currently in -mm which might be from ryan.roberts(a)arm.com are mm-userfaultfd-uffdio_move-implementation-should-use-ptep_get.patch tools-mm-add-thpmaps-script-to-dump-thp-usage-info.patch arm64-mm-make-set_ptes-robust-when-oas-cross-48-bit-boundary.patch

11 months, 2 weeks

1
0
0 0

[merged mm-stable] mm-hugetlb-restore-the-reservation-if-needed.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/hugetlb: restore the reservation if needed has been removed from the -mm tree. Its filename was mm-hugetlb-restore-the-reservation-if-needed.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Breno Leitao <leitao(a)debian.org> Subject: mm/hugetlb: restore the reservation if needed Date: Wed, 17 Jan 2024 09:10:57 -0800 Currently there is a bug that a huge page could be stolen, and when the original owner tries to fault in it, it causes a page fault. You can achieve that by: 1) Creating a single page echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages 2) mmap() the page above with MAP_HUGETLB into (void *ptr1). * This will mark the page as reserved 3) touch the page, which causes a page fault and allocates the page * This will move the page out of the free list. * It will also unreserved the page, since there is no more free page 4) madvise(MADV_DONTNEED) the page * This will free the page, but not mark it as reserved. 5) Allocate a secondary page with mmap(MAP_HUGETLB) into (void *ptr2). * it should fail, but, since there is no more available page. * But, since the page above is not reserved, this mmap() succeed. 6) Faulting at ptr1 will cause a SIGBUS * it will try to allocate a huge page, but there is none available A full reproducer is in selftest. See https://lore.kernel.org/all/20240105155419.1939484-1-leitao@debian.org/ Fix this by restoring the reserved page if necessary. If the page being unmapped has HPAGE_RESV_OWNER set, and needs a reservation, set the restore_reserve flag, which will move the page from free to reserved. Link: https://lkml.kernel.org/r/20240117171058.2192286-1-leitao@debian.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Suggested-by: Rik van Riel <riel(a)surriel.com> Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/mm/hugetlb.c~mm-hugetlb-restore-the-reservation-if-needed +++ a/mm/hugetlb.c @@ -5677,6 +5677,16 @@ void __unmap_hugepage_range(struct mmu_g hugetlb_count_sub(pages_per_huge_page(h), mm); hugetlb_remove_rmap(page_folio(page)); + if (is_vma_resv_set(vma, HPAGE_RESV_OWNER) && + vma_needs_reservation(h, vma, start)) { + /* + * Restore the reservation if needed, otherwise the + * backing page could be stolen by someone. + */ + folio_set_hugetlb_restore_reserve(page_folio(page)); + vma_add_reservation(h, vma, address); + } + spin_unlock(ptl); tlb_remove_page_size(tlb, page, huge_page_size(h)); /* _ Patches currently in -mm which might be from leitao(a)debian.org are selftests-mm-new-test-that-steals-pages.patch

11 months, 2 weeks

1
0
0 0

[merged mm-stable] selftests-mm-update-va_high_addr_switchsh-to-check-cpu-for-la57-flag.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests/mm: Update va_high_addr_switch.sh to check CPU for la57 flag has been removed from the -mm tree. Its filename was selftests-mm-update-va_high_addr_switchsh-to-check-cpu-for-la57-flag.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Audra Mitchell <audra(a)redhat.com> Subject: selftests/mm: Update va_high_addr_switch.sh to check CPU for la57 flag Date: Fri, 19 Jan 2024 15:58:01 -0500 In order for the page table level 5 to be in use, the CPU must have the setting enabled in addition to the CONFIG option. Check for the flag to be set to avoid false test failures on systems that do not have this cpu flag set. The test does a series of mmap calls including three using the MAP_FIXED flag and specifying an address that is 1<<47 or 1<<48. These addresses are only available if you are using level 5 page tables, which requires both the CPU to have the capabiltiy (la57 flag) and the kernel to be configured. Currently the test only checks for the kernel configuration option, so this test can still report a false positive. Here are the three failing lines: $ ./va_high_addr_switch | grep FAILED mmap(ADDR_SWITCH_HINT, 2 * PAGE_SIZE, MAP_FIXED): 0xffffffffffffffff - FAILED mmap(HIGH_ADDR, MAP_FIXED): 0xffffffffffffffff - FAILED mmap(ADDR_SWITCH_HINT, 2 * PAGE_SIZE, MAP_FIXED): 0xffffffffffffffff - FAILED I thought (for about a second) refactoring the test so that these three mmap calls will only be run on systems with the level 5 page tables available, but the whole point of the test is to check the level 5 feature... Link: https://lkml.kernel.org/r/20240119205801.62769-1-audra@redhat.com Fixes: 4f2930c6718a ("selftests/vm: only run 128TBswitch with 5-level paging") Signed-off-by: Audra Mitchell <audra(a)redhat.com> Cc: Rafael Aquini <raquini(a)redhat.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Adam Sindelar <adam(a)wowsignal.io> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/va_high_addr_switch.sh | 6 ++++++ 1 file changed, 6 insertions(+) --- a/tools/testing/selftests/mm/va_high_addr_switch.sh~selftests-mm-update-va_high_addr_switchsh-to-check-cpu-for-la57-flag +++ a/tools/testing/selftests/mm/va_high_addr_switch.sh @@ -29,9 +29,15 @@ check_supported_x86_64() # See man 1 gzip under '-f'. local pg_table_levels=$(gzip -dcfq "${config}" | grep PGTABLE_LEVELS | cut -d'=' -f 2) + local cpu_supports_pl5=$(awk '/^flags/ {if (/la57/) {print 0;} + else {print 1}; exit}' /proc/cpuinfo 2>/dev/null) + if [[ "${pg_table_levels}" -lt 5 ]]; then echo "$0: PGTABLE_LEVELS=${pg_table_levels}, must be >= 5 to run this test" exit $ksft_skip + elif [[ "${cpu_supports_pl5}" -ne 0 ]]; then + echo "$0: CPU does not have the necessary la57 flag to support page table level 5" + exit $ksft_skip fi } _ Patches currently in -mm which might be from audra(a)redhat.com are

11 months, 2 weeks

1
0
0 0

[merged mm-stable] userfaultfd-fix-mmap_changing-checking-in-mfill_atomic_hugetlb.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: userfaultfd: fix mmap_changing checking in mfill_atomic_hugetlb has been removed from the -mm tree. Its filename was userfaultfd-fix-mmap_changing-checking-in-mfill_atomic_hugetlb.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Lokesh Gidra <lokeshgidra(a)google.com> Subject: userfaultfd: fix mmap_changing checking in mfill_atomic_hugetlb Date: Wed, 17 Jan 2024 14:37:29 -0800 In mfill_atomic_hugetlb(), mmap_changing isn't being checked again if we drop mmap_lock and reacquire it. When the lock is not held, mmap_changing could have been incremented. This is also inconsistent with the behavior in mfill_atomic(). Link: https://lkml.kernel.org/r/20240117223729.1444522-1-lokeshgidra@google.com Fixes: df2cc96e77011 ("userfaultfd: prevent non-cooperative events vs mcopy_atomic races") Signed-off-by: Lokesh Gidra <lokeshgidra(a)google.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Brian Geffon <bgeffon(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jann Horn <jannh(a)google.com> Cc: Kalesh Singh <kaleshsingh(a)google.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Nicolas Geoffray <ngeoffray(a)google.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/userfaultfd.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/mm/userfaultfd.c~userfaultfd-fix-mmap_changing-checking-in-mfill_atomic_hugetlb +++ a/mm/userfaultfd.c @@ -357,6 +357,7 @@ static __always_inline ssize_t mfill_ato unsigned long dst_start, unsigned long src_start, unsigned long len, + atomic_t *mmap_changing, uffd_flags_t flags) { struct mm_struct *dst_mm = dst_vma->vm_mm; @@ -472,6 +473,15 @@ retry: goto out; } mmap_read_lock(dst_mm); + /* + * If memory mappings are changing because of non-cooperative + * operation (e.g. mremap) running in parallel, bail out and + * request the user to retry later + */ + if (mmap_changing && atomic_read(mmap_changing)) { + err = -EAGAIN; + break; + } dst_vma = NULL; goto retry; @@ -506,6 +516,7 @@ extern ssize_t mfill_atomic_hugetlb(stru unsigned long dst_start, unsigned long src_start, unsigned long len, + atomic_t *mmap_changing, uffd_flags_t flags); #endif /* CONFIG_HUGETLB_PAGE */ @@ -622,8 +633,8 @@ retry: * If this is a HUGETLB vma, pass off to appropriate routine */ if (is_vm_hugetlb_page(dst_vma)) - return mfill_atomic_hugetlb(dst_vma, dst_start, - src_start, len, flags); + return mfill_atomic_hugetlb(dst_vma, dst_start, src_start, + len, mmap_changing, flags); if (!vma_is_anonymous(dst_vma) && !vma_is_shmem(dst_vma)) goto out_unlock; _ Patches currently in -mm which might be from lokeshgidra(a)google.com are userfaultfd-fix-return-error-if-mmap_changing-is-non-zero-in-move-ioctl.patch

11 months, 2 weeks

1
0
0 0

[merged mm-stable] selftests-mm-ksm_tests-should-only-madv_hugepage-valid-memory.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests/mm: ksm_tests should only MADV_HUGEPAGE valid memory has been removed from the -mm tree. Its filename was selftests-mm-ksm_tests-should-only-madv_hugepage-valid-memory.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Ryan Roberts <ryan.roberts(a)arm.com> Subject: selftests/mm: ksm_tests should only MADV_HUGEPAGE valid memory Date: Mon, 22 Jan 2024 12:05:54 +0000 ksm_tests was previously mmapping a region of memory, aligning the returned pointer to a PMD boundary, then setting MADV_HUGEPAGE, but was setting it past the end of the mmapped area due to not taking the pointer alignment into consideration. Fix this behaviour. Up until commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries"), this buggy behavior was (usually) masked because the alignment difference was always less than PMD-size. But since the mentioned commit, `ksm_tests -H -s 100` started failing. Link: https://lkml.kernel.org/r/20240122120554.3108022-1-ryan.roberts@arm.com Fixes: 325254899684 ("selftests: vm: add KSM huge pages merging time test") Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Pedro Demarchi Gomes <pedrodemargomes(a)gmail.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/ksm_tests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/mm/ksm_tests.c~selftests-mm-ksm_tests-should-only-madv_hugepage-valid-memory +++ a/tools/testing/selftests/mm/ksm_tests.c @@ -566,7 +566,7 @@ static int ksm_merge_hugepages_time(int if (map_ptr_orig == MAP_FAILED) err(2, "initial mmap"); - if (madvise(map_ptr, len + HPAGE_SIZE, MADV_HUGEPAGE)) + if (madvise(map_ptr, len, MADV_HUGEPAGE)) err(2, "MADV_HUGEPAGE"); pagemap_fd = open("/proc/self/pagemap", O_RDONLY); _ Patches currently in -mm which might be from ryan.roberts(a)arm.com are mm-userfaultfd-uffdio_move-implementation-should-use-ptep_get.patch tools-mm-add-thpmaps-script-to-dump-thp-usage-info.patch arm64-mm-make-set_ptes-robust-when-oas-cross-48-bit-boundary.patch

11 months, 2 weeks

1
0
0 0

[merged mm-stable] scs-add-config_mmu-dependency-for-vfree_atomic.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: scs: add CONFIG_MMU dependency for vfree_atomic() has been removed from the -mm tree. Its filename was scs-add-config_mmu-dependency-for-vfree_atomic.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Samuel Holland <samuel.holland(a)sifive.com> Subject: scs: add CONFIG_MMU dependency for vfree_atomic() Date: Mon, 22 Jan 2024 09:52:01 -0800 The shadow call stack implementation fails to build without CONFIG_MMU: ld.lld: error: undefined symbol: vfree_atomic >>> referenced by scs.c >>> kernel/scs.o:(scs_free) in archive vmlinux.a Link: https://lkml.kernel.org/r/20240122175204.2371009-1-samuel.holland@sifive.com Fixes: a2abe7cbd8fe ("scs: switch to vmapped shadow stacks") Signed-off-by: Samuel Holland <samuel.holland(a)sifive.com> Reviewed-by: Sami Tolvanen <samitolvanen(a)google.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/arch/Kconfig~scs-add-config_mmu-dependency-for-vfree_atomic +++ a/arch/Kconfig @@ -673,6 +673,7 @@ config SHADOW_CALL_STACK bool "Shadow Call Stack" depends on ARCH_SUPPORTS_SHADOW_CALL_STACK depends on DYNAMIC_FTRACE_WITH_ARGS || DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER + depends on MMU help This option enables the compiler's Shadow Call Stack, which uses a shadow stack to protect function return addresses from _ Patches currently in -mm which might be from samuel.holland(a)sifive.com are

11 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024