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 7087AE82CAE for ; Wed, 27 Sep 2023 17:06:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C61868D0098; Wed, 27 Sep 2023 13:06:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C116C8D0093; Wed, 27 Sep 2023 13:06:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B01408D0098; Wed, 27 Sep 2023 13:06:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A1D598D0093 for ; Wed, 27 Sep 2023 13:06:33 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 406081A0DB8 for ; Wed, 27 Sep 2023 17:06:33 +0000 (UTC) X-FDA: 81283006266.15.2DE5CDD Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf19.hostedemail.com (Postfix) with ESMTP id 0456B1A002F for ; Wed, 27 Sep 2023 17:06:30 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695834391; 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: in-reply-to:in-reply-to:references:references; bh=i02XAEtSH+Cf8LDf3/xfe04q4DXasM/uxl5qAK8dy6c=; b=uI2UzumBHegO90hgI3x1FRH+c9dtskqU3NlsnkmXIfrpnhqeJMogU37uyha3vNbcI+og1o I2ZM+EQBtVaeTYZuGrPxiIlN9b+8clhITrqg85j65BiwHoeboTpZVyknanMQ1X78TXLs7v R8pQohwwwzVPR0vjKLZJE7uKDyIOejk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695834391; a=rsa-sha256; cv=none; b=Jc8I6XYa1dgFT7RclPJHRSkzG8plblW2KJFZOxBxk3QTVMEv9qobuxDDg3pqHXOFs7yY+X O4qYfs1Ph+36F1ycZJmPPMYlIoXgymWb3pE3GsU3J2/PfUDyKwwpCvd6a9N1D1p+BXP9jz IUX07/K6eTvRQzzk8iv8MRk5iKvPLho= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 5D450CE1919; Wed, 27 Sep 2023 17:06:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75B32C433C8; Wed, 27 Sep 2023 17:06:25 +0000 (UTC) Date: Wed, 27 Sep 2023 18:06:22 +0100 From: Catalin Marinas To: Liu Shixin Cc: Patrick Wang , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] mm/kmemleak: fix partially freeing unknown object warning Message-ID: References: <20230927035923.1425340-1-liushixin2@huawei.com> <20230927035923.1425340-3-liushixin2@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230927035923.1425340-3-liushixin2@huawei.com> X-Rspamd-Queue-Id: 0456B1A002F X-Rspam-User: X-Stat-Signature: 3yo5ct6ry7qymt7x1fwhhtb5f1mdhcsh X-Rspamd-Server: rspam03 X-HE-Tag: 1695834390-560035 X-HE-Meta: U2FsdGVkX189Lw1rruobnfO+0Uxu3Yv7h9aNV8L8Yf9K8FUTVbo4WUeaIzcfkfAC4hzhfZT4cIKKsZaWNPoDZlHQwkD07/2nvRzfVYzLkzYdWi6xIu1mLsqRkhnLlor5Jjzv3/mCUm+FRmq7ZsWh+q9onwjmnsnpsF9jDmvlG3P+J8g+Qy/n7LdxrGKuP4eeaYaYyn/gey2Eh9KSEVLFvLL6472kUsy3eQHrYu84M/1GjDKqGp+1R+b6flXvr9WZiQ0kjC6YG8wgWfxCCVyXB6ZW19TFlrh/x0nIAtf+QUlOKq+xGrt6yFUBfrn/6Uf911HwEenfZ+5KoYYKR/ESs2iY8iFTZjsoY+3BvXcDbU3I1yrIubYzpanbHrFzb4+iuYfOBQ+/UVLlSI4imcb2LSjBcbIoUFUuESlZJnIwjkV1R1tUCCm9Qh5vVo19tXawF/MlfxcrSWQ7DBtkP7A9hS95+imbrEI53sbprAzYQTz4VK15bKZLy7jznAQD/UywCi40DRQ/1lrxwvFTYeroXkSF/KyXk9MPz+r82rc+02fueN/i1ri7AAoa7itUd4wj+YzhqtWL1ZmPlGL/1Ddrxy83YQCJ7UbGnDgJtgqOs6+wG5n9goX/UMajvUtCgl239rIoPXeh5/A7VLAozxoxFFV/msjUSYnYj6rN9dKAhLW2rH/btDLyWstfHKfkfY9vuAMUerPxlwWg4C5C1Ky6DnwLloYDeqOEQ8+3uS+4KjaDM/xUNc5HplPIIgTq7NE99XcYB0DLcZWC/I1LzIdGcU/v2S5MPbD/uS+82clcyxfChnf5B5b8+4dvWJ5UZGrtIbr00jw1xEJ586y4lxNrNpNrMJXaozQmg+mzql87nlHIL0vtdyW85vsbjBDgs+jXF/42ZmZ531htnuZhcOcoOE5wj46OxBsGfkVK37LjC5SpCIU1RF+SNU/X8NRbLbwcD9u4SeuqLJ31tR0OnGD sew3JwEO Jr7nNj5fi/I5fciB3RGChnLRiaWp7McJSwpTAZ5wm3kppLPpbRDgYCFzbouf9DBHeDveO++xJOOwrK2M7qYbgPCupPUFHWJrwzbgi6FK002sgJcKQFrx4zPyHIqWccjGof6h7uD+VzIPiaWf8G2mP7wZ4BTDCYv4Jk6ka/VpV+Gu2nySX774cHtrBg3XfAHuunXGSPRWNBn78VeMBCgkIUZlO5PEjXSdTb+2kzuGllwqcZ2+v4+1YoS1BrYrQLYugdOk7cF++rbXdgKa6RdZ1EZJbtKcyPjRdbrbDWedl0ET3reETeLDUgVVlXDd8fYEQH4bt2tSZsZzLxHV3ShiWkoBmSk9jVIYKwh62M5DwgqeoorJzSrbuNykefNy7EyXdoTpm3jWgm+y4N50= 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, Sep 27, 2023 at 11:59:22AM +0800, Liu Shixin wrote: > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index 54c2c90d3abc..5a2bbd85df57 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -208,6 +208,8 @@ static struct rb_root object_tree_root = RB_ROOT; > static struct rb_root object_phys_tree_root = RB_ROOT; > /* protecting the access to object_list, object_tree_root (or object_phys_tree_root) */ > static DEFINE_RAW_SPINLOCK(kmemleak_lock); > +/* Serial delete_object_part() to ensure all objects is deleted correctly */ > +static DEFINE_RAW_SPINLOCK(delete_object_part_mutex); Don't call this mutex, it implies sleeping. > > /* allocation caches for kmemleak internal data */ > static struct kmem_cache *object_cache; > @@ -784,13 +786,16 @@ static void delete_object_part(unsigned long ptr, size_t size, bool is_phys) > { > struct kmemleak_object *object; > unsigned long start, end; > + unsigned long flags; > > + raw_spin_lock_irqsave(&delete_object_part_mutex, flags); > object = find_and_remove_object(ptr, 1, is_phys); > if (!object) { > #ifdef DEBUG > kmemleak_warn("Partially freeing unknown object at 0x%08lx (size %zu)\n", > ptr, size); > #endif > + raw_spin_unlock_irqrestore(&delete_object_part_mutex, flags); I prefer a goto out and a single place for unlocking. However, we already take the kmemleak_lock in find_and_remove_object(). So better to open-code that function here and avoid introducing a new lock. __create_object() may need a new bool argument, no_lock or something. Or just split it into separate functions for allocating the kmemleak structure and adding it to the corresponding trees/lists under a lock. -- Catalin