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]
Date:   Fri, 18 Jun 2021 18:20:01 +0000
From:   Dennis Zhou <dennis@...nel.org>
To:     Wan Jiabing <wanjiabing@...o.com>
Cc:     Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, kael_w@...h.net
Subject: Re: [PATCH] mm/percpu: Fix gfp flag in pcpu_balance_populated

Hello,

On Fri, Jun 18, 2021 at 11:14:36PM +0800, Wan Jiabing wrote:
> Fix coccicheck warning:
> 
> ./mm/percpu.c:2045:19-29: ERROR: function pcpu_balance_populated
> called on line 2232 inside lock on line 2228 but uses GFP_KERNEL
> 
> When pcpu_balance_populated() is called in pcpu_balance_workfn(),
> it helds spin_lock but use GFP_KERNEL to alloc mem, which is unsafe.
> 
> Signed-off-by: Wan Jiabing <wanjiabing@...o.com>
> ---
>  mm/percpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/percpu.c b/mm/percpu.c
> index b4cebeca4c0c..4031f32e6975 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2042,7 +2042,7 @@ static void pcpu_balance_free(bool empty_only)
>  static void pcpu_balance_populated(void)
>  {
>  	/* gfp flags passed to underlying allocators */
> -	const gfp_t gfp = GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN;
> +	const gfp_t gfp = GFP_ATOMIC | __GFP_NORETRY | __GFP_NOWARN;
>  	struct pcpu_chunk *chunk;
>  	int slot, nr_to_pop, ret;
>  
> -- 
> 2.30.2
> 

In both places gfp flags are passed, the pcpu_lock is dropped. So I
think this is an issue with coccicheck. Regardless, the fix wouldn't be
to switch to GFP_ATOMIC but to make the locking correct.

Thanks,
Dennis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ