[PATCH V5 1/2] arm: mm: Introduce {pte,pmd}_isset and {pte,pmd}_isclear

Steve Capper steve.capper at linaro.org
Fri Jun 27 05:48:33 PDT 2014


On Fri, Jun 27, 2014 at 01:34:34PM +0100, Will Deacon wrote:
> On Fri, Jun 27, 2014 at 01:24:00PM +0100, Steve Capper wrote:
> > On Fri, Jun 27, 2014 at 12:24:20PM +0100, Will Deacon wrote:
> > > On Tue, Jun 24, 2014 at 01:23:23PM +0100, Steve Capper wrote:
> > > >  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > > > -#define pmd_trans_huge(pmd)	(pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT))
> > > > -#define pmd_trans_splitting(pmd) (pmd_val(pmd) & PMD_SECT_SPLITTING)
> > > > +#define pmd_trans_huge(pmd)	(pmd_val(pmd) && pmd_isclear((pmd), PMD_TABLE_BIT))
> > > 
> > > Why isn't this just pmd_present(pmd) && !pmd_table(pmd)? Put another way, I
> > > see to have forgotten why we need PMD_TABLE_BIT instead of just using
> > > pmd_table and pmd_sect to work out whether we have a table or a block.
> > > 
> > 
> > If we use pmd_sect, we are testing for block entries, but THPs are allowed to
> > be faulting entries (i.e. PROT_NONE). A non-zero pmd that does not have the
> > table bit set can safely be assumed to be a PROT_NONE THP.
> 
> Ah yes, I forgot about faulting entries. We should still be able to use
> pmd_table(pmd) as opposed to PMD_TABLE_BIT though, right?

Yes, that should be okay, thanks I'll simplify this.

> 
> Will



More information about the linux-arm-kernel mailing list