On Thu, Mar 15, 2018 at 07:49:01PM +0530, Chintan Pandya wrote:
> On 3/15/2018 7:01 PM, Mark Rutland wrote:
> > On Thu, Mar 15, 2018 at 06:15:04PM +0530, Chintan Pandya wrote:
> > > @@ -91,10 +93,15 @@ static inline int ioremap_pmd_range(pud_t *pud,
> > > unsigned long addr,
> > > if (ioremap_pmd_enabled() &&
> > > ((next - addr) == PMD_SIZE) &&
> > > - IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
> > > - pmd_free_pte_page(pmd)) {
> > > - if (pmd_set_huge(pmd, phys_addr + addr, prot))
> > > + IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
> > > + old_pmd = *pmd;
> > > + pmd_clear(pmd);
> > > + flush_tlb_pgtable(&init_mm, addr);
> > > + if (pmd_set_huge(pmd, phys_addr + addr, prot)) {
> > > + pmd_free_pte_page(&old_pmd);
> > > continue;
> > > + } else
> > > + set_pmd(pmd, old_pmd);
> > > }
> >
> > Can we have something like a pmd_can_set_huge() helper? Then we could
> > avoid pointless modification and TLB invalidation work when
> > pmd_set_huge() will fail.
>
> Actually, pmd_set_huge() will never fail because, if
> CONFIG_HAVE_ARCH_HUGE_VMAP is disabled, ioremap_pmd_enabled()
> will fail and if enabled (i.e. ARM64 & x86), they don't fail
> in their implementation. So, rather we can do the following.
AFAICT, that's not true. The x86 pmd_set_huge() can fail under certain
conditions:
int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot)
{
u8 mtrr, uniform;
mtrr = mtrr_type_lookup(addr, addr + PMD_SIZE, &uniform);
if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) &&
(mtrr != MTRR_TYPE_WRBACK)) {
pr_warn_once("%s: Cannot satisfy [mem %#010llx-%#010llx] with a
huge-page mapping due to MTRR override.\n",
__func__, addr, addr + PMD_SIZE);
return 0;
}
prot = pgprot_4k_2_large(prot);
set_pte((pte_t *)pmd, pfn_pte(
(u64)addr >> PAGE_SHIFT,
__pgprot(pgprot_val(prot) | _PAGE_PSE)));
return 1;
}
... perhaps that can never happen in this particular case, but that's
not clear to me.
Thanks,
Mark.
