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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 7 Apr 2024 13:01:36 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Klara Modin <klarasmodin@...il.com>
Cc: akpm@...ux-foundation.org, surenb@...gle.com, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/memprofiling: explicitly include irqflags.h in
 alloc_tag.h

On Sun, Apr 07, 2024 at 03:32:52PM +0200, Klara Modin wrote:
> linux/alloc_tag.h uses the macro this_cpu_inc which eventually expands to:
> 
>  #define this_cpu_generic_to_op(pcp, val, op)				\
>  do {									\
>  	unsigned long __flags;						\
>  	raw_local_irq_save(__flags);					\
>  	raw_cpu_generic_to_op(pcp, val, op);				\
>  	raw_local_irq_restore(__flags);					\
>  } while (0)
> 
> The macros raw_local_irq_save and raw_local_irq_restore are defined in
> linux/irqflags.h which is not included implicitly on all configs.
> Therefore, include it explicitly.
> 
> Fixes: ac906a377c67 ("lib: add allocation tagging support for memory allocation profiling")
> Link: https://lore.kernel.org/lkml/6b8149f3-80e6-413c-abcb-1925ecda9d8c@gmail.com/
> Signed-off-by: Klara Modin <klarasmodin@...il.com>
> ---
>  include/linux/alloc_tag.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h
> index e867461585ff..afc9e259a2d3 100644
> --- a/include/linux/alloc_tag.h
> +++ b/include/linux/alloc_tag.h
> @@ -12,6 +12,7 @@
>  #include <asm/percpu.h>
>  #include <linux/cpumask.h>
>  #include <linux/static_key.h>
> +#include <linux/irqflags.h>

Actually, shouldn't this end up in a percpu header? Or was there a
problem with that?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ