linux-next: manual merge of the slab tree with the mm tree

linux-next: manual merge of the slab tree with the mm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

Hi all,

Today's linux-next merge of the slab tree got a conflict in:

  mm/kasan/quarantine.c

between commit:

  f644ee35cf5b ("kasan: use stack_depot_put for Generic mode")

from the mm tree and commit:

  40a038d5fc11 ("KASAN: remove code paths guarded by CONFIG_SLAB")

from the slab tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/kasan/quarantine.c
index 265ca2bbe2dd,138c57b836f2..000000000000
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@@ -143,22 -143,7 +143,21 @@@ static void *qlink_to_object(struct qli
  static void qlink_free(struct qlist_node *qlink, struct kmem_cache *cache)
  {
  	void *object = qlink_to_object(qlink, cache);
 -	struct kasan_free_meta *meta = kasan_get_free_meta(cache, object);
 +	struct kasan_alloc_meta *alloc_meta = kasan_get_alloc_meta(cache, object);
 +	struct kasan_free_meta *free_meta = kasan_get_free_meta(cache, object);
- 	unsigned long flags;
 +
 +	if (alloc_meta) {
 +		stack_depot_put(alloc_meta->alloc_track.stack);
 +		stack_depot_put(alloc_meta->aux_stack[0]);
 +		stack_depot_put(alloc_meta->aux_stack[1]);
 +		__memset(alloc_meta, 0, sizeof(*alloc_meta));
 +	}
 +
 +	if (free_meta &&
 +	    *(u8 *)kasan_mem_to_shadow(object) == KASAN_SLAB_FREETRACK) {
 +		stack_depot_put(free_meta->free_track.stack);
 +		free_meta->free_track.stack = 0;
 +	}
  
  	/*
  	 * If init_on_free is enabled and KASAN's free metadata is stored in

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the slab tree with the mm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

Hi all,

Today's linux-next merge of the slab tree got a conflict in:

  mm/slab_common.c

between commits:

  01869cf7b4c6 ("slub: use folio APIs in free_large_kmalloc()")
  8017164cb101 ("slub: use a folio in __kmalloc_large_node")

from the mm tree and commits:

  b774d3e326d3 ("mm/slab: move kfree() from slab_common.c to slub.c")
  4862caa5cba0 ("mm/slab: move kmalloc() functions from slab_common.c to slub.c")

from the slab tree.

I fixed it up (I used the latter version of this file and applied the
following merge fix patch) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 2 Jan 2024 15:26:48 +1100
Subject: [PATCH] fix up for "mm/slab: move kfree() from slab_common.c to
 slub.c"

and "mm/slab: move kmalloc() functions from slab_common.c to slub.c"
interacting with commits

  01869cf7b4c6 ("slub: use folio APIs in free_large_kmalloc()")
  8017164cb101 ("slub: use a folio in __kmalloc_large_node")

from the mm tree

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/slub.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 236e728e49ed..2ef88bbf56a3 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3915,7 +3915,7 @@ EXPORT_SYMBOL(kmem_cache_alloc_node);
  */
 static void *__kmalloc_large_node(size_t size, gfp_t flags, int node)
 {
-	struct page *page;
+	struct folio *folio;
 	void *ptr = NULL;
 	unsigned int order = get_order(size);
 
@@ -3923,10 +3923,10 @@ static void *__kmalloc_large_node(size_t size, gfp_t flags, int node)
 		flags = kmalloc_fix_flags(flags);
 
 	flags |= __GFP_COMP;
-	page = alloc_pages_node(node, flags, order);
-	if (page) {
-		ptr = page_address(page);
-		mod_lruvec_page_state(page, NR_SLAB_UNRECLAIMABLE_B,
+	folio = (struct folio *)alloc_pages_node(node, flags, order);
+	if (folio) {
+		ptr = folio_address(folio);
+		lruvec_stat_mod_folio(folio, NR_SLAB_UNRECLAIMABLE_B,
 				      PAGE_SIZE << order);
 	}
 
@@ -4375,9 +4375,9 @@ static void free_large_kmalloc(struct folio *folio, void *object)
 	kasan_kfree_large(object);
 	kmsan_kfree_large(object);
 
-	mod_lruvec_page_state(folio_page(folio, 0), NR_SLAB_UNRECLAIMABLE_B,
+	lruvec_stat_mod_folio(folio, NR_SLAB_UNRECLAIMABLE_B,
 			      -(PAGE_SIZE << order));
-	__free_pages(folio_page(folio, 0), order);
+	folio_put(folio);
 }
 
 /**
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the slab tree with the mm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

Hi all,

Today's linux-next merge of the slab tree got a conflict in:

  include/linux/slab.h

between commit:

  78f5d33f3dd4 ("mm, treewide: rename MAX_ORDER to MAX_PAGE_ORDER")

from the mm tree and commit:

  a9e0b9f27266 ("mm/slab: remove CONFIG_SLAB code from slab common code")

from the slab tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/slab.h
index d63823e518c0,b2015d0e01ad..000000000000
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@@ -308,19 -307,10 +307,10 @@@ static inline unsigned int arch_slab_mi
   * (PAGE_SIZE*2).  Larger requests are passed to the page allocator.
   */
  #define KMALLOC_SHIFT_HIGH	(PAGE_SHIFT + 1)
 -#define KMALLOC_SHIFT_MAX	(MAX_ORDER + PAGE_SHIFT)
 +#define KMALLOC_SHIFT_MAX	(MAX_PAGE_ORDER + PAGE_SHIFT)
  #ifndef KMALLOC_SHIFT_LOW
- #define KMALLOC_SHIFT_LOW	5
- #endif
- #endif
- 
- #ifdef CONFIG_SLUB
- #define KMALLOC_SHIFT_HIGH	(PAGE_SHIFT + 1)
- #define KMALLOC_SHIFT_MAX	(MAX_PAGE_ORDER + PAGE_SHIFT)
- #ifndef KMALLOC_SHIFT_LOW
  #define KMALLOC_SHIFT_LOW	3
  #endif
- #endif
  
  /* Maximum allocatable size */
  #define KMALLOC_MAX_SIZE	(1UL << KMALLOC_SHIFT_MAX)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the slab tree with the mm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

Hi all,

Today's linux-next merge of the slab tree got a conflict in:

  mm/slab.c

between commit:

  3ef36a834801 ("kasan: rename and document kasan_(un)poison_object_data")

from the mm tree and commit:

  16a1d968358a ("mm/slab: remove mm/slab.c and slab_def.h")

from the slab tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the slab tree with the mm tree

[Catalin Marinas]

On Mon, Jun 19, 2023 at 02:03:30PM +1000, Stephen Rothwell wrote:
> diff --cc mm/slab_common.c
> index 43c008165f56,90ecaface410..000000000000
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@@ -892,24 -876,17 +890,24 @@@ new_kmalloc_cache(int idx, enum kmalloc
>   		flags |= SLAB_CACHE_DMA;
>   	}
>   
>  +	if (minalign > ARCH_KMALLOC_MINALIGN) {
>  +		aligned_size = ALIGN(aligned_size, minalign);
>  +		aligned_idx = __kmalloc_index(aligned_size, false);
>  +	}
>  +
> + 	/*
> + 	 * If CONFIG_MEMCG_KMEM is enabled, disable cache merging for
> + 	 * KMALLOC_NORMAL caches.
> + 	 */
> + 	if (IS_ENABLED(CONFIG_MEMCG_KMEM) && (type == KMALLOC_NORMAL))
> + 		flags |= SLAB_NO_MERGE;
> + 
>  -	kmalloc_caches[type][idx] = create_kmalloc_cache(
>  -					kmalloc_info[idx].name[type],
>  -					kmalloc_info[idx].size, flags, 0,
>  -					kmalloc_info[idx].size);
>  +	if (!kmalloc_caches[type][aligned_idx])
>  +		kmalloc_caches[type][aligned_idx] = create_kmalloc_cache(
>  +					kmalloc_info[aligned_idx].name[type],
>  +					aligned_size, flags);
>  +	if (idx != aligned_idx)
>  +		kmalloc_caches[type][idx] = kmalloc_caches[type][aligned_idx];
> - 
> - 	/*
> - 	 * If CONFIG_MEMCG_KMEM is enabled, disable cache merging for
> - 	 * KMALLOC_NORMAL caches.
> - 	 */
> - 	if (IS_ENABLED(CONFIG_MEMCG_KMEM) && (type == KMALLOC_NORMAL))
> - 		kmalloc_caches[type][idx]->refcount = -1;
>   }
>   
>   /*

Thanks Stephen. The resolution looks fine to me.

-- 
Catalin

linux-next: manual merge of the slab tree with the mm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]

Hi all,

Today's linux-next merge of the slab tree got a conflict in:

  mm/slab_common.c

between commits:

  fef594ee7142 ("mm/slab: simplify create_kmalloc_cache() args and make it static")
  6e6f174b6eda ("mm/slab: limit kmalloc() minimum alignment to dma_get_cache_alignment()")

from the mm tree and commit:

  d5bf48574699 ("mm/slab_common: use SLAB_NO_MERGE instead of negative refcount")

from the slab tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/slab_common.c
index 43c008165f56,90ecaface410..000000000000
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@@ -892,24 -876,17 +890,24 @@@ new_kmalloc_cache(int idx, enum kmalloc
  		flags |= SLAB_CACHE_DMA;
  	}
  
 +	if (minalign > ARCH_KMALLOC_MINALIGN) {
 +		aligned_size = ALIGN(aligned_size, minalign);
 +		aligned_idx = __kmalloc_index(aligned_size, false);
 +	}
 +
+ 	/*
+ 	 * If CONFIG_MEMCG_KMEM is enabled, disable cache merging for
+ 	 * KMALLOC_NORMAL caches.
+ 	 */
+ 	if (IS_ENABLED(CONFIG_MEMCG_KMEM) && (type == KMALLOC_NORMAL))
+ 		flags |= SLAB_NO_MERGE;
+ 
 -	kmalloc_caches[type][idx] = create_kmalloc_cache(
 -					kmalloc_info[idx].name[type],
 -					kmalloc_info[idx].size, flags, 0,
 -					kmalloc_info[idx].size);
 +	if (!kmalloc_caches[type][aligned_idx])
 +		kmalloc_caches[type][aligned_idx] = create_kmalloc_cache(
 +					kmalloc_info[aligned_idx].name[type],
 +					aligned_size, flags);
 +	if (idx != aligned_idx)
 +		kmalloc_caches[type][idx] = kmalloc_caches[type][aligned_idx];
- 
- 	/*
- 	 * If CONFIG_MEMCG_KMEM is enabled, disable cache merging for
- 	 * KMALLOC_NORMAL caches.
- 	 */
- 	if (IS_ENABLED(CONFIG_MEMCG_KMEM) && (type == KMALLOC_NORMAL))
- 		kmalloc_caches[type][idx]->refcount = -1;
  }
  
  /*

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the slab tree with the mm tree

[Yosry Ahmed]

On Tue, Apr 4, 2023 at 9:08 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the slab tree got a conflict in:
>
>   mm/slob.c
>
> between commit:
>
>   3fb083757df1 ("mm: vmscan: refactor updating reclaimed pages in reclaim_state")
>
> from the mm tree and commit:
>
>   6630e950d532 ("mm/slob: remove slob.c")
>
> from the slab tree.
>
> I fixed it up (I just removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any

Sounds good to me, thanks! Let me know if anything else needs to be done here.


> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.


>
> --
> Cheers,
> Stephen Rothwell

linux-next: manual merge of the slab tree with the mm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

Hi all,

Today's linux-next merge of the slab tree got a conflict in:

  mm/slob.c

between commit:

  3fb083757df1 ("mm: vmscan: refactor updating reclaimed pages in reclaim_state")

from the mm tree and commit:

  6630e950d532 ("mm/slob: remove slob.c")

from the slab tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the slab tree with the mm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

Hi all,

Today's linux-next merge of the slab tree got a conflict in:

  include/linux/slab.h

between commit:

  af8daebdbc08 ("mm, treewide: redefine MAX_ORDER sanely")

from the mm tree and commit:

  4503dfcf39b1 ("mm/slab: remove CONFIG_SLOB code from slab common code")

from the slab tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]