Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp14491998rwb; Mon, 28 Nov 2022 01:27:19 -0800 (PST) X-Google-Smtp-Source: AA0mqf5uiUKYgVWR+hPGMinZVGFEpp6k1WF+ORuw4rKGYQHGwFKNIZbPeJsNqAESRuUQ0/JgttMd X-Received: by 2002:aa7:cd8d:0:b0:463:19ca:a573 with SMTP id x13-20020aa7cd8d000000b0046319caa573mr45942519edv.31.1669627639618; Mon, 28 Nov 2022 01:27:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669627639; cv=none; d=google.com; s=arc-20160816; b=GmsO0K1rt/9Vdkk+hZjGBsUfpAFre+5x9tTuKUXy/hAQCATa0WpvYLIMCIlPme1nTO NJ6+Wz84p9AgG5jaGdPy3QGQwe1WM3SOgJXMnNCahToTrPoxgluFO1awpPItjAXDPyqC AU9KJnBgVsHm5W1Y/tplTLcDDqESqdgYcx3a3KUbt47J2qyW9gNp/W1y6x3xpLq6MFEr ozvtoPNPtRIKjaylsLiYRdrDvTouPhN5Atgsl27bE8MxL8sY3LQMANK4v9rTMOvgRULr y1GuincEB7cyEpf8qrqmdfmU3MXQGLR2wY39lxgjbGTwGOqAWb2h1q4I0DGoZ5WiNDQc 8GHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=a4rJKN0rzxMtYPVFH3X1SCLXScB5NZ3FCnauSXVVZMg=; b=0cLOd6qwtWrk/ibvYxViO1BfoySuWbq9ZXw3cj3Ht8z7Ujmps1/s+Af9Ha6K5OJ87p 37jR9ZCskkrcBBC8ivgcHeVNep0l0FDC5NRbM0fkcB0li6CU//ObVN+WCzYmrf+f5mPD 2Mzpkeg5+WwoNN8JqPSkGCDktSdQ/SRk0qFo6cZ2zvWrXw99Sx9UdFlzttJo+ZvtBwrc OAPrOPL+5RWkGsAHKPZx6mhVUKSM2HuBL8/PI1nt/hGWzxljrQzVp45vjwC26ikbP/L9 UDXd1e8BmVBJNq79lchh+IwqcJ+dhCwc2lsAGxZe88u2x2DqfgcDRJZs4IEoiJH1dKTe /cyA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g16-20020a056402321000b0046af5c0f32asi4583582eda.37.2022.11.28.01.26.59; Mon, 28 Nov 2022 01:27:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230330AbiK1JOF (ORCPT + 84 others); Mon, 28 Nov 2022 04:14:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229758AbiK1JNt (ORCPT ); Mon, 28 Nov 2022 04:13:49 -0500 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72ACA186C2; Mon, 28 Nov 2022 01:13:46 -0800 (PST) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.56]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4NLKSH1MDLzJnwd; Mon, 28 Nov 2022 17:10:23 +0800 (CST) Received: from dggpemm500006.china.huawei.com (7.185.36.236) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 28 Nov 2022 17:13:44 +0800 Received: from [10.174.178.55] (10.174.178.55) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 28 Nov 2022 17:13:43 +0800 Subject: Re: [PATCH v3] mm: Make vmalloc_dump_obj() call in clean context To: "Zhang, Qiang1" , "paulmck@kernel.org" , "akpm@linux-foundation.org" , "frederic@kernel.org" , "joel@joelfernandes.org" CC: "rcu@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20221118003441.3980437-1-qiang1.zhang@intel.com> From: "Leizhen (ThunderTown)" Message-ID: <5ab0aa1c-97d7-6944-2cb0-524990687dd4@huawei.com> Date: Mon, 28 Nov 2022 17:13:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.55] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/11/28 16:33, Zhang, Qiang1 wrote: > On 2022/11/23 7:05, Zhang, Qiang1 wrote: >> >> Gently ping ???? >> >> Thanks >> Zqiang >> >>> Currently, the mem_dump_obj() is invoked in call_rcu(), the >>> call_rcu() is maybe invoked in non-preemptive code segment, for >>> object allocated from vmalloc(), the following scenarios may occur: >>> >>> CPU 0 >>> tasks context >>> spin_lock(&vmap_area_lock) >>> Interrupt context >>> call_rcu() >>> mem_dump_obj >>> vmalloc_dump_obj >>> spin_lock(&vmap_area_lock) <--deadlock >>> >>> and for PREEMPT-RT kernel, the spinlock will convert to sleepable >>> lock, so the vmap_area_lock spinlock not allowed to get in >>> non-preemptive code segment. therefore, this commit make the >>> vmalloc_dump_obj() call in a clean context. >>> >>> Signed-off-by: Zqiang >>> --- >>> v1->v2: >>> add IS_ENABLED(CONFIG_PREEMPT_RT) check. >>> v2->v3: >>> change commit message and add some comment. >>> >>> mm/util.c | 4 +++- >>> mm/vmalloc.c | 25 +++++++++++++++++++++++++ >>> 2 files changed, 28 insertions(+), 1 deletion(-) >>> >>> diff --git a/mm/util.c b/mm/util.c >>> index 12984e76767e..2b0222a728cc 100644 >>> --- a/mm/util.c >>> +++ b/mm/util.c >>> @@ -1128,7 +1128,9 @@ void mem_dump_obj(void *object) >>> return; >>> >>> if (virt_addr_valid(object)) >>> - type = "non-slab/vmalloc memory"; >>> + type = "non-slab memory"; >>> + else if (is_vmalloc_addr(object)) >>> + type = "vmalloc memory"; >>> else if (object == NULL) >>> type = "NULL pointer"; >>> else if (object == ZERO_SIZE_PTR) >>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c index >>> ccaa461998f3..4351eafbe7ab 100644 >>> --- a/mm/vmalloc.c >>> +++ b/mm/vmalloc.c >>> @@ -4034,6 +4034,31 @@ bool vmalloc_dump_obj(void *object) >>> struct vm_struct *vm; >>> void *objp = (void *)PAGE_ALIGN((unsigned long)object); >>> >>> + /* for non-vmalloc addr, return directly */ >>> + if (!is_vmalloc_addr(objp)) >>> + return false; >>> + >>> + /** >>> + * for non-Preempt-RT kernel, return directly. otherwise not >>> + * only needs to determine whether it is in the interrupt context >>> + * (in_interrupt())to avoid deadlock, but also to avoid acquire >>> + * vmap_area_lock spinlock in disables interrupts or preempts >>> + * critical sections, because the vmap_area_lock spinlock convert >>> + * to sleepable lock >>> + */ >>> + if (IS_ENABLED(CONFIG_PREEMPT_RT) && !preemptible()) >>> + return false; >>> + >>> + /** >>> + * get here, for Preempt-RT kernel, it means that we are in >>> + * preemptible context(preemptible() is true), it also means >>> + * that the in_interrupt() will return false. >>> + * for non-Preempt-RT kernel, only needs to determine whether >>> + * it is in the interrupt context(in_interrupt()) to avoid deadlock >>> + */ >>> + if (in_interrupt()) >>> + return false; >> >> >> We want mem_dump_obj() to work properly in the interrupt context. But with this if statement, it's impossible to work properly. > > This is to avoid the following scenarios, because, call_rcu() can be invoked in hard irq or > softirq context, so mem_dump_obj() not dump some details info. OK. Sorry, I'm confusing your issue with what I'm doing right now. https://lkml.org/lkml/2022/11/16/913 I need "if (in_interrupt() && spin_is_locked(&vmap_area_lock))". So mem_dump_obj() can work well in interrupt, except the task was interrupted in the critical section of vmap_area_lock. > > CPU 0 > tasks context > spin_lock(&vmap_area_lock) > Interrupt or softirq context > call_rcu() > mem_dump_obj > vmalloc_dump_obj > spin_lock(&vmap_area_lock) <--deadlock > > because mem_dump_obj() only used by RCU, I'm not sure if this modification is appropriate, > need to hear from Paul. > > Thanks > Zqiang > > >> >> Here's my test case: >> void *tst_p; >> >> void my_irqwork_handler(struct irq_work *work) { >> void *p = tst_p; >> >> printk("enter my_irqwork_handler: CPU=%d, locked=%d\n", smp_processor_id(), tst_is_locked()); >> mem_dump_obj(p); >> vfree(p); >> } >> >> static void test_mem_dump(void) >> { >> struct irq_work work = IRQ_WORK_INIT_HARD(my_irqwork_handler); >> >> tst_p = vmalloc(PAGE_SIZE); >> if (!tst_p) { >> printk("vmalloc failed\n"); >> return; >> } >> printk("enter test_mem_dump: CPU=%d\n", smp_processor_id()); >> >> //tst_lock(); >> irq_work_queue(&work); >> //tst_unlock(); >> >> printk("leave test_mem_dump: CPU=%d\n", smp_processor_id()); } >> >> Test result: >> [ 45.212941] enter test_mem_dump: CPU=0 >> [ 45.213280] enter my_irqwork_handler: CPU=0, locked=0 >> [ 45.213546] vmalloc memory >> [ 45.213996] leave test_mem_dump: CPU=0 >> >>> + >>> vm = find_vm_area(objp); >>> if (!vm) >>> return false; >>> -- >>> 2.25.1 >> >> >> -- >> Regards, >> Zhen Lei -- Regards, Zhen Lei