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 X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2945EC282CE for ; Mon, 11 Feb 2019 19:31:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EC343218A1 for ; Mon, 11 Feb 2019 19:31:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="r8LNa58f" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388354AbfBKTb0 (ORCPT ); Mon, 11 Feb 2019 14:31:26 -0500 Received: from mail-it1-f195.google.com ([209.85.166.195]:36326 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728075AbfBKTb0 (ORCPT ); Mon, 11 Feb 2019 14:31:26 -0500 Received: by mail-it1-f195.google.com with SMTP id c9so1191441itj.1 for ; Mon, 11 Feb 2019 11:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8faLjypp9oBqvvmAUk/zBcM9e4IAAl0A1mCRvgstVWk=; b=r8LNa58feN1ABfdDIplriW3jrBSM5pVzLIOPNlYyZgjnILMm6J+HideLRw04s5a7dq g2b1awQ8SzwHub3bHyeUaOVCa0K6xY1S3B4GQJU409S1fbj8xSkpyrbK7qzSaA28xW0n t3uV8qyizxDBgdZapizjs1/h6Y/nROe2qn0c6tmtV9lc82MX05nA3oerhKG9WrnXLb+n 4lU1P0gjsMJZmssxGoBocl+jbq7ADmUk+nx2CcYWOtFg19uNnl/gMAGqWD1MwDXSSpm3 bpAMkBUjJSf4oE8mphJnAXXvUenRB+CSut3rp0c8Pbm1nLvtA1NVo6r4rxJ1b4Bl6KeC L0lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8faLjypp9oBqvvmAUk/zBcM9e4IAAl0A1mCRvgstVWk=; b=GIaZs1CpFgdUJf1JmaUuhERvtf+ANuJ4FcSlC4komYX8vi7MUOmSJG0L3Z5Sz0esn6 1gVKtHb+XTUVxE0aiOl78za3RK6pbHtc0QpdlbbLsMRT1rBFfF/hle+zyKZkGTOFK2xq jN4dOiigUZGIpW+iwQViJgoVv6P8sMYreLKymYifRzuikqsUlLg9tdQ6vG2hRaCUDbd6 +ClH2nP9cVvudBuYY+Cq8WtvjIin5qZm3NUcLC5rMmnWdccv/SshfqpwPtZmXctt025r EtwLV6Rw0cL03jC2zXCmiMTLg7lnDWhoLgUr3GxMqtxj3xiBvHihMFDUa2VuWAnr2Gon 5Cow== X-Gm-Message-State: AHQUAuY+NjwLmCD0ATRSKZoNhag7svdttfBO3w2IhLLANVVccgUnMu5N IiMMx488HuOG0zU+XsqtVgjjBbuuS07QqDl4zOg= X-Google-Smtp-Source: AHgI3IalfCrC5KhHPFaIunNDXZsRyO0/wYAJ1hZUoSYqvyF8sZsLYjsp5odUjo0EyHXbwGjTt9OPlG1At59c+9S5NvE= X-Received: by 2002:a02:9f86:: with SMTP id a6mr5572263jam.87.1549913485345; Mon, 11 Feb 2019 11:31:25 -0800 (PST) MIME-Version: 1.0 References: <154990116432.24530.10541030990995303432.stgit@firesoul> <154990121192.24530.11128024662816211563.stgit@firesoul> In-Reply-To: <154990121192.24530.11128024662816211563.stgit@firesoul> From: Alexander Duyck Date: Mon, 11 Feb 2019 11:31:13 -0800 Message-ID: Subject: Re: [net-next PATCH 2/2] net: page_pool: don't use page->private to store dma_addr_t To: Jesper Dangaard Brouer Cc: Netdev , linux-mm , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Ilias Apalodimas , Matthew Wilcox , Saeed Mahameed , Andrew Morton , Mel Gorman , "David S. Miller" , Tariq Toukan Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Feb 11, 2019 at 8:07 AM Jesper Dangaard Brouer wrote: > > From: Ilias Apalodimas > > As pointed out by David Miller the current page_pool implementation > stores dma_addr_t in page->private. > This won't work on 32-bit platforms with 64-bit DMA addresses since the > page->private is an unsigned long and the dma_addr_t a u64. > > A previous patch is adding dma_addr_t on struct page to accommodate this. > This patch adapts the page_pool related functions to use the newly added > struct for storing and retrieving DMA addresses from network drivers. > > Signed-off-by: Ilias Apalodimas > Signed-off-by: Jesper Dangaard Brouer > --- > net/core/page_pool.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/net/core/page_pool.c b/net/core/page_pool.c > index 43a932cb609b..897a69a1477e 100644 > --- a/net/core/page_pool.c > +++ b/net/core/page_pool.c > @@ -136,7 +136,9 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool, > if (!(pool->p.flags & PP_FLAG_DMA_MAP)) > goto skip_dma_map; > > - /* Setup DMA mapping: use page->private for DMA-addr > + /* Setup DMA mapping: use 'struct page' area for storing DMA-addr > + * since dma_addr_t can be either 32 or 64 bits and does not always fit > + * into page private data (i.e 32bit cpu with 64bit DMA caps) > * This mapping is kept for lifetime of page, until leaving pool. > */ > dma = dma_map_page(pool->p.dev, page, 0, > @@ -146,7 +148,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool, > put_page(page); > return NULL; > } > - set_page_private(page, dma); /* page->private = dma; */ > + page->dma_addr = dma; > > skip_dma_map: > /* When page just alloc'ed is should/must have refcnt 1. */ > @@ -175,13 +177,16 @@ EXPORT_SYMBOL(page_pool_alloc_pages); > static void __page_pool_clean_page(struct page_pool *pool, > struct page *page) > { > + dma_addr_t dma; > + > if (!(pool->p.flags & PP_FLAG_DMA_MAP)) > return; > > + dma = page->dma_addr; > /* DMA unmap */ > - dma_unmap_page(pool->p.dev, page_private(page), > + dma_unmap_page(pool->p.dev, dma, > PAGE_SIZE << pool->p.order, pool->p.dma_dir); > - set_page_private(page, 0); > + page->dma_addr = 0; > } > > /* Return a page to the page allocator, cleaning up our state */ This comment is unrelated to this patch specifically, but applies more generally to the page_pool use of dma_unmap_page. So just looking at this I am pretty sure the use of just dma_unmap_page isn't correct here. You should probably be using dma_unmap_page_attrs and specifically be passing the attribute DMA_ATTR_SKIP_CPU_SYNC so that you can tear down the mapping without invalidating the contents of the page. This is something that will work for most cases but if you run into a case where this is used with SWIOTLB in bounce buffer mode you would end up potentially corrupting data on the unmap call.