From: Miles Chen <miles.chen@mediatek.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Robin Murphy <robin.murphy@arm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Andrew Morton <akpm@linux-foundation.org>,
wsd_upstream@mediatek.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, iommu@lists.linux-foundation.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v3] dma-debug: fix incorrect pfn calculation
Date: Mon, 2 Oct 2017 18:30:41 +0800 [thread overview]
Message-ID: <1506940241.28397.36.camel@mtkswgap22> (raw)
In-Reply-To: <20171001080449.GB11843@lst.de>
On Sun, 2017-10-01 at 10:04 +0200, Christoph Hellwig wrote:
> On Wed, Sep 27, 2017 at 11:23:52AM +0100, Robin Murphy wrote:
> > > I found that debug_dma_alloc_coherent() and debug_dma_free_coherent()
> > > assume that dma_alloc_coherent() always returns a linear address.
> > > However it's possible that dma_alloc_coherent() returns a non-linear
> > > address. In this case, page_to_pfn(virt_to_page(virt)) will return an
> > > incorrect pfn. If the pfn is valid and mapped as a COW page,
> > > we will hit the warning when doing wp_page_copy().
>
> Hmm, can the debug code assume anything? Right now you're just patching
> it from supporting linear and vmalloc. But what about other
> potential mapping types?
thanks for the review.
ARCHs like metag and xtensa define their mappings (non-vmalloc and
non-linear) for dma allocation.
These mapping types are architecture-dependent and should not be used
outside arch folders. So it is hard to check the mappings and convert
a virtual address to a correct pfn in lib/dam-debug.c
How about recording only vmalloc (by is_vmalloc_addr()) and linear
address (by virt_addr_valid()) in lib/dma-debug? Since current
implementation is not correct for those ARCHs.
if (!is_vmalloc_addr(addr) && !virt_addr_valid(addr))
return;
or
every ARCH should define its own dmava-to-pfn API to convert
a dma-allocted virtual address to a correct pfn and lib/dma-debug.c
can use that API directly. (long-term)
>
> > > + entry->pfn = is_vmalloc_addr(virt) ? vmalloc_to_pfn(virt) :
> > > + page_to_pfn(virt_to_page(virt));
>
> Please use normal if/else conditionsals:
Is this for better readability? I'll send another patch for this.
thanks
>
> if (is_vmalloc_addr(virt))
> entry->pfn = vmalloc_to_pfn(virt);
> else
> entry->pfn = page_to_pfn(virt_to_page(virt));
>
> > > + .pfn = is_vmalloc_addr(virt) ? vmalloc_to_pfn(virt) :
> > > + page_to_pfn(virt_to_page(virt)),
>
> Same here.
WARNING: multiple messages have this Message-ID (diff)
From: Miles Chen <miles.chen@mediatek.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Robin Murphy <robin.murphy@arm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Andrew Morton <akpm@linux-foundation.org>,
wsd_upstream@mediatek.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, iommu@lists.linux-foundation.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v3] dma-debug: fix incorrect pfn calculation
Date: Mon, 2 Oct 2017 18:30:41 +0800 [thread overview]
Message-ID: <1506940241.28397.36.camel@mtkswgap22> (raw)
In-Reply-To: <20171001080449.GB11843@lst.de>
On Sun, 2017-10-01 at 10:04 +0200, Christoph Hellwig wrote:
> On Wed, Sep 27, 2017 at 11:23:52AM +0100, Robin Murphy wrote:
> > > I found that debug_dma_alloc_coherent() and debug_dma_free_coherent()
> > > assume that dma_alloc_coherent() always returns a linear address.
> > > However it's possible that dma_alloc_coherent() returns a non-linear
> > > address. In this case, page_to_pfn(virt_to_page(virt)) will return an
> > > incorrect pfn. If the pfn is valid and mapped as a COW page,
> > > we will hit the warning when doing wp_page_copy().
>
> Hmm, can the debug code assume anything? Right now you're just patching
> it from supporting linear and vmalloc. But what about other
> potential mapping types?
thanks for the review.
ARCHs like metag and xtensa define their mappings (non-vmalloc and
non-linear) for dma allocation.
These mapping types are architecture-dependent and should not be used
outside arch folders. So it is hard to check the mappings and convert
a virtual address to a correct pfn in lib/dam-debug.c
How about recording only vmalloc (by is_vmalloc_addr()) and linear
address (by virt_addr_valid()) in lib/dma-debug? Since current
implementation is not correct for those ARCHs.
if (!is_vmalloc_addr(addr) && !virt_addr_valid(addr))
return;
or
every ARCH should define its own dmava-to-pfn API to convert
a dma-allocted virtual address to a correct pfn and lib/dma-debug.c
can use that API directly. (long-term)
>
> > > + entry->pfn = is_vmalloc_addr(virt) ? vmalloc_to_pfn(virt) :
> > > + page_to_pfn(virt_to_page(virt));
>
> Please use normal if/else conditionsals:
Is this for better readability? I'll send another patch for this.
thanks
>
> if (is_vmalloc_addr(virt))
> entry->pfn = vmalloc_to_pfn(virt);
> else
> entry->pfn = page_to_pfn(virt_to_page(virt));
>
> > > + .pfn = is_vmalloc_addr(virt) ? vmalloc_to_pfn(virt) :
> > > + page_to_pfn(virt_to_page(virt)),
>
> Same here.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Miles Chen <miles.chen@mediatek.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Robin Murphy <robin.murphy@arm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Andrew Morton <akpm@linux-foundation.org>,
<wsd_upstream@mediatek.com>, <linux-kernel@vger.kernel.org>,
<linux-mm@kvack.org>, <iommu@lists.linux-foundation.org>,
<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH v3] dma-debug: fix incorrect pfn calculation
Date: Mon, 2 Oct 2017 18:30:41 +0800 [thread overview]
Message-ID: <1506940241.28397.36.camel@mtkswgap22> (raw)
In-Reply-To: <20171001080449.GB11843@lst.de>
On Sun, 2017-10-01 at 10:04 +0200, Christoph Hellwig wrote:
> On Wed, Sep 27, 2017 at 11:23:52AM +0100, Robin Murphy wrote:
> > > I found that debug_dma_alloc_coherent() and debug_dma_free_coherent()
> > > assume that dma_alloc_coherent() always returns a linear address.
> > > However it's possible that dma_alloc_coherent() returns a non-linear
> > > address. In this case, page_to_pfn(virt_to_page(virt)) will return an
> > > incorrect pfn. If the pfn is valid and mapped as a COW page,
> > > we will hit the warning when doing wp_page_copy().
>
> Hmm, can the debug code assume anything? Right now you're just patching
> it from supporting linear and vmalloc. But what about other
> potential mapping types?
thanks for the review.
ARCHs like metag and xtensa define their mappings (non-vmalloc and
non-linear) for dma allocation.
These mapping types are architecture-dependent and should not be used
outside arch folders. So it is hard to check the mappings and convert
a virtual address to a correct pfn in lib/dam-debug.c
How about recording only vmalloc (by is_vmalloc_addr()) and linear
address (by virt_addr_valid()) in lib/dma-debug? Since current
implementation is not correct for those ARCHs.
if (!is_vmalloc_addr(addr) && !virt_addr_valid(addr))
return;
or
every ARCH should define its own dmava-to-pfn API to convert
a dma-allocted virtual address to a correct pfn and lib/dma-debug.c
can use that API directly. (long-term)
>
> > > + entry->pfn = is_vmalloc_addr(virt) ? vmalloc_to_pfn(virt) :
> > > + page_to_pfn(virt_to_page(virt));
>
> Please use normal if/else conditionsals:
Is this for better readability? I'll send another patch for this.
thanks
>
> if (is_vmalloc_addr(virt))
> entry->pfn = vmalloc_to_pfn(virt);
> else
> entry->pfn = page_to_pfn(virt_to_page(virt));
>
> > > + .pfn = is_vmalloc_addr(virt) ? vmalloc_to_pfn(virt) :
> > > + page_to_pfn(virt_to_page(virt)),
>
> Same here.
next prev parent reply other threads:[~2017-10-02 10:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-27 3:48 [PATCH v3] dma-debug: fix incorrect pfn calculation miles.chen
2017-09-27 3:48 ` miles.chen
2017-09-27 3:48 ` miles.chen
2017-09-27 10:23 ` Robin Murphy
2017-09-27 10:23 ` Robin Murphy
2017-10-01 8:04 ` Christoph Hellwig
2017-10-01 8:04 ` Christoph Hellwig
2017-10-02 10:30 ` Miles Chen [this message]
2017-10-02 10:30 ` Miles Chen
2017-10-02 10:30 ` Miles Chen
2017-10-03 7:07 ` Christoph Hellwig
2017-10-03 7:07 ` Christoph Hellwig
2017-10-03 7:07 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1506940241.28397.36.camel@mtkswgap22 \
--to=miles.chen@mediatek.com \
--cc=akpm@linux-foundation.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=wsd_upstream@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.