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] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yk6lz0UYyKIv5ibI@arm.com>
Date:   Thu, 7 Apr 2022 09:50:23 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Hyeonggon Yoo <42.hyeyoo@...il.com>
Cc:     Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/10] mm/slab: Allow dynamic kmalloc() minimum alignment

On Thu, Apr 07, 2022 at 03:46:37AM +0000, Hyeonggon Yoo wrote:
> On Tue, Apr 05, 2022 at 02:57:56PM +0100, Catalin Marinas wrote:
> > --- a/mm/slab_common.c
> > +++ b/mm/slab_common.c
> > @@ -838,9 +838,18 @@ void __init setup_kmalloc_cache_index_table(void)
> >  	}
> >  }
> >  
> > -static void __init
> > +unsigned int __weak arch_kmalloc_minalign(void)
> > +{
> > +	return ARCH_KMALLOC_MINALIGN;
> > +}
> > +
> 
> As ARCH_KMALLOC_ALIGN and arch_kmalloc_minalign() may not be same after
> patch 10, I think s/ARCH_KMALLOC_ALIGN/arch_kmalloc_minalign/g
> for every user of it would be more correct?

Not if the code currently using ARCH_KMALLOC_MINALIGN needs a constant.
Yes, there probably are a few places where the code can cope with a
dynamic arch_kmalloc_minalign() but there are two other cases where a
constant is needed:

1. As a BUILD_BUG check because the code is storing some flags in the
   bottom bits of a pointer. A smaller ARCH_KMALLOC_MINALIGN works just
   fine here.

2. As a static alignment for DMA requirements. That's where the newly
   exposed ARCH_DMA_MINALIGN should be used.

Note that this series doesn't make the situation any worse than before
since ARCH_DMA_MINALIGN stays at 128 bytes for arm64. Current users can
evolve to use a dynamic alignment in future patches. My main aim with
this series is to be able to create kmalloc-64 caches on arm64.

> > @@ -851,10 +860,17 @@ new_kmalloc_cache(int idx, enum kmalloc_cache_type type, slab_flags_t flags)
> >  		flags |= SLAB_ACCOUNT;
> >  	}
> >  
> > -	kmalloc_caches[type][idx] = create_kmalloc_cache(
> > -					kmalloc_info[idx].name[type],
> > -					kmalloc_info[idx].size, flags, 0,
> > -					kmalloc_info[idx].size);
> > +	if (minalign > ARCH_KMALLOC_MINALIGN) {
> > +		aligned_size = ALIGN(aligned_size, minalign);
> > +		aligned_idx = __kmalloc_index(aligned_size, false);
> > +	}
> > +
> > +	if (!kmalloc_caches[type][aligned_idx])
> > +		kmalloc_caches[type][aligned_idx] = create_kmalloc_cache(
> > +					kmalloc_info[aligned_idx].name[type],
> > +					aligned_size, flags, 0, aligned_size);
> > +	if (idx != aligned_idx)
> > +		kmalloc_caches[type][idx] = kmalloc_caches[type][aligned_idx];
> 
> I would prefer detecting minimum kmalloc size in create_kmalloc_caches()
> in runtime instead of changing behavior of new_kmalloc_cache().

That was my initial attempt but we have a couple of
create_kmalloc_cache() (not *_caches) calls directly, one of them in
mm/slab.c kmem_cache_init(). So I wanted all the minalign logic in a
single place, hence I replaced the explicit create_kmalloc_cache() call
with new_kmalloc_cache(). See this patch and patch 9 for some clean-up.

-- 
Catalin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ