From patchwork Fri Apr 15 02:13:24 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814199 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C481BC433F5 for ; Fri, 15 Apr 2022 02:13:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56B176B0078; Thu, 14 Apr 2022 22:13:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 51A1E6B007B; Thu, 14 Apr 2022 22:13:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 394BB6B007D; Thu, 14 Apr 2022 22:13:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 27BC96B0078 for ; Thu, 14 Apr 2022 22:13:29 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 1198E1232C9 for ; Fri, 15 Apr 2022 02:13:29 +0000 (UTC) X-FDA: 79357491738.25.FB3D29E Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf28.hostedemail.com (Postfix) with ESMTP id 5391BC0005 for ; Fri, 15 Apr 2022 02:13:28 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C7C09B82B5F; Fri, 15 Apr 2022 02:13:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6202FC385A1; Fri, 15 Apr 2022 02:13:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988805; bh=cCJT7GRyn1N+l/cEvym3eVl2X3LmfC4pc3YND5oM+14=; h=Date:To:From:In-Reply-To:Subject:From; b=jwLbhiIQ1LCwesVQc9EXO8Kkw1lNn45iYViU74UM+iDQBxRmABmjktA1vKQsLr66k zJiqt0bKiIFBSIZR2zoiYIaKCCDq5ybSNmk3UouNrmyPaiYObePsp2vxO0bz2yFLd8 NjjyozvC+9aWGhuMh/w/KNdK1MXVK0XRgx59vP4k= Date: Thu, 14 Apr 2022 19:13:24 -0700 To: joe@perches.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 01/14] MAINTAINERS: Broadcom internal lists aren't maintainers Message-Id: <20220415021325.6202FC385A1@smtp.kernel.org> Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=jwLbhiIQ; dmarc=none; spf=pass (imf28.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5391BC0005 X-Stat-Signature: w9i9iyg1abp7kh84i8zh993ksyk7um6z X-HE-Tag: 1649988808-780029 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Joe Perches Subject: MAINTAINERS: Broadcom internal lists aren't maintainers Convert the broadcom internal list M: and L: entries to R: as exploder email addresses are neither maintainers nor mailing lists. Reorder the entries as necessary. Link: https://lkml.kernel.org/r/04eb301f5b3adbefdd78e76657eff0acb3e3d87f.camel@perches.com Signed-off-by: Joe Perches Signed-off-by: Andrew Morton --- MAINTAINERS | 64 +++++++++++++++++++++++++------------------------- 1 file changed, 32 insertions(+), 32 deletions(-) --- a/MAINTAINERS~maintainers-broadcom-internal-lists-arent-maintainers +++ a/MAINTAINERS @@ -3743,7 +3743,7 @@ F: include/linux/platform_data/b53.h BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE M: Nicolas Saenz Julienne -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-rpi-kernel@lists.infradead.org (moderated for non-subscribers) L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Maintained @@ -3758,7 +3758,7 @@ BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM M: Florian Fainelli M: Ray Jui M: Scott Branden -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team S: Maintained T: git git://github.com/broadcom/mach-bcm F: arch/arm/mach-bcm/ @@ -3778,7 +3778,7 @@ F: arch/mips/include/asm/mach-bcm47xx/* BROADCOM BCM4908 ETHERNET DRIVER M: Rafał Miłecki -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: netdev@vger.kernel.org S: Maintained F: Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml @@ -3787,7 +3787,7 @@ F: drivers/net/ethernet/broadcom/unimac. BROADCOM BCM4908 PINMUX DRIVER M: Rafał Miłecki -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-gpio@vger.kernel.org S: Maintained F: Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml @@ -3797,7 +3797,7 @@ BROADCOM BCM5301X ARM ARCHITECTURE M: Florian Fainelli M: Hauke Mehrtens M: Rafał Miłecki -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/boot/dts/bcm470* @@ -3808,7 +3808,7 @@ F: arch/arm/mach-bcm/bcm_5301x.c BROADCOM BCM53573 ARM ARCHITECTURE M: Florian Fainelli M: Rafał Miłecki -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/boot/dts/bcm47189* @@ -3816,7 +3816,7 @@ F: arch/arm/boot/dts/bcm53573* BROADCOM BCM63XX ARM ARCHITECTURE M: Florian Fainelli -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Maintained T: git git://github.com/broadcom/stblinux.git @@ -3830,7 +3830,7 @@ F: drivers/usb/gadget/udc/bcm63xx_udc.* BROADCOM BCM7XXX ARM ARCHITECTURE M: Florian Fainelli -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Maintained T: git git://github.com/broadcom/stblinux.git @@ -3848,21 +3848,21 @@ N: bcm7120 BROADCOM BDC DRIVER M: Al Cooper L: linux-usb@vger.kernel.org -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team S: Maintained F: Documentation/devicetree/bindings/usb/brcm,bdc.yaml F: drivers/usb/gadget/udc/bdc/ BROADCOM BMIPS CPUFREQ DRIVER M: Markus Mayer -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-pm@vger.kernel.org S: Maintained F: drivers/cpufreq/bmips-cpufreq.c BROADCOM BMIPS MIPS ARCHITECTURE M: Florian Fainelli -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-mips@vger.kernel.org S: Maintained T: git git://github.com/broadcom/stblinux.git @@ -3928,53 +3928,53 @@ F: drivers/net/wireless/broadcom/brcm802 BROADCOM BRCMSTB GPIO DRIVER M: Doug Berger M: Florian Fainelli -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team S: Supported F: Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml F: drivers/gpio/gpio-brcmstb.c BROADCOM BRCMSTB I2C DRIVER M: Kamal Dasu +R: Broadcom Kernel Team L: linux-i2c@vger.kernel.org -L: bcm-kernel-feedback-list@broadcom.com S: Supported F: Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml F: drivers/i2c/busses/i2c-brcmstb.c BROADCOM BRCMSTB UART DRIVER M: Al Cooper +R: Broadcom Kernel Team L: linux-serial@vger.kernel.org -L: bcm-kernel-feedback-list@broadcom.com S: Maintained F: Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml F: drivers/tty/serial/8250/8250_bcm7271.c BROADCOM BRCMSTB USB EHCI DRIVER M: Al Cooper +R: Broadcom Kernel Team L: linux-usb@vger.kernel.org -L: bcm-kernel-feedback-list@broadcom.com S: Maintained F: Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml F: drivers/usb/host/ehci-brcm.* BROADCOM BRCMSTB USB PIN MAP DRIVER M: Al Cooper +R: Broadcom Kernel Team L: linux-usb@vger.kernel.org -L: bcm-kernel-feedback-list@broadcom.com S: Maintained F: Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml F: drivers/usb/misc/brcmstb-usb-pinmap.c BROADCOM BRCMSTB USB2 and USB3 PHY DRIVER M: Al Cooper +R: Broadcom Kernel Team L: linux-kernel@vger.kernel.org -L: bcm-kernel-feedback-list@broadcom.com S: Maintained F: drivers/phy/broadcom/phy-brcm-usb* BROADCOM ETHERNET PHY DRIVERS M: Florian Fainelli -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: netdev@vger.kernel.org S: Supported F: Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt @@ -3985,7 +3985,7 @@ F: include/linux/brcmphy.h BROADCOM GENET ETHERNET DRIVER M: Doug Berger M: Florian Fainelli -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: netdev@vger.kernel.org S: Supported F: Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml @@ -3999,7 +3999,7 @@ F: include/linux/platform_data/mdio-bcm- BROADCOM IPROC ARM ARCHITECTURE M: Ray Jui M: Scott Branden -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Maintained T: git git://github.com/broadcom/stblinux.git @@ -4027,7 +4027,7 @@ N: stingray BROADCOM IPROC GBIT ETHERNET DRIVER M: Rafał Miłecki -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: netdev@vger.kernel.org S: Maintained F: Documentation/devicetree/bindings/net/brcm,amac.yaml @@ -4036,7 +4036,7 @@ F: drivers/net/ethernet/broadcom/unimac. BROADCOM KONA GPIO DRIVER M: Ray Jui -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team S: Supported F: Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt F: drivers/gpio/gpio-bcm-kona.c @@ -4069,7 +4069,7 @@ F: drivers/firmware/broadcom/* BROADCOM PMB (POWER MANAGEMENT BUS) DRIVER M: Rafał Miłecki M: Florian Fainelli -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-pm@vger.kernel.org S: Maintained T: git git://github.com/broadcom/stblinux.git @@ -4085,7 +4085,7 @@ F: include/linux/bcma/ BROADCOM SPI DRIVER M: Kamal Dasu -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team S: Maintained F: Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml F: drivers/spi/spi-bcm-qspi.* @@ -4094,7 +4094,7 @@ F: drivers/spi/spi-iproc-qspi.c BROADCOM STB AVS CPUFREQ DRIVER M: Markus Mayer -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-pm@vger.kernel.org S: Maintained F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt @@ -4102,7 +4102,7 @@ F: drivers/cpufreq/brcmstb* BROADCOM STB AVS TMON DRIVER M: Markus Mayer -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-pm@vger.kernel.org S: Maintained F: Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml @@ -4110,7 +4110,7 @@ F: drivers/thermal/broadcom/brcmstb* BROADCOM STB DPFE DRIVER M: Markus Mayer -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Maintained F: Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml @@ -4119,8 +4119,8 @@ F: drivers/memory/brcmstb_dpfe.c BROADCOM STB NAND FLASH DRIVER M: Brian Norris M: Kamal Dasu +R: Broadcom Kernel Team L: linux-mtd@lists.infradead.org -L: bcm-kernel-feedback-list@broadcom.com S: Maintained F: drivers/mtd/nand/raw/brcmnand/ F: include/linux/platform_data/brcmnand.h @@ -4129,7 +4129,7 @@ BROADCOM STB PCIE DRIVER M: Jim Quinlan M: Nicolas Saenz Julienne M: Florian Fainelli -M: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: linux-pci@vger.kernel.org S: Maintained F: Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml @@ -4137,7 +4137,7 @@ F: drivers/pci/controller/pcie-brcmstb.c BROADCOM SYSTEMPORT ETHERNET DRIVER M: Florian Fainelli -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team L: netdev@vger.kernel.org S: Supported F: drivers/net/ethernet/broadcom/bcmsysport.* @@ -4154,7 +4154,7 @@ F: drivers/net/ethernet/broadcom/tg3.* BROADCOM VK DRIVER M: Scott Branden -L: bcm-kernel-feedback-list@broadcom.com +R: Broadcom Kernel Team S: Supported F: drivers/misc/bcm-vk/ F: include/uapi/linux/misc/bcm_vk.h @@ -17648,8 +17648,8 @@ K: \bTIF_SECCOMP\b SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) Broadcom BRCMSTB DRIVER M: Al Cooper +R: Broadcom Kernel Team L: linux-mmc@vger.kernel.org -L: bcm-kernel-feedback-list@broadcom.com S: Maintained F: drivers/mmc/host/sdhci-brcmstb* From patchwork Fri Apr 15 02:13:27 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814200 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29CFBC433FE for ; Fri, 15 Apr 2022 02:13:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A75036B007B; Thu, 14 Apr 2022 22:13:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FD226B007D; Thu, 14 Apr 2022 22:13:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 801D16B007E; Thu, 14 Apr 2022 22:13:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 721616B007B for ; Thu, 14 Apr 2022 22:13:30 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4844F27323 for ; Fri, 15 Apr 2022 02:13:30 +0000 (UTC) X-FDA: 79357491780.11.8CB91E8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id C11C940002 for ; Fri, 15 Apr 2022 02:13:29 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 290C6621EB; Fri, 15 Apr 2022 02:13:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D31EC385A1; Fri, 15 Apr 2022 02:13:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988808; bh=DOqXlO2fX9k0E4ccfUNitl7EDptnTlmMx3IKUuoxw6U=; h=Date:To:From:In-Reply-To:Subject:From; b=tXji3r7X2uwvmKZrmmks32QYuuffgXjTG3sMMZGDLpKCLa1apxQAaDALWrtXnk98p iMywRPC2Hs70/LOvNfFji/KU/wGv90EmPJ6adH82ChdbQ3kPYq7NMVxE0DuaLbWW2F vBZLeFxFJIAjP9JajSJQLsz3vBSstpeHU1HDboSI= Date: Thu, 14 Apr 2022 19:13:27 -0700 To: patrice.chotard@foss.st.com,mpatocka@redhat.com,markhemm@googlemail.com,lczerner@redhat.com,hch@lst.de,djwong@kernel.org,chuck.lever@oracle.com,hughd@google.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 02/14] tmpfs: fix regressions from wider use of ZERO_PAGE Message-Id: <20220415021328.7D31EC385A1@smtp.kernel.org> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C11C940002 X-Stat-Signature: jkmu797e7a4jmgkas799odiaxjr5x9nq Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=tXji3r7X; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspam-User: X-HE-Tag: 1649988809-268746 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Hugh Dickins Subject: tmpfs: fix regressions from wider use of ZERO_PAGE Chuck Lever reported fsx-based xfstests generic 075 091 112 127 failing when 5.18-rc1 NFS server exports tmpfs: bisected to recent tmpfs change. Whilst nfsd_splice_action() does contain some questionable handling of repeated pages, and Chuck was able to work around there, history from Mark Hemment makes clear that there might be similar dangers elsewhere: it was not a good idea for me to pass ZERO_PAGE down to unknown actors. Revert shmem_file_read_iter() to using ZERO_PAGE for holes only when iter_is_iovec(); in other cases, use the more natural iov_iter_zero() instead of copy_page_to_iter(). We would use iov_iter_zero() throughout, but the x86 clear_user() is not nearly so well optimized as copy to user (dd of 1T sparse tmpfs file takes 57 seconds rather than 44 seconds). And now pagecache_init() does not need to SetPageUptodate(ZERO_PAGE(0)): which had caused boot failure on arm noMMU STM32F7 and STM32H7 boards Link: https://lkml.kernel.org/r/9a978571-8648-e830-5735-1f4748ce2e30@google.com Fixes: 56a8c8eb1eaf ("tmpfs: do not allocate pages on read") Signed-off-by: Hugh Dickins Reported-by: Patrice CHOTARD Reported-by: Chuck Lever III Tested-by: Chuck Lever III Cc: Mark Hemment Cc: Patrice CHOTARD Cc: Mikulas Patocka Cc: Lukas Czerner Cc: Christoph Hellwig Cc: "Darrick J. Wong" Signed-off-by: Andrew Morton Signed-off-by: Mark Hemment --- mm/filemap.c | 6 ------ mm/shmem.c | 31 ++++++++++++++++++++----------- 2 files changed, 20 insertions(+), 17 deletions(-) --- a/mm/filemap.c~tmpfs-fix-regressions-from-wider-use-of-zero_page +++ a/mm/filemap.c @@ -1063,12 +1063,6 @@ void __init pagecache_init(void) init_waitqueue_head(&folio_wait_table[i]); page_writeback_init(); - - /* - * tmpfs uses the ZERO_PAGE for reading holes: it is up-to-date, - * and splice's page_cache_pipe_buf_confirm() needs to see that. - */ - SetPageUptodate(ZERO_PAGE(0)); } /* --- a/mm/shmem.c~tmpfs-fix-regressions-from-wider-use-of-zero_page +++ a/mm/shmem.c @@ -2513,7 +2513,6 @@ static ssize_t shmem_file_read_iter(stru pgoff_t end_index; unsigned long nr, ret; loff_t i_size = i_size_read(inode); - bool got_page; end_index = i_size >> PAGE_SHIFT; if (index > end_index) @@ -2570,24 +2569,34 @@ static ssize_t shmem_file_read_iter(stru */ if (!offset) mark_page_accessed(page); - got_page = true; + /* + * Ok, we have the page, and it's up-to-date, so + * now we can copy it to user space... + */ + ret = copy_page_to_iter(page, offset, nr, to); + put_page(page); + + } else if (iter_is_iovec(to)) { + /* + * Copy to user tends to be so well optimized, but + * clear_user() not so much, that it is noticeably + * faster to copy the zero page instead of clearing. + */ + ret = copy_page_to_iter(ZERO_PAGE(0), offset, nr, to); } else { - page = ZERO_PAGE(0); - got_page = false; + /* + * But submitting the same page twice in a row to + * splice() - or others? - can result in confusion: + * so don't attempt that optimization on pipes etc. + */ + ret = iov_iter_zero(nr, to); } - /* - * Ok, we have the page, and it's up-to-date, so - * now we can copy it to user space... - */ - ret = copy_page_to_iter(page, offset, nr, to); retval += ret; offset += ret; index += offset >> PAGE_SHIFT; offset &= ~PAGE_MASK; - if (got_page) - put_page(page); if (!iov_iter_count(to)) break; if (ret < nr) { From patchwork Fri Apr 15 02:13:31 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814201 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A04CFC433F5 for ; Fri, 15 Apr 2022 02:13:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BDEA6B0074; Thu, 14 Apr 2022 22:13:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 345D76B0075; Thu, 14 Apr 2022 22:13:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E7346B007D; Thu, 14 Apr 2022 22:13:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 0DB676B0074 for ; Thu, 14 Apr 2022 22:13:35 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B270F8249980 for ; Fri, 15 Apr 2022 02:13:34 +0000 (UTC) X-FDA: 79357491948.27.52AB4C2 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf07.hostedemail.com (Postfix) with ESMTP id 1EB8840007 for ; Fri, 15 Apr 2022 02:13:33 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id EB300B82BF6; Fri, 15 Apr 2022 02:13:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2123C385AA; Fri, 15 Apr 2022 02:13:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988811; bh=kJy8HCH2PF88Ukvq4CiNIs0nm73iZq6YeCxUJq69zzo=; h=Date:To:From:In-Reply-To:Subject:From; b=uu+rQXmnuzQrdBDHHnFepv7hC5HElUNTlNXY42oY1vQJEMWbF/Q9wg4Vownuq6Ui5 WNXGhnOtNdo/iIFhR0T701CvB8ZyO0EC3OsG1hnJydoulir/sSqJ1sHRsrEQPAB5sj ixYL82RjBGRRKqdqH5jet6cUOiNBumH6CyLquD+A= Date: Thu, 14 Apr 2022 19:13:31 -0700 To: willy@infradead.org,stable@vger.kernel.org,rppt@kernel.org,lkp@intel.com,axelrasmussen@google.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 03/14] mm/secretmem: fix panic when growing a memfd_secret Message-Id: <20220415021331.A2123C385AA@smtp.kernel.org> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 1EB8840007 X-Stat-Signature: 1x1hppnb766supyno3g1iys8x6x4h5z7 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=uu+rQXmn; spf=pass (imf07.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1649988813-346289 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Axel Rasmussen Subject: mm/secretmem: fix panic when growing a memfd_secret When one tries to grow an existing memfd_secret with ftruncate, one gets a panic [1]. For example, doing the following reliably induces the panic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20); The basic reason for this is, when we grow with ftruncate, we call down into simple_setattr, and then truncate_inode_pages_range, and eventually we try to zero part of the memory. The normal truncation code does this via the direct map (i.e., it calls page_address() and hands that to memset()). For memfd_secret though, we specifically don't map our pages via the direct map (i.e. we call set_direct_map_invalid_noflush() on every fault). So the address returned by page_address() isn't useful, and when we try to memset() with it we panic. This patch avoids the panic by implementing a custom setattr for memfd_secret, which detects resizes specifically (setting the size for the first time works just fine, since there are no existing pages to try to zero), and rejects them with EINVAL. One could argue growing should be supported, but I think that will require a significantly more lengthy change. So, I propose a minimal fix for the benefit of stable kernels, and then perhaps to extend memfd_secret to support growing in a separate patch. [1]: [ 774.320433] BUG: unable to handle page fault for address: ffffa0a889277028 [ 774.322297] #PF: supervisor write access in kernel mode [ 774.323306] #PF: error_code(0x0002) - not-present page [ 774.324296] PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 [ 774.325841] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [ 774.326934] CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 [ 774.328074] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 774.329732] RIP: 0010:memset_erms+0x9/0x10 [ 774.330474] Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 [ 774.333543] RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 [ 774.334404] RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 [ 774.335545] RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 [ 774.336685] RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 [ 774.337929] R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 [ 774.339236] R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 [ 774.340356] FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 [ 774.341635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 774.342535] CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 [ 774.343651] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 774.344780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 774.345938] Call Trace: [ 774.346334] [ 774.346671] ? zero_user_segments+0x82/0x190 [ 774.347346] truncate_inode_partial_folio+0xd4/0x2a0 [ 774.348128] truncate_inode_pages_range+0x380/0x830 [ 774.348904] truncate_setsize+0x63/0x80 [ 774.349530] simple_setattr+0x37/0x60 [ 774.350102] notify_change+0x3d8/0x4d0 [ 774.350681] do_sys_ftruncate+0x162/0x1d0 [ 774.351302] __x64_sys_ftruncate+0x1c/0x20 [ 774.351936] do_syscall_64+0x44/0xa0 [ 774.352486] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 774.353284] RIP: 0033:0x7f72947c392b [ 774.354001] Code: 77 05 c3 0f 1f 40 00 48 8b 15 41 85 0c 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 4d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 11 85 0c 00 f7 d8 [ 774.357938] RSP: 002b:00007ffcad62a1a8 EFLAGS: 00000202 ORIG_RAX: 000000000000004d [ 774.359116] RAX: ffffffffffffffda RBX: 000055f47662b440 RCX: 00007f72947c392b [ 774.360186] RDX: 0000000000000028 RSI: 0000000000000028 RDI: 0000000000000003 [ 774.361246] RBP: 00007ffcad62a1c0 R08: 0000000000000003 R09: 0000000000000000 [ 774.362324] R10: 00007f72946dc230 R11: 0000000000000202 R12: 000055f47662b0e0 [ 774.363393] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 774.364470] [ 774.364807] Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet [ 774.367325] CR2: ffffa0a889277028 [ 774.367838] ---[ end trace 0000000000000000 ]--- [ 774.368543] RIP: 0010:memset_erms+0x9/0x10 [ 774.369187] Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 [ 774.372282] RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 [ 774.373372] RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 [ 774.374814] RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 [ 774.376248] RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 [ 774.377687] R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 [ 774.379135] R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 [ 774.380550] FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 [ 774.382177] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 774.383329] CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 [ 774.384763] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 774.386229] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 774.387664] Kernel panic - not syncing: Fatal exception [ 774.388863] Kernel Offset: 0x8000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 774.391014] ---[ end Kernel panic - not syncing: Fatal exception ]--- [lkp@intel.com: secretmem_iops can be static] Signed-off-by: kernel test robot [axelrasmussen@google.com: return EINVAL] Link: https://lkml.kernel.org/r/20220412193023.279320-1-axelrasmussen@google.com Link: https://lkml.kernel.org/r/20220324210909.1843814-1-axelrasmussen@google.com Signed-off-by: Axel Rasmussen Signed-off-by: Axel Rasmussen Cc: Mike Rapoport Cc: Matthew Wilcox Cc: Cc: kernel test robot Signed-off-by: Andrew Morton --- mm/secretmem.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) --- a/mm/secretmem.c~mm-secretmem-fix-panic-when-growing-a-memfd_secret +++ a/mm/secretmem.c @@ -158,6 +158,22 @@ const struct address_space_operations se .isolate_page = secretmem_isolate_page, }; +static int secretmem_setattr(struct user_namespace *mnt_userns, + struct dentry *dentry, struct iattr *iattr) +{ + struct inode *inode = d_inode(dentry); + unsigned int ia_valid = iattr->ia_valid; + + if ((ia_valid & ATTR_SIZE) && inode->i_size) + return -EINVAL; + + return simple_setattr(mnt_userns, dentry, iattr); +} + +static const struct inode_operations secretmem_iops = { + .setattr = secretmem_setattr, +}; + static struct vfsmount *secretmem_mnt; static struct file *secretmem_file_create(unsigned long flags) @@ -177,6 +193,7 @@ static struct file *secretmem_file_creat mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER); mapping_set_unevictable(inode->i_mapping); + inode->i_op = &secretmem_iops; inode->i_mapping->a_ops = &secretmem_aops; /* pretend we are a normal file with zero size */ From patchwork Fri Apr 15 02:13:34 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814202 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E98BAC433F5 for ; Fri, 15 Apr 2022 02:13:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 829476B0075; Thu, 14 Apr 2022 22:13:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D9E36B007D; Thu, 14 Apr 2022 22:13:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A2CB6B007E; Thu, 14 Apr 2022 22:13:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 5B4046B0075 for ; Thu, 14 Apr 2022 22:13:37 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 2BF7C80D2D for ; Fri, 15 Apr 2022 02:13:37 +0000 (UTC) X-FDA: 79357492074.05.17782D3 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf04.hostedemail.com (Postfix) with ESMTP id 885CF40005 for ; Fri, 15 Apr 2022 02:13:36 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2613EB82B5F; Fri, 15 Apr 2022 02:13:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8140C385A7; Fri, 15 Apr 2022 02:13:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988814; bh=avesztKyswte+MiaCofRGBooc6PzYRiWU186/DEL4nw=; h=Date:To:From:In-Reply-To:Subject:From; b=C1xBvHWjhXQRpvlx51OUvGJVlWdAE0VnCijcdALz8u3jaNCS7/qQRiorWawboiYXi ERjgCERK4oV6fCYYU+wwtbSvp34l3fqD04tOBzk7BkFaUzLN6ZulVWWbA0iPY4zYwT eTjVW4iW+TvoJu66tXi98UuQ9LcRBFkip3wQDfoo= Date: Thu, 14 Apr 2022 19:13:34 -0700 To: ryabinin.a.a@gmail.com,glider@google.com,dvyukov@google.com,andreyknvl@gmail.com,qiang1.zhang@intel.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 04/14] irq_work: use kasan_record_aux_stack_noalloc() record callstack Message-Id: <20220415021334.B8140C385A7@smtp.kernel.org> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 885CF40005 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=C1xBvHWj; dmarc=none; spf=pass (imf04.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Stat-Signature: k11889dt4gi8xako1zpcbnx9cmntdija X-HE-Tag: 1649988816-766765 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Zqiang Subject: irq_work: use kasan_record_aux_stack_noalloc() record callstack [ 4.113128] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 [ 4.113132] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 239, name: bootlogd [ 4.113149] Preemption disabled at: [ 4.113149] [] rt_mutex_slowunlock+0xa1/0x4e0 [ 4.113154] CPU: 3 PID: 239 Comm: bootlogd Tainted: G W 5.17.1-rt17-yocto-preempt-rt+ #105 [ 4.113157] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 4.113159] Call Trace: [ 4.113160] [ 4.113161] dump_stack_lvl+0x60/0x8c [ 4.113165] dump_stack+0x10/0x12 [ 4.113167] __might_resched.cold+0x13b/0x173 [ 4.113172] rt_spin_lock+0x5b/0xf0 [ 4.113179] get_page_from_freelist+0x20c/0x1610 [ 4.113208] __alloc_pages+0x25e/0x5e0 [ 4.113222] __stack_depot_save+0x3c0/0x4a0 [ 4.113228] kasan_save_stack+0x3a/0x50 [ 4.113322] __kasan_record_aux_stack+0xb6/0xc0 [ 4.113326] kasan_record_aux_stack+0xe/0x10 [ 4.113329] irq_work_queue_on+0x6a/0x1c0 [ 4.113333] pull_rt_task+0x631/0x6b0 [ 4.113343] do_balance_callbacks+0x56/0x80 [ 4.113346] __balance_callbacks+0x63/0x90 [ 4.113350] rt_mutex_setprio+0x349/0x880 [ 4.113366] rt_mutex_slowunlock+0x22a/0x4e0 [ 4.113377] rt_spin_unlock+0x49/0x80 [ 4.113380] uart_write+0x186/0x2b0 [ 4.113385] do_output_char+0x2e9/0x3a0 [ 4.113389] n_tty_write+0x306/0x800 [ 4.113413] file_tty_write.isra.0+0x2af/0x450 [ 4.113422] tty_write+0x22/0x30 [ 4.113425] new_sync_write+0x27c/0x3a0 [ 4.113446] vfs_write+0x3f7/0x5d0 [ 4.113451] ksys_write+0xd9/0x180 [ 4.113463] __x64_sys_write+0x43/0x50 [ 4.113466] do_syscall_64+0x44/0x90 [ 4.113469] entry_SYSCALL_64_after_hwframe+0x44/0xae On PREEMPT_RT kernel and KASAN is enabled. the kasan_record_aux_stack() may call alloc_pages(), and the rt-spinlock will be acquired, if currently in atomic context, will trigger warning. fix it by use kasan_record_aux_stack_noalloc() to avoid call alloc_pages(). Link: https://lkml.kernel.org/r/20220402142555.2699582-1-qiang1.zhang@intel.com Signed-off-by: Zqiang Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Signed-off-by: Andrew Morton --- kernel/irq_work.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/irq_work.c~irq_work-use-kasan_record_aux_stack_noalloc-record-callstack +++ a/kernel/irq_work.c @@ -137,7 +137,7 @@ bool irq_work_queue_on(struct irq_work * if (!irq_work_claim(work)) return false; - kasan_record_aux_stack(work); + kasan_record_aux_stack_noalloc(work); preempt_disable(); if (cpu != smp_processor_id()) { From patchwork Fri Apr 15 02:13:37 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814203 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 759F7C433EF for ; Fri, 15 Apr 2022 02:13:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FE1B6B007E; Thu, 14 Apr 2022 22:13:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AE1A6B0080; Thu, 14 Apr 2022 22:13:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB7B76B0081; Thu, 14 Apr 2022 22:13:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id D9EDC6B007E for ; Thu, 14 Apr 2022 22:13:40 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id BB31A837EF for ; Fri, 15 Apr 2022 02:13:40 +0000 (UTC) X-FDA: 79357492200.03.0D44803 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf31.hostedemail.com (Postfix) with ESMTP id 4215020002 for ; Fri, 15 Apr 2022 02:13:40 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0A72CB82B5F; Fri, 15 Apr 2022 02:13:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC941C385A5; Fri, 15 Apr 2022 02:13:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988817; bh=EfxUkKFZzWkmoYV6d36EtWBG7TfddY7SyrUEmRqbwxw=; h=Date:To:From:In-Reply-To:Subject:From; b=HMaxL6ChH2BQWWhrTJgpaZ/sGz0NU61fjVwtA1EBjmby/ybV5FL3ngKk1TNdlTlaX IZL4QiwsOVrODLMmzjq3LNmMg4tBLE4/tzHRh9AMZGBOo+9Z22eXeTXE6S0szlU7qE q71otZh4qgk2q/91DBo7cokoTOZHb4cLDjcdIcFw= Date: Thu, 14 Apr 2022 19:13:37 -0700 To: will@kernel.org,ryabinin.a.a@gmail.com,glider@google.com,dvyukov@google.com,catalin.marinas@arm.com,andreyknvl@gmail.com,vincenzo.frascino@arm.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 05/14] kasan: fix hw tags enablement when KUNIT tests are disabled Message-Id: <20220415021337.BC941C385A5@smtp.kernel.org> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4215020002 X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=HMaxL6Ch; dmarc=none; spf=pass (imf31.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Stat-Signature: qr7szerjsrtj1ksmi7fq15jmeu6sq63m X-HE-Tag: 1649988820-917502 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Vincenzo Frascino Subject: kasan: fix hw tags enablement when KUNIT tests are disabled Kasan enables hw tags via kasan_enable_tagging() which based on the mode passed via kernel command line selects the correct hw backend. kasan_enable_tagging() is meant to be invoked indirectly via the cpu features framework of the architectures that support these backends. Currently the invocation of this function is guarded by CONFIG_KASAN_KUNIT_TEST which allows the enablement of the correct backend only when KUNIT tests are enabled in the kernel. This inconsistency was introduced in commit: ed6d74446cbf ("kasan: test: support async (again) and asymm modes for HW_TAGS") ... and prevents to enable MTE on arm64 when KUNIT tests for kasan hw_tags are disabled. Fix the issue making sure that the CONFIG_KASAN_KUNIT_TEST guard does not prevent the correct invocation of kasan_enable_tagging(). Link: https://lkml.kernel.org/r/20220408124323.10028-1-vincenzo.frascino@arm.com Fixes: ed6d74446cbf ("kasan: test: support async (again) and asymm modes for HW_TAGS") Signed-off-by: Vincenzo Frascino Reviewed-by: Andrey Konovalov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Andrew Morton --- mm/kasan/hw_tags.c | 5 +++-- mm/kasan/kasan.h | 10 ++++++---- 2 files changed, 9 insertions(+), 6 deletions(-) --- a/mm/kasan/hw_tags.c~kasan-fix-hw-tags-enablement-when-kunit-tests-are-disabled +++ a/mm/kasan/hw_tags.c @@ -336,8 +336,6 @@ void __kasan_poison_vmalloc(const void * #endif -#if IS_ENABLED(CONFIG_KASAN_KUNIT_TEST) - void kasan_enable_tagging(void) { if (kasan_arg_mode == KASAN_ARG_MODE_ASYNC) @@ -347,6 +345,9 @@ void kasan_enable_tagging(void) else hw_enable_tagging_sync(); } + +#if IS_ENABLED(CONFIG_KASAN_KUNIT_TEST) + EXPORT_SYMBOL_GPL(kasan_enable_tagging); void kasan_force_async_fault(void) --- a/mm/kasan/kasan.h~kasan-fix-hw-tags-enablement-when-kunit-tests-are-disabled +++ a/mm/kasan/kasan.h @@ -355,25 +355,27 @@ static inline const void *arch_kasan_set #define hw_set_mem_tag_range(addr, size, tag, init) \ arch_set_mem_tag_range((addr), (size), (tag), (init)) +void kasan_enable_tagging(void); + #else /* CONFIG_KASAN_HW_TAGS */ #define hw_enable_tagging_sync() #define hw_enable_tagging_async() #define hw_enable_tagging_asymm() +static inline void kasan_enable_tagging(void) { } + #endif /* CONFIG_KASAN_HW_TAGS */ #if defined(CONFIG_KASAN_HW_TAGS) && IS_ENABLED(CONFIG_KASAN_KUNIT_TEST) -void kasan_enable_tagging(void); void kasan_force_async_fault(void); -#else /* CONFIG_KASAN_HW_TAGS || CONFIG_KASAN_KUNIT_TEST */ +#else /* CONFIG_KASAN_HW_TAGS && CONFIG_KASAN_KUNIT_TEST */ -static inline void kasan_enable_tagging(void) { } static inline void kasan_force_async_fault(void) { } -#endif /* CONFIG_KASAN_HW_TAGS || CONFIG_KASAN_KUNIT_TEST */ +#endif /* CONFIG_KASAN_HW_TAGS && CONFIG_KASAN_KUNIT_TEST */ #ifdef CONFIG_KASAN_SW_TAGS u8 kasan_random_tag(void); From patchwork Fri Apr 15 02:13:40 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814204 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9ABCAC433EF for ; Fri, 15 Apr 2022 02:13:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 263276B0080; Thu, 14 Apr 2022 22:13:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1ECF96B0081; Thu, 14 Apr 2022 22:13:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 086C46B0082; Thu, 14 Apr 2022 22:13:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) by kanga.kvack.org (Postfix) with ESMTP id E95C16B0080 for ; Thu, 14 Apr 2022 22:13:42 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9F461183BFAAF for ; Fri, 15 Apr 2022 02:13:42 +0000 (UTC) X-FDA: 79357492284.31.68FDA4A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id 253EF80005 for ; Fri, 15 Apr 2022 02:13:41 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7B13D6220E; Fri, 15 Apr 2022 02:13:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D03BDC385A1; Fri, 15 Apr 2022 02:13:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988820; bh=TRPAefh+bPdHgAMBJ6+FbUWT+qDEjVN5YxGGy8QcdCg=; h=Date:To:From:In-Reply-To:Subject:From; b=EOTKxGmfVPcUiUxHVihIMXpE9jHLNBGNuNOERvdkS67xoNQJHMw3BaP4HWttggGHq WFCxNh+JPEgBGFiX49i/+JKLgM87UQB1YYvhBMkYGLgv9F6RtmgGbc7HzyAMhdGvQO Cjy6qMbMcRE8UeEStsaGQpP3wS1xHSNEnCg7J6Yg= Date: Thu, 14 Apr 2022 19:13:40 -0700 To: vbabka@suse.cz,oliver.sang@intel.com,42.hyeyoo@gmail.com,elver@google.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 06/14] mm, kfence: support kmem_dump_obj() for KFENCE objects Message-Id: <20220415021340.D03BDC385A1@smtp.kernel.org> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 253EF80005 X-Stat-Signature: doomk1ggmkj3brmc6yrcp175g5zrpyk7 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=EOTKxGmf; spf=pass (imf30.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1649988821-198369 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Marco Elver Subject: mm, kfence: support kmem_dump_obj() for KFENCE objects Calling kmem_obj_info() via kmem_dump_obj() on KFENCE objects has been producing garbage data due to the object not actually being maintained by SLAB or SLUB. Fix this by implementing __kfence_obj_info() that copies relevant information to struct kmem_obj_info when the object was allocated by KFENCE; this is called by a common kmem_obj_info(), which also calls the slab/slub/slob specific variant now called __kmem_obj_info(). For completeness, kmem_dump_obj() now displays if the object was allocated by KFENCE. Link: https://lore.kernel.org/all/20220323090520.GG16885@xsang-OptiPlex-9020/ Link: https://lkml.kernel.org/r/20220406131558.3558585-1-elver@google.com Fixes: b89fb5ef0ce6 ("mm, kfence: insert KFENCE hooks for SLUB") Fixes: d3fb45f370d9 ("mm, kfence: insert KFENCE hooks for SLAB") Signed-off-by: Marco Elver Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Reported-by: kernel test robot Acked-by: Vlastimil Babka [slab] Signed-off-by: Andrew Morton --- include/linux/kfence.h | 24 +++++++++++++++++++ mm/kfence/core.c | 21 ----------------- mm/kfence/kfence.h | 21 +++++++++++++++++ mm/kfence/report.c | 47 +++++++++++++++++++++++++++++++++++++++ mm/slab.c | 2 - mm/slab.h | 2 - mm/slab_common.c | 9 +++++++ mm/slob.c | 2 - mm/slub.c | 2 - 9 files changed, 105 insertions(+), 25 deletions(-) --- a/include/linux/kfence.h~mm-kfence-support-kmem_dump_obj-for-kfence-objects +++ a/include/linux/kfence.h @@ -204,6 +204,22 @@ static __always_inline __must_check bool */ bool __must_check kfence_handle_page_fault(unsigned long addr, bool is_write, struct pt_regs *regs); +#ifdef CONFIG_PRINTK +struct kmem_obj_info; +/** + * __kfence_obj_info() - fill kmem_obj_info struct + * @kpp: kmem_obj_info to be filled + * @object: the object + * + * Return: + * * false - not a KFENCE object + * * true - a KFENCE object, filled @kpp + * + * Copies information to @kpp for KFENCE objects. + */ +bool __kfence_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab); +#endif + #else /* CONFIG_KFENCE */ static inline bool is_kfence_address(const void *addr) { return false; } @@ -221,6 +237,14 @@ static inline bool __must_check kfence_h return false; } +#ifdef CONFIG_PRINTK +struct kmem_obj_info; +static inline bool __kfence_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) +{ + return false; +} +#endif + #endif #endif /* _LINUX_KFENCE_H */ --- a/mm/kfence/core.c~mm-kfence-support-kmem_dump_obj-for-kfence-objects +++ a/mm/kfence/core.c @@ -231,27 +231,6 @@ static bool kfence_unprotect(unsigned lo return !KFENCE_WARN_ON(!kfence_protect_page(ALIGN_DOWN(addr, PAGE_SIZE), false)); } -static inline struct kfence_metadata *addr_to_metadata(unsigned long addr) -{ - long index; - - /* The checks do not affect performance; only called from slow-paths. */ - - if (!is_kfence_address((void *)addr)) - return NULL; - - /* - * May be an invalid index if called with an address at the edge of - * __kfence_pool, in which case we would report an "invalid access" - * error. - */ - index = (addr - (unsigned long)__kfence_pool) / (PAGE_SIZE * 2) - 1; - if (index < 0 || index >= CONFIG_KFENCE_NUM_OBJECTS) - return NULL; - - return &kfence_metadata[index]; -} - static inline unsigned long metadata_to_pageaddr(const struct kfence_metadata *meta) { unsigned long offset = (meta - kfence_metadata + 1) * PAGE_SIZE * 2; --- a/mm/kfence/kfence.h~mm-kfence-support-kmem_dump_obj-for-kfence-objects +++ a/mm/kfence/kfence.h @@ -96,6 +96,27 @@ struct kfence_metadata { extern struct kfence_metadata kfence_metadata[CONFIG_KFENCE_NUM_OBJECTS]; +static inline struct kfence_metadata *addr_to_metadata(unsigned long addr) +{ + long index; + + /* The checks do not affect performance; only called from slow-paths. */ + + if (!is_kfence_address((void *)addr)) + return NULL; + + /* + * May be an invalid index if called with an address at the edge of + * __kfence_pool, in which case we would report an "invalid access" + * error. + */ + index = (addr - (unsigned long)__kfence_pool) / (PAGE_SIZE * 2) - 1; + if (index < 0 || index >= CONFIG_KFENCE_NUM_OBJECTS) + return NULL; + + return &kfence_metadata[index]; +} + /* KFENCE error types for report generation. */ enum kfence_error_type { KFENCE_ERROR_OOB, /* Detected a out-of-bounds access. */ --- a/mm/kfence/report.c~mm-kfence-support-kmem_dump_obj-for-kfence-objects +++ a/mm/kfence/report.c @@ -273,3 +273,50 @@ void kfence_report_error(unsigned long a /* We encountered a memory safety error, taint the kernel! */ add_taint(TAINT_BAD_PAGE, LOCKDEP_STILL_OK); } + +#ifdef CONFIG_PRINTK +static void kfence_to_kp_stack(const struct kfence_track *track, void **kp_stack) +{ + int i, j; + + i = get_stack_skipnr(track->stack_entries, track->num_stack_entries, NULL); + for (j = 0; i < track->num_stack_entries && j < KS_ADDRS_COUNT; ++i, ++j) + kp_stack[j] = (void *)track->stack_entries[i]; + if (j < KS_ADDRS_COUNT) + kp_stack[j] = NULL; +} + +bool __kfence_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) +{ + struct kfence_metadata *meta = addr_to_metadata((unsigned long)object); + unsigned long flags; + + if (!meta) + return false; + + /* + * If state is UNUSED at least show the pointer requested; the rest + * would be garbage data. + */ + kpp->kp_ptr = object; + + /* Requesting info an a never-used object is almost certainly a bug. */ + if (WARN_ON(meta->state == KFENCE_OBJECT_UNUSED)) + return true; + + raw_spin_lock_irqsave(&meta->lock, flags); + + kpp->kp_slab = slab; + kpp->kp_slab_cache = meta->cache; + kpp->kp_objp = (void *)meta->addr; + kfence_to_kp_stack(&meta->alloc_track, kpp->kp_stack); + if (meta->state == KFENCE_OBJECT_FREED) + kfence_to_kp_stack(&meta->free_track, kpp->kp_free_stack); + /* get_stack_skipnr() ensures the first entry is outside allocator. */ + kpp->kp_ret = kpp->kp_stack[0]; + + raw_spin_unlock_irqrestore(&meta->lock, flags); + + return true; +} +#endif --- a/mm/slab.c~mm-kfence-support-kmem_dump_obj-for-kfence-objects +++ a/mm/slab.c @@ -3665,7 +3665,7 @@ EXPORT_SYMBOL(__kmalloc_node_track_calle #endif /* CONFIG_NUMA */ #ifdef CONFIG_PRINTK -void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) +void __kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) { struct kmem_cache *cachep; unsigned int objnr; --- a/mm/slab_common.c~mm-kfence-support-kmem_dump_obj-for-kfence-objects +++ a/mm/slab_common.c @@ -555,6 +555,13 @@ bool kmem_valid_obj(void *object) } EXPORT_SYMBOL_GPL(kmem_valid_obj); +static void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) +{ + if (__kfence_obj_info(kpp, object, slab)) + return; + __kmem_obj_info(kpp, object, slab); +} + /** * kmem_dump_obj - Print available slab provenance information * @object: slab object for which to find provenance information. @@ -590,6 +597,8 @@ void kmem_dump_obj(void *object) pr_cont(" slab%s %s", cp, kp.kp_slab_cache->name); else pr_cont(" slab%s", cp); + if (is_kfence_address(object)) + pr_cont(" (kfence)"); if (kp.kp_objp) pr_cont(" start %px", kp.kp_objp); if (kp.kp_data_offset) --- a/mm/slab.h~mm-kfence-support-kmem_dump_obj-for-kfence-objects +++ a/mm/slab.h @@ -868,7 +868,7 @@ struct kmem_obj_info { void *kp_stack[KS_ADDRS_COUNT]; void *kp_free_stack[KS_ADDRS_COUNT]; }; -void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab); +void __kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab); #endif #ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR --- a/mm/slob.c~mm-kfence-support-kmem_dump_obj-for-kfence-objects +++ a/mm/slob.c @@ -463,7 +463,7 @@ out: } #ifdef CONFIG_PRINTK -void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) +void __kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) { kpp->kp_ptr = object; kpp->kp_slab = slab; --- a/mm/slub.c~mm-kfence-support-kmem_dump_obj-for-kfence-objects +++ a/mm/slub.c @@ -4312,7 +4312,7 @@ int __kmem_cache_shutdown(struct kmem_ca } #ifdef CONFIG_PRINTK -void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) +void __kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) { void *base; int __maybe_unused i; From patchwork Fri Apr 15 02:13:46 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814205 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9802CC433EF for ; Fri, 15 Apr 2022 02:13:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3477A6B0081; Thu, 14 Apr 2022 22:13:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F7576B0082; Thu, 14 Apr 2022 22:13:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BF296B0083; Thu, 14 Apr 2022 22:13:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 0E8CC6B0081 for ; Thu, 14 Apr 2022 22:13:49 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id E78491232B2 for ; Fri, 15 Apr 2022 02:13:48 +0000 (UTC) X-FDA: 79357492536.25.FBF8A5E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 59799A0006 for ; Fri, 15 Apr 2022 02:13:48 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AF9AC6221D; Fri, 15 Apr 2022 02:13:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 165E6C385A1; Fri, 15 Apr 2022 02:13:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988827; bh=xCFUpoOfjpWMzrJK4rQeRfdrhaHekCZ3L54NTJ5EtI4=; h=Date:To:From:In-Reply-To:Subject:From; b=ycWOACPY5a7e3zVT5ItlaYNvus4defw/J/e/c8W4DOpqF7kyfTZpfGPjnSKSWJSLg WVi4sf4P85uDAycs3JeZOR+SuEvkazKld/YR5Znn0NBnHZiRHcHgDWDpDVdtdMUNT2 q/RQQqJHqDJU73S+YE5iEatXN/rE2OxDkABGEeeU= Date: Thu, 14 Apr 2022 19:13:46 -0700 To: stable@vger.kernel.org,senozhatsky@chromium.org,ngupta@vflare.org,ivan@cloudflare.com,david@redhat.com,axboe@kernel.dk,minchan@kernel.org,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 08/14] mm: fix unexpected zeroed page mapping with zram swap Message-Id: <20220415021347.165E6C385A1@smtp.kernel.org> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 59799A0006 X-Stat-Signature: e1bd8x44hdfhyq3zoj5n4ix8k3hsk84h Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=ycWOACPY; dmarc=none; spf=pass (imf15.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1649988828-145606 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Minchan Kim Subject: mm: fix unexpected zeroed page mapping with zram swap Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the *zero data* to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed data The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swap_slot_free_notify function. With this patch, CPU A will see correct data. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU B The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly. Link: https://lkml.kernel.org/r/YjTVVxIAsnKAXjTd@google.com Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device") Reported-by: Ivan Babrou Tested-by: Ivan Babrou Signed-off-by: Minchan Kim Cc: Nitin Gupta Cc: Sergey Senozhatsky Cc: Jens Axboe Cc: David Hildenbrand Cc: [4.14+] Signed-off-by: Andrew Morton --- mm/page_io.c | 54 ------------------------------------------------- 1 file changed, 54 deletions(-) --- a/mm/page_io.c~mm-fix-unexpected-zeroed-page-mapping-with-zram-swap +++ a/mm/page_io.c @@ -51,54 +51,6 @@ void end_swap_bio_write(struct bio *bio) bio_put(bio); } -static void swap_slot_free_notify(struct page *page) -{ - struct swap_info_struct *sis; - struct gendisk *disk; - swp_entry_t entry; - - /* - * There is no guarantee that the page is in swap cache - the software - * suspend code (at least) uses end_swap_bio_read() against a non- - * swapcache page. So we must check PG_swapcache before proceeding with - * this optimization. - */ - if (unlikely(!PageSwapCache(page))) - return; - - sis = page_swap_info(page); - if (data_race(!(sis->flags & SWP_BLKDEV))) - return; - - /* - * The swap subsystem performs lazy swap slot freeing, - * expecting that the page will be swapped out again. - * So we can avoid an unnecessary write if the page - * isn't redirtied. - * This is good for real swap storage because we can - * reduce unnecessary I/O and enhance wear-leveling - * if an SSD is used as the as swap device. - * But if in-memory swap device (eg zram) is used, - * this causes a duplicated copy between uncompressed - * data in VM-owned memory and compressed data in - * zram-owned memory. So let's free zram-owned memory - * and make the VM-owned decompressed page *dirty*, - * so the page should be swapped out somewhere again if - * we again wish to reclaim it. - */ - disk = sis->bdev->bd_disk; - entry.val = page_private(page); - if (disk->fops->swap_slot_free_notify && __swap_count(entry) == 1) { - unsigned long offset; - - offset = swp_offset(entry); - - SetPageDirty(page); - disk->fops->swap_slot_free_notify(sis->bdev, - offset); - } -} - static void end_swap_bio_read(struct bio *bio) { struct page *page = bio_first_page_all(bio); @@ -114,7 +66,6 @@ static void end_swap_bio_read(struct bio } SetPageUptodate(page); - swap_slot_free_notify(page); out: unlock_page(page); WRITE_ONCE(bio->bi_private, NULL); @@ -394,11 +345,6 @@ int swap_readpage(struct page *page, boo if (sis->flags & SWP_SYNCHRONOUS_IO) { ret = bdev_read_page(sis->bdev, swap_page_sector(page), page); if (!ret) { - if (trylock_page(page)) { - swap_slot_free_notify(page); - unlock_page(page); - } - count_vm_event(PSWPIN); goto out; } From patchwork Fri Apr 15 02:13:49 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814206 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A935C433EF for ; Fri, 15 Apr 2022 02:13:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0158D6B0082; Thu, 14 Apr 2022 22:13:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F05486B0083; Thu, 14 Apr 2022 22:13:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D58346B0085; Thu, 14 Apr 2022 22:13:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id C6D446B0082 for ; Thu, 14 Apr 2022 22:13:51 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AF3BD27EC3 for ; Fri, 15 Apr 2022 02:13:51 +0000 (UTC) X-FDA: 79357492662.12.E39ABCB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id 308CBA0002 for ; Fri, 15 Apr 2022 02:13:51 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9C13B621EB; Fri, 15 Apr 2022 02:13:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02C1AC385A5; Fri, 15 Apr 2022 02:13:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988830; bh=HsSQiCzVou7pdy0n3uzXUYPUGgfLQFTxEX9aiaeWYA8=; h=Date:To:From:In-Reply-To:Subject:From; b=e9snAHju5jwScKCgUygtfIkII0Acd/DRIgk2wTJ1l4Gu+u23mxGMaYdnt/OD6BtjU wwaUxNM8y0U27bq9nbGrMM7Ewruz3purAdgexvfYJxmnMOp9cNv8Cka1iEdRWWmLvq LY8MjHFy47MBDWSew5Kcnieh8TuASIooAt6ITbSY= Date: Thu, 14 Apr 2022 19:13:49 -0700 To: vbabka@suse.cz,nigupta@nvidia.com,lkp@intel.com,quic_charante@quicinc.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 09/14] mm: compaction: fix compiler warning when CONFIG_COMPACTION=n Message-Id: <20220415021350.02C1AC385A5@smtp.kernel.org> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 308CBA0002 X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=e9snAHju; spf=pass (imf25.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Stat-Signature: je5zf5oj9ubcxu78rs14ycrdfthm8q39 X-HE-Tag: 1649988831-304025 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Charan Teja Kalla Subject: mm: compaction: fix compiler warning when CONFIG_COMPACTION=n The below warning is reported when CONFIG_COMPACTION=n: mm/compaction.c:56:27: warning: 'HPAGE_FRAG_CHECK_INTERVAL_MSEC' defined but not used [-Wunused-const-variable=] 56 | static const unsigned int HPAGE_FRAG_CHECK_INTERVAL_MSEC = 500; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix it by moving 'HPAGE_FRAG_CHECK_INTERVAL_MSEC' under CONFIG_COMPACTION defconfig. Also since this is just a 'static const int' type, use #define for it. Link: https://lkml.kernel.org/r/1647608518-20924-1-git-send-email-quic_charante@quicinc.com Signed-off-by: Charan Teja Kalla Reported-by: kernel test robot Acked-by: Vlastimil Babka Cc: Nitin Gupta Signed-off-by: Andrew Morton --- mm/compaction.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/mm/compaction.c~mm-compaction-fix-compiler-warning-when-config_compaction=n +++ a/mm/compaction.c @@ -26,6 +26,11 @@ #include "internal.h" #ifdef CONFIG_COMPACTION +/* + * Fragmentation score check interval for proactive compaction purposes. + */ +#define HPAGE_FRAG_CHECK_INTERVAL_MSEC (500) + static inline void count_compact_event(enum vm_event_item item) { count_vm_event(item); @@ -51,11 +56,6 @@ static inline void count_compact_events( #define pageblock_end_pfn(pfn) block_end_pfn(pfn, pageblock_order) /* - * Fragmentation score check interval for proactive compaction purposes. - */ -static const unsigned int HPAGE_FRAG_CHECK_INTERVAL_MSEC = 500; - -/* * Page order with-respect-to which proactive compaction * calculates external fragmentation, which is used as * the "fragmentation score" of a node/zone. From patchwork Fri Apr 15 02:13:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814207 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D842CC4332F for ; Fri, 15 Apr 2022 02:13:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6CAA06B0083; Thu, 14 Apr 2022 22:13:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6796E6B0085; Thu, 14 Apr 2022 22:13:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 541BF6B0087; Thu, 14 Apr 2022 22:13:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 447226B0083 for ; Thu, 14 Apr 2022 22:13:56 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2535E3BDE for ; Fri, 15 Apr 2022 02:13:56 +0000 (UTC) X-FDA: 79357492872.01.36B80D6 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf01.hostedemail.com (Postfix) with ESMTP id 9195840002 for ; Fri, 15 Apr 2022 02:13:55 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 60ADDB82BF5; Fri, 15 Apr 2022 02:13:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAC8DC385A5; Fri, 15 Apr 2022 02:13:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988833; bh=tfzIATRIEssyLcoxMcSK4FK9aTSQ+1j3NcOkbDQ7poc=; h=Date:To:From:In-Reply-To:Subject:From; b=v/8PQkr+vBRUpzYoyAmDsMC+FNaZgdN/7JjM3DKfCiYwBLv6+jLoHNhyFO/WXr4nE qwYN7QphbtQ2twQUh41vVFFcq26ZFTNE2J2Pa1ZMeHscAi6Dmzf8UrkdvtS8E4gXaU 8W4r2EC1yrQq12n3IP9HxmOuyhmN3FFe2PbB89YE= Date: Thu, 14 Apr 2022 19:13:52 -0700 To: stable@vger.kernel.org,naoya.horiguchi@nec.com,mike.kravetz@oracle.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 10/14] hugetlb: do not demote poisoned hugetlb pages Message-Id: <20220415021352.EAC8DC385A5@smtp.kernel.org> Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="v/8PQkr+"; dmarc=none; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9195840002 X-Stat-Signature: 1j3mf1ugkkzdho3ekp68tkbqhd5x75pt X-HE-Tag: 1649988835-960311 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Mike Kravetz Subject: hugetlb: do not demote poisoned hugetlb pages It is possible for poisoned hugetlb pages to reside on the free lists. The huge page allocation routines which dequeue entries from the free lists make a point of avoiding poisoned pages. There is no such check and avoidance in the demote code path. If a hugetlb page on the is on a free list, poison will only be set in the head page rather then the page with the actual error. If such a page is demoted, then the poison flag may follow the wrong page. A page without error could have poison set, and a page with poison could not have the flag set. Check for poison before attempting to demote a hugetlb page. Also, return -EBUSY to the caller if only poisoned pages are on the free list. Link: https://lkml.kernel.org/r/20220307215707.50916-1-mike.kravetz@oracle.com Fixes: 8531fc6f52f5 ("hugetlb: add hugetlb demote page support") Signed-off-by: Mike Kravetz Reviewed-by: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton --- mm/hugetlb.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) --- a/mm/hugetlb.c~hugetlb-do-not-demote-poisoned-hugetlb-pages +++ a/mm/hugetlb.c @@ -3475,7 +3475,6 @@ static int demote_pool_huge_page(struct { int nr_nodes, node; struct page *page; - int rc = 0; lockdep_assert_held(&hugetlb_lock); @@ -3486,15 +3485,19 @@ static int demote_pool_huge_page(struct } for_each_node_mask_to_free(h, nr_nodes, node, nodes_allowed) { - if (!list_empty(&h->hugepage_freelists[node])) { - page = list_entry(h->hugepage_freelists[node].next, - struct page, lru); - rc = demote_free_huge_page(h, page); - break; + list_for_each_entry(page, &h->hugepage_freelists[node], lru) { + if (PageHWPoison(page)) + continue; + + return demote_free_huge_page(h, page); } } - return rc; + /* + * Only way to get here is if all pages on free lists are poisoned. + * Return -EBUSY so that caller will not retry. + */ + return -EBUSY; } #define HSTATE_ATTR_RO(_name) \ From patchwork Fri Apr 15 02:13:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814208 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DC1EC43219 for ; Fri, 15 Apr 2022 02:13:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 915516B0085; Thu, 14 Apr 2022 22:13:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89C136B0087; Thu, 14 Apr 2022 22:13:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73D466B0088; Thu, 14 Apr 2022 22:13:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id 65C496B0085 for ; Thu, 14 Apr 2022 22:13:58 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 31733A79A5 for ; Fri, 15 Apr 2022 02:13:58 +0000 (UTC) X-FDA: 79357492956.29.5A783E1 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf10.hostedemail.com (Postfix) with ESMTP id BEAB0C0009 for ; Fri, 15 Apr 2022 02:13:57 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 98A63B82B5F; Fri, 15 Apr 2022 02:13:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B0B3C385A1; Fri, 15 Apr 2022 02:13:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988836; bh=BKRZEFrsT7HckjP5sHfg9m9OXct1eM7WyctjCsktjL0=; h=Date:To:From:In-Reply-To:Subject:From; b=VobwKsOtL9/lzK56pUwdrV37Wx3MHwRc7XltBcqZa49C2J0b69TuppanPp8VWNJSh XehNRwrTmpTtowSP/bBxehpNm6xcHvk54SRhkZRkXycGcETO+3af9J6HSxF0dNYTPT D6jBG6ufJpIuv6tcbCDBrWkhg8cMyEpyw9wo40vQ= Date: Thu, 14 Apr 2022 19:13:55 -0700 To: viro@zeniv.linux.org.uk,surenb@google.com,stable@vger.kernel.org,sspatil@google.com,songliubraving@fb.com,shuah@kernel.org,rppt@kernel.org,rientjes@google.com,regressions@leemhuis.info,ndesaulniers@google.com,mike.kravetz@oracle.com,maskray@google.com,kirill.shutemov@linux.intel.com,irogers@google.com,hughd@google.com,hjl.tools@gmail.com,ckennelly@google.com,adobriyan@gmail.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 11/14] revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders" Message-Id: <20220415021356.1B0B3C385A1@smtp.kernel.org> X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BEAB0C0009 X-Stat-Signature: fnr4icmon56mqu3dqfyyc64xz1jhhiwr Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=VobwKsOt; spf=pass (imf10.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1649988837-265687 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Andrew Morton Subject: revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders" 925346c129da11 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders") is an attempt to fix regressions due to 9630f0d60fec5f ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE"). But regressionss continue to be reported: https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.info/ https://bugzilla.kernel.org/show_bug.cgi?id=215720 https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info This patch reverts the fix, so the original can also be reverted. Fixes: 925346c129da11 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders") Cc: H.J. Lu Cc: Chris Kennelly Cc: Al Viro Cc: Alexey Dobriyan Cc: Song Liu Cc: David Rientjes Cc: Ian Rogers Cc: Hugh Dickins Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Fangrui Song Cc: Nick Desaulniers Cc: Kirill A. Shutemov Cc: Mike Kravetz Cc: Shuah Khan Cc: Thorsten Leemhuis Cc: Mike Rapoport Cc: Signed-off-by: Andrew Morton --- fs/binfmt_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/binfmt_elf.c~revert-fs-binfmt_elf-fix-pt_load-p_align-values-for-loaders +++ a/fs/binfmt_elf.c @@ -1118,7 +1118,7 @@ out_free_interp: * without MAP_FIXED nor MAP_FIXED_NOREPLACE). */ alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum); - if (interpreter || alignment > ELF_MIN_ALIGN) { + if (alignment > ELF_MIN_ALIGN) { load_bias = ELF_ET_DYN_BASE; if (current->flags & PF_RANDOMIZE) load_bias += arch_mmap_rnd(); From patchwork Fri Apr 15 02:13:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814209 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4167C433F5 for ; Fri, 15 Apr 2022 02:14:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51C596B0087; Thu, 14 Apr 2022 22:14:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CBC06B0088; Thu, 14 Apr 2022 22:14:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 393CA6B0089; Thu, 14 Apr 2022 22:14:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 2A51D6B0087 for ; Thu, 14 Apr 2022 22:14:01 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0283C2373C for ; Fri, 15 Apr 2022 02:14:00 +0000 (UTC) X-FDA: 79357493082.13.FFB51EC Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 6B7A040006 for ; Fri, 15 Apr 2022 02:14:00 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E2A3B6220E; Fri, 15 Apr 2022 02:13:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FCA3C385A5; Fri, 15 Apr 2022 02:13:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988839; bh=am2ji8hOArEj1jJvaTmG1u8UgrvozH1QixzKt+KNgWU=; h=Date:To:From:In-Reply-To:Subject:From; b=Fx/60ptRS88rycGMyNZZbzfrt/wpN4qFFZtmnPKZFN7XJXELZJfMo7nQX1RhMz6B/ PqCS64+RxvO+cwxBK3HDcZdY7BzYSJIaa+d58gHI0phEUln+4es3L0AhbvodPYcKl3 wWPrpoa1INiiohMDLVcOI0TdZdZ9BwMvI6UfkO54= Date: Thu, 14 Apr 2022 19:13:58 -0700 To: viro@zeniv.linux.org.uk,surenb@google.com,stable@vger.kernel.org,sspatil@google.com,songliubraving@fb.com,shuah@kernel.org,rppt@kernel.org,rientjes@google.com,regressions@leemhuis.info,ndesaulniers@google.com,mike.kravetz@oracle.com,maskray@google.com,kirill.shutemov@linux.intel.com,irogers@google.com,hughd@google.com,hjl.tools@gmail.com,ckennelly@google.com,adobriyan@gmail.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 12/14] revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE" Message-Id: <20220415021359.3FCA3C385A5@smtp.kernel.org> Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="Fx/60ptR"; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Stat-Signature: cmxeacmf1qif3enxzyznyrrcbh1hz99q X-Rspamd-Queue-Id: 6B7A040006 X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1649988840-404530 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Andrew Morton Subject: revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE" Despite Mike's attempted fix (925346c129da117122), regressions reports continue: https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.info/ https://bugzilla.kernel.org/show_bug.cgi?id=215720 https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info So revert this patch. Fixes: 9630f0d60fec ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE") Cc: Alexey Dobriyan Cc: Al Viro Cc: Chris Kennelly Cc: David Rientjes Cc: Fangrui Song Cc: H.J. Lu Cc: Hugh Dickins Cc: Ian Rogers Cc: Kirill A. Shutemov Cc: Mike Kravetz Cc: Mike Rapoport Cc: Nick Desaulniers Cc: Sandeep Patil Cc: Shuah Khan Cc: Song Liu Cc: Suren Baghdasaryan Cc: Thorsten Leemhuis Cc: Signed-off-by: Andrew Morton --- fs/binfmt_elf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/binfmt_elf.c~revert-fs-binfmt_elf-use-pt_load-p_align-values-for-static-pie +++ a/fs/binfmt_elf.c @@ -1117,11 +1117,11 @@ out_free_interp: * independently randomized mmap region (0 load_bias * without MAP_FIXED nor MAP_FIXED_NOREPLACE). */ - alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum); - if (alignment > ELF_MIN_ALIGN) { + if (interpreter) { load_bias = ELF_ET_DYN_BASE; if (current->flags & PF_RANDOMIZE) load_bias += arch_mmap_rnd(); + alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum); if (alignment) load_bias &= ~(alignment - 1); elf_flags |= MAP_FIXED_NOREPLACE; From patchwork Fri Apr 15 02:14:01 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814210 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F39D4C433F5 for ; Fri, 15 Apr 2022 02:14:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 852276B0088; Thu, 14 Apr 2022 22:14:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FFF06B0089; Thu, 14 Apr 2022 22:14:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C8AF6B008A; Thu, 14 Apr 2022 22:14:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0219.hostedemail.com [216.40.44.219]) by kanga.kvack.org (Postfix) with ESMTP id 5CBB36B0088 for ; Thu, 14 Apr 2022 22:14:04 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1BD7A8249980 for ; Fri, 15 Apr 2022 02:14:04 +0000 (UTC) X-FDA: 79357493208.29.21B7CAB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id 9CEE0C0009 for ; Fri, 15 Apr 2022 02:14:03 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 05CF562226; Fri, 15 Apr 2022 02:14:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BC21C385A5; Fri, 15 Apr 2022 02:14:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988842; bh=H2iypGY9BaC4SA681TThy2eJKi1ILIBobrhY0GhHqkc=; h=Date:To:From:In-Reply-To:Subject:From; b=B14meI9LZfboYGHLeewF7Rdxi4NRrruW9TZ5qFA5vtrXxS/MqtjtHHMZ+XIS3Q2wu RooqhdSPoCYUEcnBNM2bvQAsqWn0cXHWRzebFJjvH5pch0N97ZLzH8ZI8ZRpqMjFKo X7fGkbsZvASXJlFvqTEPxO790M96pY1asR76FCeQ= Date: Thu, 14 Apr 2022 19:14:01 -0700 To: urezki@gmail.com,hch@lst.de,chris@chrisdown.name,bhe@redhat.com,osandov@fb.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 13/14] mm/vmalloc: fix spinning drain_vmap_work after reading from /proc/vmcore Message-Id: <20220415021402.5BC21C385A5@smtp.kernel.org> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 9CEE0C0009 X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=B14meI9L; spf=pass (imf28.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Stat-Signature: rswa6dnpodq6nijrsb5of3dnw9z5fwrw X-HE-Tag: 1649988843-14404 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Omar Sandoval Subject: mm/vmalloc: fix spinning drain_vmap_work after reading from /proc/vmcore Commit 3ee48b6af49c ("mm, x86: Saving vmcore with non-lazy freeing of vmas") introduced set_iounmap_nonlazy(), which sets vmap_lazy_nr to lazy_max_pages() + 1, ensuring that any future vunmaps() immediately purge the vmap areas instead of doing it lazily. Commit 690467c81b1a ("mm/vmalloc: Move draining areas out of caller context") moved the purging from the vunmap() caller to a worker thread. Unfortunately, set_iounmap_nonlazy() can cause the worker thread to spin (possibly forever). For example, consider the following scenario: 1. Thread reads from /proc/vmcore. This eventually calls __copy_oldmem_page() -> set_iounmap_nonlazy(), which sets vmap_lazy_nr to lazy_max_pages() + 1. 2. Then it calls free_vmap_area_noflush() (via iounmap()), which adds 2 pages (one page plus the guard page) to the purge list and vmap_lazy_nr. vmap_lazy_nr is now lazy_max_pages() + 3, so the drain_vmap_work is scheduled. 3. Thread returns from the kernel and is scheduled out. 4. Worker thread is scheduled in and calls drain_vmap_area_work(). It frees the 2 pages on the purge list. vmap_lazy_nr is now lazy_max_pages() + 1. 5. This is still over the threshold, so it tries to purge areas again, but doesn't find anything. 6. Repeat 5. If the system is running with only one CPU (which is typicial for kdump) and preemption is disabled, then this will never make forward progress: there aren't any more pages to purge, so it hangs. If there is more than one CPU or preemption is enabled, then the worker thread will spin forever in the background. (Note that if there were already pages to be purged at the time that set_iounmap_nonlazy() was called, this bug is avoided.) This can be reproduced with anything that reads from /proc/vmcore multiple times. E.g., vmcore-dmesg /proc/vmcore. It turns out that improvements to vmap() over the years have obsoleted the need for this "optimization". I benchmarked `dd if=/proc/vmcore of=/dev/null` with 4k and 1M read sizes on a system with a 32GB vmcore. The test was run on 5.17, 5.18-rc1 with a fix that avoided the hang, and 5.18-rc1 with set_iounmap_nonlazy() removed entirely: |5.17 |5.18+fix|5.18+removal 4k|40.86s| 40.09s| 26.73s 1M|24.47s| 23.98s| 21.84s The removal was the fastest (by a wide margin with 4k reads). This patch removes set_iounmap_nonlazy(). Link: https://lkml.kernel.org/r/52f819991051f9b865e9ce25605509bfdbacadcd.1649277321.git.osandov@fb.com Fixes: 690467c81b1a ("mm/vmalloc: Move draining areas out of caller context") Signed-off-by: Omar Sandoval Acked-by: Chris Down Reviewed-by: Uladzislau Rezki (Sony) Reviewed-by: Christoph Hellwig Acked-by: Baoquan He Signed-off-by: Andrew Morton --- arch/x86/include/asm/io.h | 2 -- arch/x86/kernel/crash_dump_64.c | 1 - mm/vmalloc.c | 11 ----------- 3 files changed, 14 deletions(-) --- a/arch/x86/include/asm/io.h~mm-vmalloc-fix-spinning-drain_vmap_work-after-reading-from-proc-vmcore +++ a/arch/x86/include/asm/io.h @@ -210,8 +210,6 @@ void __iomem *ioremap(resource_size_t of extern void iounmap(volatile void __iomem *addr); #define iounmap iounmap -extern void set_iounmap_nonlazy(void); - #ifdef __KERNEL__ void memcpy_fromio(void *, const volatile void __iomem *, size_t); --- a/arch/x86/kernel/crash_dump_64.c~mm-vmalloc-fix-spinning-drain_vmap_work-after-reading-from-proc-vmcore +++ a/arch/x86/kernel/crash_dump_64.c @@ -37,7 +37,6 @@ static ssize_t __copy_oldmem_page(unsign } else memcpy(buf, vaddr + offset, csize); - set_iounmap_nonlazy(); iounmap((void __iomem *)vaddr); return csize; } --- a/mm/vmalloc.c~mm-vmalloc-fix-spinning-drain_vmap_work-after-reading-from-proc-vmcore +++ a/mm/vmalloc.c @@ -1671,17 +1671,6 @@ static DEFINE_MUTEX(vmap_purge_lock); /* for per-CPU blocks */ static void purge_fragmented_blocks_allcpus(void); -#ifdef CONFIG_X86_64 -/* - * called before a call to iounmap() if the caller wants vm_area_struct's - * immediately freed. - */ -void set_iounmap_nonlazy(void) -{ - atomic_long_set(&vmap_lazy_nr, lazy_max_pages()+1); -} -#endif /* CONFIG_X86_64 */ - /* * Purges all lazily-freed vmap areas. */ From patchwork Fri Apr 15 02:14:04 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12814211 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00894C433F5 for ; Fri, 15 Apr 2022 02:14:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 879966B0089; Thu, 14 Apr 2022 22:14:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8277E6B008A; Thu, 14 Apr 2022 22:14:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C9BB6B008C; Thu, 14 Apr 2022 22:14:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 5CD916B0089 for ; Thu, 14 Apr 2022 22:14:07 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2221E27BFD for ; Fri, 15 Apr 2022 02:14:07 +0000 (UTC) X-FDA: 79357493334.08.0D40DA2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 8E222140006 for ; Fri, 15 Apr 2022 02:14:06 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 03B5B62219; Fri, 15 Apr 2022 02:14:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5EBADC385A7; Fri, 15 Apr 2022 02:14:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988845; bh=eBBWAnXrVUdhi6HB2GZp6T9EAQR1Og4UhicA+Umrp6E=; h=Date:To:From:In-Reply-To:Subject:From; b=k3qjibzzNtJShJVheS/MtFb3s5dnZMgNnC7Uvf9vgugDT+ZLPGgTOjdAntB9evZp0 HbtoPg/Wc/8mIXETw8DTz+kzj6w7RS9AwdVAYFXoBWLRB4A6NxSOJEC7XutmbN3UCt f1Lo4iLlZOEJm0rUWWUnOItXBggfRnsuzk9DFDQ0= Date: Thu, 14 Apr 2022 19:14:04 -0700 To: stable@vger.kernel.org,catalin.marinas@arm.com,patrick.wang.shcn@gmail.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 14/14] mm: kmemleak: take a full lowmem check in kmemleak_*_phys() Message-Id: <20220415021405.5EBADC385A7@smtp.kernel.org> Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=k3qjibzz; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Stat-Signature: cyybf7m1qog79cdxrhw5qj4xneiobrc1 X-Rspamd-Queue-Id: 8E222140006 X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1649988846-575298 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Patrick Wang Subject: mm: kmemleak: take a full lowmem check in kmemleak_*_phys() The kmemleak_*_phys() apis do not check the address for lowmem's min boundary, while the caller may pass an address below lowmem, which will trigger an oops: # echo scan > /sys/kernel/debug/kmemleak [ 54.888353] Unable to handle kernel paging request at virtual address ff5fffffffe00000 [ 54.888932] Oops [#1] [ 54.889102] Modules linked in: [ 54.889326] CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33 [ 54.889620] Hardware name: riscv-virtio,qemu (DT) [ 54.889901] epc : scan_block+0x74/0x15c [ 54.890215] ra : scan_block+0x72/0x15c [ 54.890390] epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30 [ 54.890607] gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200 [ 54.890835] t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90 [ 54.891024] s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000 [ 54.891201] a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001 [ 54.891377] a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005 [ 54.891552] s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90 [ 54.891727] s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0 [ 54.891903] s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000 [ 54.892078] s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f [ 54.892271] t5 : 0000000000000001 t6 : 0000000000000000 [ 54.892408] status: 0000000000000100 badaddr: ff5fffffffe00000 cause: 000000000000000d [ 54.892643] [] scan_gray_list+0x12e/0x1a6 [ 54.892824] [] kmemleak_scan+0x2aa/0x57e [ 54.892961] [] kmemleak_write+0x32a/0x40c [ 54.893096] [] full_proxy_write+0x56/0x82 [ 54.893235] [] vfs_write+0xa6/0x2a6 [ 54.893362] [] ksys_write+0x6c/0xe2 [ 54.893487] [] sys_write+0x22/0x2a [ 54.893609] [] ret_from_syscall+0x0/0x2 [ 54.894183] ---[ end trace 0000000000000000 ]--- The callers may not quite know the actual address they pass(e.g. from devicetree). So the kmemleak_*_phys() apis should guarantee the address they finally use is in lowmem range, so check the address for lowmem's min boundary. Link: https://lkml.kernel.org/r/20220413122925.33856-1-patrick.wang.shcn@gmail.com Signed-off-by: Patrick Wang Acked-by: Catalin Marinas Cc: Signed-off-by: Andrew Morton --- mm/kmemleak.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/mm/kmemleak.c~mm-kmemleak-take-a-full-lowmem-check-in-kmemleak__phys +++ a/mm/kmemleak.c @@ -1132,7 +1132,7 @@ EXPORT_SYMBOL(kmemleak_no_scan); void __ref kmemleak_alloc_phys(phys_addr_t phys, size_t size, int min_count, gfp_t gfp) { - if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) + if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) kmemleak_alloc(__va(phys), size, min_count, gfp); } EXPORT_SYMBOL(kmemleak_alloc_phys); @@ -1146,7 +1146,7 @@ EXPORT_SYMBOL(kmemleak_alloc_phys); */ void __ref kmemleak_free_part_phys(phys_addr_t phys, size_t size) { - if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) + if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) kmemleak_free_part(__va(phys), size); } EXPORT_SYMBOL(kmemleak_free_part_phys); @@ -1158,7 +1158,7 @@ EXPORT_SYMBOL(kmemleak_free_part_phys); */ void __ref kmemleak_not_leak_phys(phys_addr_t phys) { - if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) + if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) kmemleak_not_leak(__va(phys)); } EXPORT_SYMBOL(kmemleak_not_leak_phys); @@ -1170,7 +1170,7 @@ EXPORT_SYMBOL(kmemleak_not_leak_phys); */ void __ref kmemleak_ignore_phys(phys_addr_t phys) { - if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) + if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) kmemleak_ignore(__va(phys)); } EXPORT_SYMBOL(kmemleak_ignore_phys);