Escalated to Bugzilla from IssueTracker
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-34.EL).
The fix has been bounced from the RHEL3 U6 respin because it broke the build.
Reverting to ASSIGNED state.
A fix for this problem has just been committed to the RHEL3 U7
patch pool this evening (in kernel version 2.4.21-37.1.EL).
Please note that this bug has been marked x86-specific (hardware field
is set to "i686"), and the fix committed in -37.1.EL only resolves this
problem on x86 RPMs.
An analogous problem might also occur on x86_64 (and ia32e) kernels. If
so, a new x86_64-specific bugzilla should be created with an appropriate
patch for the (different) associated source code.
This fix has been found to cause boot-up failures on certain types of
systems. This is now deemed a U7 regression (because the fix was
committed to the 1st U7 build).
Reverting to ASSIGNED state until this has been resolved.
A new (alternative) patch has been posted for internal review. It addresses
the boot-up regression on NX-capable systems as well as the original problem
on both x86 and x86_64 arches.
We anticipate reverting the original patch in the next U7 build.
Created attachment 119353 [details]
new patch under review
This is the alternate patch, which should apply cleanly on top of RHEL3 U6.
If it passes review, it will be committed to U7 after the patch committed
to -37.1.EL is reverted.
Created attachment 119399 [details]
revised patch under review
The prior patch was not correct for x86_64. This new patch contains
identical changes for x86 but revised changes for x86_64.
The patch in comment #32 has just been committed to the RHEL3 U7
patch pool this evening (in kernel version 2.4.21-37.4.EL).
Note that these fixes resolve the change_page_attr()/NX/large-page
problems for both x86 and x86_64 architectures, and thus comment #27
(regarding creating a different BZ for x86_64) is no longer applicable.
See comments from Dell engineering and consider modifying the patch as appropriate :
Event posted 10-05-2005 11:30am by stuart_hayes
Ernie2.patch loses the _PAGE_NX bit (in i386) when it reverts pages back into a
large page, because it is reverting pages into PAGE_KERNEL_PSE (which doesn't
have the NX bit set).
That shouldn't actually break anything, but it kind of defeats the purpose of
having an NX bit. This could be fixed by passing "is_kern_mapping" to revert
page in the i386 arch (not just the x86_64 arch), and using
"__pgprot(__PAGE_KERNEL_LARGE)" instead of "PAGE_KERNEL_PSE" in the
revert_page() function if the NX bit should be set.
I'm running the patch as is now (with the i386 architecture).
I did consider making revert_page() on i386 do something more intelligent.
However, in the interest of wanting to avoid any potential for regressions,
I leaned towards maintaining its existing behavior (always reverting to a
non-NX huge page).
That being said, I'd be supportive of a future change to tighten up NX
protection, which would need to be done in revert_page() and free_initmem().
It's not needed to resolve this bugzilla, but it's a good idea in principle.
I'd favor introducing a new set of macros in include/asm-i386/pgtable.h to
parallel PAGE_KERNEL_PSE but with the NX bit conditionally set (or perhaps
PAGE_KERNEL_PSE should be changed and a non-NX version should be added,
which would be closer to the x86_64 fix).
Unlinking Issue Tracker ticket 75455 from this bug, since the IT is actually
regarding a bug in the NVidia driver (see bug 164500 for more details).
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.