- Linux-stable-mirror - lists.linaro.org

✅ PASS: Test report for kernel 5.3.14-e123302.cki (stable-queue)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git Commit: e123302d9edd - xfrm: Fix memleak on xfrm state destroy The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK All kernel binaries, config files, and logs are available for download here: https://artifacts.cki-project.org/pipelines/320164 Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns transport ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests ppc64le: Host 1: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests Host 2: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common x86_64: Host 1: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡ Podman system integration test (as root) ⚡⚡⚡ Podman system integration test (as user) ⚡⚡⚡ LTP ⚡⚡⚡ Loopdev Sanity ⚡⚡⚡ Memory function: memfd_create ⚡⚡⚡ Memory function: kaslr ⚡⚡⚡ AMTU (Abstract Machine Test Utility) ⚡⚡⚡ Networking bridge: sanity ⚡⚡⚡ Ethernet drivers sanity ⚡⚡⚡ Networking MACsec: sanity ⚡⚡⚡ Networking socket: fuzz ⚡⚡⚡ Networking sctp-auth: sockopts test ⚡⚡⚡ Networking: igmp conformance test ⚡⚡⚡ Networking route: pmtu ⚡⚡⚡ Networking route_func: local ⚡⚡⚡ Networking route_func: forward ⚡⚡⚡ Networking TCP: keepalive test ⚡⚡⚡ Networking UDP: socket ⚡⚡⚡ Networking tunnel: geneve basic test ⚡⚡⚡ Networking tunnel: gre basic ⚡⚡⚡ L2TP basic test ⚡⚡⚡ Networking tunnel: vxlan basic ⚡⚡⚡ Networking ipsec: basic netns transport ⚡⚡⚡ Networking ipsec: basic netns tunnel ⚡⚡⚡ audit: audit testsuite test ⚡⚡⚡ httpd: mod_ssl smoke sanity ⚡⚡⚡ tuned: tune-processes-through-perf ⚡⚡⚡ pciutils: sanity smoke test ⚡⚡⚡ ALSA PCM loopback test ⚡⚡⚡ ALSA Control (mixer) Userspace Element test ⚡⚡⚡ storage: SCSI VPD ⚡⚡⚡ stress: stress-ng ⚡⚡⚡ trace: ftrace/tracer 🚧 ⚡⚡⚡ CIFS Connectathon 🚧 ⚡⚡⚡ POSIX pjd-fstest suites 🚧 ⚡⚡⚡ jvm test suite 🚧 ⚡⚡⚡ LTP: openposix test suite 🚧 ⚡⚡⚡ Networking vnic: ipvlan/basic 🚧 ⚡⚡⚡ iotop: sanity 🚧 ⚡⚡⚡ Usex - version 1.9-29 🚧 ⚡⚡⚡ storage: dm/common Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡ Storage SAN device stress - mpt3sas driver Host 3: ✅ Boot test ✅ Storage SAN device stress - megaraid_sas Host 4: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IOMMU boot test 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests Host 5: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns transport ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ pciutils: sanity smoke test ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ stress: stress-ng ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Test sources: https://github.com/CKI-project/tests-beaker 💚 Pull requests are welcome for new tests or improvements to existing tests! Waived tests ------------ If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed. Testing timeout --------------- We aim to provide a report within reasonable timeframe. Tests that haven't finished running are marked with ⏱. Reports for non-upstream kernels have a Beaker recipe linked to next to each host.

5 years, 11 months

1
0
0 0

Re: [PATCH] erofs: zero out when listxattr is called with no xattr

by Gao Xiang

Hi Sasha, On Mon, Dec 02, 2019 at 10:13:11PM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: cadf1ccf1b00 ("staging: erofs: add error handling for xattr submodule"). > > The bot has tested the following trees: v5.4.1, v5.3.14, v4.19.87. > > v5.4.1: Build OK! > v5.3.14: Failed to apply! Possible dependencies: > Unable to calculate > > v4.19.87: Failed to apply! Possible dependencies: > Unable to calculate Because of file movement, I'll backport manually then. Thanks, Gao Xiang > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? > > -- > Thanks, > Sasha

5 years, 11 months

1
0
0 0

[PATCH] nvme: Namepace identification descriptor list is optional

by Keith Busch

Despite NVM Express specification 1.3 requires a controller claiming to be 1.3 or higher implement Identify CNS 03h (Namespace Identification Descriptor list), the driver doesn't really need this identification in order to use a namespace. The code had already documented in comments that we're not to consider an error to this command. Return success if the controller provided any response to an namespace identification descriptors command. Fixes: 538af88ea7d9de24 ("nvme: make nvme_report_ns_ids propagate error back") Reported-by: Ingo Brunberg <ingo_brunberg(a)web.de> Cc: Sagi Grimberg <sagi(a)grimberg.me> Cc: stable(a)vger.kernel.org # 5.4+ Signed-off-by: Keith Busch <kbusch(a)kernel.org> --- drivers/nvme/host/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index e6ee34376c5e..2a84e1402244 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -1735,6 +1735,8 @@ static int nvme_report_ns_ids(struct nvme_ctrl *ctrl, unsigned int nsid, if (ret) dev_warn(ctrl->device, "Identify Descriptors failed (%d)\n", ret); + if (ret > 0) + ret = 0; } return ret; } -- 2.21.0

5 years, 11 months

3
8
0 0

stable-rc/linux-4.19.y boot: 142 boots: 0 failed, 134 passed with 7 offline, 1 untried/unknown (v4.19.87)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 142 boots: 0 failed, 134 passed with 7 offline, 1 untried/unknown (v4.19.87) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.87/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.87 Git Commit: 174651bdf802a2139065e8e31ce950e2f3fc4a94 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 80 unique boards, 23 SoC families, 17 builds out of 206 Boot Regressions Detected: arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: new failure (last pass: v4.19.86-299-gcc82722f8f1b) dm365evm,legacy: lab-baylibre-seattle: new failure (last pass: v4.19.86-299-gcc82722f8f1b) Offline Platforms: arm: exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab sunxi_defconfig: gcc-8 sun7i-a20-bananapi: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab mt7623n-bananapi-bpi-r2: 1 offline lab sun7i-a20-bananapi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 11 months

1
0
0 0

stable-rc/linux-4.14.y boot: 129 boots: 2 failed, 120 passed with 6 offline, 1 untried/unknown (v4.14.157)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 129 boots: 2 failed, 120 passed with 6 offline, 1 untried/unknown (v4.14.157) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.157/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.157 Git Commit: fbc5fe7a54d02e11972e3b2a5ddb6ffc88162c8f Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 71 unique boards, 21 SoC families, 15 builds out of 201 Boot Failures Detected: arm: multi_v7_defconfig: gcc-8: omap3-beagle-xm: 1 failed lab arm64: defconfig: gcc-8: meson-gxm-q200: 1 failed lab Offline Platforms: arm: exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab sunxi_defconfig: gcc-8 sun7i-a20-bananapi: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab mt7623n-bananapi-bpi-r2: 1 offline lab sun7i-a20-bananapi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 11 months

1
0
0 0

[PATCH v2 3/3] arm64: dts: allwinner: a64: olinuxino: Fix SDIO supply regulator

by Stefan Mavrodiev

A64-OLinuXino uses DCDC1 (VCC-IO) for MMC1 supply. In commit 916b68cfe4b5 ("arm64: dts: a64-olinuxino: Enable RTL8723BS WiFi") ALDO2 is set, which is VCC-PL. Since DCDC1 is always present, the boards are working without a problem. This patch sets the correct regulator. Fixes: 916b68cfe4b5 ("arm64: dts: a64-olinuxino: Enable RTL8723BS WiFi") Cc: stable(a)vger.kernel.org # v4.16+ Signed-off-by: Stefan Mavrodiev <stefan(a)olimex.com> --- arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts index ad3559c576dd..869bb146a9ff 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts @@ -140,7 +140,7 @@ &mmc1 { pinctrl-names = "default"; pinctrl-0 = <&mmc1_pins>; - vmmc-supply = <&reg_aldo2>; + vmmc-supply = <&reg_dcdc1>; vqmmc-supply = <&reg_dldo4>; mmc-pwrseq = <&wifi_pwrseq>; bus-width = <4>; -- 2.17.1

5 years, 11 months

2
1
0 0

[PATCH v2 1/3] arm64: dts: allwinner: a64: olinuxino: Fix eMMC supply regulator

by Stefan Mavrodiev

A64-OLinuXino-eMMC uses 1.8V for eMMC supply. This is done via a triple jumper, which sets VCC-PL to either 1.8V or 3.3V. This setting is different for boards with and without eMMC. This is not a big issue for DDR52 mode, however the eMMC will not work in HS200/HS400, since these modes explicitly requires 1.8V. Fixes: 94f68f3a4b2a ("arm64: dts: allwinner: a64: Add A64 OlinuXino board (with eMMC)") Cc: stable(a)vger.kernel.org # v5.4 Signed-off-by: Stefan Mavrodiev <stefan(a)olimex.com> --- Changes for v2: - Restore the original eMMC vmmc-supply property arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts index 96ab0227e82d..121e6cc4849b 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts @@ -15,7 +15,7 @@ pinctrl-names = "default"; pinctrl-0 = <&mmc2_pins>; vmmc-supply = <&reg_dcdc1>; - vqmmc-supply = <&reg_dcdc1>; + vqmmc-supply = <&reg_eldo1>; bus-width = <8>; non-removable; cap-mmc-hw-reset; -- 2.17.1

5 years, 11 months

2
1
0 0

[merged] memfd-fix-cow-issue-on-map_private-and-f_seal_future_write-mappings.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, memfd: fix COW issue on MAP_PRIVATE and F_SEAL_FUTURE_WRITE mappings has been removed from the -mm tree. Its filename was memfd-fix-cow-issue-on-map_private-and-f_seal_future_write-mappings.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Nicolas Geoffray <ngeoffray(a)google.com> Subject: mm, memfd: fix COW issue on MAP_PRIVATE and F_SEAL_FUTURE_WRITE mappings F_SEAL_FUTURE_WRITE has unexpected behavior when used with MAP_PRIVATE: A private mapping created after the memfd file that gets sealed with F_SEAL_FUTURE_WRITE loses the copy-on-write at fork behavior, meaning children and parent share the same memory, even though the mapping is private. The reason for this is due to the code below: static int shmem_mmap(struct file *file, struct vm_area_struct *vma) { struct shmem_inode_info *info = SHMEM_I(file_inode(file)); if (info->seals & F_SEAL_FUTURE_WRITE) { /* * New PROT_WRITE and MAP_SHARED mmaps are not allowed when * "future write" seal active. */ if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) return -EPERM; /* * Since the F_SEAL_FUTURE_WRITE seals allow for a MAP_SHARED * read-only mapping, take care to not allow mprotect to revert * protections. */ vma->vm_flags &= ~(VM_MAYWRITE); } ... } And for the mm to know if a mapping is copy-on-write: static inline bool is_cow_mapping(vm_flags_t flags) { return (flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE; } The patch fixes the issue by making the mprotect revert protection happen only for shared mappings. For private mappings, using mprotect will have no effect on the seal behavior. The F_SEAL_FUTURE_WRITE feature was introduced in v5.1 so v5.3.x stable kernels would need a backport. [akpm(a)linux-foundation.org: reflow comment, per Christoph] Link: http://lkml.kernel.org/r/20191107195355.80608-1-joel@joelfernandes.org Fixes: ab3948f58ff84 ("mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd") Signed-off-by: Nicolas Geoffray <ngeoffray(a)google.com> Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/mm/shmem.c~memfd-fix-cow-issue-on-map_private-and-f_seal_future_write-mappings +++ a/mm/shmem.c @@ -2214,11 +2214,14 @@ static int shmem_mmap(struct file *file, return -EPERM; /* - * Since the F_SEAL_FUTURE_WRITE seals allow for a MAP_SHARED - * read-only mapping, take care to not allow mprotect to revert - * protections. + * Since an F_SEAL_FUTURE_WRITE sealed memfd can be mapped as + * MAP_SHARED and read-only, take care to not allow mprotect to + * revert protections on such mappings. Do this only for shared + * mappings. For private mappings, don't need to mask + * VM_MAYWRITE as we still want them to be COW-writable. */ - vma->vm_flags &= ~(VM_MAYWRITE); + if (vma->vm_flags & VM_SHARED) + vma->vm_flags &= ~(VM_MAYWRITE); } file_accessed(file); _ Patches currently in -mm which might be from ngeoffray(a)google.com are

5 years, 11 months

1
0
0 0

[merged] mm-fix-a-huge-pud-insertion-race-during-faulting.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/memory.c: fix a huge pud insertion race during faulting has been removed from the -mm tree. Its filename was mm-fix-a-huge-pud-insertion-race-during-faulting.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Thomas Hellstrom <thellstrom(a)vmware.com> Subject: mm/memory.c: fix a huge pud insertion race during faulting A huge pud page can theoretically be faulted in racing with pmd_alloc() in __handle_mm_fault(). That will lead to pmd_alloc() returning an invalid pmd pointer. Fix this by adding a pud_trans_unstable() function similar to pmd_trans_unstable() and check whether the pud is really stable before using the pmd pointer. Race: Thread 1: Thread 2: Comment create_huge_pud() Fallback - not taken. create_huge_pud() Taken. pmd_alloc() Returns an invalid pointer. This will result in user-visible huge page data corruption. Note that this was caught during a code audit rather than a real experienced problem. It looks to me like the only implementation that currently creates huge pud pagetable entries is dev_dax_huge_fault() which doesn't appear to care much about private (COW) mappings or write-tracking which is, I believe, a prerequisite for create_huge_pud() falling back on thread 1, but not in thread 2. Link: http://lkml.kernel.org/r/20191115115808.21181-2-thomas_os@shipmail.org Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages") Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/asm-generic/pgtable.h | 25 +++++++++++++++++++++++++ mm/memory.c | 6 ++++++ 2 files changed, 31 insertions(+) --- a/include/asm-generic/pgtable.h~mm-fix-a-huge-pud-insertion-race-during-faulting +++ a/include/asm-generic/pgtable.h @@ -938,6 +938,31 @@ static inline int pud_trans_huge(pud_t p } #endif +/* See pmd_none_or_trans_huge_or_clear_bad for discussion. */ +static inline int pud_none_or_trans_huge_or_dev_or_clear_bad(pud_t *pud) +{ + pud_t pudval = READ_ONCE(*pud); + + if (pud_none(pudval) || pud_trans_huge(pudval) || pud_devmap(pudval)) + return 1; + if (unlikely(pud_bad(pudval))) { + pud_clear_bad(pud); + return 1; + } + return 0; +} + +/* See pmd_trans_unstable for discussion. */ +static inline int pud_trans_unstable(pud_t *pud) +{ +#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && \ + defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD) + return pud_none_or_trans_huge_or_dev_or_clear_bad(pud); +#else + return 0; +#endif +} + #ifndef pmd_read_atomic static inline pmd_t pmd_read_atomic(pmd_t *pmdp) { --- a/mm/memory.c~mm-fix-a-huge-pud-insertion-race-during-faulting +++ a/mm/memory.c @@ -4010,6 +4010,7 @@ static vm_fault_t __handle_mm_fault(stru vmf.pud = pud_alloc(mm, p4d, address); if (!vmf.pud) return VM_FAULT_OOM; +retry_pud: if (pud_none(*vmf.pud) && __transparent_hugepage_enabled(vma)) { ret = create_huge_pud(&vmf); if (!(ret & VM_FAULT_FALLBACK)) @@ -4036,6 +4037,11 @@ static vm_fault_t __handle_mm_fault(stru vmf.pmd = pmd_alloc(mm, vmf.pud, address); if (!vmf.pmd) return VM_FAULT_OOM; + + /* Huge pud page fault raced with pmd_alloc? */ + if (pud_trans_unstable(vmf.pud)) + goto retry_pud; + if (pmd_none(*vmf.pmd) && __transparent_hugepage_enabled(vma)) { ret = create_huge_pmd(&vmf); if (!(ret & VM_FAULT_FALLBACK)) _ Patches currently in -mm which might be from thellstrom(a)vmware.com are

5 years, 11 months

1
0
0 0

please apply mbox files for CONFIG_UNWINDER_FRAME_POINTER clang support

by Nick Desaulniers

Greg, Sasha, Please apply the following mbox files to 5.3, 4.19, and 4.14 respectively. They enable CONFIG_UNWINDER_FRAME_POINTER support for 32b ARM kernels when compiled with Clang. This is upstream commit 6dc5fd93b2f1ef75d5e50fced8cb193811f25f22. It's a clean cherry-pick to 5.3. A slight nudge was needed for 4.19 and 4.14 since the config name was changed in upstream commit f9b58e8c7d03. A further nudge was needed for 4.14 since a4353898980c and 469cb7376c06 don't exist there. We're looking to use these in Android. Trusting the better judgement of the stable maintainers, we're happy to carry these in the Android common kernel trees, alternatively, but I think these are pretty low risk to take. Link: https://github.com/ClangBuiltLinux/linux/issues/35 -- Thanks, ~Nick Desaulniers

5 years, 11 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror