[PATCH FC6] x86_64 page_is_ram() uses __initdata; breaks /dev/crash and /dev/mem restriction
by Dave Anderson
Somewhere after the 2.6.18 timeframe, Andi Kleen made the
x86_64 e820 map __initdata:
struct e820map e820 __initdata;
This is fine for upstream x86_64 kernels, because the e820 map never
gets used during runtime. But because we (RHEL/Fedora) have an x86_64
version of page_is_ram(), it ends up using __init data.
I became aware of this when I got an FC6/crash-utility bugzilla #237383,
filed because the crash utility started failing on later FC6 live systems.
This is because the kernel's /dev/crash module crash.ko started failing
because it uses page_is_ram() as a memory access qualifer.
Also, because of Red Hat's restriction on the use of /dev/mem to only
the first 256 RAM pages, the __initdata addition ends up opening the flood
gates for /dev/mem usage. That's because of this:
/*
* devmem_is_allowed() checks to see if /dev/mem access to a certain address is
* valid. The argument is a physical page number.
*
*
* On x86-64, access has to be given to the first megabyte of ram because that area
* contains bios code and data regions used by X and dosemu and similar apps.
* Access has to be given to non-kernel-ram areas as well, these contain the PCI
* mmio resources as well as potential bios/acpi data regions.
*/
int devmem_is_allowed(unsigned long pagenr)
{
if (pagenr <= 256)
return 1;
if (!page_is_ram(pagenr))
return 1;
return 0;
}
The function is meant to allow /dev/mem accesses above pagenr 256
only if they are *not* RAM -- but since since page_is_ram() is failing,
it inadvertantly allows access to any pagenr.
(Interestingly enough, this bug allows the user of the crash
utility to work around the /dev/crash failure by alternatively
using /dev/mem instead! /dev/crash was only created to begin
with because of the /dev/mem restriction...
Anyway, reverting back from __initdata fixes the situation for both
/dev/crash and the /dev/mem restriction.
Dave Anderson
(patch is against 2.6.20-1.2944)
--- linux-2.6.20.x86_64/arch/x86_64/kernel/e820.c.orig 2007-04-26 14:38:12.000000000 -0400
+++ linux-2.6.20.x86_64/arch/x86_64/kernel/e820.c 2007-04-26 14:38:24.000000000 -0400
@@ -25,7 +25,7 @@
#include <asm/bootsetup.h>
#include <asm/sections.h>
-struct e820map e820 __initdata;
+struct e820map e820;
/*
* PFN of last memory page.
16 years
Pre-release kernel versioning
by Thorsten Leemhuis
Hi all!
I'd like to put a old but still valid discussion on the table again
where a solution never was found: Pre-release kernel versioning.
In short: Kernel like for example kernel-2.6.20-1.3066.fc7 are in
reality 2.6.21-rc6-git5. That's not only confusing to users, it also
breaks outside kernel modules sometimes; just yesterday I saw a patch in
3rd party repo applied that did this...
+-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21)
++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
...to make it compile against the kernel from FC4-test4 (no idea if it
helped, but I had to apply similar patches in the past nyself to make
somethign work), as the kernels in rawhide until they switched to
2.6.21-final announces itself as 2.6.20-1.3066.fc7 instead of
2.6.21-rc6-git5, as upstream would do.
I don't want to get further into the details if I don't have to, as this
stuff was discussed multiple times already on mailing lists. The last
time was here:
https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00897.html
So, what will we do in the future? Can we (after F7 is out and rawhide
rolls again) please switch to something less confusing where version
somehow allows normal users to clearly see what kernel they got? And one
that doesn't confuse outside modules? Something like
kernel-2.6.22-1.3200.fc7.rc2.git15
maybe?
CU
thl
16 years, 1 month
Keep the FC6 kernel at 2.6.20 or move it to 2.6.21?
by Chuck Ebbert
The number of bugs reported against the FC6 kernel is now dropping.
Should we move to kernel 2.6.21 and risk a whole new wave of bug reports,
or leave it on 2.6.20 and live with the fact that some things can't/won't
be fixed right, like support for PCI message signaled interrupts?
16 years, 1 month
About audio programming
by bluehat prometheus
Hello!
I want to know something more about audio programming on Fedora
I using Fedora Core 4 ,by the way.
But I have no idea about it, can anyone tell me how to do with it??
Such as which header file to use, libs, etc. Please give me a sample if you
can..
Thanks,pretty thanks!!
16 years, 1 month
[OT] please review new kernel build doc on fedora wiki
by Sam Folk-Williams
Hi,
I (with DaveJ) help maintain the kernel release notes for Fedora. A user suggested a
while back that we remove the building instructions from the release notes and
put those in a separate doc devoted to more detailed instructions on building
the kernel RPM (including applying patches and configuring options).
I've got a draft doc now. I come to this from a support perspective - building
kernels with patches I get from Engineering to pass on for testing. I'd like to
get the point of view of some kernel developers as well.
- Is what's here correct?
- Is there more that should be here?
- Does the info here conform to best practices?
Any feedback appreciated. I am happy to make edits myself if you reply, or of
course any one can make edits on their own.
http://fedoraproject.org/wiki/Docs/Drafts/CustomKernel
Thanks,
Sam
--
Sam Folk-Williams, RHCE Red Hat Global Support Services
Phone: 919/754-4558 GPG ID: 1B0D46BA
16 years, 1 month
Re: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21?
by Christopher Brown
> On 18.04.2007 23:23, Dave Jones wrote:
> > On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote:
> > > I'd say let F7 testing iron out 2.6.21 for a while before deciding
> about
> > > FC6. We should be in the part of freeze where serious Fedora weenies
> are
> > > doing a lot of testing.
> > Getting 2.6.21 into FC6 does also have the additional advantage that
> > it's an extra round of testing for what will become the F7 kernel.
>
> +1 -- putting in in updates-testing quite soon might be a start.
+1 for moving it straight into updates for reasons already stated plus isn't
a kernel upgrade dependent on user confirmation? I have always felt for this
reason that updates-testing is not the right place for testing kernels as
the installonlyn plugin for yum ensures that a backup kernel (hopefully
stable) is always available.
Cheers
Chris
--
http://www.chruz.com
16 years, 1 month
solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys
by Daniel Kirsten
Hallo,
we discussed the following problem in march
>my compiled 2.6.20-1.2925 kernel does not boot.
>It hangs after unmounting the old proc and
>sys filesystems. However, I can still use
>Ctrl+Alt+Del to reboot.
>
>Maybe, the problem is related to Selinux.
>
>My compiled kernels 2.6.19-1.2895 and 2.6.19-1.2911
>worked fine, and I did not change the kernel
>configuration.
>
>The Fedora-kernels 2.6.19-1.2895, 2.6.19-1.2911 and
>2.6.20-1.2925 also work.
The same problem occured in 2.6.20-1.2933.
However, in a needle-in-the-haystick search, I solved the
problem by DISabeling the option
Compat VDSO support (COMPAT_VDSO)
Best regards, Daniel
16 years, 1 month
Spinning kernel-vanilla packages via standard spec
by Jarod Wilson
A little follow-on to the "Longing for git-bisect" thread, in a
newly-created/subjected thread...
So, I've been poking around in the kernel spec file extensively the past
few days already... Any objections to my attempting to implement the
building of a kernel-vanilla package as well?
Roland, not sure if you were already planning to do this in conjunction
with digging up your old patches, or if you were just throwing the
patches out there, but either way, I'm happy to take on the task, but
I'll defer to anyone else that really wants to do it.
--
Jarod Wilson
jwilson(a)redhat.com
16 years, 2 months
Make "pci=nomsi" the default on 2.6.20 kernels?
by Chuck Ebbert
It seems like more and more problems with PCI MSI are turning up
in the 2.6.20 kernel. Discussion upstream concluded that maybe
it should have been off by default in 2.6.20, so maybe we should
just do that in Fedora and make people who want it use "pci=msi"
to enable it? It's probably not going to be really stable until
2.6.22...
16 years, 2 months
Putting the full unstripped modules in the kernel-debuginfo package
by Chuck Ebbert
Right now we package the debuginfo so it contains only the
DWARF debug information, but some utilities can't work with
that. If we put the full modules with debug info in the
package then everything should work, at the cost of making
the package about 14MB larger. Is there any reason not to
do this? (i686 debuginfo is about 175MB now.)
16 years, 2 months
