March 2022 - Linux-stable-mirror

+ mempolicy-mbind_range-set_policy-after-vma_merge.patch added to -mm tree

by Andrew Morton

The patch titled Subject: mempolicy: mbind_range() set_policy() after vma_merge() has been added to the -mm tree. Its filename is mempolicy-mbind_range-set_policy-after-vma_merge.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/mempolicy-mbind_range-set_policy-… and later at https://ozlabs.org/~akpm/mmotm/broken-out/mempolicy-mbind_range-set_policy-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mempolicy: mbind_range() set_policy() after vma_merge() v2.6.34 commit 9d8cebd4bcd7 ("mm: fix mbind vma merge problem") introduced vma_merge() to mbind_range(); but unlike madvise, mlock and mprotect, it put a "continue" to next vma where its precedents go to update flags on current vma before advancing: that left vma with the wrong setting in the infamous vma_merge() case 8. v3.10 commit 1444f92c8498 ("mm: merging memory blocks resets mempolicy") tried to fix that in vma_adjust(), without fully understanding the issue. v3.11 commit 3964acd0dbec ("mm: mempolicy: fix mbind_range() && vma_adjust() interaction") reverted that, and went about the fix in the right way, but chose to optimize out an unnecessary mpol_dup() with a prior mpol_equal() test. But on tmpfs, that also pessimized out the vital call to its ->set_policy(), leaving the new mbind unenforced. The user visible effect was that the pages got allocated on the local node (happened to be 0), after the mbind() caller had specifically asked for them to be allocated on node 1. There was not any page migration involved in the case reported: the pages simply got allocated on the wrong node. Just delete that optimization now (though it could be made conditional on vma not having a set_policy). Also remove the "next" variable: it turned out to be blameless, but also pointless. Link: https://lkml.kernel.org/r/319e4db9-64ae-4bca-92f0-ade85d342ff@google.com Fixes: 3964acd0dbec ("mm: mempolicy: fix mbind_range() && vma_adjust() interaction") Signed-off-by: Hugh Dickins <hughd(a)google.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mempolicy.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/mm/mempolicy.c~mempolicy-mbind_range-set_policy-after-vma_merge +++ a/mm/mempolicy.c @@ -786,7 +786,6 @@ static int vma_replace_policy(struct vm_ static int mbind_range(struct mm_struct *mm, unsigned long start, unsigned long end, struct mempolicy *new_pol) { - struct vm_area_struct *next; struct vm_area_struct *prev; struct vm_area_struct *vma; int err = 0; @@ -801,8 +800,7 @@ static int mbind_range(struct mm_struct if (start > vma->vm_start) prev = vma; - for (; vma && vma->vm_start < end; prev = vma, vma = next) { - next = vma->vm_next; + for (; vma && vma->vm_start < end; prev = vma, vma = vma->vm_next) { vmstart = max(start, vma->vm_start); vmend = min(end, vma->vm_end); @@ -817,10 +815,6 @@ static int mbind_range(struct mm_struct anon_vma_name(vma)); if (prev) { vma = prev; - next = vma->vm_next; - if (mpol_equal(vma_policy(vma), new_pol)) - continue; - /* vma_merge() joined vma && vma->next, case 8 */ goto replace; } if (vma->vm_start != vmstart) { _ Patches currently in -mm which might be from hughd(a)google.com are mm-fs-delete-pf_swapwrite.patch mm-__isolate_lru_page_prepare-in-isolate_migratepages_block.patch tmpfs-support-for-file-creation-time-fix.patch shmem-mapping_set_exiting-to-help-mapped-resilience.patch tmpfs-do-not-allocate-pages-on-read.patch mm-_install_special_mapping-apply-vm_locked_clear_mask.patch mempolicy-mbind_range-set_policy-after-vma_merge.patch mm-thp-refix-__split_huge_pmd_locked-for-migration-pmd.patch mm-thp-clearpagedoublemap-in-first-page_add_file_rmap.patch mm-delete-__clearpagewaiters.patch mm-filemap_unaccount_folio-large-skip-mapcount-fixup.patch mm-thp-fix-nr_file_mapped-accounting-in-page__file_rmap.patch mm-warn-on-deleting-redirtied-only-if-accounted.patch mm-unmap_mapping_range_tree-with-i_mmap_rwsem-shared.patch

3 years, 9 months

1
0
0 0

[PATCH] block: check more requests for multiple_queues in blk_attempt_plug_merge

by Song Liu

RAID arrays check/repair operations benefit a lot from merging requests. If we only check the previous entry for merge attempt, many merge will be missed. As a result, significant regression is observed for RAID check and repair. Fix this by checking more than just the previous entry when plug->multiple_queues == true. This improves the check/repair speed of a 20-HDD raid6 from 19 MB/s to 103 MB/s. Fixes: d38a9c04c0d5 ("block: only check previous entry for plug merge attempt") Cc: stable(a)vger.kernel.org # v5.16 Reported-by: Larkin Lowrey <llowrey(a)nuclearwinter.com> Reported-by: Wilson Jonathan <i400sjon(a)gmail.com> Reported-by: Roger Heflin <rogerheflin(a)gmail.com> Signed-off-by: Song Liu <song(a)kernel.org> --- block/blk-merge.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/block/blk-merge.c b/block/blk-merge.c index 4de34a332c9f..57e2075fb2f4 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -1089,12 +1089,14 @@ bool blk_attempt_plug_merge(struct request_queue *q, struct bio *bio, if (!plug || rq_list_empty(plug->mq_list)) return false; - /* check the previously added entry for a quick merge attempt */ - rq = rq_list_peek(&plug->mq_list); - if (rq->q == q) { - if (blk_attempt_bio_merge(q, rq, bio, nr_segs, false) == - BIO_MERGE_OK) - return true; + rq_list_for_each(&plug->mq_list, rq) { + if (rq->q == q) { + if (blk_attempt_bio_merge(q, rq, bio, nr_segs, false) == + BIO_MERGE_OK) + return true; + } + if (!plug->multiple_queues) + break; } return false; } -- 2.30.2

3 years, 9 months

7
23
0 0

+ mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch added to -mm tree

by Andrew Morton

The patch titled Subject: mm: madvise: skip unmapped vma holes passed to process_madvise has been added to the -mm tree. Its filename is mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/mm-madvise-skip-unmapped-vma-hole… and later at https://ozlabs.org/~akpm/mmotm/broken-out/mm-madvise-skip-unmapped-vma-hole… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Charan Teja Kalla <quic_charante(a)quicinc.com> Subject: mm: madvise: skip unmapped vma holes passed to process_madvise The process_madvise() system call is expected to skip holes in vma passed through 'struct iovec' vector list. But do_madvise, which process_madvise() calls for each vma, returns ENOMEM in case of unmapped holes, despite the VMA is processed. Thus process_madvise() should treat ENOMEM as expected and consider the VMA passed to as processed and continue processing other vma's in the vector list. Returning -ENOMEM to user, despite the VMA is processed, will be unable to figure out where to start the next madvise. Link: https://lkml.kernel.org/r/4f091776142f2ebf7b94018146de72318474e686.16470087… Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: an external memory hinting API") Signed-off-by: Charan Teja Kalla <quic_charante(a)quicinc.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Stephen Rothwell <sfr(a)canb.auug.org.au> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/madvise.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/mm/madvise.c~mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise +++ a/mm/madvise.c @@ -1428,9 +1428,16 @@ SYSCALL_DEFINE5(process_madvise, int, pi while (iov_iter_count(&iter)) { iovec = iov_iter_iovec(&iter); + /* + * do_madvise returns ENOMEM if unmapped holes are present + * in the passed VMA. process_madvise() is expected to skip + * unmapped holes passed to it in the 'struct iovec' list + * and not fail because of them. Thus treat -ENOMEM return + * from do_madvise as valid and continue processing. + */ ret = do_madvise(mm, (unsigned long)iovec.iov_base, iovec.iov_len, behavior); - if (ret < 0) + if (ret < 0 && ret != -ENOMEM) break; iov_iter_advance(&iter, iovec.iov_len); } _ Patches currently in -mm which might be from quic_charante(a)quicinc.com are mm-vmscan-fix-documentation-for-page_check_references.patch mm-madvise-return-correct-bytes-advised-with-process_madvise.patch mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch

3 years, 9 months

1
0
0 0

+ mm-madvise-return-correct-bytes-advised-with-process_madvise.patch added to -mm tree

by Andrew Morton

The patch titled Subject: mm: madvise: return correct bytes advised with process_madvise has been added to the -mm tree. Its filename is mm-madvise-return-correct-bytes-advised-with-process_madvise.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/mm-madvise-return-correct-bytes-a… and later at https://ozlabs.org/~akpm/mmotm/broken-out/mm-madvise-return-correct-bytes-a… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Charan Teja Kalla <quic_charante(a)quicinc.com> Subject: mm: madvise: return correct bytes advised with process_madvise Patch series "mm: madvise: return correct bytes processed with process_madvise", v2. With the process_madvise(), always choose to return non zero processed bytes over an error. This can help the user to know on which VMA, passed in the 'struct iovec' vector list, is failed to advise thus can take the decission of retrying/skipping on that VMA. This patch (of 2): The process_madvise() system call returns error even after processing some VMA's passed in the 'struct iovec' vector list which leaves the user confused to know where to restart the advise next. It is also against this syscall man page[1] documentation where it mentions that "return value may be less than the total number of requested bytes, if an error occurred after some iovec elements were already processed.". Consider a user passed 10 VMA's in the 'struct iovec' vector list of which 9 are processed but one. Then it just returns the error caused on that failed VMA despite the first 9 VMA's processed, leaving the user confused about on which VMA it is failed. Returning the number of bytes processed here can help the user to know which VMA it is failed on and thus can retry/skip the advise on that VMA. [1]https://man7.org/linux/man-pages/man2/process_madvise.2.html. Link: https://lkml.kernel.org/r/cover.1647008754.git.quic_charante@quicinc.com Link: https://lkml.kernel.org/r/125b61a0edcee5c2db8658aed9d06a43a19ccafc.16470087… Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: an external memory hinting API") Signed-off-by: Charan Teja Kalla <quic_charante(a)quicinc.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: David Rientjes <rientjes(a)google.com> Cc: Stephen Rothwell <sfr(a)canb.auug.org.au> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/madvise.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/mm/madvise.c~mm-madvise-return-correct-bytes-advised-with-process_madvise +++ a/mm/madvise.c @@ -1435,8 +1435,7 @@ SYSCALL_DEFINE5(process_madvise, int, pi iov_iter_advance(&iter, iovec.iov_len); } - if (ret == 0) - ret = total_len - iov_iter_count(&iter); + ret = (total_len - iov_iter_count(&iter)) ? : ret; release_mm: mmput(mm); _ Patches currently in -mm which might be from quic_charante(a)quicinc.com are mm-vmscan-fix-documentation-for-page_check_references.patch mm-madvise-return-correct-bytes-advised-with-process_madvise.patch mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch

3 years, 9 months

1
0
0 0

[PATCH v3 11/11] rpmsg: Fix kfree() of static memory on setting driver_override

by Krzysztof Kozlowski

The driver_override field from platform driver should not be initialized from static memory (string literal) because the core later kfree() it, for example when driver_override is set via sysfs. Use dedicated helper to set driver_override properly. Fixes: 950a7388f02b ("rpmsg: Turn name service into a stand alone driver") Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)canonical.com> --- drivers/rpmsg/rpmsg_core.c | 3 ++- drivers/rpmsg/rpmsg_internal.h | 13 +++++++++++-- drivers/rpmsg/rpmsg_ns.c | 14 ++++++++++++-- include/linux/rpmsg.h | 6 ++++-- 4 files changed, 29 insertions(+), 7 deletions(-) diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c index d9e612f4f0f2..6e2bf2742973 100644 --- a/drivers/rpmsg/rpmsg_core.c +++ b/drivers/rpmsg/rpmsg_core.c @@ -397,7 +397,8 @@ field##_store(struct device *dev, struct device_attribute *attr, \ const char *buf, size_t sz) \ { \ struct rpmsg_device *rpdev = to_rpmsg_device(dev); \ - char *new, *old; \ + const char *old; \ + char *new; \ \ new = kstrndup(buf, sz, GFP_KERNEL); \ if (!new) \ diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h index b1245d3ed7c6..31345d6e9a7e 100644 --- a/drivers/rpmsg/rpmsg_internal.h +++ b/drivers/rpmsg/rpmsg_internal.h @@ -92,10 +92,19 @@ int rpmsg_release_channel(struct rpmsg_device *rpdev, */ static inline int rpmsg_chrdev_register_device(struct rpmsg_device *rpdev) { + int ret; + strcpy(rpdev->id.name, "rpmsg_chrdev"); - rpdev->driver_override = "rpmsg_chrdev"; + ret = driver_set_override(&rpdev->dev, &rpdev->driver_override, + "rpmsg_chrdev", strlen("rpmsg_chrdev")); + if (ret) + return ret; + + ret = rpmsg_register_device(rpdev); + if (ret) + kfree(rpdev->driver_override); - return rpmsg_register_device(rpdev); + return ret; } #endif diff --git a/drivers/rpmsg/rpmsg_ns.c b/drivers/rpmsg/rpmsg_ns.c index 762ff1ae279f..95a51543f5ad 100644 --- a/drivers/rpmsg/rpmsg_ns.c +++ b/drivers/rpmsg/rpmsg_ns.c @@ -20,12 +20,22 @@ */ int rpmsg_ns_register_device(struct rpmsg_device *rpdev) { + int ret; + strcpy(rpdev->id.name, "rpmsg_ns"); - rpdev->driver_override = "rpmsg_ns"; + ret = driver_set_override(&rpdev->dev, &rpdev->driver_override, + "rpmsg_ns", strlen("rpmsg_ns")); + if (ret) + return ret; + rpdev->src = RPMSG_NS_ADDR; rpdev->dst = RPMSG_NS_ADDR; - return rpmsg_register_device(rpdev); + ret = rpmsg_register_device(rpdev); + if (ret) + kfree(rpdev->driver_override); + + return ret; } EXPORT_SYMBOL(rpmsg_ns_register_device); diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h index 02fa9116cd60..20c8cd1cde21 100644 --- a/include/linux/rpmsg.h +++ b/include/linux/rpmsg.h @@ -41,7 +41,9 @@ struct rpmsg_channel_info { * rpmsg_device - device that belong to the rpmsg bus * @dev: the device struct * @id: device id (used to match between rpmsg drivers and devices) - * @driver_override: driver name to force a match + * @driver_override: driver name to force a match; do not set directly, + * because core frees it; use driver_set_override() to + * set or clear it. * @src: local address * @dst: destination address * @ept: the rpmsg endpoint of this channel @@ -51,7 +53,7 @@ struct rpmsg_channel_info { struct rpmsg_device { struct device dev; struct rpmsg_device_id id; - char *driver_override; + const char *driver_override; u32 src; u32 dst; struct rpmsg_endpoint *ept; -- 2.32.0

3 years, 9 months

2
1
0 0

stable-rc/queue/4.19 baseline: 84 runs, 1 regressions (v4.19.233-33-g7f14a8aa5043)

by kernelci.org bot

stable-rc/queue/4.19 baseline: 84 runs, 1 regressions (v4.19.233-33-g7f14a8aa5043) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------+-------+---------------+----------+----------------------------+------------ rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.19/kernel/v4.19.23… Test: baseline Tree: stable-rc Branch: queue/4.19 Describe: v4.19.233-33-g7f14a8aa5043 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 7f14a8aa5043838c163913de339bef48851b397b Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------+-------+---------------+----------+----------------------------+------------ rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/622b6c6ebfdc988911c62973 Results: 83 PASS, 7 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.233-33-g7f14a8aa50… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.233-33-g7f14a8aa50… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.bootrr.rockchip-i2s1-probed: https://kernelci.org/test/case/id/622b6c6ebfdc988911c62997 failing since 5 days (last pass: v4.19.232-31-g5cf846953aa2, first fail: v4.19.232-44-gfd65e02206f4) 2022-03-11T15:36:07.457208 /lava-5859900/1/../bin/lava-test-case

3 years, 9 months

1
0
0 0

[PATCH v6] x86/sgx: Free backing memory after faulting the enclave page

by Jarkko Sakkinen

There is a limited amount of SGX memory (EPC) on each system. When that memory is used up, SGX has its own swapping mechanism which is similar in concept but totally separate from the core mm/* code. Instead of swapping to disk, SGX swaps from EPC to normal RAM. That normal RAM comes from a shared memory pseudo-file and can itself be swapped by the core mm code. There is a hierarchy like this: EPC <-> shmem <-> disk After data is swapped back in from shmem to EPC, the shmem backing storage needs to be freed. Currently, the backing shmem is not freed. This effectively wastes the shmem while the enclave is running. The memory is recovered when the enclave is destroyed and the backing storage freed. Sort this out by freeing memory with shmem_truncate_range(), as soon as a page is faulted back to the EPC. In addition, free the memory for PCMD pages as soon as all PCMD's in a page have been marked as unused by zeroing its contents. Reported-by: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: stable(a)vger.kernel.org Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- v6: * Re-applied on top of tip/x86/sgx and fixed the merge conflict, i.e. sgx_encl_get_backing() instead of sgx_encl_lookup_backing(). v5: * Encapsulated file offset calculation for PCMD struct. * Replaced "magic number" PAGE_SIZE with sizeof(struct sgx_secs) to make the offset calculation more self-documentative. v4: * Sanitized the offset calculations. v3: * Resend. v2: * Rewrite commit message as proposed by Dave. * Truncate PCMD pages (Dave). --- arch/x86/kernel/cpu/sgx/encl.c | 57 ++++++++++++++++++++++++++++------ 1 file changed, 48 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c index 001808e3901c..6fa3d0a14b93 100644 --- a/arch/x86/kernel/cpu/sgx/encl.c +++ b/arch/x86/kernel/cpu/sgx/encl.c @@ -12,6 +12,30 @@ #include "encls.h" #include "sgx.h" +/* + * Calculate byte offset of a PCMD struct associated with an enclave page. PCMD's + * follow right after the EPC data in the backing storage. In addition to the + * visible enclave pages, there's one extra page slot for SECS, before PCMD + * structs. + */ +static inline pgoff_t sgx_encl_get_backing_page_pcmd_offset(struct sgx_encl *encl, + unsigned long page_index) +{ + pgoff_t epc_end_off = encl->size + sizeof(struct sgx_secs); + + return epc_end_off + page_index * sizeof(struct sgx_pcmd); +} + +/* + * Free a page from the backing storage in the given page index. + */ +static inline void sgx_encl_truncate_backing_page(struct sgx_encl *encl, unsigned long page_index) +{ + struct inode *inode = file_inode(encl->backing); + + shmem_truncate_range(inode, PFN_PHYS(page_index), PFN_PHYS(page_index) + PAGE_SIZE - 1); +} + /* * ELDU: Load an EPC page as unblocked. For more info, see "OS Management of EPC * Pages" in the SDM. @@ -22,9 +46,11 @@ static int __sgx_encl_eldu(struct sgx_encl_page *encl_page, { unsigned long va_offset = encl_page->desc & SGX_ENCL_PAGE_VA_OFFSET_MASK; struct sgx_encl *encl = encl_page->encl; + pgoff_t page_index, page_pcmd_off; struct sgx_pageinfo pginfo; struct sgx_backing b; - pgoff_t page_index; + bool pcmd_page_empty; + u8 *pcmd_page; int ret; if (secs_page) @@ -32,14 +58,16 @@ static int __sgx_encl_eldu(struct sgx_encl_page *encl_page, else page_index = PFN_DOWN(encl->size); + page_pcmd_off = sgx_encl_get_backing_page_pcmd_offset(encl, page_index); + ret = sgx_encl_get_backing(encl, page_index, &b); if (ret) return ret; pginfo.addr = encl_page->desc & PAGE_MASK; pginfo.contents = (unsigned long)kmap_atomic(b.contents); - pginfo.metadata = (unsigned long)kmap_atomic(b.pcmd) + - b.pcmd_offset; + pcmd_page = kmap_atomic(b.pcmd); + pginfo.metadata = (unsigned long)pcmd_page + b.pcmd_offset; if (secs_page) pginfo.secs = (u64)sgx_get_epc_virt_addr(secs_page); @@ -55,11 +83,24 @@ static int __sgx_encl_eldu(struct sgx_encl_page *encl_page, ret = -EFAULT; } - kunmap_atomic((void *)(unsigned long)(pginfo.metadata - b.pcmd_offset)); + memset(pcmd_page + b.pcmd_offset, 0, sizeof(struct sgx_pcmd)); + + /* + * The area for the PCMD in the page was zeroed above. Check if the + * whole page is now empty meaning that all PCMD's have been zeroed: + */ + pcmd_page_empty = !memchr_inv(pcmd_page, 0, PAGE_SIZE); + + kunmap_atomic(pcmd_page); kunmap_atomic((void *)(unsigned long)pginfo.contents); sgx_encl_put_backing(&b, false); + sgx_encl_truncate_backing_page(encl, page_index); + + if (pcmd_page_empty) + sgx_encl_truncate_backing_page(encl, PFN_DOWN(page_pcmd_off)); + return ret; } @@ -577,7 +618,7 @@ static struct page *sgx_encl_get_backing_page(struct sgx_encl *encl, int sgx_encl_get_backing(struct sgx_encl *encl, unsigned long page_index, struct sgx_backing *backing) { - pgoff_t pcmd_index = PFN_DOWN(encl->size) + 1 + (page_index >> 5); + pgoff_t page_pcmd_off = sgx_encl_get_backing_page_pcmd_offset(encl, page_index); struct page *contents; struct page *pcmd; @@ -585,7 +626,7 @@ int sgx_encl_get_backing(struct sgx_encl *encl, unsigned long page_index, if (IS_ERR(contents)) return PTR_ERR(contents); - pcmd = sgx_encl_get_backing_page(encl, pcmd_index); + pcmd = sgx_encl_get_backing_page(encl, PFN_DOWN(page_pcmd_off)); if (IS_ERR(pcmd)) { put_page(contents); return PTR_ERR(pcmd); @@ -594,9 +635,7 @@ int sgx_encl_get_backing(struct sgx_encl *encl, unsigned long page_index, backing->page_index = page_index; backing->contents = contents; backing->pcmd = pcmd; - backing->pcmd_offset = - (page_index & (PAGE_SIZE / sizeof(struct sgx_pcmd) - 1)) * - sizeof(struct sgx_pcmd); + backing->pcmd_offset = page_pcmd_off & (PAGE_SIZE - 1); return 0; } -- 2.35.1

3 years, 9 months

3
6
0 0

stable-rc/queue/5.10 baseline: 101 runs, 1 regressions (v5.10.104-58-gc5c63ac732e2)

by kernelci.org bot

stable-rc/queue/5.10 baseline: 101 runs, 1 regressions (v5.10.104-58-gc5c63ac732e2) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------+-------+---------------+----------+----------------------------+------------ rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.10/kernel/v5.10.10… Test: baseline Tree: stable-rc Branch: queue/5.10 Describe: v5.10.104-58-gc5c63ac732e2 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: c5c63ac732e2ad54f8ccb07163c746d90f36295e Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------+-------+---------------+----------+----------------------------+------------ rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/622b60fe21cc3c0f26c629a0 Results: 90 PASS, 2 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.104-58-gc5c63ac732… HTML log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.104-58-gc5c63ac732… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.bootrr.rockchip-i2s1-probed: https://kernelci.org/test/case/id/622b60fe21cc3c0f26c629c6 failing since 3 days (last pass: v5.10.103-56-ge5a40f18f4ce, first fail: v5.10.103-105-gf074cce6ae0d) 2022-03-11T14:47:10.159142 /lava-5859734/1/../bin/lava-test-case

3 years, 9 months

1
0
0 0

[tip: x86/urgent] x86/traps: Mark do_int3() NOKPROBE_SYMBOL

by tip-bot2 for Li Huafei

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: a365a65f9ca1ceb9cf1ac29db4a4f51df7c507ad Gitweb: https://git.kernel.org/tip/a365a65f9ca1ceb9cf1ac29db4a4f51df7c507ad Author: Li Huafei <lihuafei1(a)huawei.com> AuthorDate: Thu, 10 Mar 2022 20:09:15 +08:00 Committer: Borislav Petkov <bp(a)suse.de> CommitterDate: Fri, 11 Mar 2022 19:19:30 +01:00 x86/traps: Mark do_int3() NOKPROBE_SYMBOL Since kprobe_int3_handler() is called in do_int3(), probing do_int3() can cause a breakpoint recursion and crash the kernel. Therefore, do_int3() should be marked as NOKPROBE_SYMBOL. Fixes: 21e28290b317 ("x86/traps: Split int3 handler up") Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20220310120915.63349-1-lihuafei1@huawei.com --- arch/x86/kernel/traps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index c9d566d..8143693 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -659,6 +659,7 @@ static bool do_int3(struct pt_regs *regs) return res == NOTIFY_STOP; } +NOKPROBE_SYMBOL(do_int3); static void do_int3_user(struct pt_regs *regs) {

3 years, 9 months

1
0
0 0

stable-rc/queue/4.14 baseline: 48 runs, 1 regressions (v4.14.270-31-g223a2e117a9e)

by kernelci.org bot

stable-rc/queue/4.14 baseline: 48 runs, 1 regressions (v4.14.270-31-g223a2e117a9e) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------+------+--------------+----------+--------------------+------------ meson8b-odroidc1 | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.27… Test: baseline Tree: stable-rc Branch: queue/4.14 Describe: v4.14.270-31-g223a2e117a9e URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 223a2e117a9e692969ef5d2e3ff53f195d10afc8 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------+------+--------------+----------+--------------------+------------ meson8b-odroidc1 | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/622b53cf0101fc24fec62968 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.270-31-g223a2e117a… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.270-31-g223a2e117a… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/622b53cf0101fc24fec62969 failing since 26 days (last pass: v4.14.266-18-g18b83990eba9, first fail: v4.14.266-28-g7d44cfe0255d)

3 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2022