From: Wang YanQing <udknight@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
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: Mon, 26 Mar 2012 00:27:01 +0000 [thread overview]
Message-ID: <20120326002701.GA3624@udknight> (raw)
In-Reply-To: <20120322004135.GA4253@udknight>
On Thu, Mar 22, 2012 at 08:41:35AM +0800, Wang YanQing wrote:
> 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.
>
Sorry for the delay reply and cross email threads, Alan Cox.
But I still can't find a better way then to check the pcibios_enabled variable,
any better suggestion?
WARNING: multiple messages have this Message-ID (diff)
From: Wang YanQing <udknight@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
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: Mon, 26 Mar 2012 08:27:01 +0800 [thread overview]
Message-ID: <20120326002701.GA3624@udknight> (raw)
In-Reply-To: <20120322004135.GA4253@udknight>
On Thu, Mar 22, 2012 at 08:41:35AM +0800, Wang YanQing wrote:
> 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.
>
Sorry for the delay reply and cross email threads, Alan Cox.
But I still can't find a better way then to check the pcibios_enabled variable,
any better suggestion?
next prev parent reply other threads:[~2012-03-26 0:27 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
2012-03-22 0:41 ` Wang YanQing
2012-03-26 0:27 ` Wang YanQing [this message]
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=20120326002701.GA3624@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.