linux-kernel - Re: [PATCH] [9/9] GBPAGES: Do kernel direct mapping at boot using GB pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Jan 2008 18:10:02 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andi Kleen <ak@...e.de>
cc:	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [9/9] GBPAGES: Do kernel direct mapping at boot using
 GB pages

On Thu, 31 Jan 2008, Andi Kleen wrote:

> On Thu, Jan 31, 2008 at 05:17:41PM +0100, Thomas Gleixner wrote:
> > On Tue, 29 Jan 2008, Andi Kleen wrote:
> > >
> > > +static unsigned long direct_entry(unsigned long paddr)
> > 
> > Please use a more sensible function name. This one has no association
> > with the functionality at all.
> 
> Can you suggest one? I honestly cannot think of a better one.
> Its's a "entry" in the "direct" mapping.

Doh, yes :) It just did not trigger.

> > > +	if (direct_gbpages >= 0 && cpu_has_gbpages) {
> > > +		printk(KERN_INFO "Using GB pages for direct mapping\n");
> > > +		direct_gbpages = 1;
> > > +	} else
> > > +		direct_gbpages = 0;
> > > +}
> > 
> > Please use simple boolean logic. gbpages are either enabled or disabled.
> 
> It's a fairly standard widely used idiom for command line options because 
> it allows default and forcing.  e.g. there can be cases when the kernel
> disables it, but then it makes sense for the command line option
> to override it. There is already one case in the kernel that 
> disables it.

Right, but please use some constants. I was tripping over the 

       if (direct_gbpages > 0)

somewhere else in the code and it would have been simpler to see
something like:

	if (direct_gbpages == GBPAGES_ENABLED)

> > >   * prefetches from the CPU leading to inconsistent cache lines.
> > > @@ -467,6 +511,8 @@ __clear_kernel_mapping(unsigned long add
> > >  			continue;
> > >  
> > >  		pud = pud_offset(pgd, address);
> > > +		if (pud_large(*pud))
> > > +			split_gb_page(pud, __pa(address));
> > >  		if (pud_none(*pud))
> > >  			continue;
> > 
> > As I said before, this needs to use CPA and not implement another variant.
> 
> Ok, I can switch GART over to CPA, but that will make the patch
> much more intrusive and a little riskier. Is that ok for you
> and will it be still considered .25 candidate? 

We have the code in place already and we need to shake out any
remaining problems anyway. So using the CPA code would be preferred as
it adds another user. Can you give it a try please ?

Thanks,
	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/