From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF97DC433FE for ; Wed, 30 Nov 2022 05:57:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233839AbiK3F5s (ORCPT ); Wed, 30 Nov 2022 00:57:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233955AbiK3F5I (ORCPT ); Wed, 30 Nov 2022 00:57:08 -0500 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8DF5C77223; Tue, 29 Nov 2022 21:56:56 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id o5so16399736wrm.1; Tue, 29 Nov 2022 21:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6w+OdNdRFHbYUVtJA19A47W8lBW0pPewV38NS5DP0eg=; b=lkMY4jkWg70EE3fQH7Y0sib3cykd1n1T3kHixPfe86BQgLqVRK1uTXnZ6ZiI4GsAgu ozglYdOLC00u0utGIMBkEklWc76MHZ/hajC9tspFxd5XuowHwhEHQk8+rs8tXjBDUTkT baGDyq6obFQviCVni1/SG7bCObZpfJAkCtBGh+UMee+YVRjT89nmcx+Tx5zxfF9YB6Q4 lmBp1J4xjePYoj14v0Fln5WlZanLa+VRF1gm2Vl06X6Wgrmlto6HG+e+1W7rdBZiJr9a 9p8xwCs/gF+IJyxluR4FvW5hS6F97XOHlnut7Dje3r5JmTq3W57ceHF0TbLGCpOK4lJJ OgMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6w+OdNdRFHbYUVtJA19A47W8lBW0pPewV38NS5DP0eg=; b=Qdwhz0yY2EHkv0jlwHgT0K8C+kLBfCnI9KjPOpi4ZewU67+3lOobGxuGP9o24YMjQa MwdbcDxlsGXv88s6yK88s0jdH1UC/PSnGKzT5G9l4+Lf6bnLguSkA/FVC5GtMIdUDhgQ hupNx93BoFdxPFlfc9W4M/pINnT879vpdsoWRXRBb1b7lJGHOSYN6GI2N9f2G1PZ2vTf bNA3eogMlpoBNA/w2Mx9VK12diCaeiFyh1snuIHFsmyGGHSPD4LZQU3A2ifr4c62adM6 QmFjWRUjehcr7hXR5hd/Eft6OKOmDnAW9kWqPaoDGpsFcT5/kfroU8y5P6EVBmtRxSmH d44w== X-Gm-Message-State: ANoB5pl7KBijOKfTjQaqx+bMGT+GIy5qfOKmJIqdH9CzJkIq2a51vyxr PzANBPmZm/puxTFr4G57Xc0Ots4TmoTqSykTore6X7Tv X-Google-Smtp-Source: AA0mqf49nwlETYQIm+SAUx75IQEY7QfFc4l75jRTh8XT/+ayBmcLfg4uN2g0DFCyybeUSgiiJqcJdALdpAw96ez/3aU= X-Received: by 2002:a05:6000:181:b0:241:c6f9:3e5a with SMTP id p1-20020a056000018100b00241c6f93e5amr27677332wrx.157.1669787815082; Tue, 29 Nov 2022 21:56:55 -0800 (PST) MIME-Version: 1.0 References: <41eda0ea-0ed4-1ffb-5520-06fda08e5d38@huawei.com> <07a7491e-f391-a9b2-047e-cab5f23decc5@huawei.com> <59fc54b7-c276-2918-6741-804634337881@huaweicloud.com> <541aa740-dcf3-35f5-9f9b-e411978eaa06@redhat.com> <23b5de45-1a11-b5c9-d0d3-4dbca0b7661e@huaweicloud.com> <8d424223-1da6-60bf-dd2c-cd2fe6d263fe@huaweicloud.com> In-Reply-To: From: Tonghao Zhang Date: Wed, 30 Nov 2022 13:56:18 +0800 Message-ID: Subject: Re: [net-next] bpf: avoid hashtab deadlock with try_lock To: Hao Luo Cc: Hou Tao , Waiman Long , Peter Zijlstra , Ingo Molnar , Will Deacon , netdev@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Jiri Olsa , bpf , "houtao1@huawei.com" , LKML , Boqun Feng Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Nov 30, 2022 at 1:02 PM Hao Luo wrote: > > On Tue, Nov 29, 2022 at 8:13 PM Hou Tao wrote: > > > > On 11/30/2022 10:47 AM, Tonghao Zhang wrote: > <...> > > > if (in_nmi()) { > > > if (!raw_spin_trylock_irqsave(&b->raw_lock, flags)) > > > return -EBUSY; > > > > The only purpose of trylock here is to make lockdep happy and it may lead to > > unnecessary -EBUSY error for htab operations in NMI context. I still prefer add > > a virtual lock-class for map_locked to fix the lockdep warning. So could you use > > separated patches to fix the potential dead-lock and the lockdep warning ? It > > will be better you can also add a bpf selftests for deadlock problem as said before. > > > > Agree with Tao here. Tonghao, could you send another version which: > > - separates the fix to deadlock and the fix to lockdep warning > - includes a bpf selftest to verify the fix to deadlock > - with bpf-specific tag: [PATCH bpf-next] > > There are multiple ideas on the fly in this thread, it's easy to lose > track of what has been proposed and what change you intend to make. Hi, I will send v2 soon. Thanks. > Thanks, > Hao -- Best regards, Tonghao