linux-kernel - Re: [RFC PATCH] clk: fix possible circular locking in clk_notifier

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:   Wed, 09 Jun 2021 14:35:02 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Michael Turquette <mturquette@...libre.com>,
        Sean Nyekjaer <sean@...nix.com>
Cc:     Sean Nyekjaer <sean@...nix.com>, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] clk: fix possible circular locking in clk_notifier_register()

Quoting Sean Nyekjaer (2021-06-07 04:01:54)
> Allocating memory with prepare_lock mutex held makes lockdep unhappy
> when memory pressure makes the system do fs_reclaim on eg. rawnand using
> clk.
> 
[...]
> [  462.949628]  *** DEADLOCK ***
> [  462.949628]
> [  462.955563] 1 lock held by kswapd0/22:
> [  462.959322]  #0: 11f3c233 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x48
> 
> Signed-off-by: Sean Nyekjaer <sean@...nix.com>
> ---
> 
> Could have used GPF_NOWAIT, but it seems wrong during memory reclaim.
> 
>  drivers/clk/clk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 65508eb89ec9..eb2a547487d6 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -4348,7 +4348,7 @@ int clk_notifier_register(struct clk *clk, struct notifier_block *nb)
>                         goto found;
>  
>         /* if clk wasn't in the notifier list, allocate new clk_notifier */
> -       cn = kzalloc(sizeof(*cn), GFP_KERNEL);
> +       cn = kzalloc(sizeof(*cn), GFP_ATOMIC);

We could not allocate this here and instead allocate it before taking
the lock with the assumption that we'll insert the notifier. That's
probably the normal case. If we allocated it but didn't use it then we
can free it on exit, outside the lock. Can you make that change and
resend? Using GFP_ATOMIC is not the best solution here.