From nobody Sun Feb 8 19:56:56 2026 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 7CE03C77B7D for ; Mon, 15 May 2023 05:03:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233086AbjEOFDE (ORCPT ); Mon, 15 May 2023 01:03:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230205AbjEOFC5 (ORCPT ); Mon, 15 May 2023 01:02:57 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A36B9E73; Sun, 14 May 2023 22:02:56 -0700 (PDT) Received: from dggpemm500005.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4QKRxt54nCzLpxV; Mon, 15 May 2023 13:00:02 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Mon, 15 May 2023 13:02:54 +0800 From: Yunsheng Lin To: , , CC: , , Yunsheng Lin , Pavel Begunkov Subject: [PATCH net-next] net: skbuff: update comment about pfmemalloc propagating Date: Mon, 15 May 2023 13:01:07 +0800 Message-ID: <20230515050107.46397-1-linyunsheng@huawei.com> X-Mailer: git-send-email 2.33.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.69.192.56] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" __skb_fill_page_desc_noacc() is not doing any pfmemalloc propagating, and yet it has a comment about that, commit 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") may have accidentally moved it to __skb_fill_page_desc_noacc(), so move it back to __skb_fill_page_desc() which is supposed to be doing pfmemalloc propagating. Signed-off-by: Yunsheng Lin CC: Pavel Begunkov Reviewed-by: Pavel Begunkov --- Also maybe we need a better name for 'noacc' or add some comment about that, as 'noacc' seems a little confusing for __skb_fill_page_desc_noacc(). --- include/linux/skbuff.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 00e8c435fa1a..4b8d55247198 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -2426,11 +2426,6 @@ static inline void __skb_fill_page_desc_noacc(struct= skb_shared_info *shinfo, { skb_frag_t *frag =3D &shinfo->frags[i]; =20 - /* - * Propagate page pfmemalloc to the skb if we can. The problem is - * that not all callers have unique ownership of the page but rely - * on page_is_pfmemalloc doing the right thing(tm). - */ skb_frag_fill_page_desc(frag, page, off, size); } =20 @@ -2463,6 +2458,11 @@ static inline void __skb_fill_page_desc(struct sk_bu= ff *skb, int i, struct page *page, int off, int size) { __skb_fill_page_desc_noacc(skb_shinfo(skb), i, page, off, size); + + /* Propagate page pfmemalloc to the skb if we can. The problem is + * that not all callers have unique ownership of the page but rely + * on page_is_pfmemalloc doing the right thing(tm). + */ page =3D compound_head(page); if (page_is_pfmemalloc(page)) skb->pfmemalloc =3D true; --=20 2.33.0