Re: possible deadlock in sk_clone_lock

[Michal Hocko <mhocko@suse.com>]

On Mon 01-03-21 08:39:22, Shakeel Butt wrote:
> On Mon, Mar 1, 2021 at 7:57 AM Michal Hocko <mhocko@suse.com> wrote:
[...]
> > Then how come this can ever be a problem? in_task() should exclude soft
> > irq context unless I am mistaken.
> >
> 
> If I take the following example of syzbot's deadlock scenario then
> CPU1 is the one freeing the hugetlb pages. It is in the process
> context but has disabled softirqs (see __tcp_close()).
> 
>         CPU0                    CPU1
>         ----                    ----
>    lock(hugetlb_lock);
>                                 local_irq_disable();
>                                 lock(slock-AF_INET);
>                                 lock(hugetlb_lock);
>    <Interrupt>
>      lock(slock-AF_INET);
> 
> So, this deadlock scenario is very much possible.

OK, I see the point now. I was focusing on the IRQ context and hugetlb
side too much. We do not need to be freeing from there. All it takes is
to get a dependency chain over a common lock held here. Thanks for
bearing with me.

Let's see whether we can make hugetlb_lock irq safe.

-- 
Michal Hocko
SUSE Labs