December 2020 - Linux-stable-mirror

patch "usb: mtu3: fix memory corruption in mtu3_debugfs_regset()" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: mtu3: fix memory corruption in mtu3_debugfs_regset() to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 3f6f6343a29d9ea7429306b83b18e66dc1331d5c Mon Sep 17 00:00:00 2001 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Thu, 3 Dec 2020 11:41:13 +0300 Subject: usb: mtu3: fix memory corruption in mtu3_debugfs_regset() This code is using the wrong sizeof() so it does not allocate enough memory. It allocates 32 bytes but 72 are required. That will lead to memory corruption. Fixes: ae07809255d3 ("usb: mtu3: add debugfs interface files") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Link: https://lore.kernel.org/r/X8ikqc4Mo2/0G72j@mwanda Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/mtu3/mtu3_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/mtu3/mtu3_debugfs.c b/drivers/usb/mtu3/mtu3_debugfs.c index fdeade6254ae..7537bfd651af 100644 --- a/drivers/usb/mtu3/mtu3_debugfs.c +++ b/drivers/usb/mtu3/mtu3_debugfs.c @@ -127,7 +127,7 @@ static void mtu3_debugfs_regset(struct mtu3 *mtu, void __iomem *base, struct debugfs_regset32 *regset; struct mtu3_regset *mregs; - mregs = devm_kzalloc(mtu->dev, sizeof(*regset), GFP_KERNEL); + mregs = devm_kzalloc(mtu->dev, sizeof(*mregs), GFP_KERNEL); if (!mregs) return; -- 2.29.2

3 years, 10 months

1
0
0 0

patch "usb: chipidea: ci_hdrc_imx: Pass DISABLE_DEVICE_STREAMING flag to" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: chipidea: ci_hdrc_imx: Pass DISABLE_DEVICE_STREAMING flag to to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From c7721e15f434920145c376e8fe77e1c079fc3726 Mon Sep 17 00:00:00 2001 From: Fabio Estevam <festevam(a)gmail.com> Date: Mon, 7 Dec 2020 10:09:09 +0800 Subject: usb: chipidea: ci_hdrc_imx: Pass DISABLE_DEVICE_STREAMING flag to imx6ul According to the i.MX6UL Errata document: https://www.nxp.com/docs/en/errata/IMX6ULCE.pdf ERR007881 also affects i.MX6UL, so pass the CI_HDRC_DISABLE_DEVICE_STREAMING flag to workaround the issue. Fixes: 52fe568e5d71 ("usb: chipidea: imx: add imx6ul usb support") Cc: <stable(a)vger.kernel.org> Signed-off-by: Fabio Estevam <festevam(a)gmail.com> Signed-off-by: Peter Chen <peter.chen(a)nxp.com> Link: https://lore.kernel.org/r/20201207020909.22483-2-peter.chen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/chipidea/ci_hdrc_imx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c index 25c65accf089..5e07a0a86d11 100644 --- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -57,7 +57,8 @@ static const struct ci_hdrc_imx_platform_flag imx6sx_usb_data = { static const struct ci_hdrc_imx_platform_flag imx6ul_usb_data = { .flags = CI_HDRC_SUPPORTS_RUNTIME_PM | - CI_HDRC_TURN_VBUS_EARLY_ON, + CI_HDRC_TURN_VBUS_EARLY_ON | + CI_HDRC_DISABLE_DEVICE_STREAMING, }; static const struct ci_hdrc_imx_platform_flag imx7d_usb_data = { -- 2.29.2

3 years, 10 months

1
0
0 0

stable-rc/linux-4.4.y baseline: 131 runs, 13 regressions (v4.4.247-13-g8f96dadc6cc2d)

by kernelci.org bot

stable-rc/linux-4.4.y baseline: 131 runs, 13 regressions (v4.4.247-13-g8f96dadc6cc2d) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ beagle-xm | arm | lab-baylibre | gcc-8 | omap2plus_defconfig | 2 panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 qemu_arm-virt-gicv2 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv2 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv2 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv2 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv2 | arm | lab-linaro-lkft | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3 | arm | lab-linaro-lkft | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.247-… Test: baseline Tree: stable-rc Branch: linux-4.4.y Describe: v4.4.247-13-g8f96dadc6cc2d URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 8f96dadc6cc2d33ea42fbcf2cff02e88365fe6de Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ beagle-xm | arm | lab-baylibre | gcc-8 | omap2plus_defconfig | 2 Details: https://kernelci.org/test/plan/id/5fceb4561da211265dc94cc8 Results: 2 PASS, 2 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.dmesg.crit: https://kernelci.org/test/case/id/5fceb4561da211265dc94ccb new failure (last pass: v4.4.246) 1 lines 2020-12-07 22:59:47.960000+00:00 Connected to omap3-beagle-xm console [channel connected] (~$quit to exit) 2020-12-07 22:59:47.961000+00:00 (user:) is already connected 2020-12-07 22:59:47.961000+00:00 (user:) is already connected 2020-12-07 22:59:47.961000+00:00 (user:) is already connected 2020-12-07 22:59:47.962000+00:00 (user:) is already connected 2020-12-07 22:59:47.962000+00:00 (user:) is already connected 2020-12-07 22:59:47.962000+00:00 (user:) is already connected 2020-12-07 22:59:47.962000+00:00 (user:) is already connected 2020-12-07 22:59:47.962000+00:00 (user:) is already connected 2020-12-07 22:59:47.962000+00:00 (user:) is already connected ... (477 line(s) more) * baseline.dmesg.emerg: https://kernelci.org/test/case/id/5fceb4561da211265dc94ccd new failure (last pass: v4.4.246) 28 lines 2020-12-07 23:01:37.626000+00:00 kern :emerg : Stack: (0xcb8fdd10 to 0xcb8fe000) 2020-12-07 23:01:37.633000+00:00 kern :emerg : dd00: bf02b83c bf010b84 cb99be10 bf02b8c8 2020-12-07 23:01:37.641000+00:00 kern :emerg : dd20: cb99be10 bf2200a8 00000002 cb937010 cb99be10 bf24ab54 cbba8510 cbba8510 2020-12-07 23:01:37.650000+00:00 kern :emerg : dd40: 00000000 00000000 ce226930 c01fb3c4 ce226930 ce226930 c0857d30 00000001 2020-12-07 23:01:37.658000+00:00 kern :emerg : dd60: ce226930 cbba8510 cbba85d0 00000000 ce226930 c0857d30 00000001 c09612c0 2020-12-07 23:01:37.667000+00:00 kern :emerg : dd80: ffffffed bf24efc8 fffffdfb 00000028 00000001 c00ce2b4 bf24f148 c0407354 2020-12-07 23:01:37.674000+00:00 kern :emerg : dda0: c09612c0 c120ca30 bf24efc8 00000000 00000028 c0405828 c09612c0 c09612f4 2020-12-07 23:01:37.683000+00:00 kern :emerg : ddc0: bf24efc8 00000000 00000000 c04059d0 00000000 bf24efc8 c0405944 c0403cf4 2020-12-07 23:01:37.691000+00:00 kern :emerg : dde0: ce0c38a4 ce220910 bf24efc8 cbbad840 c09dbb68 c0404e40 bf24db50 c095e460 2020-12-07 23:01:37.699000+00:00 kern :emerg : de00: cbbbda80 bf24efc8 c095e460 cbbbda80 bf252000 c0406408 c095e460 c095e460 ... (16 line(s) more) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb454fdddbe75a5c94cd8 Results: 3 PASS, 1 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.dmesg.emerg: https://kernelci.org/test/case/id/5fceb454fdddbe75a5c94cdd failing since 5 days (last pass: v4.4.246-25-g412881df37c23, first fail: v4.4.247) 2 lines 2020-12-07 23:01:34.722000+00:00 kern :emerg : lock: emif_lock+0x0/0xfffff26c [emif], .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv2 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb54423faa147a3c94cea Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb54423faa147a3c94ceb failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv2 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb6c47f23e09f72c94ce2 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb6c47f23e09f72c94ce3 failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv2 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb516ae71efd631c94cbe Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb516ae71efd631c94cbf failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv2 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb54323faa147a3c94ce5 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb54323faa147a3c94ce6 failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv2 | arm | lab-linaro-lkft | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb5284f9fbc9e06c94cd2 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb5284f9fbc9e06c94cd3 failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv3 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb5264f9fbc9e06c94cc6 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb5264f9fbc9e06c94cc7 failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv3 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb710691eed7449c94cd2 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb710691eed7449c94cd3 failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv3 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb509de8cded35dc94cc4 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb509de8cded35dc94cc5 failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb5324f9fbc9e06c94cde Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb5324f9fbc9e06c94cdf failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2) platform | arch | lab | compiler | defconfig | regressions --------------------+------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv3 | arm | lab-linaro-lkft | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fceb5294f9fbc9e06c94cd5 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.247-13-g8f96dadc6c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fceb5294f9fbc9e06c94cd6 failing since 23 days (last pass: v4.4.243-14-gcb8e837cb602, first fail: v4.4.243-20-g3c35b64319c2)

3 years, 10 months

1
0
0 0

[PATCH] exfat: Avoid allocating upcase table using kcalloc()

by Artem Labazov

The table for Unicode upcase conversion requires an order-5 allocation, which may fail on a highly-fragmented system: pool-udisksd: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 4 PID: 3756880 Comm: pool-udisksd Tainted: G U 5.8.10-200.fc32.x86_64 #1 Hardware name: Dell Inc. XPS 13 9360/0PVG6D, BIOS 2.13.0 11/14/2019 Call Trace: dump_stack+0x6b/0x88 warn_alloc.cold+0x75/0xd9 ? _cond_resched+0x16/0x40 ? __alloc_pages_direct_compact+0x144/0x150 __alloc_pages_slowpath.constprop.0+0xcfa/0xd30 ? __schedule+0x28a/0x840 ? __wait_on_bit_lock+0x92/0xa0 __alloc_pages_nodemask+0x2df/0x320 kmalloc_order+0x1b/0x80 kmalloc_order_trace+0x1d/0xa0 exfat_create_upcase_table+0x115/0x390 [exfat] exfat_fill_super+0x3ef/0x7f0 [exfat] ? sget_fc+0x1d0/0x240 ? exfat_init_fs_context+0x120/0x120 [exfat] get_tree_bdev+0x15c/0x250 vfs_get_tree+0x25/0xb0 do_mount+0x7c3/0xaf0 ? copy_mount_options+0xab/0x180 __x64_sys_mount+0x8e/0xd0 do_syscall_64+0x4d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Make the driver use vmalloc() to eliminate the issue. Cc: stable(a)vger.kernel.org # v5.7+ Signed-off-by: Artem Labazov <123321artyom(a)gmail.com> --- fs/exfat/nls.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/exfat/nls.c b/fs/exfat/nls.c index 675d0e7058c5..0582faf8de77 100644 --- a/fs/exfat/nls.c +++ b/fs/exfat/nls.c @@ -6,6 +6,7 @@ #include <linux/string.h> #include <linux/slab.h> #include <linux/buffer_head.h> +#include <linux/vmalloc.h> #include <asm/unaligned.h> #include "exfat_raw.h" @@ -659,7 +660,7 @@ static int exfat_load_upcase_table(struct super_block *sb, unsigned char skip = false; unsigned short *upcase_table; - upcase_table = kcalloc(UTBL_COUNT, sizeof(unsigned short), GFP_KERNEL); + upcase_table = vmalloc(UTBL_COUNT*sizeof(unsigned short)); if (!upcase_table) return -ENOMEM; @@ -715,7 +716,7 @@ static int exfat_load_default_upcase_table(struct super_block *sb) unsigned short uni = 0, *upcase_table; unsigned int index = 0; - upcase_table = kcalloc(UTBL_COUNT, sizeof(unsigned short), GFP_KERNEL); + upcase_table = vmalloc(UTBL_COUNT*sizeof(unsigned short)); if (!upcase_table) return -ENOMEM; @@ -803,5 +804,5 @@ int exfat_create_upcase_table(struct super_block *sb) void exfat_free_upcase_table(struct exfat_sb_info *sbi) { - kfree(sbi->vol_utbl); + vfree(sbi->vol_utbl); } -- 2.26.2

3 years, 10 months

4
8
0 0

[merged] hugetlb_cgroup-fix-offline-of-hugetlb-cgroup-with-reservations.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: hugetlb_cgroup: fix offline of hugetlb cgroup with reservations has been removed from the -mm tree. Its filename was hugetlb_cgroup-fix-offline-of-hugetlb-cgroup-with-reservations.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: hugetlb_cgroup: fix offline of hugetlb cgroup with reservations Adrian Moreno was ruuning a kubernetes 1.19 + containerd/docker workload using hugetlbfs. In this environment the issue is reproduced by: 1 - Start a simple pod that uses the recently added HugePages medium feature (pod yaml attached) 2 - Start a DPDK app. It doesn't need to run successfully (as in transfer packets) nor interact with real hardware. It seems just initializing the EAL layer (which handles hugepage reservation and locking) is enough to trigger the issue 3 - Delete the Pod (or let it "Complete"). This would result in a kworker thread going into a tight loop (top output): 1425 root 20 0 0 0 0 R 99.7 0.0 5:22.45 kworker/28:7+cgroup_destroy 'perf top -g' reports: - 63.28% 0.01% [kernel] [k] worker_thread - 49.97% worker_thread - 52.64% process_one_work - 62.08% css_killed_work_fn - hugetlb_cgroup_css_offline 41.52% _raw_spin_lock - 2.82% _cond_resched rcu_all_qs 2.66% PageHuge - 0.57% schedule - 0.57% __schedule We are spinning in the do-while loop in hugetlb_cgroup_css_offline. Worse yet, we are holding the master cgroup lock (cgroup_mutex) while infinitely spinning. Little else can be done on the system as the cgroup_mutex can not be acquired. Do note that the issue can be reproduced by simply offlining a hugetlb cgroup containing pages with reservation counts. The loop in hugetlb_cgroup_css_offline is moving page counts from the cgroup being offlined to the parent cgroup. This is done for each hstate, and is repeated until hugetlb_cgroup_have_usage returns false. The routine moving counts (hugetlb_cgroup_move_parent) is only moving 'usage' counts. The routine hugetlb_cgroup_have_usage is checking for both 'usage' and 'reservation' counts. Discussion about what to do with reservation counts when reparenting was discussed here: https://lore.kernel.org/linux-kselftest/CAHS8izMFAYTgxym-Hzb_JmkTK1N_S9tGN7… The decision was made to leave a zombie cgroup for with reservation counts. Unfortunately, the code checking reservation counts was incorrectly added to hugetlb_cgroup_have_usage. To fix the issue, simply remove the check for reservation counts. While fixing this issue, a related bug in hugetlb_cgroup_css_offline was noticed. The hstate index is not reinitialized each time through the do-while loop. Fix this as well. Link: https://lkml.kernel.org/r/20201203220242.158165-1-mike.kravetz@oracle.com Fixes: 1adc4d419aa2 ("hugetlb_cgroup: add interface for charge/uncharge hugetlb reservations") Reported-by: Adrian Moreno <amorenoz(a)redhat.com> Tested-by: Adrian Moreno <amorenoz(a)redhat.com> Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reviewed-by: Shakeel Butt <shakeelb(a)google.com> Cc: Mina Almasry <almasrymina(a)google.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Greg Thelen <gthelen(a)google.com> Cc: Sandipan Das <sandipan(a)linux.ibm.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/hugetlb_cgroup.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/mm/hugetlb_cgroup.c~hugetlb_cgroup-fix-offline-of-hugetlb-cgroup-with-reservations +++ a/mm/hugetlb_cgroup.c @@ -82,11 +82,8 @@ static inline bool hugetlb_cgroup_have_u for (idx = 0; idx < hugetlb_max_hstate; idx++) { if (page_counter_read( - hugetlb_cgroup_counter_from_cgroup(h_cg, idx)) || - page_counter_read(hugetlb_cgroup_counter_from_cgroup_rsvd( - h_cg, idx))) { + hugetlb_cgroup_counter_from_cgroup(h_cg, idx))) return true; - } } return false; } @@ -202,9 +199,10 @@ static void hugetlb_cgroup_css_offline(s struct hugetlb_cgroup *h_cg = hugetlb_cgroup_from_css(css); struct hstate *h; struct page *page; - int idx = 0; + int idx; do { + idx = 0; for_each_hstate(h) { spin_lock(&hugetlb_lock); list_for_each_entry(page, &h->hugepage_activelist, lru) _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are

3 years, 10 months

1
0
0 0

[merged] mm-swapfile-do-not-sleep-with-a-spin-lock-held.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/swapfile: do not sleep with a spin lock held has been removed from the -mm tree. Its filename was mm-swapfile-do-not-sleep-with-a-spin-lock-held.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Qian Cai <qcai(a)redhat.com> Subject: mm/swapfile: do not sleep with a spin lock held We can't call kvfree() with a spin lock held, so defer it. Fixes a might_sleep() runtime warning. Link: https://lkml.kernel.org/r/20201202151549.10350-1-qcai@redhat.com Fixes: 873d7bcfd066 ("mm/swapfile.c: use kvzalloc for swap_info_struct allocation") Signed-off-by: Qian Cai <qcai(a)redhat.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/swapfile.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/mm/swapfile.c~mm-swapfile-do-not-sleep-with-a-spin-lock-held +++ a/mm/swapfile.c @@ -2867,6 +2867,7 @@ late_initcall(max_swapfiles_check); static struct swap_info_struct *alloc_swap_info(void) { struct swap_info_struct *p; + struct swap_info_struct *defer = NULL; unsigned int type; int i; @@ -2895,7 +2896,7 @@ static struct swap_info_struct *alloc_sw smp_wmb(); WRITE_ONCE(nr_swapfiles, nr_swapfiles + 1); } else { - kvfree(p); + defer = p; p = swap_info[type]; /* * Do not memset this entry: a racing procfs swap_next() @@ -2908,6 +2909,7 @@ static struct swap_info_struct *alloc_sw plist_node_init(&p->avail_lists[i], 0); p->flags = SWP_USED; spin_unlock(&swap_lock); + kvfree(defer); spin_lock_init(&p->lock); spin_lock_init(&p->cont_lock); _ Patches currently in -mm which might be from qcai(a)redhat.com are

3 years, 10 months

1
0
0 0

[merged] mm-zsmallocc-drop-zsmalloc_pgtable_mapping.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/zsmalloc.c: drop ZSMALLOC_PGTABLE_MAPPING has been removed from the -mm tree. Its filename was mm-zsmallocc-drop-zsmalloc_pgtable_mapping.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Minchan Kim <minchan(a)kernel.org> Subject: mm/zsmalloc.c: drop ZSMALLOC_PGTABLE_MAPPING While I was doing zram testing, I found sometimes decompression failed since the compression buffer was corrupted. With investigation, I found below commit calls cond_resched unconditionally so it could make a problem in atomic context if the task is reschedule. [ 55.109012] BUG: sleeping function called from invalid context at mm/vmalloc.c:108 [ 55.110774] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 946, name: memhog [ 55.111973] 3 locks held by memhog/946: [ 55.112807] #0: ffff9d01d4b193e8 (&mm->mmap_lock#2){++++}-{4:4}, at: __mm_populate+0x103/0x160 [ 55.114151] #1: ffffffffa3d53de0 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_slowpath.constprop.0+0xa98/0x1160 [ 55.115848] #2: ffff9d01d56b8110 (&zspage->lock){.+.+}-{3:3}, at: zs_map_object+0x8e/0x1f0 [ 55.118947] CPU: 0 PID: 946 Comm: memhog Not tainted 5.9.3-00011-gc5bfc0287345-dirty #316 [ 55.121265] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 [ 55.122540] Call Trace: [ 55.122974] dump_stack+0x8b/0xb8 [ 55.123588] ___might_sleep.cold+0xb6/0xc6 [ 55.124328] unmap_kernel_range_noflush+0x2eb/0x350 [ 55.125198] unmap_kernel_range+0x14/0x30 [ 55.125920] zs_unmap_object+0xd5/0xe0 [ 55.126604] zram_bvec_rw.isra.0+0x38c/0x8e0 [ 55.127462] zram_rw_page+0x90/0x101 [ 55.128199] bdev_write_page+0x92/0xe0 [ 55.128957] ? swap_slot_free_notify+0xb0/0xb0 [ 55.129841] __swap_writepage+0x94/0x4a0 [ 55.130636] ? do_raw_spin_unlock+0x4b/0xa0 [ 55.131462] ? _raw_spin_unlock+0x1f/0x30 [ 55.132261] ? page_swapcount+0x6c/0x90 [ 55.133038] pageout+0xe3/0x3a0 [ 55.133702] shrink_page_list+0xb94/0xd60 [ 55.134626] shrink_inactive_list+0x158/0x460 We can fix this by removing the ZSMALLOC_PGTABLE_MAPPING feature (which contains the offending calling code) from zsmalloc. Even though this option showed some amount improvement(e.g., 30%) in some arm32 platforms, it has been headache to maintain since it have abused APIs[1](e.g., unmap_kernel_range in atomic context). Since we are approaching to deprecate 32bit machines and already made the config option available for only builtin build since v5.8, lastly it has been not default option in zsmalloc, it's time to drop the option for better maintenance. [1] http://lore.kernel.org/linux-mm/20201105170249.387069-1-minchan@kernel.org Link: https://lkml.kernel.org/r/20201117202916.GA3856507@google.com Fixes: e47110e90584 ("mm/vunmap: add cond_resched() in vunmap_pmd_range") Signed-off-by: Minchan Kim <minchan(a)kernel.org> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com> Cc: Tony Lindgren <tony(a)atomide.com> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Harish Sriram <harish(a)linux.ibm.com> Cc: Uladzislau Rezki <urezki(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/arm/configs/omap2plus_defconfig | 1 include/linux/zsmalloc.h | 1 mm/Kconfig | 13 ------ mm/zsmalloc.c | 54 ------------------------- 4 files changed, 69 deletions(-) --- a/arch/arm/configs/omap2plus_defconfig~mm-zsmallocc-drop-zsmalloc_pgtable_mapping +++ a/arch/arm/configs/omap2plus_defconfig @@ -81,7 +81,6 @@ CONFIG_PARTITION_ADVANCED=y CONFIG_BINFMT_MISC=y CONFIG_CMA=y CONFIG_ZSMALLOC=m -CONFIG_ZSMALLOC_PGTABLE_MAPPING=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y --- a/include/linux/zsmalloc.h~mm-zsmallocc-drop-zsmalloc_pgtable_mapping +++ a/include/linux/zsmalloc.h @@ -20,7 +20,6 @@ * zsmalloc mapping modes * * NOTE: These only make a difference when a mapped object spans pages. - * They also have no effect when ZSMALLOC_PGTABLE_MAPPING is selected. */ enum zs_mapmode { ZS_MM_RW, /* normal read-write mapping */ --- a/mm/Kconfig~mm-zsmallocc-drop-zsmalloc_pgtable_mapping +++ a/mm/Kconfig @@ -707,19 +707,6 @@ config ZSMALLOC returned by an alloc(). This handle must be mapped in order to access the allocated space. -config ZSMALLOC_PGTABLE_MAPPING - bool "Use page table mapping to access object in zsmalloc" - depends on ZSMALLOC=y - help - By default, zsmalloc uses a copy-based object mapping method to - access allocations that span two pages. However, if a particular - architecture (ex, ARM) performs VM mapping faster than copying, - then you should select this. This causes zsmalloc to use page table - mapping rather than copying for object mapping. - - You can check speed with zsmalloc benchmark: - https://github.com/spartacus06/zsmapbench - config ZSMALLOC_STAT bool "Export zsmalloc statistics" depends on ZSMALLOC --- a/mm/zsmalloc.c~mm-zsmallocc-drop-zsmalloc_pgtable_mapping +++ a/mm/zsmalloc.c @@ -293,11 +293,7 @@ struct zspage { }; struct mapping_area { -#ifdef CONFIG_ZSMALLOC_PGTABLE_MAPPING - struct vm_struct *vm; /* vm area for mapping object that span pages */ -#else char *vm_buf; /* copy buffer for objects that span pages */ -#endif char *vm_addr; /* address of kmap_atomic()'ed pages */ enum zs_mapmode vm_mm; /* mapping mode */ }; @@ -1113,54 +1109,6 @@ static struct zspage *find_get_zspage(st return zspage; } -#ifdef CONFIG_ZSMALLOC_PGTABLE_MAPPING -static inline int __zs_cpu_up(struct mapping_area *area) -{ - /* - * Make sure we don't leak memory if a cpu UP notification - * and zs_init() race and both call zs_cpu_up() on the same cpu - */ - if (area->vm) - return 0; - area->vm = get_vm_area(PAGE_SIZE * 2, 0); - if (!area->vm) - return -ENOMEM; - - /* - * Populate ptes in advance to avoid pte allocation with GFP_KERNEL - * in non-preemtible context of zs_map_object. - */ - return apply_to_page_range(&init_mm, (unsigned long)area->vm->addr, - PAGE_SIZE * 2, NULL, NULL); -} - -static inline void __zs_cpu_down(struct mapping_area *area) -{ - if (area->vm) - free_vm_area(area->vm); - area->vm = NULL; -} - -static inline void *__zs_map_object(struct mapping_area *area, - struct page *pages[2], int off, int size) -{ - unsigned long addr = (unsigned long)area->vm->addr; - - BUG_ON(map_kernel_range(addr, PAGE_SIZE * 2, PAGE_KERNEL, pages) < 0); - area->vm_addr = area->vm->addr; - return area->vm_addr + off; -} - -static inline void __zs_unmap_object(struct mapping_area *area, - struct page *pages[2], int off, int size) -{ - unsigned long addr = (unsigned long)area->vm_addr; - - unmap_kernel_range(addr, PAGE_SIZE * 2); -} - -#else /* CONFIG_ZSMALLOC_PGTABLE_MAPPING */ - static inline int __zs_cpu_up(struct mapping_area *area) { /* @@ -1241,8 +1189,6 @@ out: pagefault_enable(); } -#endif /* CONFIG_ZSMALLOC_PGTABLE_MAPPING */ - static int zs_cpu_prepare(unsigned int cpu) { struct mapping_area *area; _ Patches currently in -mm which might be from minchan(a)kernel.org are zram-support-a-page-writeback.patch zram-add-stat-to-gather-incompressible-pages-since-zram-set-up.patch

3 years, 10 months

1
0
0 0

[merged] mm-list_lru-set-shrinker-map-bit-when-child-nr_items-is-not-zero.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: list_lru: set shrinker map bit when child nr_items is not zero has been removed from the -mm tree. Its filename was mm-list_lru-set-shrinker-map-bit-when-child-nr_items-is-not-zero.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Yang Shi <shy828301(a)gmail.com> Subject: mm: list_lru: set shrinker map bit when child nr_items is not zero When investigating a slab cache bloat problem, significant amount of negative dentry cache was seen, but confusingly they neither got shrunk by reclaimer (the host has very tight memory) nor be shrunk by dropping cache. The vmcore shows there are over 14M negative dentry objects on lru, but tracing result shows they were even not scanned at all. The further investigation shows the memcg's vfs shrinker_map bit is not set. So the reclaimer or dropping cache just skip calling vfs shrinker. So we have to reboot the hosts to get the memory back. I didn't manage to come up with a reproducer in test environment, and the problem can't be reproduced after rebooting. But it seems there is race between shrinker map bit clear and reparenting by code inspection. The hypothesis is elaborated as below. The memcg hierarchy on our production environment looks like: root / \ system user The main workloads are running under user slice's children, and it creates and removes memcg frequently. So reparenting happens very often under user slice, but no task is under user slice directly. So with the frequent reparenting and tight memory pressure, the below hypothetical race condition may happen: CPU A CPU B reparent dst->nr_items == 0 shrinker: total_objects == 0 add src->nr_items to dst set_bit return SHRINK_EMPTY clear_bit child memcg offline replace child's kmemcg_id with parent's (in memcg_offline_kmem()) list_lru_del() between shrinker runs see parent's kmemcg_id dec dst->nr_items reparent again dst->nr_items may go negative due to concurrent list_lru_del() The second run of shrinker: read nr_items without any synchronization, so it may see intermediate negative nr_items then total_objects may return 0 coincidently keep the bit cleared dst->nr_items != 0 skip set_bit add scr->nr_item to dst After this point dst->nr_item may never go zero, so reparenting will not set shrinker_map bit anymore. And since there is no task under user slice directly, so no new object will be added to its lru to set the shrinker map bit either. That bit is kept cleared forever. How does list_lru_del() race with reparenting? It is because reparenting replaces children's kmemcg_id to parent's without protecting from nlru->lock, so list_lru_del() may see parent's kmemcg_id but actually deleting items from child's lru, but dec'ing parent's nr_items, so the parent's nr_items may go negative as commit 2788cf0c401c268b4819c5407493a8769b7007aa ("memcg: reparent list_lrus and free kmemcg_id on css offline") says. Since it is impossible that dst->nr_items goes negative and src->nr_items goes zero at the same time, so it seems we could set the shrinker map bit iff src->nr_items != 0. We could synchronize list_lru_count_one() and reparenting with nlru->lock, but it seems checking src->nr_items in reparenting is the simplest and avoids lock contention. Link: https://lkml.kernel.org/r/20201202171749.264354-1-shy828301@gmail.com Fixes: fae91d6d8be5 ("mm/list_lru.c: set bit in memcg shrinker bitmap on first list_lru item appearance") Signed-off-by: Yang Shi <shy828301(a)gmail.com> Suggested-by: Roman Gushchin <guro(a)fb.com> Reviewed-by: Roman Gushchin <guro(a)fb.com> Acked-by: Kirill Tkhai <ktkhai(a)virtuozzo.com> Reviewed-by: Shakeel Butt <shakeelb(a)google.com> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: <stable(a)vger.kernel.org> [4.19] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/list_lru.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/mm/list_lru.c~mm-list_lru-set-shrinker-map-bit-when-child-nr_items-is-not-zero +++ a/mm/list_lru.c @@ -534,7 +534,6 @@ static void memcg_drain_list_lru_node(st struct list_lru_node *nlru = &lru->node[nid]; int dst_idx = dst_memcg->kmemcg_id; struct list_lru_one *src, *dst; - bool set; /* * Since list_lru_{add,del} may be called under an IRQ-safe lock, @@ -546,11 +545,12 @@ static void memcg_drain_list_lru_node(st dst = list_lru_from_memcg_idx(nlru, dst_idx); list_splice_init(&src->list, &dst->list); - set = (!dst->nr_items && src->nr_items); - dst->nr_items += src->nr_items; - if (set) + + if (src->nr_items) { + dst->nr_items += src->nr_items; memcg_set_shrinker_bit(dst_memcg, nid, lru_shrinker_id(lru)); - src->nr_items = 0; + src->nr_items = 0; + } spin_unlock_irq(&nlru->lock); } _ Patches currently in -mm which might be from shy828301(a)gmail.com are mm-truncate_complete_page-is-not-existed-anymore.patch mm-migrate-simplify-the-logic-for-handling-permanent-failure.patch mm-migrate-skip-shared-exec-thp-for-numa-balancing.patch mm-migrate-clean-up-migrate_prep_local.patch mm-migrate-return-enosys-if-thp-migration-is-unsupported.patch

3 years, 10 months

1
0
0 0

[merged] mm-memcg-slab-fix-obj_cgroup_charge-return-value-handling.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: memcg/slab: fix obj_cgroup_charge() return value handling has been removed from the -mm tree. Its filename was mm-memcg-slab-fix-obj_cgroup_charge-return-value-handling.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Roman Gushchin <guro(a)fb.com> Subject: mm: memcg/slab: fix obj_cgroup_charge() return value handling Commit 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all allocations") introduced a regression into the handling of the obj_cgroup_charge() return value. If a non-zero value is returned (indicating of exceeding one of memory.max limits), the allocation should fail, instead of falling back to non-accounted mode. To make the code more readable, move memcg_slab_pre_alloc_hook() and memcg_slab_post_alloc_hook() calling conditions into bodies of these hooks. Link: https://lkml.kernel.org/r/20201127161828.GD840171@carbon.dhcp.thefacebook.c… Fixes: 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all allocations") Signed-off-by: Roman Gushchin <guro(a)fb.com> Reviewed-by: Shakeel Butt <shakeelb(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/slab.h | 40 ++++++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 16 deletions(-) --- a/mm/slab.h~mm-memcg-slab-fix-obj_cgroup_charge-return-value-handling +++ a/mm/slab.h @@ -274,22 +274,32 @@ static inline size_t obj_full_size(struc return s->size + sizeof(struct obj_cgroup *); } -static inline struct obj_cgroup *memcg_slab_pre_alloc_hook(struct kmem_cache *s, - size_t objects, - gfp_t flags) +/* + * Returns false if the allocation should fail. + */ +static inline bool memcg_slab_pre_alloc_hook(struct kmem_cache *s, + struct obj_cgroup **objcgp, + size_t objects, gfp_t flags) { struct obj_cgroup *objcg; + if (!memcg_kmem_enabled()) + return true; + + if (!(flags & __GFP_ACCOUNT) && !(s->flags & SLAB_ACCOUNT)) + return true; + objcg = get_obj_cgroup_from_current(); if (!objcg) - return NULL; + return true; if (obj_cgroup_charge(objcg, flags, objects * obj_full_size(s))) { obj_cgroup_put(objcg); - return NULL; + return false; } - return objcg; + *objcgp = objcg; + return true; } static inline void mod_objcg_state(struct obj_cgroup *objcg, @@ -315,7 +325,7 @@ static inline void memcg_slab_post_alloc unsigned long off; size_t i; - if (!objcg) + if (!memcg_kmem_enabled() || !objcg) return; flags &= ~__GFP_ACCOUNT; @@ -400,11 +410,11 @@ static inline void memcg_free_page_obj_c { } -static inline struct obj_cgroup *memcg_slab_pre_alloc_hook(struct kmem_cache *s, - size_t objects, - gfp_t flags) +static inline bool memcg_slab_pre_alloc_hook(struct kmem_cache *s, + struct obj_cgroup **objcgp, + size_t objects, gfp_t flags) { - return NULL; + return true; } static inline void memcg_slab_post_alloc_hook(struct kmem_cache *s, @@ -508,9 +518,8 @@ static inline struct kmem_cache *slab_pr if (should_failslab(s, flags)) return NULL; - if (memcg_kmem_enabled() && - ((flags & __GFP_ACCOUNT) || (s->flags & SLAB_ACCOUNT))) - *objcgp = memcg_slab_pre_alloc_hook(s, size, flags); + if (!memcg_slab_pre_alloc_hook(s, objcgp, size, flags)) + return NULL; return s; } @@ -529,8 +538,7 @@ static inline void slab_post_alloc_hook( s->flags, flags); } - if (memcg_kmem_enabled()) - memcg_slab_post_alloc_hook(s, objcg, flags, size, p); + memcg_slab_post_alloc_hook(s, objcg, flags, size, p); } #ifndef CONFIG_SLOB _ Patches currently in -mm which might be from guro(a)fb.com are mm-memcg-fix-obsolete-code-comments.patch mm-memcg-deprecate-the-non-hierarchical-mode.patch docs-cgroup-v1-reflect-the-deprecation-of-the-non-hierarchical-mode.patch cgroup-remove-obsoleted-broken_hierarchy-and-warned_broken_hierarchy.patch mm-vmstat-fix-proc-sys-vm-stat_refresh-generating-false-warnings.patch mm-vmstat-fix-proc-sys-vm-stat_refresh-generating-false-warnings-fix.patch mm-slub-call-account_slab_page-after-slab-page-initialization.patch mm-memcg-slab-pre-allocate-obj_cgroups-for-slab-caches-with-slab_account.patch mm-memcg-slab-pre-allocate-obj_cgroups-for-slab-caches-with-slab_account-v2.patch

3 years, 10 months

1
0
0 0

[merged] coredump-fix-core_pattern-parse-error.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: coredump: fix core_pattern parse error has been removed from the -mm tree. Its filename was coredump-fix-core_pattern-parse-error.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Menglong Dong <dong.menglong(a)zte.com.cn> Subject: coredump: fix core_pattern parse error 'format_corename()' will splite 'core_pattern' on spaces when it is in pipe mode, and take helper_argv[0] as the path to usermode executable. It works fine in most cases. However, if there is a space between '|' and '/file/path', such as '| /usr/lib/systemd/systemd-coredump %P %u %g', helper_argv[0] will be parsed as '', and users will get a 'Core dump to | disabled'. It is not friendly to users, as the pattern above was valid previously. Fix this by ignoring the spaces between '|' and '/file/path'. Link: https://lkml.kernel.org/r/5fb62870.1c69fb81.8ef5d.af76@mx.google.com Fixes: 315c69261dd3 ("coredump: split pipe command whitespace before expanding template") Signed-off-by: Menglong Dong <dong.menglong(a)zte.com.cn> Cc: Paul Wise <pabs3(a)bonedaddy.net> Cc: Jakub Wilk <jwilk(a)jwilk.net> [https://bugs.debian.org/924398] Cc: Neil Horman <nhorman(a)tuxdriver.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/coredump.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/coredump.c~coredump-fix-core_pattern-parse-error +++ a/fs/coredump.c @@ -229,7 +229,8 @@ static int format_corename(struct core_n */ if (ispipe) { if (isspace(*pat_ptr)) { - was_space = true; + if (cn->used != 0) + was_space = true; pat_ptr++; continue; } else if (was_space) { _ Patches currently in -mm which might be from dong.menglong(a)zte.com.cn are

3 years, 10 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2020