Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 8a0621cf authored by Vlastimil Babka's avatar Vlastimil Babka Committed by Suren Baghdasaryan
Browse files

UPSTREAM: include/linux/slab.h: fix sparse warning in kmalloc_type()

Multiple people have reported the following sparse warning:

./include/linux/slab.h:332:43: warning: dubious: x & !y

The minimal fix would be to change the logical & to boolean &&, which
emits the same code, but Andrew has suggested that the branch-avoiding
tricks are maybe not worthwile.  David Laight provided a nice comparison
of disassembly of multiple variants, which shows that the current version
produces a 4 deep dependency chain, and fixing the sparse warning by
changing logical and to multiplication emits an IMUL, making it even more
expensive.

The code as rewritten by this patch yielded the best disassembly, with a
single predictable branch for the most common case, and a ternary operator
for the rest, which gcc seems to compile without a branch or cmov by
itself.

The result should be more readable, without a sparse warning and probably
also faster for the common case.

Link: http://lkml.kernel.org/r/80340595-d7c5-97b9-4f6c-23fa893a91e9@suse.cz


Fixes: 1291523f2c1d ("mm, slab/slub: introduce kmalloc-reclaimable caches")
Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarVlastimil Babka <vbabka@suse.cz>
Reported-by: default avatarBart Van Assche <bvanassche@acm.org>
Reported-by: default avatarDarryl T. Agostinelli <dagostinelli@gmail.com>
Reported-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Suggested-by: default avatarDavid Laight <David.Laight@ACULAB.COM>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>

(cherry picked from commit 4e45f712d82c6b7a37e02faf388173ad12ab464d)

Bug: 138148041
Test: verify KReclaimable accounting after ION allocation+deallocation
Change-Id: I17844e923dc322392304959b5eed6b7c61e3ef6e
Signed-off-by: default avatarSuren Baghdasaryan <surenb@google.com>
parent 31575ef8
Loading
Loading
Loading
Loading
+12 −12
Original line number Original line Diff line number Diff line
@@ -316,22 +316,22 @@ kmalloc_caches[NR_KMALLOC_TYPES][KMALLOC_SHIFT_HIGH + 1];


static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags)
static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags)
{
{
	int is_dma = 0;
	int type_dma = 0;
	int is_reclaimable;

#ifdef CONFIG_ZONE_DMA
#ifdef CONFIG_ZONE_DMA
	is_dma = !!(flags & __GFP_DMA);
	/*
	type_dma = is_dma * KMALLOC_DMA;
	 * The most common case is KMALLOC_NORMAL, so test for it
#endif
	 * with a single branch for both flags.

	 */
	is_reclaimable = !!(flags & __GFP_RECLAIMABLE);
	if (likely((flags & (__GFP_DMA | __GFP_RECLAIMABLE)) == 0))
		return KMALLOC_NORMAL;


	/*
	/*
	 * If an allocation is both __GFP_DMA and __GFP_RECLAIMABLE, return
	 * At least one of the flags has to be set. If both are, __GFP_DMA
	 * KMALLOC_DMA and effectively ignore __GFP_RECLAIMABLE
	 * is more important.
	 */
	 */
	return type_dma + (is_reclaimable & !is_dma) * KMALLOC_RECLAIM;
	return flags & __GFP_DMA ? KMALLOC_DMA : KMALLOC_RECLAIM;
#else
	return flags & __GFP_RECLAIMABLE ? KMALLOC_RECLAIM : KMALLOC_NORMAL;
#endif
}
}


/*
/*