From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5FBDF372EDD for ; Mon, 27 Apr 2026 09:17:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777281465; cv=none; b=gFb5iVgfZ+a8TIhuIsXWx4HUJWKcosuiNrb6QdA6N4RMCs4Z/4zYpAwzt0EnQh1u6L6N+OoKH7/iyvWuoC9xKu43kNt+P/SaamV1nIQZCzyVD1FhQ2y4RBwl7agTpZN+Jy8Kf7f56WnK6fk1vXDHg1yAd82Sc7m4dZrBcFmOH68= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777281465; c=relaxed/simple; bh=5gSyueKrFTodcm2zMQHeQOSRw+ArQETISQSNchRRKKs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=CvO3i3kOicsKAdKxs9iIqyq0Q/QLKmcnQfnTNORH2V5AHjKW2hSLcJd0HhIJsm8ypqCmQ7rALUF0UXgtaYmwB18ktEJcVycnUv8Ag0/8KEUO6rhdYGpBQyMAvDpxkwgDRj4eXi9YY0rpKLUcCL/4p32+f0K0V2zixRZekNu/XK4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=BBiq1pXq; arc=none smtp.client-ip=91.218.175.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="BBiq1pXq" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1777281452; 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=ORHngxvyZgMWhS/hIL5qRYN26UMVGb5ngq+TKZyDg0M=; b=BBiq1pXqeKCV203ZvOj67Z/33UqGDuxwcoU8KXnRwokCLX0JGoGrycz9MVzJYt3sNvUY8w UItlOVhAetp7joyoDg60oTEh8L6qIGXkVzKLM50YvpODxYKTt9bRTIav1HhkIRprYXXVqa xoUBLaui1da4tTR732wtjHotyKLSyoY= Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\)) Subject: Re: [PATCH 2/2] drivers/base/memory: fix memory block reference leak in poison accounting X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <7fe73023-1fd1-0c10-107e-5c0f47383453@huawei.com> Date: Mon, 27 Apr 2026 17:16:34 +0800 Cc: Muchun Song , Ying Huang , Dan Williams , Vishal Verma , Naoya Horiguchi , linux-mm@kvack.org, linux-cxl@vger.kernel.org, driver-core@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org, David Hildenbrand , Oscar Salvador , Andrew Morton , Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260426144447.817722-1-songmuchun@bytedance.com> <20260426144447.817722-2-songmuchun@bytedance.com> <7fe73023-1fd1-0c10-107e-5c0f47383453@huawei.com> To: Miaohe Lin X-Migadu-Flow: FLOW_OUT > On Apr 27, 2026, at 17:13, Miaohe Lin wrote: >=20 > On 2026/4/26 22:44, Muchun Song wrote: >> memblk_nr_poison_inc() and memblk_nr_poison_sub() look up a memory >> block via find_memory_block_by_id(), which acquires a reference to = the >> memory block device. >>=20 >> Both helpers use the returned memory block without dropping that >> reference, leaking the device reference on each successful lookup. = Drop >> the reference after updating nr_hwpoison. >>=20 >> Fixes: 5033091de814 ("mm/hwpoison: introduce per-memory_block = hwpoison counter") >> Cc: stable@vger.kernel.org >> Signed-off-by: Muchun Song >=20 > This patch looks good to me with one question below: >=20 > Reviewed-by: Miaohe Lin Thanks. >=20 >> --- >> drivers/base/memory.c | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >>=20 >> diff --git a/drivers/base/memory.c b/drivers/base/memory.c >> index f806a683b767..6981b55d582a 100644 >> --- a/drivers/base/memory.c >> +++ b/drivers/base/memory.c >> @@ -1230,8 +1230,10 @@ void memblk_nr_poison_inc(unsigned long pfn) >> const unsigned long block_id =3D pfn_to_block_id(pfn); >> struct memory_block *mem =3D find_memory_block_by_id(block_id); >>=20 >> - if (mem) >> + if (mem) { >> atomic_long_inc(&mem->nr_hwpoison); >> + put_device(&mem->dev); >=20 > Comment above find_memory_block_by_id says it's called under = device_hotplug_lock. >=20 > /* > * A reference for the returned memory block device is acquired. > * > * Called under device_hotplug_lock. > */ > struct memory_block *find_memory_block_by_id(unsigned long block_id) >=20 > But device_hotplug_lock is missing here. Should we add it? Yes. Otherwise mem can be freed concurrently. sashiko.dev reported the issue as well. Thanks. = https://sashiko.dev/#/patchset/20260426144447.817722-1-songmuchun%40byteda= nce.com >=20 > Thanks. > .