lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251114154759.76541-1-sj@kernel.org>
Date: Fri, 14 Nov 2025 07:47:57 -0800
From: SeongJae Park <sj@...nel.org>
To: Jean Delvare <jdelvare@...e.de>
Cc: SeongJae Park <sj@...nel.org>,
	linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>,
	David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH] mm/cma: Remove CONFIG_CMA_SYSFS option

On Fri, 14 Nov 2025 09:48:14 +0100 Jean Delvare <jdelvare@...e.de> wrote:

> Hi Seong Jae,
> 
> On Thu, 13 Nov 2025 17:09:27 -0800, SeongJae Park wrote:
> > On Thu, 13 Nov 2025 14:56:36 +0100 Jean Delvare <jdelvare@...e.de> wrote:
> > 
> > > The sysfs interface to CMA has a marginal runtime cost and a small
> > > footprint, there's no reason not to include it in all kernels where
> > > the dependencies are satisfied.  
> > 
> > Overall change looks good to me.  I have a question below, though.
> > 
> > > 
> > > Signed-off-by: Jean Delvare <jdelvare@...e.de>
> > > ---
> > > As discussed with David:
> > >   https://lkml.org/lkml/2025/8/6/371
> > > 
> > >  arch/loongarch/configs/loongson3_defconfig |    1 -
> > >  arch/s390/configs/debug_defconfig          |    1 -
> > >  arch/s390/configs/defconfig                |    1 -
> > >  mm/Kconfig                                 |    7 -------
> > >  mm/Makefile                                |    4 +++-
> > >  mm/cma.h                                   |    4 ++--
> > >  6 files changed, 5 insertions(+), 13 deletions(-)
> > > 
> > > --- linux-6.17.orig/arch/loongarch/configs/loongson3_defconfig
> > > +++ linux-6.17/arch/loongarch/configs/loongson3_defconfig  
> > [...]
> > > --- linux-6.17.orig/mm/cma.h
> > > +++ linux-6.17/mm/cma.h
> > > @@ -49,7 +49,7 @@ struct cma {
> > >  	char name[CMA_MAX_NAME];
> > >  	int nranges;
> > >  	struct cma_memrange ranges[CMA_MAX_RANGES];
> > > -#ifdef CONFIG_CMA_SYSFS
> > > +#ifdef CONFIG_SYSFS
> > >  	/* the number of CMA page successful allocations */
> > >  	atomic64_t nr_pages_succeeded;
> > >  	/* the number of CMA page allocation failures */
> > > @@ -80,7 +80,7 @@ static inline unsigned long cma_bitmap_m
> > >  	return cmr->count >> cma->order_per_bit;
> > >  }
> > >  
> > > -#ifdef CONFIG_CMA_SYSFS
> > > +#ifdef CONFIG_SYSFS
> > >  void cma_sysfs_account_success_pages(struct cma *cma, unsigned long nr_pages);
> > >  void cma_sysfs_account_fail_pages(struct cma *cma, unsigned long nr_pages);
> > >  void cma_sysfs_account_release_pages(struct cma *cma, unsigned long nr_pages);  
> > 
> > Why don't you check CONFIG_CMA together?  I think that makes the change more
> > complete and safe.
> > 
> > I found there is no file that can be compiled without CONFIG_CMA but still
> > including this header file, so I expect no real issue for now, though.
> 
> This would actually make no difference. This header file is internal
> and not expected to be included by any file besides that CMA core
> itself, so it is assumed that CONFIG_CMA=y whenever this header file
> is used. If not, then things would break already, even without my
> proposed changes (due to cma_areas and cma_area_count being declared
> but never defined).

Makes sense.

Reviewed-by: SeongJae Park <sj@...nel.org>


Thanks,
SJ

[...]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ