All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang YanQing <udknight@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Michal Januszewski <spock@gentoo.org>,
	linux-fbdev@vger.kernel.org, x86@kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] x86: export 'pcibios_enabled'
Date: Thu, 22 Mar 2012 08:41:35 +0800	[thread overview]
Message-ID: <20120322004135.GA4253@udknight> (raw)
In-Reply-To: <20120314112137.68fa4f70@pyramind.ukuu.org.uk>

On Wed, Mar 14, 2012 at 11:21:37AM +0000, Alan Cox wrote:
> You can use set_memory_x() to mark memory executable (and _nx to set it back).
> 
NO I can't, if I set_memory_x and don't set pcibios_enabled = 1, then
static_protections will still failed because pcibios_enabled == 0, 
and I don't want to use set_memory_x, because I don't want to give the user 
of uvesafb that feeling "I will lost BIOS NX protection if I choice uvesafb."

> If you really need to know if NX is being used then the check
> 
> 	if (__supported_pte_mask & PTE_NX)
> 
> will do the trick and the variable is exported.
I don't understand what do you mean, do you means CONFIG_X86_PAE for 32? Or CONFIG_X86_64?
when NX is being used, the pci bios is NX or not also depend on
ACPI.ACPI on or off all will influnce the code path in pci_arch_init,
decide the set_bios_x have chance to execute or not.See
https://lkml.org/lkml/2011/11/16/84

By the way _PAGE_NX instead of PTE_NX, right?

> I'd suggest however you wrap that in a cpu_has_nx() type macro somewhere
> in the arch headers.
> 
The same above.

> If you go poking around pcibios values you are going to get burned if
> someone is ever bored enough to make NX and PCIBIOS work together
> differently.
> 
Indeed according to 5bd5a452662bc37c54fb6828db1a3faf87e6511c, who bring me 
the trouble, check the pcibios_enabled is the only simple and good way to 
resolve the Oops I meet.

If you really don't want it, and if I am not all wrong about your "helper method",
you means you want export the below:
int check_pcibios_enabled()?
See https://lkml.org/lkml/2012/2/26/124

Thanks.


WARNING: multiple messages have this Message-ID (diff)
From: Wang YanQing <udknight@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Michal Januszewski <spock@gentoo.org>,
	linux-fbdev@vger.kernel.org, x86@kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] x86: export 'pcibios_enabled'
Date: Thu, 22 Mar 2012 00:41:35 +0000	[thread overview]
Message-ID: <20120322004135.GA4253@udknight> (raw)
In-Reply-To: <20120314112137.68fa4f70@pyramind.ukuu.org.uk>

On Wed, Mar 14, 2012 at 11:21:37AM +0000, Alan Cox wrote:
> You can use set_memory_x() to mark memory executable (and _nx to set it back).
> 
NO I can't, if I set_memory_x and don't set pcibios_enabled = 1, then
static_protections will still failed because pcibios_enabled = 0, 
and I don't want to use set_memory_x, because I don't want to give the user 
of uvesafb that feeling "I will lost BIOS NX protection if I choice uvesafb."

> If you really need to know if NX is being used then the check
> 
> 	if (__supported_pte_mask & PTE_NX)
> 
> will do the trick and the variable is exported.
I don't understand what do you mean, do you means CONFIG_X86_PAE for 32? Or CONFIG_X86_64?
when NX is being used, the pci bios is NX or not also depend on
ACPI.ACPI on or off all will influnce the code path in pci_arch_init,
decide the set_bios_x have chance to execute or not.See
https://lkml.org/lkml/2011/11/16/84

By the way _PAGE_NX instead of PTE_NX, right?

> I'd suggest however you wrap that in a cpu_has_nx() type macro somewhere
> in the arch headers.
> 
The same above.

> If you go poking around pcibios values you are going to get burned if
> someone is ever bored enough to make NX and PCIBIOS work together
> differently.
> 
Indeed according to 5bd5a452662bc37c54fb6828db1a3faf87e6511c, who bring me 
the trouble, check the pcibios_enabled is the only simple and good way to 
resolve the Oops I meet.

If you really don't want it, and if I am not all wrong about your "helper method",
you means you want export the below:
int check_pcibios_enabled()?
See https://lkml.org/lkml/2012/2/26/124

Thanks.


  reply	other threads:[~2012-03-22  0:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13  9:41 linux-next: Tree for Mar 13 Stephen Rothwell
2012-03-13 17:10 ` linux-next: Tree for Mar 13 (dlm / gfs2) Randy Dunlap
2012-03-13 20:30 ` [PATCH] x86: export 'pcibios_enabled' Randy Dunlap
2012-03-13 20:30   ` Randy Dunlap
2012-03-14  0:43   ` H. Peter Anvin
2012-03-14  0:43     ` H. Peter Anvin
2012-03-14  9:29     ` Alan Cox
2012-03-14 10:59       ` Florian Tobias Schandinat
2012-03-14 11:21         ` Alan Cox
2012-03-22  0:41           ` Wang YanQing [this message]
2012-03-22  0:41             ` Wang YanQing
2012-03-26  0:27             ` Wang YanQing
2012-03-26  0:27               ` Wang YanQing
2012-03-16  0:41     ` Wang YanQing
2012-03-16  0:41       ` Wang YanQing
2012-03-19  0:30   ` Wang YanQing
2012-03-19  0:30     ` Wang YanQing
2012-03-19  1:03     ` [PATCH v2] x86: export 'pcibios_enabled' as GPL Randy Dunlap
2012-03-19  1:03       ` Randy Dunlap
2012-03-21  4:37       ` Wang YanQing
2012-03-21  4:37         ` Wang YanQing
2012-03-21  9:29         ` Alan Cox
2012-03-13 21:06 ` linux-next: Tree for Mar 13 (ata) Randy Dunlap
2012-03-13 21:22   ` Jeff Garzik
2012-03-14  0:36     ` Dan Williams

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=20120322004135.GA4253@udknight \
    --to=udknight@gmail.com \
    --cc=FlorianSchandinat@gmx.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=hpa@zytor.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=sfr@canb.auug.org.au \
    --cc=spock@gentoo.org \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.