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 4ADA4C4332F for ; Wed, 30 Nov 2022 05:02:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232641AbiK3FC2 (ORCPT ); Wed, 30 Nov 2022 00:02:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50950 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231852AbiK3FC1 (ORCPT ); Wed, 30 Nov 2022 00:02:27 -0500 Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99A3C6F820 for ; Tue, 29 Nov 2022 21:02:26 -0800 (PST) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-3bfd998fa53so107144557b3.5 for ; Tue, 29 Nov 2022 21:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=AQfI9itT56aGkQXPmrJoqcBSs6MMztV/FP9e3fo34YE=; b=gfcNra0cbSMcEsa9a6u7N6E+fn9tqIWr7b5nZhCPU+3qqkjLm76Gro9nvAwB0oGlq6 k6Xnd4JvXTRnEXry2GvzBvSf2gusHv164kEtbCgPrXC6zr475X/EPwsWTjr4GmzL8s0L 3bQQVffgXdW1LqoKMsZpgDqOwaDtDtuBvxbt6Gp1fwZ0PGDLRdUAjrgcWellpuoB4SXW kvIsFCAIivvJMAtSwH4d4t930DuuIeLxWjNLREjM0rLNdyF5WNB8PMJuQPlxWZ+NnOAb 463l3iBrFzdDhYNfM1tQzTnkYVtuS4J3domqcCJem7h4VdMb1wsPhuOrhx1KwrQlEMuQ nBHg== 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=AQfI9itT56aGkQXPmrJoqcBSs6MMztV/FP9e3fo34YE=; b=hWlqt2V7hs6Blk+BMhB5VlIyuGtOkDIXjYc6a7Cc1nzHLycu+KF+A/7D7x8lCJcXyH I9bDUTOYPY6U30CRUQBD2qfN/nw7d9GXmu0uLumY2uccygAl1gWa4PlkwFKyV0wNjjvR 1sT2h/bYxa0ZLx8la6nxPy8+SVCoM+tZrJPdCSjN2lSGIei/joB/Qz9Nz6+uJzZ2pXos S7sFB70eDe5ALME5kQeS+NpG/Ere2X6uyiDtdiurvhuxoud9N9vrfZ6NpvJ0W1dHhSpK iVgpxMuvqQsG84qUm5EDHZkuZb8Hwn0hvB5IovA2CpzUQbjcfTlET/JU9TaVADIu9kdL 5BIA== X-Gm-Message-State: ANoB5pm+Z/HPGvoePEpDNyXwawLRiMK/dLdg/vnBKOCt+1VfT3swsUVA +TQK1H88buwsAIrKFrsBx/6ZOcdGePRvC6cn5TVv6g== X-Google-Smtp-Source: AA0mqf7zVAnnD/UlTCjMZ1by0J8F4WRMqduoFzjwV2cFa/ztIR/2VbOlT17w6zKgggS27T6ehDgQSeqjUikjBpGPyVk= X-Received: by 2002:a81:9b83:0:b0:381:2226:74ff with SMTP id s125-20020a819b83000000b00381222674ffmr56493985ywg.102.1669784545693; Tue, 29 Nov 2022 21:02:25 -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: <8d424223-1da6-60bf-dd2c-cd2fe6d263fe@huaweicloud.com> From: Hao Luo Date: Tue, 29 Nov 2022 21:02:11 -0800 Message-ID: Subject: Re: [net-next] bpf: avoid hashtab deadlock with try_lock To: Hou Tao Cc: Tonghao Zhang , 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 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. Thanks, Hao