Received: by 2002:a05:6359:6284:b0:131:369:b2a3 with SMTP id se4csp4741124rwb; Tue, 8 Aug 2023 13:06:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH2iPzAs1tQAZ12RREfnBJzovSydOx6ynqhX4hWRLi4dUF9lk6suVxiEiQEBqd5YXFDdcGU X-Received: by 2002:a17:906:10dd:b0:99c:da06:bca with SMTP id v29-20020a17090610dd00b0099cda060bcamr498448ejv.4.1691525171447; Tue, 08 Aug 2023 13:06:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691525171; cv=none; d=google.com; s=arc-20160816; b=CRSvA5GLOBpjVTf0bacpP9gAkV6puP+pf+F4gI0nNdFmCTLehHtbhnwT/mnQeSqbSy 3VMofL3jBNpH/Sih2HF3+e5+LkK98+RgKKf1h7CMBpoehnJGQL8zFpvLu6X20YnMlDcc E4uPy23oiGxPL9J4/NuIEXV68HDSYfKyotZBNlvV8Q+iGQgVAalTAeFgdJ4jF14DdL9S eex58TPeRn1akY7c5WU9Z8cQxa+dqzNo6xUh3T/1zmksusAYoxZSeeHyLm+1STjmBHbA 7o/sY1n48G1kulwUKsquKxA4Pk7p9nSuiPGZhvqjnJLprTFZnxkpgUkjkgnoLdW+p6q3 j74g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=o1NFY3VdQSb9Zqy0SLKHAuSu4mepElX+9AY6ISptc7A=; fh=RYKyo9Mfhy1XFnDFIHciltRFuhpbA2F69n05V6sgAuw=; b=QKNx7YQUhM69Go229JdzrqCir7ES+cht06Ilpl/2d/RwL0LgtpBhjGDxQ4/ypQX4MP X12QlWbUozxCwhaaE9WElRcnmOwtTJxECFo/X7TFgYZvM9XhLCgR0tA1V3dFFgHzfWZv /yZoJiV5iJubhDUyl0wB2tfrvOkeJmwi49oOJE/Nr9J3AIlDDpEtie3r5rFS8jfIBo+D 6Jp/YrJZgg6Z5iWKPsYKdeaQl8Zu7p1uaWG0JVpKoSXuEBsCx6EzlbKxP/zTsGqu93b/ siH5Exchl0wdg8vEVtBOct9nfzFpYMSZoe8hVv8paqqn33Zm0iqWkZ9xCo5TTCY93nS2 1Wnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=lnjNTk76; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g11-20020a17090669cb00b0099bd2095b65si7527500ejs.917.2023.08.08.13.05.45; Tue, 08 Aug 2023 13:06:11 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=lnjNTk76; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232031AbjHHTPP (ORCPT + 99 others); Tue, 8 Aug 2023 15:15:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230216AbjHHTOo (ORCPT ); Tue, 8 Aug 2023 15:14:44 -0400 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F42614595; Tue, 8 Aug 2023 09:37:38 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-d593a63e249so1291681276.3; Tue, 08 Aug 2023 09:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691512628; x=1692117428; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=o1NFY3VdQSb9Zqy0SLKHAuSu4mepElX+9AY6ISptc7A=; b=lnjNTk76EJhxe170Ber/m2Ta5V/1jtLHDBLmMD0JYx7yevLbvSYvVGGDAu0GW3D/6U Sa8ChHydFDVZmbX0tTfE9p8ENZ0pybIQ48smkQNCSh7bk2nIx4uCPinzCsm+EER//nVF 3/6BT1ghjjupgQKsNaYGxT2x/g90u0xnAGn5dJQmT+HuBHoZ4HTl/Bi//ktD1jPQdX98 CKzDpoWYu5sPRplLUxF/viKmvBqSqpLiAUI+JOb3LmRJPJ8OZq8s8ZgB7vOOR2bl073w 6wUd9eQ3qc7uszytp3WCqmSeonZGwguAEm+6VVP1qSBHUK471ZEJ5QEQOLdrgNvpMSjI kNSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691512628; x=1692117428; h=content-transfer-encoding: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=o1NFY3VdQSb9Zqy0SLKHAuSu4mepElX+9AY6ISptc7A=; b=I56n8FPRclMCGrjoxKPhcIJJVVcoSDA5SRK7Y7g7RByHzaAYt3B/xCJpTUYUHKrvt3 RD9sbtZcUsF6JqOgpU3FP/F4unbamIm6K/8iDsdkcZvEiMlCJL9VDIJmxnWgzeOwIyQb vgKTAp5YD2YMkzwn8WjUvu16TUsny7DirspRHanPqSPCMbLOfRsPLc0ELIhWveqtnzdF w01xc0Cfs9DumxWNzsksdAKuM/6h6QCCgtTrVK7MfOTJ/Ry6vTvuIAwI/3NG59VIgSlw ucWR/RHCBM/LlRmNajTDtK96snVUPiYKt4vOJnZs7prSZlJQ0t4iaI1jpUvXMDOCglOX 5tIA== X-Gm-Message-State: AOJu0YwRe+iF2SDYo+t0pI08hJyVv5NcDZ2k3rxcrCghUXTMt3qIAQL1 6XB/MiF+g+D+aKfD2zBKa8iFOVxXak/jJa++BtEfLX3f X-Received: by 2002:a17:90a:1f41:b0:268:e5db:6e19 with SMTP id y1-20020a17090a1f4100b00268e5db6e19mr9233015pjy.20.1691502363028; Tue, 08 Aug 2023 06:46:03 -0700 (PDT) MIME-Version: 1.0 References: <20230804180529.2483231-1-aleksander.lobakin@intel.com> <20230804180529.2483231-6-aleksander.lobakin@intel.com> <692d71dc8068b3d27aba39d7141c811755965786.camel@gmail.com> <601c0203-ee5f-03a3-e9dd-fdb241f3bcdc@intel.com> In-Reply-To: <601c0203-ee5f-03a3-e9dd-fdb241f3bcdc@intel.com> From: Alexander Duyck Date: Tue, 8 Aug 2023 06:45:26 -0700 Message-ID: Subject: Re: [PATCH net-next v4 5/6] page_pool: add a lockdep check for recycling in hardirq To: Alexander Lobakin Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maciej Fijalkowski , Larysa Zaremba , Yunsheng Lin , Alexander Duyck , Jesper Dangaard Brouer , Ilias Apalodimas , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 8, 2023 at 6:16=E2=80=AFAM Alexander Lobakin wrote: > > From: Alexander H Duyck > Date: Mon, 07 Aug 2023 07:48:54 -0700 > > > On Fri, 2023-08-04 at 20:05 +0200, Alexander Lobakin wrote: > >> From: Jakub Kicinski > >> > >> Page pool use in hardirq is prohibited, add debug checks > >> to catch misuses. IIRC we previously discussed using > >> DEBUG_NET_WARN_ON_ONCE() for this, but there were concerns > >> that people will have DEBUG_NET enabled in perf testing. > >> I don't think anyone enables lockdep in perf testing, > >> so use lockdep to avoid pushback and arguing :) > >> > >> Signed-off-by: Jakub Kicinski > >> Acked-by: Jesper Dangaard Brouer > >> Signed-off-by: Alexander Lobakin > >> --- > >> include/linux/lockdep.h | 7 +++++++ > >> net/core/page_pool.c | 2 ++ > >> 2 files changed, 9 insertions(+) > >> > >> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h > >> index 310f85903c91..dc2844b071c2 100644 > >> --- a/include/linux/lockdep.h > >> +++ b/include/linux/lockdep.h > >> @@ -625,6 +625,12 @@ do { = \ > >> WARN_ON_ONCE(__lockdep_enabled && !this_cpu_read(hardirq_context)= ); \ > >> } while (0) > >> > >> +#define lockdep_assert_no_hardirq() \ > >> +do { = \ > >> + WARN_ON_ONCE(__lockdep_enabled && (this_cpu_read(hardirq_context)= || \ > >> + !this_cpu_read(hardirqs_enable= d))); \ > >> +} while (0) > >> + > >> #define lockdep_assert_preemption_enabled() \ > >> do { = \ > >> WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT) && \ > >> @@ -659,6 +665,7 @@ do { = \ > >> # define lockdep_assert_irqs_enabled() do { } while (0) > >> # define lockdep_assert_irqs_disabled() do { } while (0) > >> # define lockdep_assert_in_irq() do { } while (0) > >> +# define lockdep_assert_no_hardirq() do { } while (0) > >> > >> # define lockdep_assert_preemption_enabled() do { } while (0) > >> # define lockdep_assert_preemption_disabled() do { } while (0) > >> diff --git a/net/core/page_pool.c b/net/core/page_pool.c > >> index 03ad74d25959..77cb75e63aca 100644 > >> --- a/net/core/page_pool.c > >> +++ b/net/core/page_pool.c > >> @@ -587,6 +587,8 @@ static __always_inline struct page * > >> __page_pool_put_page(struct page_pool *pool, struct page *page, > >> unsigned int dma_sync_size, bool allow_direct) > >> { > >> + lockdep_assert_no_hardirq(); > >> + > >> /* This allocator is optimized for the XDP mode that uses > >> * one-frame-per-page, but have fallbacks that act like the > >> * regular page allocator APIs. > > > > So two points. > > > > First could we look at moving this inside the if statement just before > > we return the page, as there isn't a risk until we get into that path > > of needing a lock. > > > > Secondly rather than returning an error is there any reason why we > > couldn't just look at not returning page and instead just drop into the > > release path which wouldn't take the locks in the first place? Either > > That is exception path to quickly catch broken drivers and fix them, why > bother? It's not something we have to live with. My concern is that the current "fix" consists of stalling a Tx ring. We need to have a way to allow forward progress when somebody mixes xdp_frame and skb traffic as I suspect we will end up with a number of devices doing this since they cannot handle recycling the pages in hardirq context. The only reason why the skbs don't have the problem is that they are queued and then cleaned up in the net_tx_action. That is why I wonder if we shouldn't look at adding some sort of support for doing something like that with xdp_frame as well. Something like a dev_kfree_pp_page_any to go along with the dev_kfree_skb_any.