Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 06 Apr 2023 14:13:23 -0700
From:   John Fastabend <john.fastabend@gmail.com>
To:     Xin Liu <liuxin350@huawei.com>, andrii@kernel.org, ast@kernel.org,
        daniel@iogearbox.net, martin.lau@linux.dev, song@kernel.org,
        yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org,
        sdf@google.com, haoluo@google.com, jolsa@kernel.org
Cc:     bpf@vger.kernel.org, hsinweih@uci.edu,
        linux-kernel@vger.kernel.org, yanan@huawei.com,
        wuchangye@huawei.com, xiesongyang@huawei.com,
        kongweibin2@huawei.com, liuxin350@huawei.com,
        zhangmingyi5@huawei.com
Message-ID: <642f35f3881ee_6e3a2085@john.notmuch>
In-Reply-To: <20230406122622.109978-1-liuxin350@huawei.com>
References: <20230406122622.109978-1-liuxin350@huawei.com>
Subject: RE: [PATCH bpf-next] bpf, sockmap: fix deadlocks in the sockhash and
 sockmap
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Xin Liu wrote:
> When huang uses sched_switch tracepoint, the tracepoint
> does only one thing in the mounted ebpf program, which
> deletes the fixed elements in sockhash ([0])
> 
> It seems that elements in sockhash are rarely actively
> deleted by users or ebpf program. Therefore, we do not
> pay much attention to their deletion. Compared with hash
> maps, sockhash only provides spin_lock_bh protection.
> This causes it to appear to have self-locking behavior
> in the interrupt context.
> 
>   [0]:https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/
> 
> Reported-by: Hsin-Wei Hung <hsinweih@uci.edu>
> Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
> Signed-off-by: Xin Liu <liuxin350@huawei.com>

Yeah even if we delete entries we do it from a sockops. Thanks for the
fix.

Acked-by: John Fastabend <john.fastabend@gmail.com>