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 A6F0CC83013 for ; Wed, 2 Jul 2025 07:29:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 15B6C6B00B0; Wed, 2 Jul 2025 03:29:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 134936B00B4; Wed, 2 Jul 2025 03:29:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 048FA6B00B8; Wed, 2 Jul 2025 03:29:09 -0400 (EDT) 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 E849B6B00B0 for ; Wed, 2 Jul 2025 03:29:09 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BE56F1D8852 for ; Wed, 2 Jul 2025 07:29:09 +0000 (UTC) X-FDA: 83618498418.02.BA8CD66 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf05.hostedemail.com (Postfix) with ESMTP id 6AA35100002 for ; Wed, 2 Jul 2025 07:29:07 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=XiLMRqTq; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=O1aNKbuL; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=XiLMRqTq; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=O1aNKbuL; spf=pass (imf05.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751441347; 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=lVIsBl9hllwNnK2RPVGCxz20gNq3g7ebI1tf7GBZSuw=; b=jnek1iGkHoblbM+fNhu+ikLUrOQ/afX2rY+hLEJlb7N0nuk+bV9DT1TkBsPnLSP/wNhpW7 zWDr6f49W9hiMEsGa8VK7p3UqdUyIshmkIWVfEe0ANyoXfy9PO8vD2K/S+EPvoyph25+WI lCKl4Yn/iF1ecvf2RneYfGdh23mX4rQ= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=XiLMRqTq; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=O1aNKbuL; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=XiLMRqTq; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=O1aNKbuL; spf=pass (imf05.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751441347; a=rsa-sha256; cv=none; b=MPh10iYj5Un0R2JY/3hg9b3v1taKv4PqnsPMSZUtJXKp5fDm2ANVm8smAfwh/OgPGckg95 W4PG3RRLoIp/4184K/PSAiKQqbXxj2nJYM3Rnur2TWlFlvwhfXdTPKuF/jqiv7eZ71QUw3 MLRvGUitAFUCy7jwl6XdYqlwoaDCsV0= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B417F1F445; Wed, 2 Jul 2025 07:29:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1751441345; h=from:from:reply-to: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; bh=lVIsBl9hllwNnK2RPVGCxz20gNq3g7ebI1tf7GBZSuw=; b=XiLMRqTqr/R+laACxUArPADJvhuczPIpV8BIM/OFa04GcQAJ5bKHB+s9KwpHmLkoGUTIJe dpqvkxW3xoGTM8EVjIF4BQGpLGIyiVFQHRVdgvjXTufa2tV5uo+BflkguvRafAIh5CA8WV 05yu8ea8XgNV8OUizXg/g+SZgDpyMPA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1751441345; h=from:from:reply-to: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; bh=lVIsBl9hllwNnK2RPVGCxz20gNq3g7ebI1tf7GBZSuw=; b=O1aNKbuLz7uO3z9xmridSpDFKfIzEEsNMTZyUI/55JHCpN7yDdH+lVC7BxN6L8hBnRjls7 0NDRNSWvkdxjH1Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1751441345; h=from:from:reply-to: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; bh=lVIsBl9hllwNnK2RPVGCxz20gNq3g7ebI1tf7GBZSuw=; b=XiLMRqTqr/R+laACxUArPADJvhuczPIpV8BIM/OFa04GcQAJ5bKHB+s9KwpHmLkoGUTIJe dpqvkxW3xoGTM8EVjIF4BQGpLGIyiVFQHRVdgvjXTufa2tV5uo+BflkguvRafAIh5CA8WV 05yu8ea8XgNV8OUizXg/g+SZgDpyMPA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1751441345; h=from:from:reply-to: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; bh=lVIsBl9hllwNnK2RPVGCxz20gNq3g7ebI1tf7GBZSuw=; b=O1aNKbuLz7uO3z9xmridSpDFKfIzEEsNMTZyUI/55JHCpN7yDdH+lVC7BxN6L8hBnRjls7 0NDRNSWvkdxjH1Bw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1A0CF1369C; Wed, 2 Jul 2025 07:29:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id VtfvBMHfZGiuOwAAD6G6ig (envelope-from ); Wed, 02 Jul 2025 07:29:05 +0000 Message-ID: <630b4379-751a-4bf1-a249-f2e051ec77d6@suse.cz> Date: Wed, 2 Jul 2025 09:30:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [syzbot] [mm?] WARNING in xfs_init_fs_context To: Tetsuo Handa , Zi Yan , Barry Song , Carlos Maiolino , linux-xfs@vger.kernel.org, Dave Chinner Cc: syzbot , akpm@linux-foundation.org, apopple@nvidia.com, byungchul@sk.com, david@redhat.com, gourry@gourry.net, joshua.hahnjy@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, matthew.brost@intel.com, rakie.kim@sk.com, syzkaller-bugs@googlegroups.com, ying.huang@linux.alibaba.com, Harry Yoo , Michal Hocko , Matthew Wilcox References: <6861c281.a70a0220.3b7e22.0ab8.GAE@google.com> <1921ec99-7abb-42f1-a56b-d1f0f5bc1377@I-love.SAKURA.ne.jp> Content-Language: en-US From: Vlastimil Babka In-Reply-To: <1921ec99-7abb-42f1-a56b-d1f0f5bc1377@I-love.SAKURA.ne.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6AA35100002 X-Stat-Signature: 3yq5ykwtshuz74jiqhzqkzt74earysph X-HE-Tag: 1751441347-556833 X-HE-Meta: U2FsdGVkX1+2DLZ2TGiaovt9suU9hOdG9Y8q9mW7agd3bJhEbNgsZ/TxqE+r4txVocMbPCU4q1UUIpCIqX/tya1ePEsrN3Q7Iow9LOeA3nDtfbMDvjLeXW0DcZCFALFgJa9Y6kgnaTSXaF2Aa66tau+XquV0iVESiQpM1rmEdo/Q9JdmxQvx5y76+jsBzuohHqxm/ouvHKXXYHB4VAS/u+1ymof/hGqNjySw88moU3qkyq/ueMOyhmYPBZEv4Qt0LvI9KORI187Xd9Ga7+fPsoM5cf6TB8+9Rf+U8kQn/G/VBEL6G9al8gpI5JPTCqYYK0DJrhQ3llwRXCrnx//q/ECxHKx/Lym/BWcOD/zFEJcu22Xh9hCznhIydiJ1qne7ZkUlXcePfXEeD/dQ75yusK3qHnUDXqMfBPn3+Xu/w9cO5h/Ybb5g5C75kpSaW7WgW0kAXmQmsiNyRlwDbHEYB0wKqZ1mSd3Hmfw5nF2PlCspDzRc4Ibl1lLaWLwEXPIT6+LQ9lAqJviqzuCNYdeELLZ7eyVGkeYPX4Y0OHbWXHhcBuTv53ojWraUW+BlzPsQMnKtThNYAiaNncdq6TgM2ljSV2zq4Eng0Zkux2cie02sK9cta7RMiNP3D0vql8zCNWxsne7oop1M9MYbCR/QWDFKTTeG7XuRv5+iwrU2VF0dSI48hpsXlQ1iGJh+8Uf1IcsJdksLY+1IgTY9vHHtD53h24WJuKMKVx+DatqANWAhQvOWFbWHgz0kDESWJunI5Zt3L24sC3kD5MbuE88dZprExpVc5Xu6hsH57/cK2rOLpSpxixm1H0zmAg5shNoiylK+x3vgK3f5otMZLh2h3hOraq6E5X10GSa4rTxvMM8ZquowRCli8HXiqswSUxTV7r6OGoe1k4q7iyUDOeBkU/r1rxxQhJDZJJukrmiiEinTvvvy6zsvh4IDBUCfvaZqir6yj4QQYiV4MpG7DsQ e9J9jHpm mA+IWYKEEJs4gCuS/Wny50JhYZo7TTmKTo/FX0KR1YVw0iD1PuIK3MfzTcxNo5xoY/nbpqeLoiDycLcAixZ4+mcTs0pBSvjt2zy0ja0gdtYdHZi8+gUKx03MCXokIS+MHKXVdeM07vyNc6G83qEFLQFPEvPySgYiqNQsg7VtW7QyXWD7WsLZ2bnh/Lb/SZYrc9mYuvphV9IT5ILtlWrMUzniLOlaTQIlSrvLJxVAAGC6tbvAO+qvaAqy3F339nJeaOGQCsPqdEapY3ctxfkyLtrJeb7wpJ8pUCOAs5uoTo04nnKSjEz8hZ941Wjlqwd/Gm2x2ztHcmqnfWjVs/DvqKC/tUveiex/DXu4G90zjPFeU5JaGAGUvT1f35oyVWTeMtX/54Ke6C7wXj7tkgTWcW3LrUD0eG5y8f13enkgNQ4tOm6DiP+SMUfUkwIa9UKaniPwlgZW0NPcpMOLkrwyCFxQa7jDcvPWkROYI45sAJsO8m7uYuxXuRBPmp29VpCwZAa6ybgbFPFTtRW6zP6NCzhREHQ== 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: List-Subscribe: List-Unsubscribe: +CC xfs and few more On 7/2/25 3:41 AM, Tetsuo Handa wrote: > On 2025/07/02 0:01, Zi Yan wrote: >>> __alloc_frozen_pages_noprof+0x319/0x370 mm/page_alloc.c:4972 >>> alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2419 >>> alloc_slab_page mm/slub.c:2451 [inline] >>> allocate_slab+0xe2/0x3b0 mm/slub.c:2627 >>> new_slab mm/slub.c:2673 [inline] >> >> new_slab() allows __GFP_NOFAIL, since GFP_RECLAIM_MASK has it. >> In allocate_slab(), the first allocation without __GFP_NOFAIL >> failed, the retry used __GFP_NOFAIL but kmem_cache order >> was greater than 1, which led to the warning above. >> >> Maybe allocate_slab() should just fail when kmem_cache >> order is too big and first trial fails? I am no expert, >> so add Vlastimil for help. Thanks Zi. Slab shouldn't fail with __GFP_NOFAIL, that would only lead to subsystems like xfs to reintroduce their own forever retrying wrappers again. I think it's going the best it can for the fallback attempt by using the minimum order, so the warning will never happen due to the calculated optimal order being too large, but only if the kmalloc()/kmem_cache_alloc() requested/object size is too large itself. Hm but perhaps enabling slab_debug can inflate it over the threshold, is it the case here? I think in that rare case we could convert such fallback allocations to large kmalloc to avoid adding the debugging overhead - we can't easily create an individual slab page without the debugging layout for a kmalloc cache with debugging enabled. >> Barry, who added the nofail >> warning is cc’d. Barry's commit 903edea6c53f0 reorganized the warnings, but it existed already long before. > Indeed. In allocate_slab(struct kmem_cache *s, gfp_t flags, int node), > > /* > * Let the initial higher-order allocation fail under memory pressure > * so we fall-back to the minimum order allocation. > */ > alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL; > if ((alloc_gfp & __GFP_DIRECT_RECLAIM) && oo_order(oo) > oo_order(s->min)) > alloc_gfp = (alloc_gfp | __GFP_NOMEMALLOC) & ~__GFP_RECLAIM; > > slab = alloc_slab_page(alloc_gfp, node, oo); > if (unlikely(!slab)) { > oo = s->min; > alloc_gfp = flags; > /* > * Allocation may have failed due to fragmentation. > * Try a lower order alloc if possible > */ > slab = alloc_slab_page(alloc_gfp, node, oo); > > __GFP_NOFAIL needs to be dropped unless s->min is either 0 or 1. No, that would violate __GFP_NOFAIL semantics. > > if (unlikely(!slab)) > return NULL; > stat(s, ORDER_FALLBACK); > } > > > > By the way, why is xfs_init_fs_context() using __GFP_NOFAIL ? > > mp = kzalloc(sizeof(struct xfs_mount), GFP_KERNEL | __GFP_NOFAIL); > if (!mp) > return -ENOMEM; > > This looks an allocation attempt which can fail safely. Indeed. Dave Chinner's commit f078d4ea82760 ("xfs: convert kmem_alloc() to kmalloc()") dropped the xfs wrapper. This allocation didn't use KM_MAYFAIL so it got __GFP_NOFAIL. The commit mentions this high-order nofail issue for another allocation site that had to use xlog_kvmalloc(). I think either this allocation really can fail as the code (return -ENOMEM) suggests and thus can drop __GFP_NOFAIL, or it can use kvmalloc() - I think the wrapper for that can be removed now too after the discussion in [1] resulted in commit 46459154f997 ("mm: kvmalloc: make kmalloc fast path real fast path"). [1] https://lore.kernel.org/all/Z_XI6vBE8v_cIhjZ@dread.disaster.area/