Message ID | 20230524153311.3625329-6-dhowells@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:3046:b0:115:7a1d:dabb with SMTP id p6csp2918074rwl; Wed, 24 May 2023 08:48:19 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ67/IAY8+kbhFEjOBxO+RAO7KZETfnfYPpvenDUEyjgSEgdCTE+IeMjzgYK6KaFkp4fWfXO X-Received: by 2002:a05:6a21:6d95:b0:10b:ce6e:656b with SMTP id wl21-20020a056a216d9500b0010bce6e656bmr11648954pzb.46.1684943299361; Wed, 24 May 2023 08:48:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684943299; cv=none; d=google.com; s=arc-20160816; b=b+ec819GjyOeayYiLTK4NG+OTmyNVNrSHJNIbEKlP/Fdn1hJ9ijtwjqCe8amM3eQeO ISfERgMjQZunCETETQF4IcWehL0ilTwRgFxfUlcmB7q/rJt1YMT4h5QS8dzswvVGTWSY zQ8uDxMOpckVjQNeRKj9rYjwY4XH7X4IxYF3+PgCF2JpsVXuOEGv7ThtrRS3hS2Cay4w 0exDYCGSo0QPwcr2ZpuSQLTbIQpodgqPOqgAS+qo1BdxP2vIMENsxFSmb5wjF0nDJ/UR LewMeA1LI2+cr9Zuih9l9P6QTVCUVLUNbR5bl5Z5B/Z/TcVVlQp0I2TGekJ2X3hQN6QN 3VQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=uekJL1E5Uz+9JLqowhoPzZVYALfVqMM/z7Y13jfCLzU=; b=j3GKuiPrQUQ7nJZdxGjEZvucBcysNLvnP22Q1ClzoprlTpdql5GveKjZ28tEBoGkBI OCveO0X6M4IBbwi87FlWKAD1rWcnsKmvncU0MDCWjnUDUZS3j6YT1lQwm0IAMnX28mDJ Pd8qHvbMGcnYaTkpjK/us8xo/Hu2oSgrPWWPo+zsOS8o7OxYbutsSRyrV5VnzBqEXXP9 i5iqSUX2Jj8K74zKZ89ahhVR9NgPU6Lytjj1Wn7vtk5+weM+8HEVWVGouGoZnpywXlFj CKQNcjY5tx0P1gmMD0SQlz0M7J/Ofjq85w1wDMWS4+S0Ao3DhughTn5Ty8+myYrqbRfj 5/xA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BTDSpsph; 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=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n24-20020a638f18000000b005208c4fa34csi1393349pgd.773.2023.05.24.08.48.06; Wed, 24 May 2023 08:48:19 -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=@redhat.com header.s=mimecast20190719 header.b=BTDSpsph; 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=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237145AbjEXPg0 (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Wed, 24 May 2023 11:36:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236763AbjEXPfR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 24 May 2023 11:35:17 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF8771B6 for <linux-kernel@vger.kernel.org>; Wed, 24 May 2023 08:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684942421; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uekJL1E5Uz+9JLqowhoPzZVYALfVqMM/z7Y13jfCLzU=; b=BTDSpsphuW9fIcfezkiYIjMwV/fLk+H1R2qNj0ohldeC9yQQN1Nu1JRudoBtwqi+lYtstE 6lh71gCm9Lu8CZDVcLHpSJ+IgwNg61XWWX/cPQ6RTIyY0oQeYPKwz7va0rS4eZGy7NSVgv 9iNqw7yPVSnmEzUzC1q7a/kjS0OSino= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-168-UtOOYHJNMQqeOwkvKYu_rw-1; Wed, 24 May 2023 11:33:38 -0400 X-MC-Unique: UtOOYHJNMQqeOwkvKYu_rw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F027280BCA2; Wed, 24 May 2023 15:33:36 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.39.192.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6A068492B0A; Wed, 24 May 2023 15:33:32 +0000 (UTC) From: David Howells <dhowells@redhat.com> To: netdev@vger.kernel.org Cc: David Howells <dhowells@redhat.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Willem de Bruijn <willemdebruijn.kernel@gmail.com>, David Ahern <dsahern@kernel.org>, Matthew Wilcox <willy@infradead.org>, Jens Axboe <axboe@kernel.dk>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jeroen de Borst <jeroendb@google.com>, Catherine Sullivan <csully@google.com>, Shailend Chand <shailend@google.com>, Felix Fietkau <nbd@nbd.name>, John Crispin <john@phrozen.org>, Sean Wang <sean.wang@mediatek.com>, Mark Lee <Mark-MC.Lee@mediatek.com>, Lorenzo Bianconi <lorenzo@kernel.org>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>, Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>, Chaitanya Kulkarni <kch@nvidia.com>, Andrew Morton <akpm@linux-foundation.org>, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-nvme@lists.infradead.org Subject: [PATCH net-next 05/12] mm: Make the page_frag_cache allocator handle __GFP_ZERO itself Date: Wed, 24 May 2023 16:33:04 +0100 Message-Id: <20230524153311.3625329-6-dhowells@redhat.com> In-Reply-To: <20230524153311.3625329-1-dhowells@redhat.com> References: <20230524153311.3625329-1-dhowells@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766791104845936375?= X-GMAIL-MSGID: =?utf-8?q?1766791104845936375?= |
Series |
splice, net: Replace sendpage with sendmsg(MSG_SPLICE_PAGES), part 3
|
|
Commit Message
David Howells
May 24, 2023, 3:33 p.m. UTC
Make the page_frag_cache allocator handle __GFP_ZERO itself rather than
passing it off to the page allocator. There may be a mix of callers, some
specifying __GFP_ZERO and some not - and even if all specify __GFP_ZERO, we
might refurbish the page, in which case the returned memory doesn't get
cleared.
This is a potential bug in the nvme over TCP driver.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Eric Dumazet <edumazet@google.com>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Jens Axboe <axboe@kernel.dk>
cc: Jeroen de Borst <jeroendb@google.com>
cc: Catherine Sullivan <csully@google.com>
cc: Shailend Chand <shailend@google.com>
cc: Felix Fietkau <nbd@nbd.name>
cc: John Crispin <john@phrozen.org>
cc: Sean Wang <sean.wang@mediatek.com>
cc: Mark Lee <Mark-MC.Lee@mediatek.com>
cc: Lorenzo Bianconi <lorenzo@kernel.org>
cc: Matthias Brugger <matthias.bgg@gmail.com>
cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
cc: Keith Busch <kbusch@kernel.org>
cc: Jens Axboe <axboe@fb.com>
cc: Christoph Hellwig <hch@lst.de>
cc: Sagi Grimberg <sagi@grimberg.me>
cc: Chaitanya Kulkarni <kch@nvidia.com>
cc: Andrew Morton <akpm@linux-foundation.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: netdev@vger.kernel.org
cc: linux-arm-kernel@lists.infradead.org
cc: linux-mediatek@lists.infradead.org
cc: linux-nvme@lists.infradead.org
cc: linux-mm@kvack.org
---
mm/page_frag_alloc.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
Comments
On Wed, 24 May 2023 16:33:04 +0100 David Howells wrote: > Make the page_frag_cache allocator handle __GFP_ZERO itself rather than > passing it off to the page allocator. There may be a mix of callers, some > specifying __GFP_ZERO and some not - and even if all specify __GFP_ZERO, we > might refurbish the page, in which case the returned memory doesn't get > cleared. I think it's pretty clear that page frag allocator was never supposed to support GFP_ZERO, as we don't need it in networking.. So maybe you're better off adding the memset() in nvme? CCing Alex, who I think would say something along those lines :) IDK how much we still care given that most networking drivers are migrating to page_poll these days.
On Fri, May 26, 2023 at 5:57 PM Jakub Kicinski <kuba@kernel.org> wrote: > > On Wed, 24 May 2023 16:33:04 +0100 David Howells wrote: > > Make the page_frag_cache allocator handle __GFP_ZERO itself rather than > > passing it off to the page allocator. There may be a mix of callers, some > > specifying __GFP_ZERO and some not - and even if all specify __GFP_ZERO, we > > might refurbish the page, in which case the returned memory doesn't get > > cleared. > > I think it's pretty clear that page frag allocator was never supposed > to support GFP_ZERO, as we don't need it in networking.. So maybe > you're better off adding the memset() in nvme? > > CCing Alex, who I think would say something along those lines :) > IDK how much we still care given that most networking drivers are > migrating to page_poll these days. Yeah, the page frag allocator wasn't meant to handle things like this. Generally the cache was meant to be used within one context so that the GFP flags used were consistent between calls. Currently the only thing passed appears to be GFP_ATOMIC. Also I am not a big fan of pulling this out of page_alloc.c The fact is that is where the allocation functions live so it makes sense to just leave it there. It isn't as if there is enough code added in my point of view to create yet another file and make it harder to track git history as a result.
diff --git a/mm/page_frag_alloc.c b/mm/page_frag_alloc.c index ffd68bfb677d..2b73c7f5d9a9 100644 --- a/mm/page_frag_alloc.c +++ b/mm/page_frag_alloc.c @@ -23,7 +23,10 @@ static struct folio *page_frag_cache_refill(struct page_frag_cache *nc, gfp_t gfp_mask) { struct folio *folio = NULL; - gfp_t gfp = gfp_mask; + gfp_t gfp; + + gfp_mask &= ~__GFP_ZERO; + gfp = gfp_mask; #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) gfp_mask |= __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC; @@ -71,6 +74,7 @@ void *page_frag_alloc_align(struct page_frag_cache *nc, { struct folio *folio = nc->folio; size_t offset; + void *p; WARN_ON_ONCE(!is_power_of_2(align)); @@ -133,7 +137,10 @@ void *page_frag_alloc_align(struct page_frag_cache *nc, offset &= ~(align - 1); nc->offset = offset; - return folio_address(folio) + offset; + p = folio_address(folio) + offset; + if (gfp_mask & __GFP_ZERO) + return memset(p, 0, fragsz); + return p; } EXPORT_SYMBOL(page_frag_alloc_align);