May 2023 - Linux-stable-mirror

stable-rc/queue/4.14 baseline: 124 runs, 26 regressions (v4.14.311-206-g6055a76230ac)

by kernelci.org bot

stable-rc/queue/4.14 baseline: 124 runs, 26 regressions (v4.14.311-206-g6055a76230ac) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ meson-gxl-s905x-khadas-vim | arm64 | lab-baylibre | gcc-10 | defconfig | 1 meson8b-odroidc1 | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.31… Test: baseline Tree: stable-rc Branch: queue/4.14 Describe: v4.14.311-206-g6055a76230ac URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 6055a76230acdcf1de95275c944d32d0b3f27244 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ meson-gxl-s905x-khadas-vim | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/645772649bf9ee78132e85ec Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/645772649bf9ee78132e85ed failing since 306 days (last pass: v4.14.285-35-g61a723f50c9f, first fail: v4.14.285-46-ga87318551bac) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ meson8b-odroidc1 | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/64577111b513d60e572e862e 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.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64577111b513d60e572e862f failing since 448 days (last pass: v4.14.266-18-g18b83990eba9, first fail: v4.14.266-28-g7d44cfe0255d) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64577160a25b6a483b2e8656 Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64577160a25b6a483b2e8657 failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/6457728f455b0773b82e8619 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457728f455b0773b82e861a failing since 361 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/6457719fe17f8fc55b2e8608 Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457719fe17f8fc55b2e8609 failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64577331c0c621a2782e860f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64577331c0c621a2782e8610 failing since 361 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/6457714ba25b6a483b2e860b Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457714ba25b6a483b2e860c failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/6457729db4d46960632e85fb Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457729db4d46960632e85fc failing since 361 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64577176f7c9e6b8df2e85f8 Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64577176f7c9e6b8df2e85f9 failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/6457728eb4d46960632e85f2 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457728eb4d46960632e85f3 failing since 361 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/645771c810660fa3972e85ef Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/645771c810660fa3972e85f0 failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/6457730a47593c5cd22e8615 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457730a47593c5cd22e8616 failing since 361 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/6457714ca25b6a483b2e8614 Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457714ca25b6a483b2e8615 failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/645772a4b4d46960632e8605 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/645772a4b4d46960632e8606 failing since 361 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/645771757f951178932e85ed Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/645771757f951178932e85ee failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64577290fb1db1bb552e8600 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64577290fb1db1bb552e8601 failing since 361 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/645771c7409786619d2e85fa Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/645771c7409786619d2e85fb failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/6457731dc0c621a2782e8600 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457731dc0c621a2782e8601 failing since 361 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/6457714fa25b6a483b2e8617 Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457714fa25b6a483b2e8618 failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/6457729eb4d46960632e85fe Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457729eb4d46960632e85ff failing since 361 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64577161a25b6a483b2e8659 Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64577161a25b6a483b2e865a failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/6457728cbf9c4193dd2e85fb Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457728cbf9c4193dd2e85fc failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/645771db9b138985102e85ee Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/645771db9b138985102e85ef failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/6457729113ebd629a02e8692 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/6457729113ebd629a02e8693 failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64577151a25b6a483b2e861e Results: 0 PASS, 1 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64577151a25b6a483b2e861f failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64577275bf9c4193dd2e85f4 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig 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.14/v4.14.311-206-g6055a7623… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.311-206-g6055a7623… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64577275bf9c4193dd2e85f5 failing since 285 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84)

1 year, 9 months

1
0
0 0

FAILED: patch "[PATCH] dm: don't lock fs when the map is NULL in process of resume" 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 38d11da522aacaa05898c734a1cec86f1e611129 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023050716-eggnog-acutely-8d74@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 38d11da522aa ("dm: don't lock fs when the map is NULL in process of resume") 7533afa1d27b ("dm: send just one event on resize, not two") 84010e519f95 ("dm ima: measure data on device remove") 8eb6fab402e2 ("dm ima: measure data on device resume") 91ccbbac1747 ("dm ima: measure data on table load") 89f871af1b26 ("dm: delay registering the gendisk") ba30585936b0 ("dm: move setting md->type into dm_setup_md_queue") 74a2b6ec9380 ("dm: cleanup cleanup_mapped_device") 2cfa582be800 ("Merge tag 'for-5.14/dm-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 38d11da522aacaa05898c734a1cec86f1e611129 Mon Sep 17 00:00:00 2001 From: Li Lingfeng <lilingfeng3(a)huawei.com> Date: Tue, 18 Apr 2023 16:38:04 +0800 Subject: [PATCH] dm: don't lock fs when the map is NULL in process of resume Commit fa247089de99 ("dm: requeue IO if mapping table not yet available") added a detection of whether the mapping table is available in the IO submission process. If the mapping table is unavailable, it returns BLK_STS_RESOURCE and requeues the IO. This can lead to the following deadlock problem: dm create mount ioctl(DM_DEV_CREATE_CMD) ioctl(DM_TABLE_LOAD_CMD) do_mount vfs_get_tree ext4_get_tree get_tree_bdev sget_fc alloc_super // got &s->s_umount down_write_nested(&s->s_umount, ...); ext4_fill_super ext4_load_super ext4_read_bh submit_bio // submit and wait io end ioctl(DM_DEV_SUSPEND_CMD) dev_suspend do_resume dm_suspend __dm_suspend lock_fs freeze_bdev get_active_super grab_super // wait for &s->s_umount down_write(&s->s_umount); dm_swap_table __bind // set md->map(can't get here) IO will be continuously requeued while holding the lock since mapping table is NULL. At the same time, mapping table won't be set since the lock is not available. Like request-based DM, bio-based DM also has the same problem. It's not proper to just abort IO if the mapping table not available. So clear DM_SKIP_LOCKFS_FLAG when the mapping table is NULL, this allows the DM table to be loaded and the IO submitted upon resume. Fixes: fa247089de99 ("dm: requeue IO if mapping table not yet available") Cc: stable(a)vger.kernel.org Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> Signed-off-by: Mike Snitzer <snitzer(a)kernel.org> diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index 7d5c9c582ed2..cc77cf3d4109 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1168,10 +1168,13 @@ static int do_resume(struct dm_ioctl *param) /* Do we need to load a new map ? */ if (new_map) { sector_t old_size, new_size; + int srcu_idx; /* Suspend if it isn't already suspended */ - if (param->flags & DM_SKIP_LOCKFS_FLAG) + old_map = dm_get_live_table(md, &srcu_idx); + if ((param->flags & DM_SKIP_LOCKFS_FLAG) || !old_map) suspend_flags &= ~DM_SUSPEND_LOCKFS_FLAG; + dm_put_live_table(md, srcu_idx); if (param->flags & DM_NOFLUSH_FLAG) suspend_flags |= DM_SUSPEND_NOFLUSH_FLAG; if (!dm_suspended_md(md))

1 year, 9 months

1
0
0 0

FAILED: patch "[PATCH] mm/vmemmap/devdax: fix kernel crash when probing devdax" 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 87a7ae75d7383afa998f57656d1d14e2a730cc47 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023050737-caravan-flannels-c001@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 87a7ae75d738 ("mm/vmemmap/devdax: fix kernel crash when probing devdax devices") 9420f89db2dd ("mm: move most of core MM initialization to mm/mm_init.c") 23baf831a32c ("mm, treewide: redefine MAX_ORDER sanely") 61883d3c3241 ("iommu: fix MAX_ORDER usage in __iommu_dma_alloc_pages()") 7a16d7c7619b ("mm/slub: fix MAX_ORDER usage in calculate_order()") 75558ad31548 ("sparc/mm: fix MAX_ORDER usage in tsb_grow()") d2980d8d8265 ("Merge tag 'mm-nonmm-stable-2023-02-20-15-29' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 87a7ae75d7383afa998f57656d1d14e2a730cc47 Mon Sep 17 00:00:00 2001 From: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.ibm.com> Date: Tue, 11 Apr 2023 19:52:13 +0530 Subject: [PATCH] mm/vmemmap/devdax: fix kernel crash when probing devdax devices commit 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") added support for using optimized vmmemap for devdax devices. But how vmemmap mappings are created are architecture specific. For example, powerpc with hash translation doesn't have vmemmap mappings in init_mm page table instead they are bolted table entries in the hardware page table vmemmap_populate_compound_pages() used by vmemmap optimization code is not aware of these architecture-specific mapping. Hence allow architecture to opt for this feature. I selected architectures supporting HUGETLB_PAGE_OPTIMIZE_VMEMMAP option as also supporting this feature. This patch fixes the below crash on ppc64. BUG: Unable to handle kernel data access on write at 0xc00c000100400038 Faulting instruction address: 0xc000000001269d90 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc5-150500.34-default+ #2 5c90a668b6bbd142599890245c2fb5de19d7d28a Hardware name: IBM,9009-42G POWER9 (raw) 0x4e0202 0xf000005 of:IBM,FW950.40 (VL950_099) hv:phyp pSeries NIP: c000000001269d90 LR: c0000000004c57d4 CTR: 0000000000000000 REGS: c000000003632c30 TRAP: 0300 Not tainted (6.3.0-rc5-150500.34-default+) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24842228 XER: 00000000 CFAR: c0000000004c57d0 DAR: c00c000100400038 DSISR: 42000000 IRQMASK: 0 .... NIP [c000000001269d90] __init_single_page.isra.74+0x14/0x4c LR [c0000000004c57d4] __init_zone_device_page+0x44/0xd0 Call Trace: [c000000003632ed0] [c000000003632f60] 0xc000000003632f60 (unreliable) [c000000003632f10] [c0000000004c5ca0] memmap_init_zone_device+0x170/0x250 [c000000003632fe0] [c0000000005575f8] memremap_pages+0x2c8/0x7f0 [c0000000036330c0] [c000000000557b5c] devm_memremap_pages+0x3c/0xa0 [c000000003633100] [c000000000d458a8] dev_dax_probe+0x108/0x3e0 [c0000000036331a0] [c000000000d41430] dax_bus_probe+0xb0/0x140 [c0000000036331d0] [c000000000cef27c] really_probe+0x19c/0x520 [c000000003633260] [c000000000cef6b4] __driver_probe_device+0xb4/0x230 [c0000000036332e0] [c000000000cef888] driver_probe_device+0x58/0x120 [c000000003633320] [c000000000cefa6c] __device_attach_driver+0x11c/0x1e0 [c0000000036333a0] [c000000000cebc58] bus_for_each_drv+0xa8/0x130 [c000000003633400] [c000000000ceefcc] __device_attach+0x15c/0x250 [c0000000036334a0] [c000000000ced458] bus_probe_device+0x108/0x110 [c0000000036334f0] [c000000000ce92dc] device_add+0x7fc/0xa10 [c0000000036335b0] [c000000000d447c8] devm_create_dev_dax+0x1d8/0x530 [c000000003633640] [c000000000d46b60] __dax_pmem_probe+0x200/0x270 [c0000000036337b0] [c000000000d46bf0] dax_pmem_probe+0x20/0x70 [c0000000036337d0] [c000000000d2279c] nvdimm_bus_probe+0xac/0x2b0 [c000000003633860] [c000000000cef27c] really_probe+0x19c/0x520 [c0000000036338f0] [c000000000cef6b4] __driver_probe_device+0xb4/0x230 [c000000003633970] [c000000000cef888] driver_probe_device+0x58/0x120 [c0000000036339b0] [c000000000cefd08] __driver_attach+0x1d8/0x240 [c000000003633a30] [c000000000cebb04] bus_for_each_dev+0xb4/0x130 [c000000003633a90] [c000000000cee564] driver_attach+0x34/0x50 [c000000003633ab0] [c000000000ced878] bus_add_driver+0x218/0x300 [c000000003633b40] [c000000000cf1144] driver_register+0xa4/0x1b0 [c000000003633bb0] [c000000000d21a0c] __nd_driver_register+0x5c/0x100 [c000000003633c10] [c00000000206a2e8] dax_pmem_init+0x34/0x48 [c000000003633c30] [c0000000000132d0] do_one_initcall+0x60/0x320 [c000000003633d00] [c0000000020051b0] kernel_init_freeable+0x360/0x400 [c000000003633de0] [c000000000013764] kernel_init+0x34/0x1d0 [c000000003633e50] [c00000000000de14] ret_from_kernel_thread+0x5c/0x64 Link: https://lkml.kernel.org/r/20230411142214.64464-1-aneesh.kumar@linux.ibm.com Fixes: 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com> Reported-by: Tarun Sahu <tsahu(a)linux.ibm.com> Reviewed-by: Joao Martins <joao.m.martins(a)oracle.com> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/include/linux/mm.h b/include/linux/mm.h index 5a3eaa9a1f8c..21a7e2460084 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -3560,6 +3560,22 @@ void vmemmap_populate_print_last(void); void vmemmap_free(unsigned long start, unsigned long end, struct vmem_altmap *altmap); #endif + +#ifdef CONFIG_ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP +static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) +{ + return is_power_of_2(sizeof(struct page)) && + pgmap && (pgmap_vmemmap_nr(pgmap) > 1) && !altmap; +} +#else +static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) +{ + return false; +} +#endif + void register_page_bootmem_memmap(unsigned long section_nr, struct page *map, unsigned long nr_pages); diff --git a/mm/mm_init.c b/mm/mm_init.c index a0ec3b3acb5e..7f7f9c677854 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -1015,10 +1015,12 @@ static void __ref __init_zone_device_page(struct page *page, unsigned long pfn, * of an altmap. See vmemmap_populate_compound_pages(). */ static inline unsigned long compound_nr_pages(struct vmem_altmap *altmap, - unsigned long nr_pages) + struct dev_pagemap *pgmap) { - return is_power_of_2(sizeof(struct page)) && - !altmap ? 2 * (PAGE_SIZE / sizeof(struct page)) : nr_pages; + if (!vmemmap_can_optimize(altmap, pgmap)) + return pgmap_vmemmap_nr(pgmap); + + return 2 * (PAGE_SIZE / sizeof(struct page)); } static void __ref memmap_init_compound(struct page *head, @@ -1083,7 +1085,7 @@ void __ref memmap_init_zone_device(struct zone *zone, continue; memmap_init_compound(page, pfn, zone_idx, nid, pgmap, - compound_nr_pages(altmap, pfns_per_compound)); + compound_nr_pages(altmap, pgmap)); } pr_debug("%s initialised %lu pages in %ums\n", __func__, diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index c5398a5960d0..10d73a0dfcec 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -458,8 +458,7 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn, !IS_ALIGNED(nr_pages, PAGES_PER_SUBSECTION))) return NULL; - if (is_power_of_2(sizeof(struct page)) && - pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) + if (vmemmap_can_optimize(altmap, pgmap)) r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else r = vmemmap_populate(start, end, nid, altmap);

1 year, 9 months

1
0
0 0

FAILED: patch "[PATCH] mm/vmemmap/devdax: fix kernel crash when probing devdax" failed to apply to 6.3-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.3-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.3.y git checkout FETCH_HEAD git cherry-pick -x 87a7ae75d7383afa998f57656d1d14e2a730cc47 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023050734-mosaic-duplex-55e7@gregkh' --subject-prefix 'PATCH 6.3.y' HEAD^.. Possible dependencies: 87a7ae75d738 ("mm/vmemmap/devdax: fix kernel crash when probing devdax devices") 9420f89db2dd ("mm: move most of core MM initialization to mm/mm_init.c") 23baf831a32c ("mm, treewide: redefine MAX_ORDER sanely") 61883d3c3241 ("iommu: fix MAX_ORDER usage in __iommu_dma_alloc_pages()") 7a16d7c7619b ("mm/slub: fix MAX_ORDER usage in calculate_order()") 75558ad31548 ("sparc/mm: fix MAX_ORDER usage in tsb_grow()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 87a7ae75d7383afa998f57656d1d14e2a730cc47 Mon Sep 17 00:00:00 2001 From: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.ibm.com> Date: Tue, 11 Apr 2023 19:52:13 +0530 Subject: [PATCH] mm/vmemmap/devdax: fix kernel crash when probing devdax devices commit 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") added support for using optimized vmmemap for devdax devices. But how vmemmap mappings are created are architecture specific. For example, powerpc with hash translation doesn't have vmemmap mappings in init_mm page table instead they are bolted table entries in the hardware page table vmemmap_populate_compound_pages() used by vmemmap optimization code is not aware of these architecture-specific mapping. Hence allow architecture to opt for this feature. I selected architectures supporting HUGETLB_PAGE_OPTIMIZE_VMEMMAP option as also supporting this feature. This patch fixes the below crash on ppc64. BUG: Unable to handle kernel data access on write at 0xc00c000100400038 Faulting instruction address: 0xc000000001269d90 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc5-150500.34-default+ #2 5c90a668b6bbd142599890245c2fb5de19d7d28a Hardware name: IBM,9009-42G POWER9 (raw) 0x4e0202 0xf000005 of:IBM,FW950.40 (VL950_099) hv:phyp pSeries NIP: c000000001269d90 LR: c0000000004c57d4 CTR: 0000000000000000 REGS: c000000003632c30 TRAP: 0300 Not tainted (6.3.0-rc5-150500.34-default+) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24842228 XER: 00000000 CFAR: c0000000004c57d0 DAR: c00c000100400038 DSISR: 42000000 IRQMASK: 0 .... NIP [c000000001269d90] __init_single_page.isra.74+0x14/0x4c LR [c0000000004c57d4] __init_zone_device_page+0x44/0xd0 Call Trace: [c000000003632ed0] [c000000003632f60] 0xc000000003632f60 (unreliable) [c000000003632f10] [c0000000004c5ca0] memmap_init_zone_device+0x170/0x250 [c000000003632fe0] [c0000000005575f8] memremap_pages+0x2c8/0x7f0 [c0000000036330c0] [c000000000557b5c] devm_memremap_pages+0x3c/0xa0 [c000000003633100] [c000000000d458a8] dev_dax_probe+0x108/0x3e0 [c0000000036331a0] [c000000000d41430] dax_bus_probe+0xb0/0x140 [c0000000036331d0] [c000000000cef27c] really_probe+0x19c/0x520 [c000000003633260] [c000000000cef6b4] __driver_probe_device+0xb4/0x230 [c0000000036332e0] [c000000000cef888] driver_probe_device+0x58/0x120 [c000000003633320] [c000000000cefa6c] __device_attach_driver+0x11c/0x1e0 [c0000000036333a0] [c000000000cebc58] bus_for_each_drv+0xa8/0x130 [c000000003633400] [c000000000ceefcc] __device_attach+0x15c/0x250 [c0000000036334a0] [c000000000ced458] bus_probe_device+0x108/0x110 [c0000000036334f0] [c000000000ce92dc] device_add+0x7fc/0xa10 [c0000000036335b0] [c000000000d447c8] devm_create_dev_dax+0x1d8/0x530 [c000000003633640] [c000000000d46b60] __dax_pmem_probe+0x200/0x270 [c0000000036337b0] [c000000000d46bf0] dax_pmem_probe+0x20/0x70 [c0000000036337d0] [c000000000d2279c] nvdimm_bus_probe+0xac/0x2b0 [c000000003633860] [c000000000cef27c] really_probe+0x19c/0x520 [c0000000036338f0] [c000000000cef6b4] __driver_probe_device+0xb4/0x230 [c000000003633970] [c000000000cef888] driver_probe_device+0x58/0x120 [c0000000036339b0] [c000000000cefd08] __driver_attach+0x1d8/0x240 [c000000003633a30] [c000000000cebb04] bus_for_each_dev+0xb4/0x130 [c000000003633a90] [c000000000cee564] driver_attach+0x34/0x50 [c000000003633ab0] [c000000000ced878] bus_add_driver+0x218/0x300 [c000000003633b40] [c000000000cf1144] driver_register+0xa4/0x1b0 [c000000003633bb0] [c000000000d21a0c] __nd_driver_register+0x5c/0x100 [c000000003633c10] [c00000000206a2e8] dax_pmem_init+0x34/0x48 [c000000003633c30] [c0000000000132d0] do_one_initcall+0x60/0x320 [c000000003633d00] [c0000000020051b0] kernel_init_freeable+0x360/0x400 [c000000003633de0] [c000000000013764] kernel_init+0x34/0x1d0 [c000000003633e50] [c00000000000de14] ret_from_kernel_thread+0x5c/0x64 Link: https://lkml.kernel.org/r/20230411142214.64464-1-aneesh.kumar@linux.ibm.com Fixes: 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com> Reported-by: Tarun Sahu <tsahu(a)linux.ibm.com> Reviewed-by: Joao Martins <joao.m.martins(a)oracle.com> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/include/linux/mm.h b/include/linux/mm.h index 5a3eaa9a1f8c..21a7e2460084 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -3560,6 +3560,22 @@ void vmemmap_populate_print_last(void); void vmemmap_free(unsigned long start, unsigned long end, struct vmem_altmap *altmap); #endif + +#ifdef CONFIG_ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP +static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) +{ + return is_power_of_2(sizeof(struct page)) && + pgmap && (pgmap_vmemmap_nr(pgmap) > 1) && !altmap; +} +#else +static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) +{ + return false; +} +#endif + void register_page_bootmem_memmap(unsigned long section_nr, struct page *map, unsigned long nr_pages); diff --git a/mm/mm_init.c b/mm/mm_init.c index a0ec3b3acb5e..7f7f9c677854 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -1015,10 +1015,12 @@ static void __ref __init_zone_device_page(struct page *page, unsigned long pfn, * of an altmap. See vmemmap_populate_compound_pages(). */ static inline unsigned long compound_nr_pages(struct vmem_altmap *altmap, - unsigned long nr_pages) + struct dev_pagemap *pgmap) { - return is_power_of_2(sizeof(struct page)) && - !altmap ? 2 * (PAGE_SIZE / sizeof(struct page)) : nr_pages; + if (!vmemmap_can_optimize(altmap, pgmap)) + return pgmap_vmemmap_nr(pgmap); + + return 2 * (PAGE_SIZE / sizeof(struct page)); } static void __ref memmap_init_compound(struct page *head, @@ -1083,7 +1085,7 @@ void __ref memmap_init_zone_device(struct zone *zone, continue; memmap_init_compound(page, pfn, zone_idx, nid, pgmap, - compound_nr_pages(altmap, pfns_per_compound)); + compound_nr_pages(altmap, pgmap)); } pr_debug("%s initialised %lu pages in %ums\n", __func__, diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index c5398a5960d0..10d73a0dfcec 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -458,8 +458,7 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn, !IS_ALIGNED(nr_pages, PAGES_PER_SUBSECTION))) return NULL; - if (is_power_of_2(sizeof(struct page)) && - pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) + if (vmemmap_can_optimize(altmap, pgmap)) r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else r = vmemmap_populate(start, end, nid, altmap);

1 year, 9 months

1
0
0 0

FAILED: patch "[PATCH] mm/hugetlb: fix uffd-wp during fork()" 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 5a2f8d22ace4c8ac8798fab836dca7350fa710b1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023050718-verdict-stegosaur-3aaa@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 5a2f8d22ace4 ("mm/hugetlb: fix uffd-wp during fork()") d0ce0e47b323 ("mm/hugetlb: convert hugetlb fault paths to use alloc_hugetlb_folio()") ea4c353df377 ("mm/hugetlb: convert hugetlb_install_page to folios") 0ffdc38eb564 ("mm/hugetlb: convert restore_reserve_on_error() to folios") e37d3e838d90 ("mm/hugetlb: convert alloc_migrate_huge_page to folios") ff7d853b0313 ("mm/hugetlb: increase use of folios in alloc_huge_page()") 3a740e8bb56e ("mm/hugetlb: convert alloc_surplus_huge_page() to folios") a36f1e902474 ("mm/hugetlb: convert dequeue_hugetlb_page functions to folios") 5b4bd90f9ac7 ("rmap: add folio parameter to __page_set_anon_rmap()") db4e5dbdcdd5 ("mm: use a folio in hugepage_add_anon_rmap() and hugepage_add_new_anon_rmap()") 4d510f3da4c2 ("mm: add folio_add_new_anon_rmap()") c7c3dec1c9db ("mm: rmap: remove lock_page_memcg()") 19fc1a7e8b2b ("mm/hugetlb: change hugetlb allocation functions to return a folio") 7f325a8d2563 ("mm/hugetlb: convert free_gigantic_page() to folios") 2f6c57d696ab ("mm/hugetlb: convert add_hugetlb_page() to folios and add hugetlb_cma_folio()") 1a7cdab59b22 ("mm/hugetlb: convert dissolve_free_huge_page() to folios") 911565b82853 ("mm/hugetlb: convert destroy_compound_gigantic_page() to folios") 9fd330582b2f ("mm: add folio dtor and order setter functions") 4b51634cd16a ("mm,thp,rmap: subpages_mapcount COMPOUND_MAPPED if PMD-mapped") be5ef2d9b006 ("mm,thp,rmap: subpages_mapcount of PTE-mapped subpages") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5a2f8d22ace4c8ac8798fab836dca7350fa710b1 Mon Sep 17 00:00:00 2001 From: Peter Xu <peterx(a)redhat.com> Date: Mon, 17 Apr 2023 15:53:12 -0400 Subject: [PATCH] mm/hugetlb: fix uffd-wp during fork() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Patch series "mm/hugetlb: More fixes around uffd-wp vs fork() / RO pins", v2. This patch (of 6): There're a bunch of things that were wrong: - Reading uffd-wp bit from a swap entry should use pte_swp_uffd_wp() rather than huge_pte_uffd_wp(). - When copying over a pte, we should drop uffd-wp bit when !EVENT_FORK (aka, when !userfaultfd_wp(dst_vma)). - When doing early CoW for private hugetlb (e.g. when the parent page was pinned), uffd-wp bit should be properly carried over if necessary. No bug reported probably because most people do not even care about these corner cases, but they are still bugs and can be exposed by the recent unit tests introduced, so fix all of them in one shot. Link: https://lkml.kernel.org/r/20230417195317.898696-1-peterx@redhat.com Link: https://lkml.kernel.org/r/20230417195317.898696-2-peterx@redhat.com Fixes: bc70fbf269fd ("mm/hugetlb: handle uffd-wp during fork()") Signed-off-by: Peter Xu <peterx(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Mika Penttilä <mpenttil(a)redhat.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> 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 a08fb47fb200..d105b0b6a274 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4953,11 +4953,15 @@ static bool is_hugetlb_entry_hwpoisoned(pte_t pte) static void hugetlb_install_folio(struct vm_area_struct *vma, pte_t *ptep, unsigned long addr, - struct folio *new_folio) + struct folio *new_folio, pte_t old) { + pte_t newpte = make_huge_pte(vma, &new_folio->page, 1); + __folio_mark_uptodate(new_folio); hugepage_add_new_anon_rmap(new_folio, vma, addr); - set_huge_pte_at(vma->vm_mm, addr, ptep, make_huge_pte(vma, &new_folio->page, 1)); + if (userfaultfd_wp(vma) && huge_pte_uffd_wp(old)) + newpte = huge_pte_mkuffd_wp(newpte); + set_huge_pte_at(vma->vm_mm, addr, ptep, newpte); hugetlb_count_add(pages_per_huge_page(hstate_vma(vma)), vma->vm_mm); folio_set_hugetlb_migratable(new_folio); } @@ -5032,14 +5036,12 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, */ ; } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry))) { - bool uffd_wp = huge_pte_uffd_wp(entry); - - if (!userfaultfd_wp(dst_vma) && uffd_wp) + if (!userfaultfd_wp(dst_vma)) entry = huge_pte_clear_uffd_wp(entry); set_huge_pte_at(dst, addr, dst_pte, entry); } else if (unlikely(is_hugetlb_entry_migration(entry))) { swp_entry_t swp_entry = pte_to_swp_entry(entry); - bool uffd_wp = huge_pte_uffd_wp(entry); + bool uffd_wp = pte_swp_uffd_wp(entry); if (!is_readable_migration_entry(swp_entry) && cow) { /* @@ -5050,10 +5052,10 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, swp_offset(swp_entry)); entry = swp_entry_to_pte(swp_entry); if (userfaultfd_wp(src_vma) && uffd_wp) - entry = huge_pte_mkuffd_wp(entry); + entry = pte_swp_mkuffd_wp(entry); set_huge_pte_at(src, addr, src_pte, entry); } - if (!userfaultfd_wp(dst_vma) && uffd_wp) + if (!userfaultfd_wp(dst_vma)) entry = huge_pte_clear_uffd_wp(entry); set_huge_pte_at(dst, addr, dst_pte, entry); } else if (unlikely(is_pte_marker(entry))) { @@ -5118,7 +5120,8 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, /* huge_ptep of dst_pte won't change as in child */ goto again; } - hugetlb_install_folio(dst_vma, dst_pte, addr, new_folio); + hugetlb_install_folio(dst_vma, dst_pte, addr, + new_folio, src_pte_old); spin_unlock(src_ptl); spin_unlock(dst_ptl); continue; @@ -5136,6 +5139,9 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, entry = huge_pte_wrprotect(entry); } + if (!userfaultfd_wp(dst_vma)) + entry = huge_pte_clear_uffd_wp(entry); + set_huge_pte_at(dst, addr, dst_pte, entry); hugetlb_count_add(npages, dst); }

1 year, 9 months

1
0
0 0

FAILED: patch "[PATCH] mm/hugetlb: fix uffd-wp during fork()" failed to apply to 6.2-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.2-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.2.y git checkout FETCH_HEAD git cherry-pick -x 5a2f8d22ace4c8ac8798fab836dca7350fa710b1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023050717-related-online-6936@gregkh' --subject-prefix 'PATCH 6.2.y' HEAD^.. Possible dependencies: 5a2f8d22ace4 ("mm/hugetlb: fix uffd-wp during fork()") d0ce0e47b323 ("mm/hugetlb: convert hugetlb fault paths to use alloc_hugetlb_folio()") ea4c353df377 ("mm/hugetlb: convert hugetlb_install_page to folios") 0ffdc38eb564 ("mm/hugetlb: convert restore_reserve_on_error() to folios") e37d3e838d90 ("mm/hugetlb: convert alloc_migrate_huge_page to folios") ff7d853b0313 ("mm/hugetlb: increase use of folios in alloc_huge_page()") 3a740e8bb56e ("mm/hugetlb: convert alloc_surplus_huge_page() to folios") a36f1e902474 ("mm/hugetlb: convert dequeue_hugetlb_page functions to folios") 5b4bd90f9ac7 ("rmap: add folio parameter to __page_set_anon_rmap()") db4e5dbdcdd5 ("mm: use a folio in hugepage_add_anon_rmap() and hugepage_add_new_anon_rmap()") 4d510f3da4c2 ("mm: add folio_add_new_anon_rmap()") c7c3dec1c9db ("mm: rmap: remove lock_page_memcg()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5a2f8d22ace4c8ac8798fab836dca7350fa710b1 Mon Sep 17 00:00:00 2001 From: Peter Xu <peterx(a)redhat.com> Date: Mon, 17 Apr 2023 15:53:12 -0400 Subject: [PATCH] mm/hugetlb: fix uffd-wp during fork() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Patch series "mm/hugetlb: More fixes around uffd-wp vs fork() / RO pins", v2. This patch (of 6): There're a bunch of things that were wrong: - Reading uffd-wp bit from a swap entry should use pte_swp_uffd_wp() rather than huge_pte_uffd_wp(). - When copying over a pte, we should drop uffd-wp bit when !EVENT_FORK (aka, when !userfaultfd_wp(dst_vma)). - When doing early CoW for private hugetlb (e.g. when the parent page was pinned), uffd-wp bit should be properly carried over if necessary. No bug reported probably because most people do not even care about these corner cases, but they are still bugs and can be exposed by the recent unit tests introduced, so fix all of them in one shot. Link: https://lkml.kernel.org/r/20230417195317.898696-1-peterx@redhat.com Link: https://lkml.kernel.org/r/20230417195317.898696-2-peterx@redhat.com Fixes: bc70fbf269fd ("mm/hugetlb: handle uffd-wp during fork()") Signed-off-by: Peter Xu <peterx(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Mika Penttilä <mpenttil(a)redhat.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> 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 a08fb47fb200..d105b0b6a274 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4953,11 +4953,15 @@ static bool is_hugetlb_entry_hwpoisoned(pte_t pte) static void hugetlb_install_folio(struct vm_area_struct *vma, pte_t *ptep, unsigned long addr, - struct folio *new_folio) + struct folio *new_folio, pte_t old) { + pte_t newpte = make_huge_pte(vma, &new_folio->page, 1); + __folio_mark_uptodate(new_folio); hugepage_add_new_anon_rmap(new_folio, vma, addr); - set_huge_pte_at(vma->vm_mm, addr, ptep, make_huge_pte(vma, &new_folio->page, 1)); + if (userfaultfd_wp(vma) && huge_pte_uffd_wp(old)) + newpte = huge_pte_mkuffd_wp(newpte); + set_huge_pte_at(vma->vm_mm, addr, ptep, newpte); hugetlb_count_add(pages_per_huge_page(hstate_vma(vma)), vma->vm_mm); folio_set_hugetlb_migratable(new_folio); } @@ -5032,14 +5036,12 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, */ ; } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry))) { - bool uffd_wp = huge_pte_uffd_wp(entry); - - if (!userfaultfd_wp(dst_vma) && uffd_wp) + if (!userfaultfd_wp(dst_vma)) entry = huge_pte_clear_uffd_wp(entry); set_huge_pte_at(dst, addr, dst_pte, entry); } else if (unlikely(is_hugetlb_entry_migration(entry))) { swp_entry_t swp_entry = pte_to_swp_entry(entry); - bool uffd_wp = huge_pte_uffd_wp(entry); + bool uffd_wp = pte_swp_uffd_wp(entry); if (!is_readable_migration_entry(swp_entry) && cow) { /* @@ -5050,10 +5052,10 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, swp_offset(swp_entry)); entry = swp_entry_to_pte(swp_entry); if (userfaultfd_wp(src_vma) && uffd_wp) - entry = huge_pte_mkuffd_wp(entry); + entry = pte_swp_mkuffd_wp(entry); set_huge_pte_at(src, addr, src_pte, entry); } - if (!userfaultfd_wp(dst_vma) && uffd_wp) + if (!userfaultfd_wp(dst_vma)) entry = huge_pte_clear_uffd_wp(entry); set_huge_pte_at(dst, addr, dst_pte, entry); } else if (unlikely(is_pte_marker(entry))) { @@ -5118,7 +5120,8 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, /* huge_ptep of dst_pte won't change as in child */ goto again; } - hugetlb_install_folio(dst_vma, dst_pte, addr, new_folio); + hugetlb_install_folio(dst_vma, dst_pte, addr, + new_folio, src_pte_old); spin_unlock(src_ptl); spin_unlock(dst_ptl); continue; @@ -5136,6 +5139,9 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, entry = huge_pte_wrprotect(entry); } + if (!userfaultfd_wp(dst_vma)) + entry = huge_pte_clear_uffd_wp(entry); + set_huge_pte_at(dst, addr, dst_pte, entry); hugetlb_count_add(npages, dst); }

1 year, 9 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: reinterpret async discard iops_limit=0 as no delay" failed to apply to 6.3-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.3-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.3.y git checkout FETCH_HEAD git cherry-pick -x f263a7c3a53b99f691b41e4925feb67f2e8544d0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023050732-spectator-outburst-40e8@gregkh' --subject-prefix 'PATCH 6.3.y' HEAD^.. Possible dependencies: f263a7c3a53b ("btrfs: reinterpret async discard iops_limit=0 as no delay") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f263a7c3a53b99f691b41e4925feb67f2e8544d0 Mon Sep 17 00:00:00 2001 From: Boris Burkov <boris(a)bur.io> Date: Wed, 5 Apr 2023 12:43:59 -0700 Subject: [PATCH] btrfs: reinterpret async discard iops_limit=0 as no delay Currently, a limit of 0 results in a hard coded metering over 6 hours. Since the default is a set limit, I suspect no one truly depends on this rather arbitrary setting. Repurpose it for an arguably more useful "unlimited" mode, where the delay is 0. Note that if block groups are too new, or go fully empty, there is still a delay associated with those conditions. Those delays implement heuristics for not trimming a region we are relatively likely to fully overwrite soon. CC: stable(a)vger.kernel.org # 6.2+ Reviewed-by: Neal Gompa <neal(a)gompa.dev> Signed-off-by: Boris Burkov <boris(a)bur.io> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/discard.c b/fs/btrfs/discard.c index 0bc526f5fcd9..a6d77fe41e1a 100644 --- a/fs/btrfs/discard.c +++ b/fs/btrfs/discard.c @@ -56,8 +56,6 @@ #define BTRFS_DISCARD_DELAY (120ULL * NSEC_PER_SEC) #define BTRFS_DISCARD_UNUSED_DELAY (10ULL * NSEC_PER_SEC) -/* Target completion latency of discarding all discardable extents */ -#define BTRFS_DISCARD_TARGET_MSEC (6 * 60 * 60UL * MSEC_PER_SEC) #define BTRFS_DISCARD_MIN_DELAY_MSEC (1UL) #define BTRFS_DISCARD_MAX_DELAY_MSEC (1000UL) #define BTRFS_DISCARD_MAX_IOPS (1000U) @@ -577,6 +575,7 @@ void btrfs_discard_calc_delay(struct btrfs_discard_ctl *discard_ctl) s32 discardable_extents; s64 discardable_bytes; u32 iops_limit; + unsigned long min_delay = BTRFS_DISCARD_MIN_DELAY_MSEC; unsigned long delay; discardable_extents = atomic_read(&discard_ctl->discardable_extents); @@ -607,13 +606,19 @@ void btrfs_discard_calc_delay(struct btrfs_discard_ctl *discard_ctl) } iops_limit = READ_ONCE(discard_ctl->iops_limit); - if (iops_limit) + + if (iops_limit) { delay = MSEC_PER_SEC / iops_limit; - else - delay = BTRFS_DISCARD_TARGET_MSEC / discardable_extents; + } else { + /* + * Unset iops_limit means go as fast as possible, so allow a + * delay of 0. + */ + delay = 0; + min_delay = 0; + } - delay = clamp(delay, BTRFS_DISCARD_MIN_DELAY_MSEC, - BTRFS_DISCARD_MAX_DELAY_MSEC); + delay = clamp(delay, min_delay, BTRFS_DISCARD_MAX_DELAY_MSEC); discard_ctl->delay_ms = delay; spin_unlock(&discard_ctl->lock);

1 year, 9 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: reinterpret async discard iops_limit=0 as no delay" failed to apply to 6.2-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.2-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.2.y git checkout FETCH_HEAD git cherry-pick -x f263a7c3a53b99f691b41e4925feb67f2e8544d0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023050731-defensive-scariness-cea7@gregkh' --subject-prefix 'PATCH 6.2.y' HEAD^.. Possible dependencies: f263a7c3a53b ("btrfs: reinterpret async discard iops_limit=0 as no delay") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f263a7c3a53b99f691b41e4925feb67f2e8544d0 Mon Sep 17 00:00:00 2001 From: Boris Burkov <boris(a)bur.io> Date: Wed, 5 Apr 2023 12:43:59 -0700 Subject: [PATCH] btrfs: reinterpret async discard iops_limit=0 as no delay Currently, a limit of 0 results in a hard coded metering over 6 hours. Since the default is a set limit, I suspect no one truly depends on this rather arbitrary setting. Repurpose it for an arguably more useful "unlimited" mode, where the delay is 0. Note that if block groups are too new, or go fully empty, there is still a delay associated with those conditions. Those delays implement heuristics for not trimming a region we are relatively likely to fully overwrite soon. CC: stable(a)vger.kernel.org # 6.2+ Reviewed-by: Neal Gompa <neal(a)gompa.dev> Signed-off-by: Boris Burkov <boris(a)bur.io> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/discard.c b/fs/btrfs/discard.c index 0bc526f5fcd9..a6d77fe41e1a 100644 --- a/fs/btrfs/discard.c +++ b/fs/btrfs/discard.c @@ -56,8 +56,6 @@ #define BTRFS_DISCARD_DELAY (120ULL * NSEC_PER_SEC) #define BTRFS_DISCARD_UNUSED_DELAY (10ULL * NSEC_PER_SEC) -/* Target completion latency of discarding all discardable extents */ -#define BTRFS_DISCARD_TARGET_MSEC (6 * 60 * 60UL * MSEC_PER_SEC) #define BTRFS_DISCARD_MIN_DELAY_MSEC (1UL) #define BTRFS_DISCARD_MAX_DELAY_MSEC (1000UL) #define BTRFS_DISCARD_MAX_IOPS (1000U) @@ -577,6 +575,7 @@ void btrfs_discard_calc_delay(struct btrfs_discard_ctl *discard_ctl) s32 discardable_extents; s64 discardable_bytes; u32 iops_limit; + unsigned long min_delay = BTRFS_DISCARD_MIN_DELAY_MSEC; unsigned long delay; discardable_extents = atomic_read(&discard_ctl->discardable_extents); @@ -607,13 +606,19 @@ void btrfs_discard_calc_delay(struct btrfs_discard_ctl *discard_ctl) } iops_limit = READ_ONCE(discard_ctl->iops_limit); - if (iops_limit) + + if (iops_limit) { delay = MSEC_PER_SEC / iops_limit; - else - delay = BTRFS_DISCARD_TARGET_MSEC / discardable_extents; + } else { + /* + * Unset iops_limit means go as fast as possible, so allow a + * delay of 0. + */ + delay = 0; + min_delay = 0; + } - delay = clamp(delay, BTRFS_DISCARD_MIN_DELAY_MSEC, - BTRFS_DISCARD_MAX_DELAY_MSEC); + delay = clamp(delay, min_delay, BTRFS_DISCARD_MAX_DELAY_MSEC); discard_ctl->delay_ms = delay; spin_unlock(&discard_ctl->lock);

1 year, 9 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: set default discard iops_limit to 1000" failed to apply to 6.2-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.2-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.2.y git checkout FETCH_HEAD git cherry-pick -x cfe3445a58658b2a142a9ba5f5de69d91c56a297 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023050725-customary-casing-68ab@gregkh' --subject-prefix 'PATCH 6.2.y' HEAD^.. Possible dependencies: cfe3445a5865 ("btrfs: set default discard iops_limit to 1000") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From cfe3445a58658b2a142a9ba5f5de69d91c56a297 Mon Sep 17 00:00:00 2001 From: Boris Burkov <boris(a)bur.io> Date: Wed, 5 Apr 2023 12:43:58 -0700 Subject: [PATCH] btrfs: set default discard iops_limit to 1000 Previously, the default was a relatively conservative 10. This results in a 100ms delay, so with ~300 discards in a commit, it takes the full 30s till the next commit to finish the discards. On a workstation, this results in the disk never going idle, wasting power/battery, etc. Set the default to 1000, which results in using the smallest possible delay, currently, which is 1ms. This has shown to not pathologically keep the disk busy by the original reporter. Link: https://lore.kernel.org/linux-btrfs/Y%2F+n1wS%2F4XAH7X1p@nz/ Link: https://bugzilla.redhat.com/show_bug.cgi?id=2182228 CC: stable(a)vger.kernel.org # 6.2+ Reviewed-by: Neal Gompa <neal(a)gompa.dev Signed-off-by: Boris Burkov <boris(a)bur.io> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/discard.c b/fs/btrfs/discard.c index 317aeff6c1da..0bc526f5fcd9 100644 --- a/fs/btrfs/discard.c +++ b/fs/btrfs/discard.c @@ -60,7 +60,7 @@ #define BTRFS_DISCARD_TARGET_MSEC (6 * 60 * 60UL * MSEC_PER_SEC) #define BTRFS_DISCARD_MIN_DELAY_MSEC (1UL) #define BTRFS_DISCARD_MAX_DELAY_MSEC (1000UL) -#define BTRFS_DISCARD_MAX_IOPS (10U) +#define BTRFS_DISCARD_MAX_IOPS (1000U) /* Monotonically decreasing minimum length filters after index 0 */ static int discard_minlen[BTRFS_NR_DISCARD_LISTS] = {

1 year, 9 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: set default discard iops_limit to 1000" failed to apply to 6.3-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.3-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.3.y git checkout FETCH_HEAD git cherry-pick -x cfe3445a58658b2a142a9ba5f5de69d91c56a297 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023050724-striving-matter-4a91@gregkh' --subject-prefix 'PATCH 6.3.y' HEAD^.. Possible dependencies: cfe3445a5865 ("btrfs: set default discard iops_limit to 1000") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From cfe3445a58658b2a142a9ba5f5de69d91c56a297 Mon Sep 17 00:00:00 2001 From: Boris Burkov <boris(a)bur.io> Date: Wed, 5 Apr 2023 12:43:58 -0700 Subject: [PATCH] btrfs: set default discard iops_limit to 1000 Previously, the default was a relatively conservative 10. This results in a 100ms delay, so with ~300 discards in a commit, it takes the full 30s till the next commit to finish the discards. On a workstation, this results in the disk never going idle, wasting power/battery, etc. Set the default to 1000, which results in using the smallest possible delay, currently, which is 1ms. This has shown to not pathologically keep the disk busy by the original reporter. Link: https://lore.kernel.org/linux-btrfs/Y%2F+n1wS%2F4XAH7X1p@nz/ Link: https://bugzilla.redhat.com/show_bug.cgi?id=2182228 CC: stable(a)vger.kernel.org # 6.2+ Reviewed-by: Neal Gompa <neal(a)gompa.dev Signed-off-by: Boris Burkov <boris(a)bur.io> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/discard.c b/fs/btrfs/discard.c index 317aeff6c1da..0bc526f5fcd9 100644 --- a/fs/btrfs/discard.c +++ b/fs/btrfs/discard.c @@ -60,7 +60,7 @@ #define BTRFS_DISCARD_TARGET_MSEC (6 * 60 * 60UL * MSEC_PER_SEC) #define BTRFS_DISCARD_MIN_DELAY_MSEC (1UL) #define BTRFS_DISCARD_MAX_DELAY_MSEC (1000UL) -#define BTRFS_DISCARD_MAX_IOPS (10U) +#define BTRFS_DISCARD_MAX_IOPS (1000U) /* Monotonically decreasing minimum length filters after index 0 */ static int discard_minlen[BTRFS_NR_DISCARD_LISTS] = {

1 year, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2023