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 AE2ADC7619A for ; Thu, 13 Apr 2023 00:24:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 080236B0072; Wed, 12 Apr 2023 20:24:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0089E6B0074; Wed, 12 Apr 2023 20:24:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEB85900002; Wed, 12 Apr 2023 20:24:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CBD4A6B0072 for ; Wed, 12 Apr 2023 20:24:34 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9848D402B7 for ; Thu, 13 Apr 2023 00:24:34 +0000 (UTC) X-FDA: 80674471668.27.BF91524 Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf27.hostedemail.com (Postfix) with ESMTP id CEF6A4000D for ; Thu, 13 Apr 2023 00:24:31 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b="rtY0/9Ot"; spf=pass (imf27.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.128.172 as permitted sender) smtp.mailfrom=joel@joelfernandes.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681345471; 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=Wtul3Z8jJEzUyTGyM60eqK7vbLWh1bkMyVJkOssHu7M=; b=Qk1WckSvwgc/+V/aRMoST/KIev4fCHk0IbICSj9pHu16qD3avFZ1pHpbIdidFcaz2wehOt bZMwXZFF4n7NB0EL3sA3ghnLABBMR/XHX9byFIbG6pDrAfHTfb8df7Wnei/oiB63b+Smo5 U83x37aFcUhnkKcL4MJL70aTuPXaVWg= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b="rtY0/9Ot"; spf=pass (imf27.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.128.172 as permitted sender) smtp.mailfrom=joel@joelfernandes.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681345471; a=rsa-sha256; cv=none; b=iukrJ1ynxl0c+jUV78HpQZVl/5Cu1TMphUhDTp6Qcqz8YdFtfVN/YQT1GSV579sAk147tR gBmlaMpYLTN6xV4kXwTHQWi63fDsm+8+TAxdjkXCPE0XoEG00PQYro9wqcxEo6xHhzfZmC Lo3AzOmRsT7Wqx8mb6dQL5lTkceS8Oo= Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-54ee0b73e08so254540427b3.0 for ; Wed, 12 Apr 2023 17:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1681345471; 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=Wtul3Z8jJEzUyTGyM60eqK7vbLWh1bkMyVJkOssHu7M=; b=rtY0/9OtcurYPtYIapuV/k4bBgvp1yNBP3UXLU61ovIOF9y/ROGOEKmEANW7euSGJg p8Gv5AMujfvSmbRylD2GcuNzaksfjuhHh7EDCBsdt4YgEU9kLOTOIUGgeMbMYdx66xt6 BaywR9zxv7ykjNxurW+lI3iy/ZEH5802jtMck= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681345471; 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=Wtul3Z8jJEzUyTGyM60eqK7vbLWh1bkMyVJkOssHu7M=; b=eUxmB3ue30EF4cJpZh5DMoGYGcCQkeDRB/Fna99Isf/uK+OcAh6jU1eDGuGYPujbzD ZgikvXe6g6go3A3gXQsiQ3dQZwUCBsuzw43U2l3rkHSnYJOMqgPvluGa8kXDfnJigxbu hjES5RdvC0hpBJk/9xGo+7jCYYuwtLrPtAb54VbZBIl3snJ1RjktTHzDfZI5EIRkUOWj EWKMKs37SQDHpKiz1ENTOKsmCZN97t1fCRDBoioD6mgrhcR+HDmBTL9c1P+MVb2kUfa5 DfryBHy1+0iM4AdExesJoFwxmoxlSXw14eBtV4rwDdIY2NsEXe1nVr6x2nkjim4kZxFe k3Qg== X-Gm-Message-State: AAQBX9dmrGWWKvzmpZYQqLkp+aoq4KGyA9vA7q3XbvOFrJujJayVPJWA W56UiI5j6xqzodPZNWXhf6s1wx89WJcyAcJNNzjUvQ== X-Google-Smtp-Source: AKy350YYq2bMN8DqYdnl/ogFagoOINRW2F2OuIwv3C+B33qpvClV8Jz3MQJBdHaaQsG8/zSEzfvW84GkRp/APU3TB+s= X-Received: by 2002:a81:ef02:0:b0:545:883a:544d with SMTP id o2-20020a81ef02000000b00545883a544dmr224210ywm.9.1681345470692; Wed, 12 Apr 2023 17:24:30 -0700 (PDT) MIME-Version: 1.0 References: <20230411130854.46795-1-zhengqi.arch@bytedance.com> <932bf921-a076-e166-4f95-1adb24d544cf@bytedance.com> In-Reply-To: From: Joel Fernandes Date: Wed, 12 Apr 2023 20:24:19 -0400 Message-ID: Subject: Re: [PATCH] mm: slub: annotate kmem_cache_node->list_lock as raw_spinlock To: Qi Zheng , Steven Rostedt Cc: "Zhang, Qiang1" , Boqun Feng , Vlastimil Babka , "42.hyeyoo@gmail.com" <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" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Zhao Gongyi , Sebastian Andrzej Siewior , Thomas Gleixner , RCU , "Paul E . McKenney" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 59jgws9jcy8f351ijqexjxfmeorbo5c1 X-Rspamd-Queue-Id: CEF6A4000D X-HE-Tag: 1681345471-222165 X-HE-Meta: U2FsdGVkX1+fKiM5oPKMtxii79Le/swgxjvR4iDndicgCrZtZsNOJb1KScABYpW3LXjPvC8E1/HrwfMSUrTtLsIMXqoeecd67FDv9jbCHSHuPkoCWmARCzuUeKaqvSFOMtaGd+gDWXgVBsKtfZm5JSMEO7MQRcmhUA06cI2l0XTAd1AXWS/Gy48Q511xVFcyOaO0o9dCavsQAsKdtT6USTK23P+LZziltqDh2GQzikheot8DFnCTiec/PZKH+8pbbIjpntBFkXQAbnXh7AvpjfigCHA/CoAnCu8Arv4l5Tk/FT/dKcbUftqTNBFYaRnh+UIEwXZt46dYSNddTT79xOmvML1c7UWnFf5m5r+rAu9vyI4rmFex5oPw4IFEkD5WKXP038aML0etTuNzto9qsj0pydxh4iU0eBUZzJVosXK6kHU3iRejTtZ0bR6lTUERgtDTjgvf83EIwkCp1LjVvXS6ztKxCkaBuAqnbjQa5d7Z4iVNsaIivUb8MjFGrhrb8Wyrl/6XTjhtO0gdFsUTceLhxQK3T6wAyefMoC+STVi1l+/mhL0DBGAPqKALAZJHLtld+C8CmYxpJ5nQm7E3Y+meXce2jzAgvuPRW2umeoifznnQtH4YpKDSTE3JeUKhG9LjpUoD86vhmQ4vNpnaL1YKFGEHq6JtWPn6p0ISXawAwld5DIQMGszPNCKMelxoeRMqpiWBYUhwoyFe+bf1jOI5zOv7W1QI7fqWk/NlBxI+Jg0oJLBhovrLJkZ3Gzq+J8VQQ2F9AbruWUOEjB9ER3u2C2YhguYfH79SfiolnGhdZPkpGeOe3FaWlA1ZpPS7prOlf8Y6WRfiOjYkWHTKTdlJWW7mycHsMKWjUG5Ywtb2GBSWdz1WBW8fd6McVkyfyPuklY+4RoFkbpfkgGSI5lRy+t4C4nHFZYgf17cPjWCBu3oc0NRTtDOr/Q6lC9KnlQQNH5O9Jaio6uDnmoq IoEOg1ca z1TmRS60t+bdXxUzq/Eh4wistrlINDlRKxVJeiJOsBJPKsjEBDm3vjTSYugG3/XjuJ274YLe6bXpnYlCrm6m1nspdd3QlbS5aDxZb3ZoTVPOgWYn5YMzErPUOp3BKZSsfP6JwIZUZUpn6v/5E5XBryDAenVek8XWvvpdvmUVQ2JYEMWHvCENaFShO4zQpUyoodw4isfpYIhjnSagHAfrIuxldEDKwvfero+XmhsPgwiVeT5yrs/Uqf0zKYRCiE4v1Aal5vSPZNogAMJajxgugAEL40eV+4LSnTn8TCZUAQQkbRYVMLs8h38yAL13zVdaaN92dKjxtI51AYTa0DP1FO1OpTD4UDllUBihN3ysJZV4emR5MdjB4ejszy4CQlBoKOv1mNhBGGUN1QV4d7sQ/ab/P3LaulR1hwDhSRuaYWf8qk4ycS9bNwpEfpztwv4HbZr1/JO8DxkjiOfZLtohP4q/hTw== 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 Wed, Apr 12, 2023 at 2:57=E2=80=AFAM Qi Zheng wrote: > > > > On 2023/4/12 14:44, Zhang, Qiang1 wrote: [..] > > Maybe no need to convert ->list_lock to raw_spinlock. > > > > --- a/lib/debugobjects.c > > +++ b/lib/debugobjects.c > > @@ -562,10 +562,10 @@ __debug_object_init(void *addr, const struct debu= g_obj_descr *descr, int onstack > > unsigned long flags; > > > > /* > > - * On RT enabled kernels the pool refill must happen in preempt= ible > > + * The pool refill must happen in preemptible > > * context: > > */ > > - if (!IS_ENABLED(CONFIG_PREEMPT_RT) || preemptible()) > > + if (preemptible()) > > fill_pool(); > > > > db =3D get_bucket((unsigned long) addr); > > Ah, this does fix the warning I was encountered! Actually fill_pool() should be safe to call on !CONFIG_PREEMPT_RT kernels as it is GFP_ATOMIC, however with the above change, that goes away just to satisfy a false-positive report. Because now all !preemptible() sections on !CONFIG_PREEMPT_RT kernels cannot call fill_pool(), right? So you will not end up filling the pool when it is safe to do so? I think it would be better to fix PROVE_LOCKING / CONFIG_PREEMPT_RT instead of degrading !CONFIG_PREEMPT_RT just to satisfy a false-positive report. +Steven Rostedt as well. thanks, - Joel > > > > > > > > > Thanks > > Zqiang > > > >> > >> > >> Regards, > >> Boqun > >> > >>>> > >>>> 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, w= hich > >>> > >>> 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 typ= e. > >>> > >>> 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 h= appen > >>> to refill the slabs, so lockdep will eventually complain about zone->= lock, > >>> and who knows what else. > >> > >> Oh, indeed. :( > >> > >>> > >>>> 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 soluti= on. :) > >>> > >>> Maybe, but given above, I doubt it's this one. > >>> > >>>> > >>>>> > >>>> > >>> > >> > >> -- > >> Thanks, > >> Qi > > -- > Thanks, > Qi