June 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] selftests/mm: compaction_test: fix incorrect write of zero to" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 9ad665ef55eaad1ead1406a58a34f615a7c18b5e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061333-unicorn-unstaffed-01d6@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 9ad665ef55ea ("selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9ad665ef55eaad1ead1406a58a34f615a7c18b5e Mon Sep 17 00:00:00 2001 From: Dev Jain <dev.jain(a)arm.com> Date: Tue, 21 May 2024 13:13:57 +0530 Subject: [PATCH] selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages Currently, the test tries to set nr_hugepages to zero, but that is not actually done because the file offset is not reset after read(). Fix that using lseek(). Link: https://lkml.kernel.org/r/20240521074358.675031-3-dev.jain@arm.com Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory") Signed-off-by: Dev Jain <dev.jain(a)arm.com> Cc: <stable(a)vger.kernel.org> Cc: Anshuman Khandual <anshuman.khandual(a)arm.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Sri Jayaramappa <sjayaram(a)akamai.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/tools/testing/selftests/mm/compaction_test.c b/tools/testing/selftests/mm/compaction_test.c index 0b249a06a60b..5e9bd1da9370 100644 --- a/tools/testing/selftests/mm/compaction_test.c +++ b/tools/testing/selftests/mm/compaction_test.c @@ -108,6 +108,8 @@ int check_compaction(unsigned long mem_free, unsigned long hugepage_size) goto close_fd; } + lseek(fd, 0, SEEK_SET); + /* Start with the initial condition of 0 huge pages*/ if (write(fd, "0", sizeof(char)) != sizeof(char)) { ksft_print_msg("Failed to write 0 to /proc/sys/vm/nr_hugepages: %s\n",

3 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] selftests/mm: compaction_test: fix incorrect write of zero to" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 9ad665ef55eaad1ead1406a58a34f615a7c18b5e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061332-catering-triage-c259@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 9ad665ef55ea ("selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9ad665ef55eaad1ead1406a58a34f615a7c18b5e Mon Sep 17 00:00:00 2001 From: Dev Jain <dev.jain(a)arm.com> Date: Tue, 21 May 2024 13:13:57 +0530 Subject: [PATCH] selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages Currently, the test tries to set nr_hugepages to zero, but that is not actually done because the file offset is not reset after read(). Fix that using lseek(). Link: https://lkml.kernel.org/r/20240521074358.675031-3-dev.jain@arm.com Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory") Signed-off-by: Dev Jain <dev.jain(a)arm.com> Cc: <stable(a)vger.kernel.org> Cc: Anshuman Khandual <anshuman.khandual(a)arm.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Sri Jayaramappa <sjayaram(a)akamai.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/tools/testing/selftests/mm/compaction_test.c b/tools/testing/selftests/mm/compaction_test.c index 0b249a06a60b..5e9bd1da9370 100644 --- a/tools/testing/selftests/mm/compaction_test.c +++ b/tools/testing/selftests/mm/compaction_test.c @@ -108,6 +108,8 @@ int check_compaction(unsigned long mem_free, unsigned long hugepage_size) goto close_fd; } + lseek(fd, 0, SEEK_SET); + /* Start with the initial condition of 0 huge pages*/ if (write(fd, "0", sizeof(char)) != sizeof(char)) { ksft_print_msg("Failed to write 0 to /proc/sys/vm/nr_hugepages: %s\n",

3 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] selftests/mm: compaction_test: fix incorrect write of zero to" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 9ad665ef55eaad1ead1406a58a34f615a7c18b5e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061331-trilogy-bulk-6fc0@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 9ad665ef55ea ("selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9ad665ef55eaad1ead1406a58a34f615a7c18b5e Mon Sep 17 00:00:00 2001 From: Dev Jain <dev.jain(a)arm.com> Date: Tue, 21 May 2024 13:13:57 +0530 Subject: [PATCH] selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages Currently, the test tries to set nr_hugepages to zero, but that is not actually done because the file offset is not reset after read(). Fix that using lseek(). Link: https://lkml.kernel.org/r/20240521074358.675031-3-dev.jain@arm.com Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory") Signed-off-by: Dev Jain <dev.jain(a)arm.com> Cc: <stable(a)vger.kernel.org> Cc: Anshuman Khandual <anshuman.khandual(a)arm.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Sri Jayaramappa <sjayaram(a)akamai.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/tools/testing/selftests/mm/compaction_test.c b/tools/testing/selftests/mm/compaction_test.c index 0b249a06a60b..5e9bd1da9370 100644 --- a/tools/testing/selftests/mm/compaction_test.c +++ b/tools/testing/selftests/mm/compaction_test.c @@ -108,6 +108,8 @@ int check_compaction(unsigned long mem_free, unsigned long hugepage_size) goto close_fd; } + lseek(fd, 0, SEEK_SET); + /* Start with the initial condition of 0 huge pages*/ if (write(fd, "0", sizeof(char)) != sizeof(char)) { ksft_print_msg("Failed to write 0 to /proc/sys/vm/nr_hugepages: %s\n",

3 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] selftests/mm: compaction_test: fix incorrect write of zero to" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 9ad665ef55eaad1ead1406a58a34f615a7c18b5e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061331-these-daunting-6dba@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 9ad665ef55ea ("selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9ad665ef55eaad1ead1406a58a34f615a7c18b5e Mon Sep 17 00:00:00 2001 From: Dev Jain <dev.jain(a)arm.com> Date: Tue, 21 May 2024 13:13:57 +0530 Subject: [PATCH] selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages Currently, the test tries to set nr_hugepages to zero, but that is not actually done because the file offset is not reset after read(). Fix that using lseek(). Link: https://lkml.kernel.org/r/20240521074358.675031-3-dev.jain@arm.com Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory") Signed-off-by: Dev Jain <dev.jain(a)arm.com> Cc: <stable(a)vger.kernel.org> Cc: Anshuman Khandual <anshuman.khandual(a)arm.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Sri Jayaramappa <sjayaram(a)akamai.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/tools/testing/selftests/mm/compaction_test.c b/tools/testing/selftests/mm/compaction_test.c index 0b249a06a60b..5e9bd1da9370 100644 --- a/tools/testing/selftests/mm/compaction_test.c +++ b/tools/testing/selftests/mm/compaction_test.c @@ -108,6 +108,8 @@ int check_compaction(unsigned long mem_free, unsigned long hugepage_size) goto close_fd; } + lseek(fd, 0, SEEK_SET); + /* Start with the initial condition of 0 huge pages*/ if (write(fd, "0", sizeof(char)) != sizeof(char)) { ksft_print_msg("Failed to write 0 to /proc/sys/vm/nr_hugepages: %s\n",

3 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] mm: /proc/pid/smaps_rollup: avoid skipping vma after getting" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 6d065f507d82307d6161ac75c025111fb8b08a46 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061335-lunchbox-playroom-cf81@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 6d065f507d82 ("mm: /proc/pid/smaps_rollup: avoid skipping vma after getting mmap_lock again") 250cb40f0afe ("task_mmu: convert to vma iterator") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6d065f507d82307d6161ac75c025111fb8b08a46 Mon Sep 17 00:00:00 2001 From: Yuanyuan Zhong <yzhong(a)purestorage.com> Date: Thu, 23 May 2024 12:35:31 -0600 Subject: [PATCH] mm: /proc/pid/smaps_rollup: avoid skipping vma after getting mmap_lock again After switching smaps_rollup to use VMA iterator, searching for next entry is part of the condition expression of the do-while loop. So the current VMA needs to be addressed before the continue statement. Otherwise, with some VMAs skipped, userspace observed memory consumption from /proc/pid/smaps_rollup will be smaller than the sum of the corresponding fields from /proc/pid/smaps. Link: https://lkml.kernel.org/r/20240523183531.2535436-1-yzhong@purestorage.com Fixes: c4c84f06285e ("fs/proc/task_mmu: stop using linked list and highest_vm_end") Signed-off-by: Yuanyuan Zhong <yzhong(a)purestorage.com> Reviewed-by: Mohamed Khalfella <mkhalfella(a)purestorage.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index e5a5f015ff03..f8d35f993fe5 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -970,12 +970,17 @@ static int show_smaps_rollup(struct seq_file *m, void *v) break; /* Case 1 and 2 above */ - if (vma->vm_start >= last_vma_end) + if (vma->vm_start >= last_vma_end) { + smap_gather_stats(vma, &mss, 0); + last_vma_end = vma->vm_end; continue; + } /* Case 4 above */ - if (vma->vm_end > last_vma_end) + if (vma->vm_end > last_vma_end) { smap_gather_stats(vma, &mss, last_vma_end); + last_vma_end = vma->vm_end; + } } } for_each_vma(vmi, vma);

3 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] mm/hugetlb: pass correct order_per_bit to" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 55d134a7b499c77e7cfd0ee41046f3c376e791e5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061318-magical-unclamped-49ef@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 55d134a7b499 ("mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid") a01f43901cfb ("hugetlb: be sure to free demoted CMA pages to CMA") 79dfc695525f ("hugetlb: add demote hugetlb page sysfs interfaces") 6eb4e88a6d27 ("hugetlb: create remove_hugetlb_page() to separate functionality") 262443c0421e ("hugetlb: no need to drop hugetlb_lock to call cma_release") 9157c31186c3 ("hugetlb: convert PageHugeTemporary() to HPageTemporary flag") 8f251a3d5ce3 ("hugetlb: convert page_huge_active() HPageMigratable flag") d6995da31122 ("hugetlb: use page.private for hugetlb specific page flags") dbfee5aee7e5 ("hugetlb: fix update_and_free_page contig page struct assumption") ecbf4724e606 ("mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active") 0eb2df2b5629 ("mm: hugetlb: fix a race between isolating and freeing page") 585fc0d2871c ("mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 55d134a7b499c77e7cfd0ee41046f3c376e791e5 Mon Sep 17 00:00:00 2001 From: Frank van der Linden <fvdl(a)google.com> Date: Thu, 4 Apr 2024 16:25:15 +0000 Subject: [PATCH] mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid The hugetlb_cma code passes 0 in the order_per_bit argument to cma_declare_contiguous_nid (the alignment, computed using the page order, is correctly passed in). This causes a bit in the cma allocation bitmap to always represent a 4k page, making the bitmaps potentially very large, and slower. It would create bitmaps that would be pretty big. E.g. for a 4k page size on x86, hugetlb_cma=64G would mean a bitmap size of (64G / 4k) / 8 == 2M. With HUGETLB_PAGE_ORDER as order_per_bit, as intended, this would be (64G / 2M) / 8 == 4k. So, that's quite a difference. Also, this restricted the hugetlb_cma area to ((PAGE_SIZE << MAX_PAGE_ORDER) * 8) * PAGE_SIZE (e.g. 128G on x86) , since bitmap_alloc uses normal page allocation, and is thus restricted by MAX_PAGE_ORDER. Specifying anything about that would fail the CMA initialization. So, correctly pass in the order instead. Link: https://lkml.kernel.org/r/20240404162515.527802-2-fvdl@google.com Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma") Signed-off-by: Frank van der Linden <fvdl(a)google.com> Acked-by: Roman Gushchin <roman.gushchin(a)linux.dev> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 228c886c46c1..5dc3f5ea3a2e 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -7794,9 +7794,9 @@ void __init hugetlb_cma_reserve(int order) * huge page demotion. */ res = cma_declare_contiguous_nid(0, size, 0, - PAGE_SIZE << HUGETLB_PAGE_ORDER, - 0, false, name, - &hugetlb_cma[nid], nid); + PAGE_SIZE << HUGETLB_PAGE_ORDER, + HUGETLB_PAGE_ORDER, false, name, + &hugetlb_cma[nid], nid); if (res) { pr_warn("hugetlb_cma: reservation failed: err %d, node %d", res, nid);

3 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] mm/hugetlb: pass correct order_per_bit to" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 55d134a7b499c77e7cfd0ee41046f3c376e791e5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061317-rework-obituary-d23b@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 55d134a7b499 ("mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid") a01f43901cfb ("hugetlb: be sure to free demoted CMA pages to CMA") 79dfc695525f ("hugetlb: add demote hugetlb page sysfs interfaces") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 55d134a7b499c77e7cfd0ee41046f3c376e791e5 Mon Sep 17 00:00:00 2001 From: Frank van der Linden <fvdl(a)google.com> Date: Thu, 4 Apr 2024 16:25:15 +0000 Subject: [PATCH] mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid The hugetlb_cma code passes 0 in the order_per_bit argument to cma_declare_contiguous_nid (the alignment, computed using the page order, is correctly passed in). This causes a bit in the cma allocation bitmap to always represent a 4k page, making the bitmaps potentially very large, and slower. It would create bitmaps that would be pretty big. E.g. for a 4k page size on x86, hugetlb_cma=64G would mean a bitmap size of (64G / 4k) / 8 == 2M. With HUGETLB_PAGE_ORDER as order_per_bit, as intended, this would be (64G / 2M) / 8 == 4k. So, that's quite a difference. Also, this restricted the hugetlb_cma area to ((PAGE_SIZE << MAX_PAGE_ORDER) * 8) * PAGE_SIZE (e.g. 128G on x86) , since bitmap_alloc uses normal page allocation, and is thus restricted by MAX_PAGE_ORDER. Specifying anything about that would fail the CMA initialization. So, correctly pass in the order instead. Link: https://lkml.kernel.org/r/20240404162515.527802-2-fvdl@google.com Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma") Signed-off-by: Frank van der Linden <fvdl(a)google.com> Acked-by: Roman Gushchin <roman.gushchin(a)linux.dev> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 228c886c46c1..5dc3f5ea3a2e 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -7794,9 +7794,9 @@ void __init hugetlb_cma_reserve(int order) * huge page demotion. */ res = cma_declare_contiguous_nid(0, size, 0, - PAGE_SIZE << HUGETLB_PAGE_ORDER, - 0, false, name, - &hugetlb_cma[nid], nid); + PAGE_SIZE << HUGETLB_PAGE_ORDER, + HUGETLB_PAGE_ORDER, false, name, + &hugetlb_cma[nid], nid); if (res) { pr_warn("hugetlb_cma: reservation failed: err %d, node %d", res, nid);

3 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] mm/cma: drop incorrect alignment check in" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x b174f139bdc8aaaf72f5b67ad1bd512c4868a87e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061304-wolverine-clamshell-84a2@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: b174f139bdc8 ("mm/cma: drop incorrect alignment check in cma_init_reserved_mem") e16faf26780f ("cma: factor out minimum alignment requirement") 658aafc8139c ("memblock: exclude MEMBLOCK_NOMAP regions from kmemleak") a7259df76702 ("memblock: make memblock_find_in_range method private") a70bb580bfea ("Merge tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b174f139bdc8aaaf72f5b67ad1bd512c4868a87e Mon Sep 17 00:00:00 2001 From: Frank van der Linden <fvdl(a)google.com> Date: Thu, 4 Apr 2024 16:25:14 +0000 Subject: [PATCH] mm/cma: drop incorrect alignment check in cma_init_reserved_mem cma_init_reserved_mem uses IS_ALIGNED to check if the size represented by one bit in the cma allocation bitmask is aligned with CMA_MIN_ALIGNMENT_BYTES (pageblock size). However, this is too strict, as this will fail if order_per_bit > pageblock_order, which is a valid configuration. We could check IS_ALIGNED both ways, but since both numbers are powers of two, no check is needed at all. Link: https://lkml.kernel.org/r/20240404162515.527802-1-fvdl@google.com Fixes: de9e14eebf33 ("drivers: dma-contiguous: add initialization from device tree") Signed-off-by: Frank van der Linden <fvdl(a)google.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/cma.c b/mm/cma.c index 01f5a8f71ddf..3e9724716bad 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -182,10 +182,6 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, if (!size || !memblock_is_region_reserved(base, size)) return -EINVAL; - /* alignment should be aligned with order_per_bit */ - if (!IS_ALIGNED(CMA_MIN_ALIGNMENT_PAGES, 1 << order_per_bit)) - return -EINVAL; - /* ensure minimal alignment required by mm core */ if (!IS_ALIGNED(base | size, CMA_MIN_ALIGNMENT_BYTES)) return -EINVAL;

3 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] mm/cma: drop incorrect alignment check in" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x b174f139bdc8aaaf72f5b67ad1bd512c4868a87e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061303-scouting-precise-e914@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: b174f139bdc8 ("mm/cma: drop incorrect alignment check in cma_init_reserved_mem") e16faf26780f ("cma: factor out minimum alignment requirement") 658aafc8139c ("memblock: exclude MEMBLOCK_NOMAP regions from kmemleak") a7259df76702 ("memblock: make memblock_find_in_range method private") a70bb580bfea ("Merge tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b174f139bdc8aaaf72f5b67ad1bd512c4868a87e Mon Sep 17 00:00:00 2001 From: Frank van der Linden <fvdl(a)google.com> Date: Thu, 4 Apr 2024 16:25:14 +0000 Subject: [PATCH] mm/cma: drop incorrect alignment check in cma_init_reserved_mem cma_init_reserved_mem uses IS_ALIGNED to check if the size represented by one bit in the cma allocation bitmask is aligned with CMA_MIN_ALIGNMENT_BYTES (pageblock size). However, this is too strict, as this will fail if order_per_bit > pageblock_order, which is a valid configuration. We could check IS_ALIGNED both ways, but since both numbers are powers of two, no check is needed at all. Link: https://lkml.kernel.org/r/20240404162515.527802-1-fvdl@google.com Fixes: de9e14eebf33 ("drivers: dma-contiguous: add initialization from device tree") Signed-off-by: Frank van der Linden <fvdl(a)google.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/cma.c b/mm/cma.c index 01f5a8f71ddf..3e9724716bad 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -182,10 +182,6 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, if (!size || !memblock_is_region_reserved(base, size)) return -EINVAL; - /* alignment should be aligned with order_per_bit */ - if (!IS_ALIGNED(CMA_MIN_ALIGNMENT_PAGES, 1 << order_per_bit)) - return -EINVAL; - /* ensure minimal alignment required by mm core */ if (!IS_ALIGNED(base | size, CMA_MIN_ALIGNMENT_BYTES)) return -EINVAL;

3 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] mm/cma: drop incorrect alignment check in" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x b174f139bdc8aaaf72f5b67ad1bd512c4868a87e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061302-polyester-ahead-33a7@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: b174f139bdc8 ("mm/cma: drop incorrect alignment check in cma_init_reserved_mem") e16faf26780f ("cma: factor out minimum alignment requirement") 658aafc8139c ("memblock: exclude MEMBLOCK_NOMAP regions from kmemleak") a7259df76702 ("memblock: make memblock_find_in_range method private") a70bb580bfea ("Merge tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b174f139bdc8aaaf72f5b67ad1bd512c4868a87e Mon Sep 17 00:00:00 2001 From: Frank van der Linden <fvdl(a)google.com> Date: Thu, 4 Apr 2024 16:25:14 +0000 Subject: [PATCH] mm/cma: drop incorrect alignment check in cma_init_reserved_mem cma_init_reserved_mem uses IS_ALIGNED to check if the size represented by one bit in the cma allocation bitmask is aligned with CMA_MIN_ALIGNMENT_BYTES (pageblock size). However, this is too strict, as this will fail if order_per_bit > pageblock_order, which is a valid configuration. We could check IS_ALIGNED both ways, but since both numbers are powers of two, no check is needed at all. Link: https://lkml.kernel.org/r/20240404162515.527802-1-fvdl@google.com Fixes: de9e14eebf33 ("drivers: dma-contiguous: add initialization from device tree") Signed-off-by: Frank van der Linden <fvdl(a)google.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/cma.c b/mm/cma.c index 01f5a8f71ddf..3e9724716bad 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -182,10 +182,6 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, if (!size || !memblock_is_region_reserved(base, size)) return -EINVAL; - /* alignment should be aligned with order_per_bit */ - if (!IS_ALIGNED(CMA_MIN_ALIGNMENT_PAGES, 1 << order_per_bit)) - return -EINVAL; - /* ensure minimal alignment required by mm core */ if (!IS_ALIGNED(base | size, CMA_MIN_ALIGNMENT_BYTES)) return -EINVAL;

3 months, 2 weeks

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024