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 ADC1CC77B6F for ; Tue, 11 Apr 2023 14:19:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F4EF280008; Tue, 11 Apr 2023 10:19:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A56C280001; Tue, 11 Apr 2023 10:19:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26DF4280008; Tue, 11 Apr 2023 10:19:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 185C3280001 for ; Tue, 11 Apr 2023 10:19:39 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EE43AA0C7C for ; Tue, 11 Apr 2023 14:19:38 +0000 (UTC) X-FDA: 80669318436.10.A24564C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf03.hostedemail.com (Postfix) with ESMTP id CDB642000B for ; Tue, 11 Apr 2023 14:19:36 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=crdDxRaB; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=ByqMOCwo; spf=pass (imf03.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 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=1681222777; 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=BV/iOuY3tZ30InHD5r4cvxoa3TS4xAh5ueSwnmy0PUI=; b=i7YCQ1XWkrqaG40pOLSqh6xXUmtPkRZcv6i2uUwzLoauh8hNHopOITOMITcgIa13uDJsZH xpKsw5aVAPbBlCMDRJ1dQvr1d2SxBmYfdJ+mI5TsizRrZtvqts7gsAeKahhVz5kx0rwa1O CKPTg8wNdI36z21II1dXv+xR2TeQR60= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=crdDxRaB; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=ByqMOCwo; spf=pass (imf03.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681222777; a=rsa-sha256; cv=none; b=sk2YkQz+GkH5SYkjpcGHtXi5GbwgCSrJNSqmjXd7hu8yt9+m8nPB5ze2kIlgzCLcSSNgz2 31AGkiJ+pKtcRDcjjUC/XK1/eVpFGwuJOmdwYfsoi/JY7m6B68kwJ9Pm28WR3HoixOWeMU cmr2eyV74TqwsSVw/kihwjxlHoEaA5c= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 08067219D4; Tue, 11 Apr 2023 14:19:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1681222775; 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=BV/iOuY3tZ30InHD5r4cvxoa3TS4xAh5ueSwnmy0PUI=; b=crdDxRaBGzyB3zB0DL1Kg4gQ1WCo2jvVvFNkRIhz3KimP4omI5TwRwL/nAXz3tG3c2ElZc jhDHt5N1fZaPOP7+25uTcrsykzfJbq6Q0jzZjsIvggDb9sl/oNRkveFD80krveiwNWe03g DzyIz/IoTwiWe6y7KuYLg02GCRdkgh4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1681222775; 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=BV/iOuY3tZ30InHD5r4cvxoa3TS4xAh5ueSwnmy0PUI=; b=ByqMOCwojdA9dsMWcuK6BbwAOTKrFQ4DgFdf1zXapgeMlAX555Mddlr73GFZo2pSdG3ZaV 9ksEujjGUUXvAqCA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9C0BF13638; Tue, 11 Apr 2023 14:19:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id CmiHJXZsNWSQVAAAMHmgww (envelope-from ); Tue, 11 Apr 2023 14:19:34 +0000 Message-ID: Date: Tue, 11 Apr 2023 16:19:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] mm: slub: annotate kmem_cache_node->list_lock as raw_spinlock Content-Language: en-US To: Qi Zheng , 42.hyeyoo@gmail.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, iamjoonsoo.kim@lge.com, rientjes@google.com, penberg@kernel.org, cl@linux.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhao Gongyi , Sebastian Andrzej Siewior , Thomas Gleixner , RCU , "Paul E . McKenney" References: <20230411130854.46795-1-zhengqi.arch@bytedance.com> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: CDB642000B X-Stat-Signature: kuy6siw7tn8gn7n6ycwhteti8yq1ydsd X-HE-Tag: 1681222776-771592 X-HE-Meta: U2FsdGVkX1/anCgdw2og6yA0yShaPKgB6f6xpRcTzdzhP+KsX7lJPHB0aQet66mQsfkU47hPyHry1Zqcc+uqFUZERHmTUQ1C85SjzXaOcSBUOYodbCGDRLD0GzoGbVcUmHwTQslsNt0Cxk3CQG7u+kpg6/wLfA4g/4eP2DFlRfkIE2cbqxP9SFsf1CfrDn7J7YU7RXLioxfpEX19+afyffuo0Ij/aPeOIgW6v8F188JtRhpM6revlP+8lXAf6jjZTDHVp+vNKoW8UVZp/7Da9TSmL24sTQ4iYOFE1JFeAVmNLaeO6HKBzOcev+27VRMePn4CnTb/3meY1v0aX+3rSyOr6FO4LA4N6wZl0ZLWi+YGZf/Ug1LNqlGSPJZPbVozcDKmynohYZfSGxu1bvOJoJiLoqQs/1FsU/tSDuQXcK9JBCqB3qPhZUZfr90MQO4LzhFAjZ7eLCpZmYIIL2CvJlkJokY7Dn2e1BKu6kxOP1JNdmN90ekobPdf1FChoE7JBwyDqoB1mxijEF4bX6CM5b9v7302eFkGBEGTYCpIGNfq7qqzyOPkzvaNe3sXmfq1QFJ1d/+vsxOA8Gf8+ybZoaJUYnUOPbGkiCey+rfmuvetfBd+A9fbGLKdfCtKXoZmzcKaEdSRBIMjPu/JSKlzETpi38x3/9kUdc1JJPNWQHLGAft99aU632ibKKXMMtvMsAUrVQPJ/0RN/Q8VoCh/SJMfwQA0J3BzJqespvVCaYHYLV/HiImpFg/V9XtaqgYw14K7PlJugfAUA3gT7ALsvddcQ2prc9mXUbsiD3GSQwNk7ktKNUCQHiHpxGiFCb3Q8RbIRsnPOCgJ3lci+kyizPz713YB02OqNqDECstB5bweis45k8LzTbMTsgezlLokFKllS3PlPY2Gu5bhueADqHYJOVV8glxjAYn54BNWA09DzlQETxItOB/rxVVR1062p/jsunngVPRVIUVEF+D /DFJTcwB +43WknUAUG9lGdnewO2N6JA0KNU0VDwbkqLdY36rihPoc8T9AFi3/Pupp/MV71x/sgKnVFEu3rGCpNVQCjeGCkHOU8zJmpPwRSoy/JxeoSn5OaSa+z3q5QDA67vBDLzDxXWDTH1vi7ucOzc9mkZp/SLv5gGu4Cq7Ao5/Uvtx161F1s0ZuBzKOcLzQEV/k9sZQKDEd1qqEaR0vyiA3Z/+wjlo6Y0+2te9+2+cXJn8nMiNKlUFvmNvAuobldFmVugZSdyDj28xeNJt0mEpC14OjdVMSj/vExNK+c84FUfglXk7O67N7icnfbhoPsrHHFJiu+LQCCmlJXhrAcL2GLs0lKgeXIQ== 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 4/11/23 16:08, Qi Zheng wrote: > > > On 2023/4/11 21:40, Vlastimil Babka wrote: >> On 4/11/23 15:08, Qi Zheng wrote: >>> The list_lock can be held in the critical section of >>> raw_spinlock, and then lockdep will complain about it >>> like below: >>> >>> ============================= >>> [ BUG: Invalid wait context ] >>> 6.3.0-rc6-next-20230411 #7 Not tainted >>> ----------------------------- >>> swapper/0/1 is trying to lock: >>> ffff888100055418 (&n->list_lock){....}-{3:3}, at: ___slab_alloc+0x73d/0x1330 >>> other info that might help us debug this: >>> context-{5:5} >>> 2 locks held by swapper/0/1: >>> #0: ffffffff824e8160 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic+0x22/0x2d0 >>> #1: ffff888136bede50 (&ACCESS_PRIVATE(rtpcp, lock)){....}-{2:2}, at: cblist_init_generic+0x232/0x2d0 >>> stack backtrace: >>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc6-next-20230411 #7 >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 >>> Call Trace: >>> >>> dump_stack_lvl+0x77/0xc0 >>> __lock_acquire+0xa65/0x2950 >>> ? arch_stack_walk+0x65/0xf0 >>> ? arch_stack_walk+0x65/0xf0 >>> ? unwind_next_frame+0x602/0x8d0 >>> lock_acquire+0xe0/0x300 >>> ? ___slab_alloc+0x73d/0x1330 >>> ? find_usage_forwards+0x39/0x50 >>> ? check_irq_usage+0x162/0xa70 >>> ? __bfs+0x10c/0x2c0 >>> _raw_spin_lock_irqsave+0x4f/0x90 >>> ? ___slab_alloc+0x73d/0x1330 >>> ___slab_alloc+0x73d/0x1330 >>> ? fill_pool+0x16b/0x2a0 >>> ? look_up_lock_class+0x5d/0x160 >>> ? register_lock_class+0x48/0x500 >>> ? __lock_acquire+0xabc/0x2950 >>> ? fill_pool+0x16b/0x2a0 >>> kmem_cache_alloc+0x358/0x3b0 >>> ? __lock_acquire+0xabc/0x2950 >>> fill_pool+0x16b/0x2a0 >>> ? __debug_object_init+0x292/0x560 >>> ? lock_acquire+0xe0/0x300 >>> ? cblist_init_generic+0x232/0x2d0 >>> __debug_object_init+0x2c/0x560 >>> cblist_init_generic+0x147/0x2d0 >>> rcu_init_tasks_generic+0x15/0x190 >>> kernel_init_freeable+0x6e/0x3e0 >>> ? rest_init+0x1e0/0x1e0 >>> kernel_init+0x1b/0x1d0 >>> ? rest_init+0x1e0/0x1e0 >>> ret_from_fork+0x1f/0x30 >>> >>> >>> The fill_pool() can only be called in the !PREEMPT_RT kernel >>> or in the preemptible context of the PREEMPT_RT kernel, so >>> the above warning is not a real issue, but it's better to >>> annotate kmem_cache_node->list_lock as raw_spinlock to get >>> rid of such issue. >> >> + CC some RT and RCU people > > Thanks. > >> >> AFAIK raw_spinlock is not just an annotation, but on RT it changes the >> implementation from preemptible mutex to actual spin lock, so it would be > > Yeah. > >> rather unfortunate to do that for a spurious warning. Can it be somehow >> fixed in a better way? > > It's indeed unfortunate for the warning in the commit message. But > functions like kmem_cache_alloc(GFP_ATOMIC) may indeed be called > in the critical section of raw_spinlock or in the hardirq context, which Hmm, I thought they may not, actually. > will cause problem in the PREEMPT_RT kernel. So I still think it is > reasonable to convert kmem_cache_node->list_lock to raw_spinlock type. It wouldn't be the complete solution anyway. Once we allow even a GFP_ATOMIC slab allocation for such context, it means also page allocation can happen to refill the slabs, so lockdep will eventually complain about zone->lock, and who knows what else. > In addition, there are many fix patches for this kind of warning in the > git log, so I also think there should be a general and better solution. :) Maybe, but given above, I doubt it's this one. > >> >