linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Jinjiang Tu <tujinjiang@huawei.com>
Cc: Will Deacon <will@kernel.org>,
	akpm@linux-foundation.org, david@kernel.org,
	zengheng4@huawei.com, ryan.roberts@arm.com,
	anshuman.khandual@arm.com, wangkefeng.wang@huawei.com,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH v3] arm64: mm: fix pass user prot to ioremap_prot in generic_access_phys
Date: Thu, 5 Feb 2026 14:31:47 +0000	[thread overview]
Message-ID: <aYSp0--x_QgyiUWL@arm.com> (raw)
In-Reply-To: <a4ee7faa-5b0d-4ffa-bc06-939d95ef7680@huawei.com>

On Thu, Feb 05, 2026 at 03:23:27PM +0800, Jinjiang Tu wrote:
> 在 2026/2/3 17:23, Will Deacon 写道:
> > On Tue, Feb 03, 2026 at 11:38:15AM +0800, Jinjiang Tu wrote:
> > > 在 2026/2/2 22:55, Will Deacon 写道:
> > > > On Fri, Jan 30, 2026 at 03:38:07PM +0800, Jinjiang Tu wrote:
> > > > > +#define arch_mk_kernel_prot arch_mk_kernel_prot
> > > > > +static inline pgprot_t arch_mk_kernel_prot(pgprot_t user_prot)
> > > > > +{
> > > > > +	ptdesc_t mem_type = pgprot_val(user_prot) & PTE_ATTRINDX_MASK;
> > > > > +
> > > > > +	return __pgprot_modify(PAGE_KERNEL, PTE_ATTRINDX_MASK, mem_type);
> > > > > +}
> > > > 
> > > > Do we really need another arch helper here?
[...]
> > My point is that we already have the helper: ioremap_prot(). Just fix
> > that for arm64 and cc the other arch maintainers if you're not sure how
> > to fix it for them. What we don't need to do is add an additional helper.
> 
> ioremap_prot() may be called outside of arch/arm64 in the future, and I think
> most of the cases will not pass a user prot to ioremap_prot().
> 
> generic_access_phys() is a special case, so I want to limit the modification to
> generic_access_phys() only.

Or we can just have an ioremap_user_prot() (or some more meaningful
name), defined by default as ioremap_prot(). It's still introducing a
new macro though, unless we go and rename it on all architectures.

-- 
Catalin


  reply	other threads:[~2026-02-05 14:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-30  7:38 Jinjiang Tu
2026-01-30 12:19 ` Catalin Marinas
2026-01-31  0:07   ` Jinjiang Tu
2026-02-02 14:55 ` Will Deacon
2026-02-03  3:38   ` Jinjiang Tu
2026-02-03  9:23     ` Will Deacon
2026-02-05  7:23       ` Jinjiang Tu
2026-02-05 14:31         ` Catalin Marinas [this message]
2026-02-05 17:36           ` Will Deacon
2026-02-05 18:25             ` Catalin Marinas
2026-02-06 12:08               ` Catalin Marinas
2026-02-09 12:02                 ` Will Deacon
2026-02-18 16:22                   ` Will Deacon

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=aYSp0--x_QgyiUWL@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=david@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=tujinjiang@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=zengheng4@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox