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 5E745C3601A for ; Thu, 3 Apr 2025 12:30:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04B14280003; Thu, 3 Apr 2025 08:29:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3BF3280001; Thu, 3 Apr 2025 08:29:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E293C280003; Thu, 3 Apr 2025 08:29:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C41D9280001 for ; Thu, 3 Apr 2025 08:29:58 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EDFCAC04F6 for ; Thu, 3 Apr 2025 12:29:58 +0000 (UTC) X-FDA: 83292664476.01.78EE973 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf18.hostedemail.com (Postfix) with ESMTP id E51C61C000F for ; Thu, 3 Apr 2025 12:29:56 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=readmodwrite-com.20230601.gappssmtp.com header.s=20230601 header.b=TjzhQN50; dmarc=none; spf=none (imf18.hostedemail.com: domain of matt@readmodwrite.com has no SPF policy when checking 209.85.216.47) smtp.mailfrom=matt@readmodwrite.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743683397; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JynWWB72NrUYJsGMiQgV50eLd0vWOBT/+b5bHy2kTxI=; b=hJcaS6TY02tR2Qh0LTWlWecib44JmfQuNdfnnT2D8CTllHwLf9zBDdrHlveqj+U4MYODE2 MmFKIbf6UQ/la+dXZ9jcafqaEZFeAaO9wezmZIVhKEjID9N4x8WeGY+QxPeShp9lO7JCMU 6eooEjgZhCcFu99WQP3Gue+Us1W982c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743683397; a=rsa-sha256; cv=none; b=X7R7GtKS6qhFBYiYpU2znIbu7rUgFd9x5lqU8tBCEhPmG20TKu8d6Ik02GPWUiadStOclQ 8IpUXNGK/8hVS5tKAe0EyC0McY2MyjgEyyIL2Tv/IVKzPV0xFI05pNccsKyGZeb4T7xpah 23DvaR0nMWVotcZiYy5xVfj9rZzZcyQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=readmodwrite-com.20230601.gappssmtp.com header.s=20230601 header.b=TjzhQN50; dmarc=none; spf=none (imf18.hostedemail.com: domain of matt@readmodwrite.com has no SPF policy when checking 209.85.216.47) smtp.mailfrom=matt@readmodwrite.com Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-30332dfc821so609193a91.3 for ; Thu, 03 Apr 2025 05:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readmodwrite-com.20230601.gappssmtp.com; s=20230601; t=1743683396; x=1744288196; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JynWWB72NrUYJsGMiQgV50eLd0vWOBT/+b5bHy2kTxI=; b=TjzhQN508zQSSvMidydNiI8/Ha4oySUuhlxSEmM8npGzTAFVT1CyRXhxLBh0jQGUsW ml2sWRRjmgqk1MoGe8/4C9ZO5NR4fb8wqu/yHI6Zak24YUsmxbkMagkGkI/+JA9z8QFx xDqSARzR152HU8amLD3wFxFcflhPpG7CwetOYfX80MpmqWybbipb+nO3MEL2Kb7rKBiO VuTedET8jWzQd8U3uBt11YB01/sBH3fUlce6/Wf8F1NiuWJkMagDFz3rGcEeaJ6PolOv PJQokbMGTbqRGvBlkRrgf5UzPT5h+6RJfaMH7hIT3h+z19wYavQ0fMa/q5u/s/igNQYg irzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743683396; x=1744288196; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JynWWB72NrUYJsGMiQgV50eLd0vWOBT/+b5bHy2kTxI=; b=CpkwRoVmeMM3DqYUofy9qfpFbdvLjjdAOHqfB+ISa08Ujgks8AJqbgXhv94u3k/uFb V2QSv2e1Pp6ecd7rwcX+c8hv7gwNOyxrpK3xNOQ17vLKfMbx/xWLpQ2OWUzJfimTZcCx bPqj63zkAkPdOl0QAvnVEmCD5lef+D6mCXrJE+yxmXuwaZ/Yic+8xKXdDuZtER/jWNPS VLc3tWX2wApDxuNonoGXMrTCJ68kVOW7/JbIHya1AgONLiGQQWO+CStvItziJIsT9nOH gUxcjVaWL3ca0YNLJfG/RWf+GZwWOo6aCoaDkVLfWaOPRw8drAiNE2CAPaRsjXbS1+Y1 Kimg== X-Forwarded-Encrypted: i=1; AJvYcCUmXoWRhp1s8J28IikUaJiNgIZ0YRVuKBTAoPD3VxnaR6KlyWE5M9HyHEu0gc3tI986uWkG59arnw==@kvack.org X-Gm-Message-State: AOJu0YwOID3Da7+I3rMzj7s4uBn4JDfmHuXFxagsWBXsmwew2VURHMBy vBp5Od7LLBh61rO/a3pqOagbm6Rn/lmF5xlfJGp9xTU2kY/DqWHpSF37SDGNQL6kA7r/s/L0waQ Uferd8f2bte+AOZSwzhlOY9nlMNIbnrEaozSF/A== X-Gm-Gg: ASbGncuu32JMumBT5i4oMe3pYRJ3Gx+E8vzE9ScwyZ3mOIDweyydG3xXb+VS4vpSN5m mg/1CWTXpYBJsgRTsQRQOho95VO/CN+EhsDqgqvgvlNvDEoAJv0kQ3Gv44yLm3Rd1xw2GyjRjzv r0TNUPAU1nfvV/2pxs2rr0eYw/tdRxGkUQfX/P86JexXU= X-Google-Smtp-Source: AGHT+IEayLyncgjjwGctB0Q1Cv+cwNy95giRJK1hp6OCZnvGJSXclp9RE+2Tz4Bneyh+oUJ8WDN2IepwxlZELKH+IxQ= X-Received: by 2002:a17:90b:5483:b0:2f4:4500:bb4d with SMTP id 98e67ed59e1d1-3057cc1c871mr3596324a91.20.1743683395876; Thu, 03 Apr 2025 05:29:55 -0700 (PDT) MIME-Version: 1.0 References: <20250326105914.3803197-1-matt@readmodwrite.com> In-Reply-To: <20250326105914.3803197-1-matt@readmodwrite.com> From: Matt Fleming Date: Thu, 3 Apr 2025 13:29:44 +0100 X-Gm-Features: ATxdqUEw58AvlX_Q6xWmD0IoThd6wb6Y1DvzFiOHsKQDmm1qzfkUhri_eLGnAEw Message-ID: Subject: Re: Potential Linux Crash: WARNING in ext4_dirty_folio in Linux kernel v6.13-rc5 To: willy@infradead.org Cc: adilger.kernel@dilger.ca, akpm@linux-foundation.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, luka.2016.cs@gmail.com, tytso@mit.edu, Barry Song , kernel-team@cloudflare.com, Vlastimil Babka , Miklos Szeredi , Amir Goldstein , Dave Chinner , Qi Zheng , Roman Gushchin , Muchun Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E51C61C000F X-Stat-Signature: j5hci5wmnqo1e1nzbas7ubssnht5eequ X-Rspam-User: X-HE-Tag: 1743683396-339118 X-HE-Meta: U2FsdGVkX19+iePdke64n9T+jgKXUtFGaKAlXiEeDfb5Y+D4bZOGtXJ1CkPPOk6lt8Xexps8GgBNTW08HLZRCdC+8UOMf5B2uHkGx+vAvyxWklF6Xa38fgmvKUDh8tQKqsVoF7ljaW/EGc0IQHbcwUvMSX4vTgA09asU0WlnlmRynOOd2USWvqXZFcMrGtRQIJ6lsaxsfmsmVHdsiOtt3ywtOrlr2J0WQDTbB6WkGvcUXlhAGxbOTl62T9PDuKOsS6laHsXyFdp08Sxn3e7lT2TOPB2mCauZRfl7J5YN6AoLaSA4CMN8lE6LzKbW+OQWfaXJMtmyzNpvLZGaddQ4YCpLCr43YbfS2g39Zk1HeD7jH3LIY3wvBoF+YPnZLlRGZ2k1jMUsn9YzJFQq9nPDiMTbPkfHuTONNQEqvotRF+WtZIPdZlvTh9Y9V6jcui5NB6ld8nYSD+ZISckCLxyKgRMUUD29GEsNW7pDBWy1J5vo5OQTx+RZHE7tYGN3Iu7Sl18GXt2l4qCWrxdc/m7k+9ebB1n8LmjOgKNRM6FZqrwIW2exJ5HfIwB4Vbwe4XYHAVuPHhT9CrN9eYqGw6idZLHXJ3MkU3qz93jrog6oqdwBfR11Xmzu5zNqNwazbfP4qnKTvkeqGieenlDPd94wcWlaoJqNxP3sPnrJoZkqLuyH09mLcY4wivxff0p6A5e3bZUSCXoA7jFaxCmzDIKDXepL8r1I9LhLsiVLNEsnjUSFQcOtrNhl/wNfZ8fQ0ILInfRH8xxX3x/UAtTTHUXZ9XBQZdpUww6Y7VFkT/V81jKnkcY4aCSE/++D8y7N9YxeCuGJJRbXEqbc6hZNfejkl0DtbcnNP5vWuimdhiTNhhFdw1FBp1jjKWJDzVGhgAOqQFrannESsIKtphAhXgoBSa28IbO1NjLI5LKWwtK2Dk68u8MYN9srwRtzhRt+lotE0P2BNMKi49+/V3IRufl Oofli5lM BSXmsFIDxIhusixJPdZSmhZCKQKtJBu9D7DdrevnjtOQ03MxdfPHJyc4+xN6hH0+BlnZvVPh0Y4uy8wQqZEIizVIgoS2IDZfVBP5kcHesbOYH3tA3LLJ56jW5DfLcH88xpFEBSzYkcqOd8TgZ/97Hw4NrAXpk2xAPLpi5eSvkxDtYx4WmI75+/ApTx/yoWZ9BOz8KQnvrMvhcIQblJLfznL+zePxa0fAXCgM1cGdKq4vARWiVIiiHbKsjgBId1ThuicF0ws7lwy8tjBNA8iEez9jyjF/nk8EGp5TYR92XAIbK0B1kG0xLxVIhXUQrw9A5YybHX44EVAFhKd5lBtAKnZcpmyHsrUPIhsqsL4ciP5a1Ef9GXJikwgvtN101L7viuiciWQpOpwzLiSw1wv62PrAeAnu4mduIAfwg X-Bogosity: Ham, tests=bogofilter, spamicity=0.000164, 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 Wed, Mar 26, 2025 at 10:59=E2=80=AFAM Matt Fleming wrote: > > Hi there, > > I'm also seeing this PF_MEMALLOC WARN triggered from kswapd in 6.12.19. > > Does overlayfs need some kind of background inode reclaim support? Hey everyone, I know there was some off-list discussion last week at LSFMM, but I don't think a definite solution has been proposed for the below stacktrace. What is the shrinker API policy wrt memory allocation and I/O? Should overlayfs do something more like XFS and background reclaim to avoid GFP_NOFAIL allocations when kswapd is shrinking caches? > Call Trace: > > __alloc_pages_noprof+0x31c/0x330 > alloc_pages_mpol_noprof+0xe3/0x1d0 > folio_alloc_noprof+0x5b/0xa0 > __filemap_get_folio+0x1f3/0x380 > __getblk_slow+0xa3/0x1e0 > __ext4_get_inode_loc+0x121/0x4b0 > ext4_get_inode_loc+0x40/0xa0 > ext4_reserve_inode_write+0x39/0xc0 > __ext4_mark_inode_dirty+0x5b/0x220 > ext4_evict_inode+0x26d/0x690 > evict+0x112/0x2a0 > __dentry_kill+0x71/0x180 > dput+0xeb/0x1b0 > ovl_stack_put+0x2e/0x50 [overlay] > ovl_destroy_inode+0x3a/0x60 [overlay] > destroy_inode+0x3b/0x70 > __dentry_kill+0x71/0x180 > shrink_dentry_list+0x6b/0xe0 > prune_dcache_sb+0x56/0x80 > super_cache_scan+0x12c/0x1e0 > do_shrink_slab+0x13b/0x350 > shrink_slab+0x278/0x3a0 > shrink_node+0x328/0x880 > balance_pgdat+0x36d/0x740 > kswapd+0x1f0/0x380 > kthread+0xd2/0x100 > ret_from_fork+0x34/0x50 > ret_from_fork_asm+0x1a/0x30 >