From: Andreas Larsson <andreas@gaisler.com>
To: Christoph Hellwig <hch@lst.de>
Cc: David Miller <davem@davemloft.net>,
sparclinux@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>,
linux-kernel@vger.kernel.org, software@gaisler.com
Subject: Re: [PATCH] sparc32: Page align size in arch_dma_alloc
Date: Tue, 14 Sep 2021 13:16:16 +0200 [thread overview]
Message-ID: <a5483206-0539-1d3f-c8e8-e66dbb6c8d96@gaisler.com> (raw)
In-Reply-To: <20210914104256.GA14645@lst.de>
Please consider the environment before printing this email
On 2021-09-14 12:42, Christoph Hellwig wrote:
>> The added pgprot_dmacoherent is problematic as it sets SRMMU_PRIV, which
>> sets up kernel access only. This was fine for arch_dma_alloc that sets up
>> kernel accesses only, but for user space DMA mmap this would make them
>> kernel accessable only. Having no sparc-specific pgprot_dmacoherent,
>> keeping it to default to pgprot_noncached, is probably better.
>
> I've just tried to keep the existing attributes. If SRMMU_PRIV does
> indeed mean that the page can't also be mapped into userspace page tables
> it would be good to remove it in an incremental patch. If OTOH it only
> means that this PTE is a kernel mapping it should not affect a userspace
> mapping as that will always use separate PTEs.
Before the patch, arch_dma_alloc did via srmmu_mapiorange set up pages
with SRMMU_PRIV, which is all fine as it sets up kernel buffers. With
your patch we get PAGE_KERNEL as an argument to dma_pgprot in the
corresponding call path that earlier lead to arch_dma_alloc. PAGE_KERNEL
already includes SRMMU_PRIV so adding it again should not be necessary.
The problem I am pointing to is that adding a pgprot_dmacoherent that
adds SRMMU_PRIV, changes the behaviour of other call paths that calls
dma_pgprot but are not mapping in kernel pages.
Now this is not confirmed in execution from my side, but it seems that
from following the code that e.g. this call path that is about mapping
DMA pages accessible from user space:
dma_mmap_attrs -> dma_direct_mmap -> dma_pgprot -> pgprot_dmacoherent
goes from making it merely uncacheable with the default
#ifndef pgprot_dmacoherent
#define pgprot_dmacoherent(prot) pgprot_noncached(prot)
#endif
to also being non-user-accessible if we change to this pgprot_dmacoherent
#define pgprot_dmacoherent pgprot_dmacoherent
static inline pgprot_t pgprot_dmacoherent(pgprot_t prot)
{
pgprot_val(prot) &= ~pgprot_val(__pgprot(SRMMU_CACHE));
pgprot_val(prot) |= pgprot_val(__pgprot(SRMMU_PRIV));
return prot;
}
--
Andreas Larsson
next prev parent reply other threads:[~2021-09-14 11:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-08 7:48 [PATCH] sparc32: Page align size in arch_dma_alloc Andreas Larsson
2021-09-09 6:07 ` Christoph Hellwig
2021-09-13 13:18 ` Andreas Larsson
2021-09-14 6:17 ` Christoph Hellwig
2021-09-14 8:51 ` Andreas Larsson
2021-09-14 10:42 ` Christoph Hellwig
2021-09-14 11:16 ` Andreas Larsson [this message]
2021-09-14 11:26 ` Christoph Hellwig
[not found] ` <YTjfJl6YmBCdZ8XB@ravnborg.org>
2021-09-14 6:12 ` Christoph Hellwig
2021-09-14 11:39 ` David Miller
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=a5483206-0539-1d3f-c8e8-e66dbb6c8d96@gaisler.com \
--to=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=software@gaisler.com \
--cc=sparclinux@vger.kernel.org \
/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.