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 051E9C433FE for ; Thu, 29 Sep 2022 13:40:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 889868D0002; Thu, 29 Sep 2022 09:40:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8130D8D0001; Thu, 29 Sep 2022 09:40:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68BE48D0002; Thu, 29 Sep 2022 09:40:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 55B738D0001 for ; Thu, 29 Sep 2022 09:40:48 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 15EB641256 for ; Thu, 29 Sep 2022 13:40:48 +0000 (UTC) X-FDA: 79965233376.08.8D1DA32 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf29.hostedemail.com (Postfix) with ESMTP id 3435E120016 for ; Thu, 29 Sep 2022 13:40:46 +0000 (UTC) Date: Thu, 29 Sep 2022 15:40:43 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1664458844; h=from:from: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; bh=NfK0YUkL249AWAAyslMOpYKFXD2PGYqlQiJvKTj2JcU=; b=RnQ9jroE/zKLkHoiGgt9TCjuOMfW3M4iqg28nlA35p1Cg5BRCwM90OQqCPcQb7QzCuC8jJ qZ/Ffiwv7GLkVZ2XiY9r7lOm/RRIA8vEhd27FoxJGpHkgHgVIWI0W1Ump23P0d/lfIfuRW NgDvCb7QIdp1RFRjKq4aMUs4zUIypXgYb8mHtLe79fARswVa/Fs827eX+M8fmeH68pdbHO uXF/o+a00ni5aREApfbsB4HJWaTaH+Va5PoCsCU482F4tDAZ0+pb4LDGSO/MQXfTRKHZTG ZNyb1QJkE7JnY+78JAi4S6Z1WVIC8ae4mbAG6hg2rgIwPegmAOFC8LEQ9jwLDA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1664458845; h=from:from: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; bh=NfK0YUkL249AWAAyslMOpYKFXD2PGYqlQiJvKTj2JcU=; b=YStHJoALb8Yto97vU6ifmSvzJ6vAOIqwr7SVNeSh1voP4qKNNFL9YDJAGeAsBt7p4ADG7o w0UPEQc42YWSWTDg== From: Sebastian Andrzej Siewior To: Vlastimil Babka Cc: syzbot , akpm@linux-foundation.org, keescook@chromium.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, mhiramat@kernel.org, rostedt@goodmis.org, syzkaller-bugs@googlegroups.com, "linux-mm@kvack.org" , Michal Hocko , Jan Kara , Amir Goldstein , Matthew Bobrowski , Linux-FSDevel , Matthew Wilcox Subject: Re: [syzbot] inconsistent lock state in kmem_cache_alloc Message-ID: References: <00000000000074b50005e997178a@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664458847; a=rsa-sha256; cv=none; b=bEtWz+5ohD3RhcLKbvC/92Z+Nj/J2COQdvyC/p8b6v4b2Bn+gHy3NjW9vEaFLhtcyIagm+ zAjQ9BaGxzzxiYEIZCJwZeYKOtB/BTAEbxd3YO2xYLlkmlq+75tFKbO4jP6lkegkiHSCII pdhfZ8JZLbtzqArlZRpXmOhvsz07BKM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=RnQ9jroE; dkim=pass header.d=linutronix.de header.s=2020e header.b=YStHJoAL; spf=pass (imf29.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664458847; 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=NfK0YUkL249AWAAyslMOpYKFXD2PGYqlQiJvKTj2JcU=; b=EmQHPVFzHqCToicU6syztVf67PiEKZ6ndcGPCwlflCRV3uWNUitgaGYyj3x+F7fOGupb6O GBulkVLeMVWrjveciDfOpkDaIMQ3W6d8XbEZGkCUQISYbVv7wqiov8yhyAn4yz7RMSlVGe 36B3Zq/pr5OrRazWOr55lESJf7X0DbU= X-Stat-Signature: gsgdstci6sq5wsuqs81dmdha3fadjt4n X-Rspamd-Queue-Id: 3435E120016 X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=RnQ9jroE; dkim=pass header.d=linutronix.de header.s=2020e header.b=YStHJoAL; spf=pass (imf29.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-Rspamd-Server: rspam01 X-HE-Tag: 1664458846-178597 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: On 2022-09-29 15:24:22 [+0200], Vlastimil Babka wrote: > I'm not fully sure what this report means but I assume it's because there= 's > a GFP_KERNEL kmalloc() allocation from softirq context? Should it perhaps > use memalloc_nofs_save() at some well defined point? my guess is =E2=80=A6 > > Call Trace: > > =E2=80=A6 > > __fs_reclaim_acquire mm/page_alloc.c:4674 [inline] > > fs_reclaim_acquire+0x115/0x160 mm/page_alloc.c:4688 > > might_alloc include/linux/sched/mm.h:271 [inline] > > slab_pre_alloc_hook mm/slab.h:700 [inline] > > slab_alloc mm/slab.c:3278 [inline] > > __kmem_cache_alloc_lru mm/slab.c:3471 [inline] > > kmem_cache_alloc+0x39/0x520 mm/slab.c:3491 > > fanotify_alloc_fid_event fs/notify/fanotify/fanotify.c:580 [inline] > > fanotify_alloc_event fs/notify/fanotify/fanotify.c:813 [inline] this sets GFP to GFP_KERNEL_ACCOUNT + (__GFP_NOFAIL || __GFP_RETRY_MAYFAIL) which contains GFP_KERNEL and > > fanotify_handle_event+0x1130/0x3f40 fs/notify/fanotify/fanotify.c:948 > > send_to_group fs/notify/fsnotify.c:360 [inline] > > fsnotify+0xafb/0x1680 fs/notify/fsnotify.c:570 > > __fsnotify_parent+0x62f/0xa60 fs/notify/fsnotify.c:230 > > fsnotify_parent include/linux/fsnotify.h:77 [inline] > > fsnotify_file include/linux/fsnotify.h:99 [inline] > > fsnotify_access include/linux/fsnotify.h:309 [inline] > > __io_complete_rw_common+0x485/0x720 io_uring/rw.c:195 > > io_complete_rw+0x1a/0x1f0 io_uring/rw.c:228 > > iomap_dio_complete_work fs/iomap/direct-io.c:144 [inline] > > iomap_dio_bio_end_io+0x438/0x5e0 fs/iomap/direct-io.c:178 > > bio_endio+0x5f9/0x780 block/bio.c:1564 > > req_bio_endio block/blk-mq.c:695 [inline] > > blk_update_request+0x3fc/0x1300 block/blk-mq.c:825 > > scsi_end_request+0x7a/0x9a0 drivers/scsi/scsi_lib.c:541 > > scsi_io_completion+0x173/0x1f70 drivers/scsi/scsi_lib.c:971 > > scsi_complete+0x122/0x3b0 drivers/scsi/scsi_lib.c:1438 > > blk_complete_reqs+0xad/0xe0 block/blk-mq.c:1022 > > __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571 > > invoke_softirq kernel/softirq.c:445 [inline] > > __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650 > > irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 > > common_interrupt+0xa9/0xc0 arch/x86/kernel/irq.c:240 > > =E2=80=A6 we originate from softirq we can't use GFP_KERNEL. This also noted here: > > BUG: sleeping function called from invalid context at include/linux/sch= ed/mm.h:274 > > in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper= /1 > > preempt_count: 101, expected: 0 > > RCU nest depth: 0, expected: 0 > > INFO: lockdep is turned off. > > Preemption disabled at: > > [<0000000000000000>] 0x0 > > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.0.0-rc6-syzkaller-00321-g10= 5a36f3694e #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS= Google 08/26/2022 > > Call Trace: > > > > __dump_stack lib/dump_stack.c:88 [inline] > > dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 > > __might_resched.cold+0x222/0x26b kernel/sched/core.c:9892 > > might_alloc include/linux/sched/mm.h:274 [inline] > > slab_pre_alloc_hook mm/slab.h:700 [inline] > > slab_alloc mm/slab.c:3278 [inline] > > __kmem_cache_alloc_lru mm/slab.c:3471 [inline] > > kmem_cache_alloc+0x381/0x520 mm/slab.c:3491 > > fanotify_alloc_fid_event fs/notify/fanotify/fanotify.c:580 [inline] > > fanotify_alloc_event fs/notify/fanotify/fanotify.c:813 [inline] > > fanotify_handle_event+0x1130/0x3f40 fs/notify/fanotify/fanotify.c:948 So either the caller needs to be put into task-context or fanotify_alloc_event() needs something like diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index cd7d09a569fff..9f6c5813f7a93 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -710,7 +710,7 @@ static struct fanotify_event *fanotify_alloc_event( __kernel_fsid_t *fsid, u32 match_mask) { struct fanotify_event *event =3D NULL; - gfp_t gfp =3D GFP_KERNEL_ACCOUNT; + gfp_t gfp =3D GFP_ATOMIC | __GFP_ACCOUNT; unsigned int fid_mode =3D FAN_GROUP_FLAG(group, FANOTIFY_FID_BITS); struct inode *id =3D fanotify_fid_inode(mask, data, data_type, dir, fid_mode); Sebastian