[PATCH v3] arm64: mm: fix pass user prot to ioremap_prot in generic_access_phys

[Will Deacon]

On Thu, Feb 05, 2026 at 02:31:47PM +0000, Catalin Marinas wrote:
> 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.

ioremap_prot() has exactly one caller outside of arch code and that is
generic_access_phys(). We should just fix the arm64 implementation of
ioremap_prot() and not introduce any new macros. If a new caller comes
along later, we can figure out what to do then. We could shout if the
prot isn't a user prot so we detect the problem.

Will