From mboxrd@z Thu Jan 1 00:00:00 1970 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 C734DC282D1 for ; Thu, 6 Mar 2025 05:10:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E246280003; Thu, 6 Mar 2025 00:10:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9908C280002; Thu, 6 Mar 2025 00:10:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8593E280003; Thu, 6 Mar 2025 00:10:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5D931280002 for ; Thu, 6 Mar 2025 00:10:54 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B1D08C0FC2 for ; Thu, 6 Mar 2025 05:10:55 +0000 (UTC) X-FDA: 83189951670.08.12D720F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 1DFF918000D for ; Thu, 6 Mar 2025 05:10:53 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=i88gzM5F; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741237854; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XST+jheb705ZIJsJQQajySkT5tEWK7OqP/Yr2rYjQZc=; b=lKDja8HJ91vPlRfWF+u/FfJRxtur0mMf6eI2E5Q2FZmQEyVD/pSzARq6pZEyRgRm+zoAzB +cVkw15ydd0GTWb+mWPIrRWgZGcQeDI7MXYXCFPKhbICaF847Dj+OFyjyrAFpkVktBaeIt vpcyfpf7nUvZwg8QQy+ipADZm/E5I4U= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=i88gzM5F; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741237854; a=rsa-sha256; cv=none; b=wKy9Mpy5G6nG2JmJAxuRT1sa5w6eRuBzOzvIR5/hgwBeko1pf/4RE8yzIAxSd1s04aN7pn tLzLmTim6ktAzHy33M+vyBniOLzIqa7ssRWlgW8lK+ndJPWGYU3MTfb1gIbih0O9otT4U5 F/E1H1CL1wXfr2CQr5Alm8gcxaV4fBk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=XST+jheb705ZIJsJQQajySkT5tEWK7OqP/Yr2rYjQZc=; b=i88gzM5F9CHlNSXhYSF3Tg+OBk gP3SH4qseRy7Hnw+Uoix0oDZSbCOeYKzIuADYKD/p+muY6mZaDl+0V8DTj8TepAyIryfbzMj/VkQD +myqIK1SG80bEr6iQmWG01YFOR1U0nbvT+80auQANjWrt9uz1+9Ni0OCe6aCLxqRAu8faM7hGyLu2 Om2zOqTPVCleHOs8qoVcvXBfH0D5J/NZmagFYMLMo9v9ht5Y+d+hJ4uOVpCrwYZ8qV837G/TQo07b LOmps4qOHTvGwKi1cmzyjr8V8FLLm1U0WEe1vrq3vkcHi7bK+KHjAPd0gApTGslYGkf9kGwBu8Bv5 eiE5X8fw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tq3VT-00000006qKX-1UEm; Thu, 06 Mar 2025 05:10:51 +0000 Date: Thu, 6 Mar 2025 05:10:51 +0000 From: Matthew Wilcox To: Luka Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, OGAWA Hirofumi , linux-fsdevel@vger.kernel.org Subject: Potential Linux Crash: WARNING in __getblk_slow in Linux kernel v6.13-rc5 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 1DFF918000D X-Stat-Signature: kzzmzis9uaymmod6jpspbjcci666g83j X-HE-Tag: 1741237853-969036 X-HE-Meta: U2FsdGVkX19tKJXU9m0gTiFh3OHS3n3bkJXH6FI5uM5bB9f5BfLAggHcmWftQImDf+A1O941Nhk0P+bCXf+S7I9GFFWgnChZz/NEPmRoy4Xkq1FFLN0ZACmYVcX+eeXKHMEUoRsvub7SY8d/xB0Upb5cm1RbE4xP7OzYNuBFLwt0gPB5Ktr74ECWCHBDSW7uIRqe4YXEonR7kZEV5IWmDJcYsEYbPdGOIAPW8l0T1t41Ywx2Uyx1Iqtc9I/96vShoi2+phSPMAHKXdrJZVnZWGV+tMAx4twvQyHfq/v6n97X5yeaskyr7BdKiObQzxeiBzyw8qwwQQyf+jlOkZ/HSoOWD+McMhO41/GoX1c/WxrwgOD0xgJ/9EDbvOCFB2nNlgz8Ad0GhdotjZ/eFR/mIxaI6uIhL1bSuZffwQxV6pjgLd+MHLkkD6y6IIieunKf6jgVK0ELTQz0y8lPvpwEqQghx4cPR+ACBxxbhndF/sf91eLUavYaa2asip4RCU4RlqgnPmvIQfQcDBV0FctGgMZAq+mT9mH1aY8Aw8WO32RfmiTTxhiY2pJdEzBM3SHA1UUZsm+NguwbDQ9OgZIrDCqVGvhvELraTAUiLGtgq5aw/HkIXsMwgxmzbDPOx92PebtvLmk4EXcV7akAiCOm3hcNZJy9gOGmt6boZwzTCWwB8VAn+kiDlExk5THkVKEC9jTacNni1qOocaIWbuXK6Z+266n43J2dDRMbTeXb4H4hadPJfJuLaT8evm9uwM4/b7WjbswRS6tKvGfin+vR1Ld4LvMDL2wWaMAdzik7vFloifRxjxoQ2MtlgGNJgJ9Jy4e/luqGdHiUHYkknP4zQXVixHbirVkgHok6P49gRH/jSwaUY2knZbx7zRX8taJRRwtlyGtesKsuCiysQcoO8S0BV3IoSe2kev/6ZLmId0Uvs9NmhS/IXcGFyW4bu3YS1brA+fFyX9nOSfxWYjb twccmGb2 +R7Lc5vRqON7Asqkdqb2jbk2UQtIAHmEO4HhbjA1PMT/P13ciyHNIhmRIlFz6+UKZL8tYf3eEsWt7X20RovNXkqAw7biAX60ZMMJO8x6FoQh7klVGDTiXZSmTjhdQ6QzmFCeNFZQe11Hb4JBtuWX/cf3V2uZGqv41bb71LijNxyWYGeM2v1EA4W1HUtEiWajwgi9XH4ME7ZGGsN919r/E8/ofiflflNBq/lj1RcrUPuUQrEkMV3sQYbA6/ttSVjTAtZAT97PKqgsJF0H4clT74PVXN0IOUhSGJnqR+rt/fWMVGDlrjKgJrzqXSs4nBjRmMs4dbtkaIaCe92GEzq6DMpg89cuJG28rWfSV X-Bogosity: Ham, tests=bogofilter, spamicity=0.000500, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Mar 06, 2025 at 10:54:13AM +0800, Luka wrote: > Dear Linux Kernel Experts, > > Hello! > > I am a security researcher focused on testing Linux kernel > vulnerabilities. Recently, while testing the v6.13-rc5 Linux kernel, > we encountered a crash related to the mm kernel module. We have > successfully captured the call trace information for this crash. > > Unfortunately, we have not been able to reproduce the issue in our > local environment, so we are unable to provide a PoC (Proof of > Concept) at this time. > > We fully understand the complexity and importance of Linux kernel > maintenance, and we would like to share this finding with you for > further analysis and confirmation of the root cause. Below is a > summary of the relevant information: You're a "security researcher" ... but you're not even going to do a cursory look at the code to figure out what's going on? if (unlikely(nofail)) { ... WARN_ON_ONCE(current->flags & PF_MEMALLOC); ^^^ that's the line which triggered the warning. So it's not a problem in the memory allocator at all, it's the memory allocator reporting that someone's asked it to satisfy some impossible constraints. > alloc_pages_mpol_noprof+0xda/0x300 mm/mempolicy.c:2269 > folio_alloc_noprof+0x1e/0x70 mm/mempolicy.c:2355 > filemap_alloc_folio_noprof+0x2b2/0x2f0 mm/filemap.c:1009 > __filemap_get_folio+0x16d/0x3d0 mm/filemap.c:1951 > grow_dev_folio fs/buffer.c:1039 [inline] > grow_buffers fs/buffer.c:1105 [inline] > __getblk_slow+0x138/0x430 fs/buffer.c:1131 > bdev_getblk fs/buffer.c:1431 [inline] > __bread_gfp+0xea/0x2c0 fs/buffer.c:1485 __bread_gfp is who sets GFP_NOFAIL. > sb_bread include/linux/buffer_head.h:346 [inline] > fat12_ent_bread+0x231/0x3f0 fs/fat/fatent.c:86 > fat_ent_read+0x624/0xaa0 fs/fat/fatent.c:368 > fat_free_clusters+0x19c/0x860 fs/fat/fatent.c:568 > fat_free.isra.0+0x377/0x850 fs/fat/file.c:376 > fat_truncate_blocks+0x10d/0x190 fs/fat/file.c:394 > fat_free_eofblocks fs/fat/inode.c:633 [inline] > fat_evict_inode+0x1b1/0x260 fs/fat/inode.c:658 > evict+0x337/0x7c0 fs/inode.c:796 > dispose_list fs/inode.c:845 [inline] > prune_icache_sb+0x189/0x290 fs/inode.c:1033 > super_cache_scan+0x33d/0x510 fs/super.c:223 > do_shrink_slab mm/shrinker.c:437 [inline] > shrink_slab+0x43e/0x930 mm/shrinker.c:664 > shrink_node_memcgs mm/vmscan.c:5931 [inline] > shrink_node+0x4dd/0x15c0 mm/vmscan.c:5970 > shrink_zones mm/vmscan.c:6215 [inline] > do_try_to_free_pages+0x284/0x1160 mm/vmscan.c:6277 > try_to_free_pages+0x1ee/0x3e0 mm/vmscan.c:6527 > __perform_reclaim mm/page_alloc.c:3929 [inline] And __perform_reclaim() is where PF_MEMALLOC gets set. > __alloc_pages_direct_reclaim mm/page_alloc.c:3951 [inline] > __alloc_pages_slowpath mm/page_alloc.c:4382 [inline] > __alloc_pages_noprof+0xa48/0x2040 mm/page_alloc.c:4766 > alloc_pages_mpol_noprof+0xda/0x300 mm/mempolicy.c:2269 > pagetable_alloc_noprof include/linux/mm.h:2899 [inline] > __pte_alloc_one_noprof include/asm-generic/pgalloc.h:70 [inline] > pte_alloc_one+0x20/0x1b0 arch/x86/mm/pgtable.c:33 > do_fault_around mm/memory.c:5274 [inline] > do_read_fault mm/memory.c:5313 [inline] > do_fault mm/memory.c:5456 [inline] > do_pte_missing mm/memory.c:3979 [inline] > handle_pte_fault mm/memory.c:5801 [inline] > __handle_mm_fault+0x15b9/0x2380 mm/memory.c:5944 > handle_mm_fault+0x1c6/0x4c0 mm/memory.c:6112 > faultin_page mm/gup.c:1196 [inline] > __get_user_pages+0x421/0x2550 mm/gup.c:1494 > populate_vma_page_range+0x16b/0x200 mm/gup.c:1932 > __mm_populate+0x1c2/0x360 mm/gup.c:2035 > mm_populate include/linux/mm.h:3396 [inline] > vm_mmap_pgoff+0x25d/0x2f0 mm/util.c:585 > ksys_mmap_pgoff+0x5a/0x480 mm/mmap.c:542 Now, I'm not sure how best to solve this. Should FAT decline to read entries if it's called from reclaim? I know XFS goes to some trouble to not do that kind of thing. Or should buffer head allocation do something to access the emergency reserves?