From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 EC7292BEC27 for ; Sat, 23 May 2026 02:49:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779504555; cv=none; b=qAm3Eal6Fo3O09ge328aKXggLFKTS6H9/V4ShKlmZN73vYx7N/zRBvCRbZFOx+v1OyZIwyu6an7nOwk9j0LH4DCErdIg+xUhpYZSdxdjY7FQ4wGX8ZlJQV8wbbzaXy4NeCZypbOklzsqu5E8MZk0Ew8VHXGR1Zl9Ce6eVK31sbQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779504555; c=relaxed/simple; bh=SiSAVc59bU1QXQDUqN2FckKINYtmVBYHMKYbNRjHUmI=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=f5byE+FZFa+cYde49ejEWV53SWx5YbFJLmwzKSFrHMKDYBXf3kMRMvI+e9IwwJKoY+Djeczrv6CTow7vV6AdybuJQoTcmYRQvzYi8lLJ6WirYWwdYCgDAXdA765pSrS89Zc4Ni4uJgYcceolm07JbIY6OVdFPrEYruPWWQ9+7b8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=pboJkTJs; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="pboJkTJs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 108021F000E9; Sat, 23 May 2026 02:49:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1779504551; bh=78N+P7P8gqbkhUPA/78W3mwHDVrIp1fEwV8A+moHM+k=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=pboJkTJsFft/vCcg33VX/hetYDvccIzh+1G8kjyipRbMXx8vprEWk+txxkF92ca64 XuWbtCSUSekl7QgehjujsU0o5o9PxP0I+PpyR3/NmaZXOoCud3k4aHuWPDMhM71PDZ ZVd7wmPplvurq6a42aQjlqBi7B6gAKSPPLODT+eE= Date: Fri, 22 May 2026 19:49:10 -0700 From: Andrew Morton To: Muchun Song Cc: Kaitao Cheng , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Minchan Kim , digetx@gmail.com, John Hubbard , Greg KH , Linux Memory Management List , LKML , Kaitao Cheng Subject: Re: [PATCH] mm/cma_sysfs: Skip inactive CMA areas in sysfs Message-Id: <20260522194910.9395371c3d3d1bfb87cd1211@linux-foundation.org> In-Reply-To: References: <20260522131434.78532-1-kaitao.cheng@linux.dev> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, 22 May 2026 21:26:59 +0800 Muchun Song wrote: > On Fri, May 22, 2026 at 9:15 PM Kaitao Cheng wrote: > > > > From: Kaitao Cheng > > > > cma_activate_area() can fail after a CMA area has already been added to > > cma_areas[]. In that case the area is left in the global array, but it > > does not reach the point where CMA_ACTIVATED is set. > > > > cma_sysfs_init() currently walks all cma_area_count entries and creates > > sysfs files for every area, including ones that failed activation. These > > areas are not usable CMA areas and should not be exposed to userspace as > > valid CMA regions. > > > > Skip CMA areas that did not reach CMA_ACTIVATED when creating the sysfs > > objects. Since inactive entries can now be skipped, make the error > > unwind tolerate entries that never had cma_kobj initialized. > > > > Fixes: 43ca106fa8ec ("mm: cma: support sysfs") > > Actually, this is not a fix since there is no serious issue when accessing those > sysfs files. I think it is an improvement. I find it hard to say because the changelog doesn't have a clear description of the userspace-visible impact of the bug. > > Reported-by: David Hildenbrand (Arm) > > Reported-by: Muchun Song > > Closes: https://lore.kernel.org/linux-mm/55481a8b-dcfc-4bef-ba59-aa0b43dca88b@kernel.org/ That says "Reading the bitmap file can make debugfs walk a freed range bitmap and trigger an invalid memory access". Maybe it oopses? So Kaitao, can you please send us a clear and complete description of how this bug affects downstream users?