Re: make git/* hung
> $ make git/utrace/prep > No such problem for me. Look with ps what is hanging. Note that since this weekend Fedora pkgs checkouts using cvs.fedora.redhat.com no longer work and cvs will tend to hang for a long time if you use them. Try a fresh checkout being sure to use cvs.fedoraproject.org instead. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: make git/* hung
> Downloading linux-2.6.31.tar.bz2... That is the "make sources" part. Just try it again. IIRC it just runs curl from some fedoraproject.org site. So if that is hanging, then talk to the Fedora infrastructure folks. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [ppc64] newer gcc breaks kernel build?
> On Thu, Sep 17, 2009 at 09:31:52PM +0200, Jakub Jelinek wrote: > > I've noticed the dot in front of the symbol, is kernel using still the for > > years deprecated oldish ppc64 ABI instead of the new one (i.e. uses > > -mcall-aixdesc instead of not using this option at all)? Maybe it is broken > > only in that case. It would be nice if -mcall-aixdesc were even in the GCC manual. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
f11 ppc64 woes
I reproduced what jwb reported on the powerstation. Mine is with F10 + updates userland, only the kernel seems to matter. The test case is: # modprobe iscsi_tcp Illegal Instruction # On -16[278], same oops that jwb saw, wrong text appearing at a page boundary. This kernel: http://kojipkgs.fedoraproject.org/scratch/roland/task_1396640/kernel-vanilla-2.6.29.4-168.fc11.ppc64.rpm does not exhibit the problem. That should be all the same buildroot stuff, and 2.6.29.4 with no extra patches. OTOH, this kernel: http://kojipkgs.fedoraproject.org/scratch/roland/task_1396192/kernel-2.6.29.4-167.fc10.ppc64.rpm also does not exibit the problem. That is normal -167 with all the same patches, but built in dist-f10-updates-candidate buildroots. But contrary to jwb's reports: On my powerstation 2.6.29.3-159.fc11.ppc64 fails to boot: Loading ipr moduipr 0001:01:01.0: IOA initialized. le scsi0 : IBM 572C Storage Adapter scsi 0:0:0:0: Direct-Access IBM-ESXS ST373455SS BA23 PQ: 0 ANSI: 5 Oops: Exception in kernel mode, sig: 4 [#1] SMP NR_CPUS=128 NUMA Maple Modules linked in: ipr(+) NIP: c040 LR: c038 CTR: c044304c REGS: c000781a7620 TRAP: 0700 Not tainted (2.6.29.3-159.fc11.ppc64) MSR: 90089032 CR: 2424 XER: 000f TASK = c00078193500[70] 'scsi_scan_0' THREAD: c000781a4000 CPU: 2 GPR00: c038 c000781a78a0 c0e6c210 c0db0390 GPR04: 0058 c0007be6e000 000a GPR08: c000781a4000 c0007be6e618 GPR12: 4428 c0ea2800 0021a344 0021a394 GPR16: 0021a368 c0007be6e000 c000781a7b50 GPR20: c00078090800 c0007be6e060 GPR24: c00078090828 fffa GPR28: c00078400120 c0e0d710 c000781a7810 NIP [c040] .transport_destroy_device+0x3c/0x50 LR [c038] .transport_destroy_device+0x34/0x50 Call Trace: [c000781a78a0] [c0446c9c] .scsi_alloc_sdev+0x220/0x284 (unreliable) [c000781a7950] [c0446f8c] .scsi_probe_and_add_lun+0x168/0xda8 [c000781a7ad0] [c0447fb0] .__scsi_scan_target+0x104/0x730 [c000781a7c20] [c0448654] .scsi_scan_channel+0x78/0xe8 [c000781a7ce0] [c04489d4] .scsi_scan_host_selected+0x11c/0x1a8 [c000781a7da0] [c0448b48] .do_scsi_scan_host+0xe8/0x10c [c000781a7e40] [c0448bb0] .do_scan_async+0x44/0x220 [c000781a7ef0] [c00c57f8] .kthread+0x90/0xe4 [c000781a7f90] [c002f730] .kernel_thread+0x54/0x70 Instruction dump: fbe1fff8 f821ff71 7c3f0b78 ebc2d0f0 f87f0070 6000 6000 e87f0070 e89e8000 4bfff8cd 6000 383f0090 <1010> 0008 1013 000f ---[ end trace 998c8eb2fd0a3b41 ]--- usb 2-1.4: new full speed USB device using ohci_hcd and address 3 usb 2-1.4: New USB device found, idVendor=05ac, idProduct=1003 It prints some more usb probe msgs, but nothing else. I can then reboot it with Ctl-Alt-Del on the USB keyboard. This is obviously a variant of the same problem. It's losing on clobbered instructions at a page boundary. Same for -158. Same for -157. Same for -155. Same for -154. Man but these bastards boot slow. Same for -152. -142 does not do that, nor exhibit the problem in "modprobe iscsi_tcp". buildroot diffs -142 vs -152: @@ -23,8 +23,8 @@ device-mapper-1.02.31-4.fc11.ppc64 device-mapper-libs-1.02.31-4.fc11.ppc64 diffutils-2.8.1-23.fc11.ppc64 -e2fsprogs-1.41.4-8.fc11.ppc64 -e2fsprogs-libs-1.41.4-8.fc11.ppc64 +e2fsprogs-1.41.4-9.fc11.ppc64 +e2fsprogs-libs-1.41.4-9.fc11.ppc64 elfutils-0.140-2.fc11.ppc64 elfutils-libelf-0.140-2.fc11.ppc64 elfutils-libs-0.140-2.fc11.ppc64 @@ -89,7 +89,7 @@ nss-3.12.3-4.fc11.ppc64 nss-softokn-freebl-3.12.3-4.fc11.ppc64 openldap-2.4.15-3.fc11.ppc64 -openssl-0.9.8k-1.fc11.ppc64 +openssl-0.9.8k-4.fc11.ppc64 pam-1.0.91-6.fc11.ppc64 patch-2.5.4-38.fc11.ppc64 pcre-7.8-2.fc11.ppc64 @@ -102,7 +102,7 @@ pkgconfig-0.23-8.fc11.ppc64 policycoreutils-2.0.62-12.2.fc11.ppc64 popt-1.13-5.fc11.ppc64 -ppl-0.10.1-1.fc11.ppc64 +ppl-0.10.2-2.fc11.ppc64 procps-3.2.7-27.fc11.ppc64 psmisc-22.6-9.fc11.ppc64 readline-5.2-14.fc11.ppc64 ppl is a library used by gcc. I eyeballed 0.10.1->0.10.2 changes and I doubt it's involved (AFAIK no actual code changes there). http://koji.fedoraproject.org/koji/taskinfo?taskID=1396771 is a scratch build of -142 in the current buildroots. I'll g
Re: 2.6.29.1-102.fc11 --with vanilla broken
> You should always specify an arch. make prep uses noarch and generally works fine. You can just ignore the strange assembler messages in the 'make configs' phase and the .config files come out fine, in my experience. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.29.1-102.fc11 --with vanilla broken
> Great. I ended up having lots of other issues with vanilla build. At > some point during the build, the "make oldconfig" becomes interactive > during the %install phase. %install?? Weird. That should not be happening. Maybe a V=1 on the make command would make kbuild explain why it decided to do that. > I also see some interesting thigs with ia64. Why is it messing with ia64 > configs? That stuff is "normal". Ignore it if it doesn't break the build. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How should anaconda check for PAE? (was Re: arch fun.)
> If we have NX (which anything made in the last few years will) > it's a performance win to use the hardware NX instead of the > segment limit hack we implemented in execshield. It's more than performance. The segment limit hack is a hack, and does not actually do full enforcement in all cases (though we have already bent over backward to ensure that these cases do not come up by default). Hardware NX is 100% reliable. > Syscalls in particular should be a lot faster, as you get to > use the sysenter/sysexit instructions which are faster than using > the int 80h entrypoint. (The way the segment limits work is > incompatible with sysenter/sysexit). This is indeed quite a big hit. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How should anaconda check for PAE? (was Re: arch fun.)
> - Should we be using the PAE kernel *regardless* of memory size (as > implied above) or do we want some memory requirements? It's always preferable on hardware (where pae actually works) that also has the nx cpu feature. True PROT_EXEC enforcement (NX) is only available in PAE mode. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
> Patch below seems to dtrt.. comments?
Why kill the configs, instead of just changing the spec settings?
> @@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
> cd linux-%{kversion}.%{_target_cpu}
>
> %if %{with_debug}
> +%ifnarch i686
> BuildKernel %make_target %kernel_image debug
> +%endif
> %if %{with_pae}
> BuildKernel %make_target %kernel_image PAEdebug
> %endif
Why not %if !%{with_up} here?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel options not enabled?
> > Or you could take my advice of many moons ago now and find less cockamamy > > ways to implement this. ;-) > > By what? Rewriting gcc? Only a wee little bit. ;-) Seriously, -pg is eight kinds of wrong, and not even what you really want anyway. (If your probe points are at actual entry points instead of inside prologues, then you can get the function arguments directly, assuming you know which calling convention that particular function has, which you don't really but you'd probably be happy pretending you did.) You do not really need any kind of magical list of spots generated at compile time. You can just do insertion anywhere it works. (If you're willing to fall back to kprobes, it works most anywhere.) You can keep it real primitive like now and just only work where there is exactly NOP5 sitting there. Then all you're really asking for at build time is to insert a gratuitous NOP5 at entry points. A compiler tweak for that is a pretty simple kludge, not even tied in to actual code generation magic. You could probably even do it with crazy-ass asm/.o fiddling as is your wont. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel options not enabled?
> But with this on, you can enable kernel function tracing at runtime. And > this is a very powerful tool. This might be something to discuss, where we > may sacrifice a bit of power for the ability of dynamic tracing. Or you could take my advice of many moons ago now and find less cockamamy ways to implement this. ;-) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel options not enabled?
> I thought we were going to enable these in rawhide since the e1000 > EEPROM problem was fixed: > > CONFIG_FUNCTION_TRACER (was CONFIG_FTRACE) > CONFIG_DYNAMIC_FTRACE Last I knew this still uses -pg and implies -fno-omit-frame-pointer. This probably kills performance somewhat, and more importantly during a rawhide debug-kernel phase, might change the corners of compiler behavior that we're checking vs what we'd want in a production kernel. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: execshield rebase
> I tried back in July when I got the diff down to under a thousand lines. > Linus wasn't really enthusiastic. I wasn't necessarily thinking too much would go in very easy. But cleaner and separate patches would at least probably stay easier to rebase. > http://www.codemonkey.org.uk/junk/linus-es.txt > has the interesting bits.. > > The get_wchan bit that he mentions definitly should be factored out. > It's completely unrelated to the NX-emulation. Quite so. Also I think the i386 NX-emulation bits can really be isolated well to an x86-only config option that is clean and nonintrusive. The mmap layout changes are necessary for NX-emulation to be worth having at all, but it is quite separable in the code. I think we should also clean up the use of the exec_shield sysctl setting for so many different magic things at once. (In the cleaned up patches, I doubt there would be anything called "exec-shield" left.) Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: execshield rebase
I've been thinking for a while execshield.patch could be split into two or three cleaner patches. Some of those might even be upstreamable as config options or something. It really isn't that big a patch at this point. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [2.6.26 PATCH] BZ#469684 utrace: make sure utrace_report_syscall_entry() can't lose TIF_SIGPENDING
Fedora kernel folks don't really pay attention to utrace innards except to make sure that I get the flames about them. The place dedicated to discussion of those innards is <[EMAIL PROTECTED]>. (It's fine to mention the Fedora kernel versions and bugzilla links on that list.) That fix is one that I just did last week, in fact. I didn't get around to the commit and push before the (USA) long holiday weekend. I've fixed some of the outstanding Fedora ptrace issues (now all represented in the ptrace-tests suite), but still had an intermittent problem to track down. Even with it still not perfect, I'll do the push today and post on utrace-devel about the unresolved details. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: f9 utrace update
> Have you also looked at the kerneloops.org data? That tends to have a > nice collection of utrace oopses/warnings... I typed "utrace" in the "Function Search" box. The only common one (many many hits) was fixed a while ago (on 9/15 around lunch time, it so happens). The other ones for non-ancient kernels are either one of a few known things I've fixed, or look likely to be failure modes of some races that I believe I have just fixed recently (this week, not in any released kernels yet). I'll be sure to check kerneloops regularly in the future. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
f9 utrace update
I've done a rebase of the utrace patch in the F-9 kernel. Builds >= 2.6.26.6-74.fc9 have the new code. It should now match the rawhide/F-10 version of utrace exactly. I believe this fixes all the outstanding ptrace-related regressions reported for f9 kernels. But I didn't scour bugzilla to keep track. The ptrace-tests suite results now match upstream kernels on x86_64. (I haven't actually tested other machines at all lately.) 2.6.26.6-74.fc9 is done in koji and 2.6.26.6-75.fc9 is building right now. That has only one small fix vs -74, and it's not one for any ptrace issue (or user-visible at all, just syscall_get_arguments() for utrace modules). I hope someone will snarf the builds from koji and test in the next day or so. (After this week, I'll be on vacation until mid-November.) Chuck will decide when a new build should be pushed as an f9 update. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[EMAIL PROTECTED]: rpms/kernel/devel kernel.spec, 1.1006, 1.1007]
What's this about? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide patches.
> > > These are policy decisions. Probably not going usptream. > > > > Can they be turned into upstream config options? > > They're already runtime settable, so it's primarily a convenience thing > - they're the sensible defaults given our userland. Can the boot defaults be turned into upstream config options? If it's worthwhile to patch the kernel to make it boot this way by default, it's worthwhile to get that default without a patch. Fewer patches to keep track of, same defaults for kernel-vanilla rpms, etc. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide patches.
> > linux-2.6-acpi-video-dos.patch > > linux-2.6-defaults-acpi-video.patch > > These are policy decisions. Probably not going usptream. Can they be turned into upstream config options? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
chcorefilter
The /proc/PID/coredump_filter mechanism makes it easy to tweak the
per-process setting to control ELF core dump style details.
This setting is per-process (per-mm) and inherited by children.
But as a user, the /proc interface is insane. It prints a magical hex
value (without a leading 0x, to make it sneaky), which you'll be damn lucky
to figure out from reading Documentation/filesystems/proc.txt. Then you
get to set it to another such magical value, which is in decimal unless you
add a leading 0x (cat /proc/x/coredump_filter > /proc/y/coredump_filter
does not copy the setting, go team).
I have kicking around this half-assed bash script that I don't care to
bother making really presentable. Where should it live? In the upstream
kernel's scripts/? (Then noone would ever see it for sure.)
In util-linux-ng? Or what? Someone want to take it off my hands?
Thanks,
Roland
#!/bin/bash
#
# Usage: chcorefilter - PID... prints [pmfse]+ string for each PID
#chcorefilter [pmfse]+ PID... changes filter bits for each PID
#
# Each bit set says a flavor of mapping that should be included in core dumps.
# The setting for a process is inherited by its new children.
#
# p anonymous Private memory
# m anonymous shared Memory
# f private File mapping
# s Shared file mapping
# e ELF headers (first page of ELF-looking untouched file mapping)
#
# Default setting upstream is 'pm', Fedora >= 8 default is 'pme'.
# GDB < 6.7 will be confused by the core files from +e settings.
#
# A fancier command would take +e or -e to set/clear just some
# bits relative to the current setting.
#
get_filter()
{
local pid=$1
local f
f=`cat /proc/$pid/coredump_filter` || exit
((f=0x$f))
local s=''
((($f & 1) == 0)) || s="${s}p"
((($f & 2) == 0)) || s="${s}m"
((($f & 4) == 0)) || s="${s}f"
((($f & 8) == 0)) || s="${s}s"
((($f & 16) == 0)) || s="${s}e"
filter_dec=$f
filter_str=${s:-.}
}
set_filter()
{
local pid=$1
local val=$2
printf "0x%x\n" $val > /proc/$pid/coredump_filter || exit
}
if [ $# -eq 0 ]; then
exec sed '1d;/^#/!q' $0
fi
if [ "x$1" = x- ]; then
shift
for pid; do
get_filter $pid
if [ $# -gt 1 ]; then
echo "${pid}: ${filter_str}"
else
echo "$filter_str"
fi
done
exit 0
fi
arg="$1"
shift
case "$arg" in
-*) op='&=~'; arg=${arg#?} ;;
+*) op='|=' ; arg=${arg#?} ;;
.) op='=' ; arg=${arg#?} ;;
*) op='=' ;;
esac
val=0
until [ -z "$arg" ]; do
case "$arg" in
p*) ((val |= 1));; # anonymous Private memory
m*) ((val |= 2));; # anonymous shared Memory
f*) ((val |= 4));; # private File mapping
s*) ((val |= 8));; # Shared file mapping
e*) ((val |= 16));; # ELF headers
*) bogon; break ;;
esac
arg=${arg#?}
done
for pid; do
get_filter $pid
((filter_dec $op $val))
set_filter $pid $filter_dec
done
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
kernel-doc
I reenabled kernel-doc and tweaked it up.
* Make htmldocs too. Some pithy bits are only in the .tmpl stuff and it is
nice to be able to point people at "install kernel-doc and point your
browser at file:///...", etc.
* make in %build, only install in %install. Pure rpm anality.
* Use %{?_smp_mflags}. mandocs is slow enough already.
* New macro switch %{doc_build_fail} to suppress barfing on 'make mandocs'
failure. We should get real kernel-doc and can eyeball the logs for
errors, but won't be breaking our builds on every rebase where upstream
tweaked comments so they broke kerneldoc. The switch defaults from
%{released_kernel}, so we should break again if kernel-doc would come out
bogus in a non-rawhide build. No extra human intervention required.
* Install in kernel-doc-%{rpmversion} (.27) subdir, not -%{kversion} (.26).
It was obviously insane to have kernel-doc-2.6.27-0.xyz.fc10 that installs
/usr/share/doc/kernel-doc-2.6.26/ files.
Gabba gabba,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rpms/kernel/devel kernel.spec,1.847,1.848
> On Tue, Aug 05, 2008 at 05:48:04AM +, Dave Jones wrote: > > +cp -a acpi config keys linux math-emu media mtd net pcmcia rdma rxrpc > > scsi sound video drm asm-generic > > $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include > > +if [ -f asm ]; then > > + cp -a `readlink asm` > > $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include > > fi > > > > This looks like it will DTRT thing in both cases. Cool. "cp -a asm/. targetdir" would work too. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
linux-2.6-build-nonintconfig.patch rebase
Running rebase.sh was so much fun that I for some reason decided to do Dave's job today and once I'd run it then I had to cope with the kconfig changes upstream. I hacked linux-2.6-build-nonintconfig.patch and is seems to be about right again. But I never did try to really understand that code. Someone ought to look at it. The headers_check magic changed, so the .spec kludge broke. Running it normally instead of using the innards seemed right to me. They seem to keep breaking stuff upstream, so the last iteration probably didn't build either. I bet upstream will fix the installing /usr/include/.install et al before long, and then the find | xargs rm I added can go. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
git11 new config items
I added these to config-generic to keep building with -git11. I have no idea if these are the right settings. +# CONFIG_MFD_TC6393XB is not set +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set +CONFIG_DMADEVICES=y +CONFIG_INTEL_IOATDMA=m +# CONFIG_DMATEST is not set Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 2/7] Change how we do nosegneg
> All sounds fairly reasonable to me, but why not have "make vdso_install" > install the file? Yeah, that will be the right thing for upstream eventually. Probably for upstream it is preferred to install files only in $INSTALL_MOD_PATH and not go touching /etc. So I think the norm will be something like /lib/modules/.../ldconfig.conf and then we can install a single /etc/ld.so.conf.d/kernel.conf that contains: include /lib/modules/*/ldconfig.conf > Looking at your patch, if you're going have a file per-variant, you need > to install it in BuildKernel. And you also only want to do it on > vdso_arches. Right. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rebase, utrace
I took the liberty of rebasing rawhide to git11. (rebase.sh works great!) That was necessary for my latest utrace patches to apply, and I turned those back on. I'm starting a build and will deal if it doesn't compile. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
vanilla-%{kversion}
I find myself doing a lot of make prep lately in the days of frequent
new upstream base patches. The untar still takes a lot longer than
the big patch. So I committed this to speed it up for the repeated
rebase case.
Thanks,
Roland
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.791
diff -u -r1.791 kernel.spec
--- kernel.spec 23 Jul 2008 19:51:09 - 1.791
+++ kernel.spec 24 Jul 2008 08:01:48 -
@@ -904,10 +904,19 @@
%endif
if [ ! -d kernel-%{kversion}/vanilla-%{vanillaversion} ]; then
- # Ok, first time we do a make prep.
- rm -f pax_global_header
+
+ if [ -d kernel-%{kversion}/vanilla-%{kversion} ]; then
+cd kernel-%{kversion}
+ else
+# Ok, first time we do a make prep.
+rm -f pax_global_header
%setup -q -n kernel-%{kversion} -c
- mv linux-%{kversion} vanilla-%{vanillaversion}
+mv linux-%{kversion} vanilla-%{kversion}
+ fi
+
+%if "%{kversion}" != "%{vanillaversion}"
+ cp -rl vanilla-%{kversion} vanilla-%{vanillaversion}
+%endif
cd vanilla-%{vanillaversion}
# Update vanilla to the latest upstream.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 2/7] Change how we do nosegneg
> We should really only install ld.so.conf files from packages
> that actually have CONFIG_XEN enabled, but it would be
> slightly messy to have only kernel-PAE.i686 and kernel.x86_64
> include it.
It wouldn't really be so hard to conditionalize it at least for the arch's
that ever need it. (The kernelcap trick might well be used for other
things in the future.)
I think the right direction to head is that upstream kernels supply a .conf
file to match the vDSO they build in. This will probably always be just a
constant file in the source, but in general can be said to be generated by
the kernel build. The contents have to match the magic bits in the vDSO
images built into the kernel, so it really should not be a distro/packaging
responsibility to populate the file.
So let's structure things around that: the kernel build for an arch that
uses vdso might include a kernelcap.conf file (or might not).
For simplicity and consistency in the .spec file, we'll install a file for
all variants even when it's an empty placeholder. For the magic, the diff
below probably covers it (wholly untested). Then it's up to BuildKernel
just to add/remove ldconfig-kernelcap.conf as part of the build (perhaps
eventually done by the upstream makefiles).
The .conf files have to not conflict (reuse same bit with different name)
across all installed kernels (or else ldconfig will complain). So a single
kernel-%{KVERREL}.conf file would be fine. But instead I made it
kernel-%{KVERREL}.variant.conf just to stay consistent with all existing
names like /lib/module/FOO and the fact that no two kernel rpms conflict on
the same file name (even if identical).
Thanks,
Roland
--- kernel.spec 23 Jul 2008 19:51:09 - 1.791
+++ kernel.spec 24 Jul 2008 00:21:24 -
@@ -1509,21 +1513,13 @@ BuildKernel vmlinux vmlinux kdump vmlinu
cd linux-%{kversion}.%{_target_cpu}
-%if %{includexen}
-%if %{with_xen}
-mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d
-rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf
-cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf <<\EOF
-# This directive teaches ldconfig to search in nosegneg subdirectories
-# and cache the DSOs there with extra bit 0 set in their hwcap match
-# fields. In Xen guest kernels, the vDSO tells the dynamic linker to
-# search in nosegneg subdirectories and to match this extra hwcap bit
-# in the ld.so.cache file.
-hwcap 0 nosegneg
-EOF
-chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf
-%endif
-%endif
+if [ ! -s ldconfig-kernelcap.conf ]; then
+ echo > ldconfig-kernelcap.conf "\
+# Placeholder file, no vDSO hwcap entries used in this kernel."
+fi
+
+%{__install} -D -m 444 ldconfig-kernelcap.conf \
+$RPM_BUILD_ROOT/etc/ld.so.conf.d/kernel-%{KVERREL}.conf
%if %{with_doc}
mkdir -p $RPM_BUILD_ROOT/usr/share/doc/kernel-doc-%{kversion}/Documentation
@@ -1728,6 +1724,7 @@ fi
/lib/modules/%{KVERREL}%{?2:.%{2}}/weak-updates\
%ifarch %{vdso_arches}\
/lib/modules/%{KVERREL}%{?2:.%{2}}/vdso\
+/etc/ld.so.conf.d/kernelcap-%{KVERREL}%{?2:.%{2}}.conf\
%endif\
/lib/modules/%{KVERREL}%{?2:.%{2}}/modules.block\
/lib/modules/%{KVERREL}%{?2:.%{2}}/modules.networking\
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 4/7] Remove unneeded %kernel_variant_post args
> Needless to say, though, I don't care much either way ... Me either. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides}
> On Wed, 2008-07-23 at 12:44 -0700, Roland McGrath wrote: > > > If you try and use e.g. kernel_obsoletes, you'll soon find > > > that it's actually kernel__obsoletes you currently need :-) > > > > So you want kernel to have an Obsoletes: that kernel-foo do not get? > > Yes; kernel-PAE.i686 obsoletes kernel-xen.i686 and kernel.x86_64 > obsoletes kernel-xen.x86_64. But you don't want all kernel* to obsolete kernel-xen? Any special reason? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides}
> If you try and use e.g. kernel_obsoletes, you'll soon find > that it's actually kernel__obsoletes you currently need :-) So you want kernel to have an Obsoletes: that kernel-foo do not get? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 4/7] Remove unneeded %kernel_variant_post args
Why bother? If it comes up in the future, the macro will be handy. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
kernel-vanilla-2.6.26-137.fc10
BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ for a kernel-vanilla build I did of 2.6.26. This gives a baseline for regression testing any problems to see if they are caused by some Fedora patches (e.g. utrace) or are also upstream. I think koji scratch only stays around for a couple of days. Maybe there is a better place to put these. Was there ever a plan to put kernel-vanilla rpms up for public consumption on a regular basis? Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: new utrace patch breaks ia64
Thanks for catching that. There were two issues (at least). I fixed the missing #include you found. Thanks. The new code is not supposed to be enabled for ia64, because some of the arch bits are still missing. I thought I'd done that in config-ia64, but I hadn't done the magic quite right. I checked in an update to the patches and configs. Please let me know if the current cvs sources build on ia64. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: revisit: turning some of the "always used" modules to built-in
> very simply put: > > it's between getting this level of information: > > http://www.kerneloops.org/raw.php?rawid=32356 > > with pointing at the exact code, and only getting this > > http://www.kerneloops.org/raw.php?rawid=32287 Thanks. I'd like to help improve the tools so that we can close this gap in the future. (I'm really just concerned with making some tools better. I am not saying anything about the desireability of building in modules.) I think one of my back-burner items would cover this. Maybe we can kibitz offline about the details. In brief poking I didn't find the code you use to generate the web reports. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: revisit: turning some of the "always used" modules to built-in
> 1) Built-in code is easier to debug/diagnose. This may sound weird, but >really, things inside the vmlinux allow for much better automated >bug diagnostics/analysis. >( and the www.kerneloops.org site uses these, but can only do the more > advanced automatic analysis on the built-in oopses) Can you point me to the details of this issue? Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Procedure to make a patch
The best plan is to use whatever directory organization floats your boat,
and then massage the patches. Start with 'yum install patchutils'.
Then usually you want something like
diff -rpuNB --exclude={'*~','*.orig'} kernel-2.5.24{.orig,} |
filterdiff --remove-timestamps --strip=2 --addprefix=linux-2.6/ > foo
Enjoy,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
> On Monday 31 March 2008 03:45:25 pm Roland McGrath wrote:
> > I had a fix for this test-building when I went to watch some schlock TV
> > last night and forgot to check on it and commit before I went to bed.
> >
> > This was my .spec diff. The regexp has three chars different from your
> > version.
> >
> > +%{expand:%%global debuginfo_args %{?debuginfo_args} -p
> > '/.*/%%{KVERREL}%{?1:.?%{1}}?/.*|/.*%%{KVERREL}%{?1:.%{1}}(\.debug)?' -o
> > debuginfo%{?1}.list}\ ^
>
> Gah. Now, in your email, the ^ pointed to the ? in debuginfo%{?1}.list, while
> when quoted (and rewrapped by kmail), it pointed at the ?
> in %%{KVERREL}%{?1:.?%{1}}... And I'm not 100% certain which one you were
> actually questioning now.
In fact, it pointed at the last (third) ? in
%%{KVERREL}%{?1:.?%{1}}?/.*
The two that you thought I might have been referring to are both correct.
> From a later reply, looks like actually the one in debuginfo%{?1}.list, which
> is necessary, so that for the base kernel, we get debuginfo.list. At least, I
> think that's the case, no?
That ? is an rpm macro syntax ? and none of those should change.
> So I *think* this would do now:
>
> %{expand:%%global debuginfo_args %{?debuginfo_args} -p
> '/.*/%%{KVERREL}%{?1:\.%{1}}/.*|/.*%%{KVERREL}%{?1:\.%{1}}(\.debug)?' -o
> debuginfo%{?1}.list}\
Note, I unwrapped the line from your message. If you don't use an MUA that
lets you be positive what the actual bytes in the message were, let alone
send the actual bytes you intended, we are not going to be able to discuss
this in email.
The line quoted above is only one char different from my version.
You have removed the ? that did not belong (right before /.* as I cited above).
You also removed another one that I did not remove. That one permitted
either %{KVERREL}.flavor or %{KVERREL}flavor to match. I think that one is
indeed no longer needed. It was originally -? rather than \.? and was to
match /lib/modules/RELflavor as well as /usr/src/kernels/REL-flavor
when that was how they looked.
So, I think the line quoted above is now correct.
Thanks,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
> I wondered that myself, but it was already there... Might have been a typo I
> inserted earlier. Yanking it works for me.
In the old regexp there was (-%%{_target_cpu})? there. That ?
applied to the whole () group. (That was so it would match both
/lib/modules/REL/blah and /usr/src/kernels/REL-ARCH/blah.)
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
I had a fix for this test-building when I went to watch some schlock TV
last night and forgot to check on it and commit before I went to bed.
This was my .spec diff. The regexp has three chars different from your version.
+%{expand:%%global debuginfo_args %{?debuginfo_args} -p
'/.*/%%{KVERREL}%{?1:.?%{1}}?/.*|/.*%%{KVERREL}%{?1:.%{1}}(\.debug)?' -o
debuginfo%{?1}.list}\
^
what's that ? for? The other differences are \. instead of . for matching
literal . in two places.
--- kernel.spec 30 Mar 2008 22:48:29 -0700 1.560
+++ kernel.spec 30 Mar 2008 22:59:22 -0700
@@ -712,7 +712,7 @@ AutoReqProv: no\
%description -n %{name}%{?1:-%{1}}-debuginfo\
This package provides debug information for package %{name}%{?1:-%{1}}.\
This is required to use SystemTap with %{name}%{?1:-%{1}}-%{KVERREL}.\
-%{expand:%%global debuginfo_args %{?debuginfo_args} -p
'/.*/%%{version}-%%{release}%{?1:-?%{1}}(-%%{_target_cpu})?/.*|/.*%%{version}-%%{release}%{?1}(\.debug)?'
-o debuginfo%{?1}.list}\
+%{expand:%%global debuginfo_args %{?debuginfo_args} -p
'/.*/%%{KVERREL}%{?1:\.?%{1}}/.*|/.*%%{KVERREL}%{?1:\.%{1}}(\.debug)?' -o
debuginfo%{?1}.list}\
%{nil}
#
@@ -1246,7 +1246,7 @@ BuildKernel() {
CopyKernel=cp
fi
-KernelVer=%{version}-%{release}.%{_target_cpu}${Flavour:+.${Flavour}}
+KernelVer=%{KVERREL}${Flavour:+.${Flavour}}
echo BUILDING A KERNEL FOR ${Flavour} %{_target_cpu}...
# make sure EXTRAVERSION says what we want it to say
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: utrace is back
Is there an alternate Koji or some other means by which I can try rawhide/ia64 rpm builds? > This is caused by the change of > #define TIF_RESTORE_SIGMASK 5 > > to > > #define TIF_RESTORE_SIGMASK 22 > > Is there a need to change this bit from 5 to 22? If that really is > needed we are going to need to change entry.S to handle it (which I will > need to find an ia64 asm expert for advice on this). This is part of a cleanup that is not yet needed. I'll drop those patches from the series for now. > So that we can continue to make ia64 progress can we %ifarch the utrace > patch out in the spec file until utrace is complete on ia64? That should be fine. I don't think other patches need it to apply. The hard 90% of the ia64 work (user_regset) has been done and posted upstream by Shaohua Li <[EMAIL PROTECTED]>. What would be best is if you can lean on linux-ia64 upstream to incorporate those changes ASAP. When the parts upstream has already seen get integrated, there will be little enough left for ia64 utrace to work that I can get it going. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
I will probably continue to find it desireable to make a dozen different
100-200M partitions to use as /boot for installs, so I don't really care
about the name noncollision. But it sure would make it a little simpler
to use (hd0,N)/ TAB in GRUB to remind me which partition is which, as
I'm always doing.
I didn't really review the spec bits thoroughly. But as far as spec
magic and building goes, I think it should be fine if you just get every
%{KVERREL}%{suffix} and make it %{KVERREL}%{suffix}.%{_arch}.
Except I think you mean %{_target_cpu}, not %{_arch}.
I agree with Jarod that keeping .%{_arch} always immediately after
%{KVERREL}%{suffix} is best. For most things, it just becomes part
of the whole "kernel release string" wad.
As has been noted, a lot of things will get unhappy if they cannot
use foo-`uname -r` and /lib/modules/`uname -r` as file names for
the installed bits. I can speak for systemtap/elfutils, which has
no plan other than /lib/modules/`uname -r` for where to locate the
kernel and module binaries (or user manual intervention with a switch).
Even if it were not for the trouble with finding all the hidden
dependencies on that, tools needing to be compatible across
kernel/distro versions, etc., where would those tools get the
%{_arch} value to look for? uname -m? uname -i? I don't think
either of those gets i586 when that's the kernel rpm %{_arch} and
the CPU is an i686, for example.
All this suggests to me that the only thing we really can make fly is to
include the differentiator in EXTRAVERSION. It will be noticeable to
users and probably draw a lot of questions and look redundant in many
places that display the arch too. But it would not be any new can of
worms on technical grounds.
For just 32/64 sharing and not e.g. i586/i686 sharing (both kernels of
same version selectable for the same install), it could be made less
repetitious by not using .%{_target_cpu} but instead just %(L=%{_lib#lib};
test -z "$L" || echo ".$L"), i.e. ".64" or nothing. (And that would be no
suffix on ia64 et al where lib64 is not used, as well as the 32-bit cases.)
Thanks,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
utrace is back
I've put the 2.6.25 rebase of utrace back in and kicked off a build. I'll pick up the pieces if it comes out all broken. (It already did, cause I forgot to test the ppc32 build upstream.) For the moment it's applied as one big patch instead of a series. I haven't figured out the arrangement for the new series yet. There is some amount of mayhem going on and this rebase was kind of hack and slash. But there's more churn than real change. About a third of the work is upstream now. All of the "quick and dirty" I've put together this week is actually either what's already upstream or nearly identical to what's been in F8 et al for a long time. So despite the late date and general disorganization of it all, this won't be as destabilizing as it sounds. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH 1/5] Don't create debuginfo.list for main package
Huh? debugfiles.list populates kernel-debuginfo-common. debuginfo.list populates kernel-debuginfo. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
> I needed the following patch to be able to build the fedora rpms > on i386. This is likely a case of the new code doing the right thing, > but me not being able to figure out the debug stuff in the spec file > at the time though. I sent a fix upstream for that. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
> M linux-2.6-i386-vdso-install-unstripped-copies-on-disk.patch > > needs a bit of inspection, looks right (and builds ok) This one should be upstream now. If anything is still missing, I should be able to get it in for 2.6.25. > M linux-2.6-utrace-core.patch > M linux-2.6-utrace-tracehook.patch > > pull-upstream.sh didn't fix this... so commented out in the build I'm behind on the rebasing. Just leave it for me to sort out. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files!
David is correct that eu-elfcmp is meant to see the stripped and unstripped files as matching. Josh is correct that the .gnu.attributes section is the new thing that is provoking the problem, owing to GCC 4.3. I'm doing three things: 1. elfcmp's bug is that it sees the .gnu.attribute sections in the stripped and unstripped files as nonidentical. This is a new section generated by GCC 4.3, which is not allocated but also is not stripped. So in the stripped file, its sh_offset (file position) moves when the other nonallocated sections are removed. I'll fix it upstream to ignore sh_offset in the cases where doesn't matter. This won't hit rawhide especially soon. (I'll also deal with the elfutils vs 4.3 on ppc issues Josh saw, but that is not anything to do with the kernel build.) This is moot wrt breaking the kernel build because of #3. 2. Part of the debuginfo_args magic macro's regexp was wrong, so it failed to match the /boot files. This is why /usr/lib/debug/boot/*.debug all wound up in kernel-debuginfo-common. I fixed the regexp so the .debug files for any unstripped ELF files in /boot will be sorted into the right kernel-debuginfo subpackage as originally intended. This is moot wrt reducing the total debuginfo rpm bloat because of #3. 3. We already copy the unstripped vmlinux into /usr/lib/debug. (This is whence arises the comparison that hit bug #1.) So .debug files stripped from an ELF vmlinux installed into /boot just duplicates the bulky part of that, and bloats that debuginfo rpm. (With bug #2 fixed, this bloat is properly sorted into each kernel-debuginfo and kernel-foo-debuginfo rather than going into kernel-debuginfo-common.) People prefer just having the unstripped vmlinux installed by kernel-debuginfo even when a split ELF /boot/vmlinux and .debug are available. It's simpler, and has the whole thing just by installing a kernel-debuginfo rpm without installing that kernel rpm in /boot. So, to dump the bloat we keep only one, and the unstripped vmlinux wins. The way to dump the /usr/lib/debug/boot/*.debug files is to strip the vmlinux we copy into /boot. I've changed BuildKernel to do this. There are no other files that ever should have matched the part of the regexp that was wrong in bug #2, so that fix is masked by this change. Since the /boot files will be seen as stripped, they won't be processed by find-debuginfo.sh at all. This circumvents bug #1. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: execshield inspection needed
Your attachment was empty. The execshield patch has gotten much smaller than it was in the beginning. It still hasn't gotten all the cleanup it could get though. The patch does a few different things that ideally would be in separate patches. 1. Segment-based PAGE_EXEC for no-NX hardware (and non-PAE 32-bit kernels). This is not really very much code. There's the GPF trap handler, and the hooks like arch_add_exec_range et al. I don't see why this couldn't be merged upstream as a config option. 2. Tighter permissions on /proc/pid/foo. This would be simple to make a config option and is such a simple patch (fs/proc/base.c) it seems like it shouldn't be hard to get upstream. 3. get_unmapped_area_prot. This is what changes the layouts and is the heart of what's really "exec-shield" since randomization has been upstream. 4. Miscellaneous tweaks and cruft. There are strange little bits of diff that I don't know the explanation for. Maybe we can clean these up. I hope Ingo knows what any other bits in there are for. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files!
Oh wait, the "copied not linked" warning probaby explains the whole thing. The /usr/lib/debug copy is not stripped, so it's not identical. Yeah, ok. I wonder why this wasn't happening before. I think it is just fixed by resolving the problems with too many copies of vmlinux. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files!
> Could this be yet another problem caused by the switch to GCC 4.3? Hard to see what it could have done to cp. ;-) + cp vmlinux /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9 ... + cp vmlinux /var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9 > Before this, it said: > > *** WARNING: identical binaries are copied, not linked: > /usr/lib/debug/lib/modules/2.6.24-9.fc9/vmlinux >and /boot/vmlinuz-2.6.24-9.fc9 > > In find-debuginfo.sh the two files are compared with both > 'cmp' and 'eu-elfcmp' -- something has changed that causes > them to be considered different where they weren't before. Off hand I would think this can only be eu-strip's fault. Unless something is silently touching files in the build or something, then it looks like eu-strip run twice (nondestructively) on the same input file produced differing stripped files. Rawhide has elfutils-0.132, which is also in updates-testing for F-[78]. If it's handy, you could try a kernel build on a rawhide with elfutils downgraded and see if that fixes it, or try a build on F-8 and see if it's broken by upgrading to the new elfutils from updates-testing. I still haven't fired up the ol' G5 to look into the thing with the vmlinux copies going into the wrong debuginfo rpms. So when I get it together, I can look into this too. I have to do a new rawhide install and such first though. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel build fails with GCC 4.3
> Why are we building kernels with this broken compiler? > > http://bugzilla.kernel.org/show_bug.cgi?id=8501 > > http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log Why are we building these broken kernels with our shiny new compiler? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fwd: Re: rawhide report: 20080130 changes
> Maybe this is because even after we strip out the debuginfo, file was > reporting "not stripped", so someone decided to override that and always > report them as stripped? I just used eu-unstrip to reassemble a module > with the full debuginfo and file still doesn't say anything about it... file's behavior changed (incompatibly) for ET_REL files, which .ko are. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fwd: Re: rawhide report: 20080130 changes
> Roland, I don't suppose any of the recent changes I seem to recall > hearing you were going to make to debuginfo might have anything to do > with this... Seems unlikely since I haven't actually made any yet. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.24
Ok, thanks for the info. If it's not likely to be weeks and weeks, then I don't think I'll update the utrace/2.6.23 backport any more with recent fixes. utrace/2.6-current is now on 2.6.24, and I won't rebase it for a few days. When it breaks rawhide or when I get to it, I'll branch utrace/2.6.24 off for F-[78] and rebase 2.6-current to back to mainline. The current version has some new fixes and the 2.6.24 branch will continue to track new fixes. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
2.6.24
Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 fairly soon? Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: debuginfo & ppc.
> On Wed, 23 Jan 2008 23:03:15 -0800 (PST) > Roland McGrath <[EMAIL PROTECTED]> wrote: > > > It is probably a better solution not to have a vmlinux.debug but instead > > keep the simple cp, and avoid the vmlinu[xz].debug files by explicitly > > stripping the /boot copy of vmlinux. > > I wish you wouldn't. If it's stripped, there's no way that I know of > other than using gdb to get an assembly dump with the function > information, etc. As it stands today, you can use objdump -rd on the > unstripped vmlinu* file and it will nicely spit out an assembly listing. You seem to have inverted the sense of what I suggested. /boot/vmlinuz-blah is stripped no matter what, it already is now. "Explicitly stripping" it as I said above means discarding the separate debug file now being created. Then the only plan is to get the whole unstripped file from /usr/lib/debug/lib/modules/.../vmlinux, as you do now. The alternative to what you quoted is what I posted the spec patch for, which changes things so there is no whole unstripped vmlinux file around (for ppc). That is the change you are concerned about, so what you favor is the solution you quoted above. But FYI: -r does nothing useful on vmlinux, which is not a relocatable file. -d works on the contents that are in a stripped file, and does not need symbols or debuginfo to print instructions. If you want symbols in its output, or something from the vmlinux DWARF info (like for -S), you can use: eu-unstrip -o vmlinux.unstrip -k kernel or eu-unstrip -o vmlinux.unstrip -e /boot/vmlinux-blah objdump -dS vmlinux.unstrip Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: debuginfo & ppc.
> I browsed a few of the internals, and it looks like the ppc variant includes
> a complete source tree
> in /usr/src/debug
It's normal to have every source file referenced by any binary's DWARF info.
for x in */debug/kernel-debuginfo-2*.rpm; do for y in $x `echo $x | sed
s,debuginfo,debuginfo-common,`; do printf "%-75s" $y; rpm -qlp $y | grep
'^/usr/src/' | wc -l; done;done
i386/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.i586.rpm 0
i386/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.i586.rpm 9162
i386/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.i686.rpm 0
i386/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.i686.rpm 9165
ppc64/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.ppc64.rpm 0
ppc64/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.ppc64.rpm8809
ppc/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.ppc.rpm 0
ppc/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.ppc.rpm8574
x86_64/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.x86_64.rpm 0
x86_64/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.x86_64.rpm 8862
> Any reason for ppc being different?
It's not a very different number of source files.
Let's wonder about the two biggest files in each rpm.
for x in */debug/kernel-debuginfo-2*.rpm; do for y in $x `echo $x | sed
s,debuginfo,debuginfo-common,`; do echo $y:; rpm -qlpv $y | sort -n -k 5,5 |
tail -2; done;done
i386/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.i586.rpm:
-rwxr--r--1 rootroot 10014436 Jan 21 16:14
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug
-rwxr-xr-x1 rootroot 77065021 Jan 21 16:11
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux
i386/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.i586.rpm:
-rw-r--r--1 rootroot 802044 Oct 9 13:31
/usr/src/debug/kernel-2.6.23/linux-2.6.23.i586/drivers/usb/misc/emi62_fw_s.h
-rw-r--r--1 rootroot 875265 Jan 21 15:55
/usr/src/debug/kernel-2.6.23/linux-2.6.23.i586/fs/nls/nls_cp949.c
i386/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.i686.rpm:
-rwxr--r--1 rootroot 10013800 Jan 21 18:44
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug
-rwxr-xr-x1 rootroot 77048944 Jan 21 18:37
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux
i386/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.i686.rpm:
-rw-r--r--1 rootroot 802044 Oct 9 13:31
/usr/src/debug/kernel-2.6.23/linux-2.6.23.i686/drivers/usb/misc/emi62_fw_s.h
-rw-r--r--1 rootroot 875265 Jan 21 15:57
/usr/src/debug/kernel-2.6.23/linux-2.6.23.i686/fs/nls/nls_cp949.c
ppc64/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.ppc64.rpm:
-rwxr--r--1 rootroot 13748248 Jan 21 17:09
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug
-rwxr-xr-x1 rootroot 67126229 Jan 21 16:30
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux
ppc64/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.ppc64.rpm:
-rwxr-xr-x1 rootroot 59098072 Jan 21 17:06
/usr/lib/debug/boot/vmlinuz-2.6.24-0.164.rc8.git4.fc9.debug
-rwxr-xr-x1 rootroot 59182336 Jan 21 17:06
/usr/lib/debug/boot/vmlinux-2.6.24-0.164.rc8.git4.fc9kdump.debug
ppc/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.ppc.rpm:
-rwxr--r--1 rootroot 9462912 Jan 21 16:29
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug
-rwxr-xr-x1 rootroot 46764240 Jan 21 16:10
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux
ppc/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.ppc.rpm:
-rwxr-xr-x1 rootroot 42107088 Jan 21 16:26
/usr/lib/debug/boot/vmlinuz-2.6.24-0.164.rc8.git4.fc9.debug
-rwxr-xr-x1 rootroot 43539424 Jan 21 16:26
/usr/lib/debug/boot/vmlinuz-2.6.24-0.164.rc8.git4.fc9smp.debug
x86_64/debug/kernel-debuginfo-2.6.24-0.164.rc8.git4.fc9.x86_64.rpm:
-rwxr--r--1 rootroot 13447688 Jan 21 16:06
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/kernel/fs/xfs/xfs.ko.debug
-rwxr-xr-x1 rootroot 57877978 Jan 21 16:04
/usr/lib/debug/lib/modules/2.6.24-0.164.rc8.git4.fc9/vmlinux
x86_64/debug/kernel-debuginfo-common-2.6.24-0.164.rc8.git4.fc9.x86_64.rpm:
-rw-r--r--1 rootroot 802044 Oct 9 13:31
/usr/src/debug/kernel-2.6.23/linux-2.6.23.x86_64/drivers/usb/misc/emi62_fw_s.h
-rw-r--r--1 rootroot 875265 Jan 21 15:54
/usr/src/debug/kernel-2.6.23/linux-2.6.23.x86_64/fs/nls/nls_cp949.c
So the funny bit is that kernel-debuginfo-common on ppc{,64} got the
.debug files for two /boot/vmlinu[xz] files. Those ought to be in the
kernel-debuginfo and kernel-kdump-debuginfo rpms if they're anywhere.
The placement of those .debug fil
utrace
I may have hashed this out with davej only in private before, so perhaps you aren't aware of the normal plan for utrace updates. You disabled utrace when you should have just run ./scripts/pull-upstreams.sh to get the current patch set. The 2008-1-3 version of the patches already applied fine. (I just regenerated for 2.6.24-rc7 but there were in fact zero changes to the patch files vs the files already up on 2008-1-3.) Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Precision 490 Reboot Hang
I've had the same problem and not gotten around to reporting it. I hadn't tried reboot=bios. For me, x86_64 kernels reboot fine but i386 kernels hang at reboot, on the same machine. Mine has BIOS version A06, and behaved the same with A04 before upgrading. This started in upstream kernels between 2.6.22 and 2.6.23 IIRC, and Fedora kernels since 2.6.23 behave the same as my hand-built upstream kernels. Sometimes sysrq-b works on a boot where formal reboot hangs, though once in a while it hangs at sysrq-b too. Possibly relevant, boot messages include: ACPI: System BIOS is requesting _OSI(Linux) ACPI: If "acpi_osi=Linux" works better, Please send dmidecode to [EMAIL PROTECTED] I haven't tried any acpi*= or reboot= kernel options. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC] Kernel subpackage for zImage wrapper.
> +# bootwrapper is only on ppc > +%ifnarch ppc Not ppc64 too? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
sparse 0.4.1
Dave asked me to ping when sparse got updated. 0.4.1 is built, [78] updates should get pushed RSN. This presumably works with the kernel source again. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: install System.map in kernel-devel
Ok, well all that is not a reason not to install the file, just reasons to fix it. I'll go ahead and check in the .spec change. Is there really a problem, or just the relocatable kernel issue? i.e. are System.map addresses "wrong" or just biased? Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
install System.map in kernel-devel
The systemtap folks are interested in having System.map installed by
kernel-devel, not just by the kernel rpm itself. This makes it possible to
do more preparations off-line for a kernel other than an installed one.
Without objection, I'll check this in on all branches.
Thanks,
Roland
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/F-8/kernel.spec,v
retrieving revision 1.239
diff -u -b -p -r1.239 kernel.spec
--- kernel.spec 22 Oct 2007 20:49:43 - 1.239
+++ kernel.spec 23 Oct 2007 13:02:39 -
@@ -1446,6 +1446,7 @@ BuildKernel() {
# first copy everything
cp --parents `find -type f -name "Makefile*" -o -name "Kconfig*"`
$RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp Module.symvers $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
+cp System.map $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
# then drop all but the needed Makefiles/Kconfig files
rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/Documentation
rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Enabling Secure Computing (SECCOMP)
> The reasons against it in the past were that it slowed down > the common case (people who aren't using the feature) It doesn't look like it should. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
more utrace updates committed
I committed another utrace update to both devel/ and F-7/. (There were multiple updates over the course of Tuesday.) The 2.6.22 backport is in now fully in synch with the tip. The current code is believed to fix outstanding F-7 bugs #248532, #267161, and #284311. Thanks, Roland P.S. I rewrote scripts/pull-upstream.sh as follows and used the same for F-7 with s/2.6-current/2.6.22/. I haven't checked these in. #!/bin/bash url=http://people.redhat.com/roland/utrace/2.6-current wget -q -O /dev/stdout $url/series | grep 'patch$' | while read i do rm -f linux-2.6-$i wget -nv -O linux-2.6-$i $url/$i done ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: sparc64 needs an entirely untouched, unstripped kernel
> On Fri, 2007-08-17 at 12:29 -0700, Roland McGrath wrote: > > I'd like to help figure out what the specific problem is, so we can solve > > it properly. > > OK, but how do we start? :) I've CC'd Jakub, who has a tendency to know every corner of this sort of thing. If that alone doesn't do it (;-), next we start with asking about exactly how this vmlinux->bootable conversion is done. (Last time I personally dealt with tftp-booting a Sun, it was a Sun 3/60, but it sounds like maybe things haven't changed much. I guess they have a little, since you're tftp'ing a kernel instead of a stage2 boot loader that does bootparam and nfs.) I looked at arch/sparc64/boot/Makefile, but a) don't know where to find elftoaout and b) you were talking about doing something with the image installed in /boot, which is AFAICT not the a.out format image at all. The "image" target in arch/sparc64/boot/Makefile is a mostly-stripped vmlinux (i.e. ELF). What is it that converts that into an a.out image, and where does that image get stored for booting? I surmise that whatever that procedure is depends on a few ELF symbols (-K sun4u_init -K _end -K _start). I'd like to grok all that more fully before suggesting the best solution. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: sparc64 needs an entirely untouched, unstripped kernel
I'd like to help figure out what the specific problem is, so we can solve it properly. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [Fwd: Testing the Current Upstream Kernel]
> On 16.08.2007 22:41, Jarod Wilson wrote: > > [...] > > Note that we can't currently build kernel and kernel-vanilla in the same > > rpmbuild pass. Further changes to the spec would be needed to make that > > doable, [...] > > Just wondering: Would that be much work or more something like ~15 > minutes of work? It's fundamentally unlike the things that are now done in one rpm build. i.e., it is not the same source. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] fix development --with vanilla build
I committed a slightly different fix for this. Note it should be quite temporary as the relevant patches are on the queue upstream. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bugzilla Bug 250377: External modules of removed kernels are not removed
Is there a reason to add a hack to the kernel %post in particular, instead of just making people use rpm triggers? I mean, horror and all that. But at least it's generic SEP horror, and not new hair for the kernel rpm itself (i.e. our problem). Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
> The signature sections are identical. Triple-checked that I was > comparing with the ext3.ko from the initrd that booted the system. [...] > To make it even more interesting: > > # cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kernel/drivers/net/e1000 > # insmod e1000.ko > Modules signature verification failed > insmod: error inserting 'e1000.ko': -1 Key was rejected by service > # strip -g e1000.ko > # insmod e1000.ko > # lsmod |grep e1000 > e1000 125977 0 Ok. This makes me think that the signature generation and/or verification are looking at something they shouldn't be. i.e., something strip changed. > > Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c > > (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. > > Sure, I'll add that too. Also hack modsign.sh to pass -v to mod-extract. The logs from mod-extract for a given module and the printks from verification looking at that module should give us something to go on. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
> Ya got me, but upon unpacking the initrd, modinfo tells me the bits in > the initrd have the right vermagic. That doesn't tell you anything useful. Compare the signature sections, e.g. readelf -x .module_sig on each. > However, the file sizes don't match. > In fact, they aren't even close. > > # (cd /tmp/initrd-104/lib; ll ext3.ko) > -rw--- 1 root root 189096 2007-08-14 15:31 ext3.ko > > # (cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kerne/fs/ext3; ll ext3.ko) > -rw-r--r-- 1 root root 2719832 2007-08-14 12:46 ext3.ko mkinitrd runs strip -g on the modules copied to the initrd. I hadn't noticed that before, but it should not be a problem. (Its affect on the signature issue should not have changed.) > Okay, so I rebuilt the initrd and bounced the box... And there's the > expected kernel panic. So now I'm thoroughly confused as to where the > hell the modules that at least booted the system came from... Ok, we'll call the first experience a mysterious hiccup then. Did you save your rpmbuild log? Can you double-check that it has no debugedit or find-debuginfo.sh runs that follow the modsign.sh runs? Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
> Roland McGrath wrote:
> >> That was from revision 1.87.
> >
> > Hmm. Actually the failure mode from before was not "modprobe" problems,
> > but never getting that far because the insmods in the initrd failed.
> > Do you have some magical setup that needs no modules? Or did it really
> > succeed at boot-time insmods and then modprobe fails?
>
> Looks like it really succeeded at boot-time insmods, I've got dm_*,
> ata_piix, ata_generic, libata, sd_mod, scsi_mod, ext3, jbd, mbcache and
> {e,o,u}hci_hcd modules all loaded.
Ok, color me ungentlemanly, but I have to ask if you've got the right
things installed on disk where modprobe is looking. I mean, where did you
get those modules with good signatures for the initrd if the ones on disk
are bad?
This is encouraging me to add the hack I had in mind the other day to make
the kernel tell you the public key it's using in a /sys file.
Thanks,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
> That was from revision 1.87. Hmm. Actually the failure mode from before was not "modprobe" problems, but never getting that far because the insmods in the initrd failed. Do you have some magical setup that needs no modules? Or did it really succeed at boot-time insmods and then modprobe fails? Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
> Roland McGrath wrote: > > This has nothing to do with the modsign issue. > > Hrm... It didn't start happening (that I noticed) until after some of > the recent changes you'd made, so I thought you might have an inkling as > to what was going on. I do, but it's harmless and not related to the modsign issue. > However, the behavior of the resulting kernel build *does* appear to be > related. I can't load any modules: > > # modprobe e1000 > FATAL: Error inserting e1000 (/lib/modules/.../e1000.ko): Key was > rejected by service. The is the failure mode that revision 1.84 of kernel.spec fixed. Are you using the current spec? > Best guess is that something goes haywire since I did this build > '--without debuginfo'. I can't see how that would break the fix for module signing. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
This has nothing to do with the modsign issue. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
modsign vs build-id
I fixed this in rawhide kernel.spec over the weekend and left a somewhat detailed comment in the changed bit. But I thought I'd bring this up directly and explain the story. The short version of What Broke is "what, you sha1 on me? no, i sha1 on you!" Module signing works by feeding all the allocated sections of the .ko into gpg and adding that signature to the .ko as the .module_sig section. The build ID note now included in each .ko when first built is an allocated section, so its contents contribute to that signature. As explained somewhere down the middle of [1], debugedit (the workhorse of find-debuginfo.sh) recomputes fresh build ID bits after editting the debuginfo, and edits the build ID bits in the object. This final build ID is computed with sha1 on most of the contents of the editted binary (including debuginfo). It's done this way to ensure that repeating the same rpmbuild twice with all the same constituents in the buildroot yields identical binaries both times (with the same build IDs), unaffected by the differences that debugedit removes, like the $RPM_BUILD_DIR name. In the old procedure, the modules were signed in place after being built. Then find-debuginfo.sh comes along at the end of the build, and edits the build ID bits in each .ko. Pow, the signature does not match the contents. The first fix I tried was changing module signing and verification so it skips allocated SHT_NOTE sections, which the build ID is. That worked. But that is not so hot in two ways. One, the signature is not serving as guarantor of the trustability of the module->build ID association. Worse, since the final build ID bits depend on everything in the installed .ko--including the .module_sig section--now repeated builds get different build IDs for the identical code compiled from identical sources. So I punted that. What kernel.spec now does is to sign the stripped .ko files only at the very end, after find-debuginfo.sh has done its work. This requires some spec macro hackery to get in at the right spot. Now a repeated build will still generate a new module-signing key and different signatures every time. But the build ID bits inside the signed modules will be the same every time. Now you know if a module got loaded with no unsigned taint, then the build ID bits it claims to have really are those the kernel packager wanted you to see. (Not that this is worth a lot.) Incidentally, if someone wants to freshen up the modsign patches, I think it would be better to change the format slightly. Thanks, Roland [1] http://fedoraproject.org/wiki/RolandMcGrath/BuildID ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: pre-release kernel release tag
> On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote: > > I propose we change the release format for snapshot kernels. > > Now we get e.g.: > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > and I suggest instead: > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > That is, put the spec file version number last, not first. This way, when > > we forget to reset fedora_cvs_origin after a rebase, we don't have to wait > > for the next kernel version to do it, just the next gitN. > > Is it that big a deal? I intended to only reset the origin after each > point release, so it doesn't really buy us anything being able to change > this with every -git. It's not a big deal, it's only numbers. The motivation was that it didn't get reset when we went from 2.6.22 to 2.6.23, and after one build hits rawhide, it's too late. Also, it's just better because it accurately reflects the topology of change. A spec release is a variant of a kernel snapshot, not vice versa. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: pre-release kernel release tag
> > On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote: > > I propose we change the release format for snapshot kernels. > > Now we get e.g.: > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > and I suggest instead: > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > That is, put the spec file version number last, not first. This way, when > > we forget to reset fedora_cvs_origin after a rebase, we don't have to wait > > for the next kernel version to do it, just the next gitN. > > > > We can't make this change until 2.6.23 sails, since for rpm version > > comparison rc* is < any [0-9]. > > Please don't do this. The kernel package is finally compliant with the > Fedora Packaging Guidelines and this change would break it again. > > The reason we prefix with the 0.# is to prevent versioning comparison > madness. What? I didn't propose removing the 0. prefix. What is the problem? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
pre-release kernel release tag
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version number last, not first. This way, when
we forget to reset fedora_cvs_origin after a rebase, we don't have to wait
for the next kernel version to do it, just the next gitN.
We can't make this change until 2.6.23 sails, since for rpm version
comparison rc* is < any [0-9].
--- kernel.spec 09 Aug 2007 13:45:09 -0700 1.72
+++ kernel.spec 09 Aug 2007 13:46:42 -0700
@@ -126,7 +126,7 @@ Summary: The Linux kernel (the core of t
%define rctag .rc0
%endif
%endif
-%define pkg_release 0.%{fedora_build}%{?rctag}%{?gittag}%{?buildid}%{?dist}
+%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid}%{?dist}
%endif
# The kernel tarball/base version
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
macroized spec committed
I put in the macroified kernel.spec last night. It also has some new magic changes to play well with the new find-debuginfo.sh. It hasn't built yet since I threw in some other broken changes at the same time, which are probably fixed by now for the next build Dave does. I made the bits that expect the new find-debuginfo.sh conditional on %fedora>7. So it probably will still work in [67] if you do later updates by plopping in the F8 spec. But I haven't really sanity-checked it for that case. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Alpha support for kernel
You should define define an all_alpha spec macro for alpha alphaev56. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
e1000e vs ppc
The e1000e patch seems to have broken ppc builds. I disabled it %ifarch (I know, bad) just for the moment so I could try to get a build to finish with my other commits. It needs a proper fix. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: macrofied kernel.spec
> Just realized it looks like you also snuck in a kernel-PAE-debug build
> variant... ;) Damn, it'd be nice if koji could spread kernel variant
> builds of the same arch across multiple builders...
I didn't add it, it was already there. I just made it uniform with the
others. Maybe the hand-editted duplication had left it not working? Or
not entirely removed when it was intended to be?
> Some of the documentation about what the -s and -r flags represent in
> the %kernel_variant_post would probably be worth adding though (just
> says [-s -r ] right now in the comment header, and my best guess
> is s=string, r=replacement).
Yeah, it forms a sed s command.
> Only other thing I'm seeing right now, though its probably been this way
> forever, is that we're a bit inconsistent about whether we use %{name}
> or just 'kernel' in %package and %description.
That matters when doing the variant-source packages like kernel-vanilla,
which I haven't tested lately. For the "install the kernel-foo package"
parts of %description, %{name}-foo might be better since it will make the
literal instructions match the intended reality for that case.
For the provides/requires some are intended to be %{name} and some kernel.
i.e., %{name}-debuginfo-common-%{_target_cpu}, but kernel-drm.
Thanks,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: macrofied kernel.spec
> I've been intending to do the same. Definitely nice to nuke a bunch of > the duplication, but at least in patch form, its not the easiest thing > to read and fully comprehend. Yes, don't try to read the patch. (It also gratuitously reorders a couple things, because that makes the final kernel.spec easier to read.) > Okay, spent a while looking at a patched spec file. I think I mostly > grok everything, though some of the magic I'm not sure I've ever seen > before. I might even feel comfortable trying to fix things iff Roland > does leave the country or have an accident... ;) If there is anything that you think should have more comments, let me know. I didn't bother with any comments explaining the % syntax being used. But probably there should be some. Like most things in rpm, 80% of the relevant details are not documented anywhere. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: macrofied kernel.spec
> Do -debuginfo packages for variants get produced automatically? Yes. The %kernel_variant_package macro uses %kernel_debuginfo_package (and %kernel_devel_package). The main package (kernel) uses those two macros, but not %kernel_variant_package. I didn't define a separate %kernel_debuginfo_files for %kernel_variant_files to use because for %kernel_variant_files the main package is just like the others. I could change it to break them out just to make it clearer. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
macrofied kernel.spec
The patch below revamps kernel.spec using macros to minimize duplication.
There is now very little boilerplate to write/update for each variant
built. It's now just a few %kernel_variant_foo macro lines for each flavor
(plus %description, which is unchanged). When the common boilerplate
details change, there is just one place to go tweak the spec (in a macro
definition) and no way to forget to update all the flavors.
There was an earlier foray into fancy macro use in the kernel spec
file, which got punted because of troubles with ancient rpmbuild
versions. But that was then, and this is now. Since then, the
build systems got fixed to use the proper rpmbuild for each build
version, and anyway are no longer running on RHEL3. No living (or
recently dead) Fedora, nor AFAIK RHEL>=4, will have problems with
this spec file.
The diff looks large, but that's because kernel.spec got ~500 lines
shorter. Even with the sprinkling of %%-heavy magic in the macro
definitions, I think the spec file is now overall easier to read.
(I say this, but then, I wrote the glibc makefiles as a child, so
my judgment is clearly suspect, and my breeding a lost cause.)
I think this is a nice cleanup on its own. The reason I actually
did it is that the debuginfo package details will have to change
soon when a new find-debuginfo.sh comes in rpm, which is cleaned up
generally and does new magic for the build-id stuff. I really
don't want to have to start dicking with that before it's
consolidated into only one place I have to touch.
I've verified that this is a no-op vs the 0.61 build. i.e., it
generates rpms with the same files and same rpm magic, modulo a few
typo fixes and cosmetic cleanups/consolidation of rpm script fragments.
In the absence of frothing vitriol, I will commit this after
f8-test1 has sailed.
Thanks,
Roland
--- kernel.spec.~1.44~ 2007-07-31 15:01:40.0 -0700
+++ kernel.spec 2007-07-31 17:44:57.0 -0700
@@ -363,6 +363,11 @@ Summary: The Linux kernel (the core of t
%define _enable_debug_packages 0
%endif
+%define with_pae_debug 0
+%if %with_pae
+%define with_pae_debug %{with_debug}
+%endif
+
#
# Three sets of minimum package version requirements in the form of Conflicts:
# to versions below the minimum
@@ -385,7 +390,12 @@ Summary: The Linux kernel (the core of t
#
# The ld.so.conf.d file we install uses syntax older ldconfig's don't grok.
#
-%define xen_conflicts glibc < 2.3.5-1, xen < 3.0.1
+%define kernel_xen_conflicts glibc < 2.3.5-1, xen < 3.0.1
+
+# upto and including kernel 2.4.9 rpms, the 4Gb+ kernel was called
kernel-enterprise
+# now that the smp kernel offers this capability, obsolete the old kernel
+%define kernel_smp_obsoletes kernel-enterprise < 2.4.10
+%define kernel_PAE_obsoletes kernel-smp < 2.6.17
#
# Packages that need to be installed before the kernel is, because the %post
@@ -393,6 +403,29 @@ Summary: The Linux kernel (the core of t
#
%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1,
mkinitrd >= 6.0.9-7
+#
+# This macro does requires, provides, conflicts, obsoletes for a kernel
package.
+# %%kernel_reqprovconf
+# It uses any kernel__conflicts and kernel__obsoletes
+# macros defined above.
+#
+%define kernel_reqprovconf \
+Provides: kernel = %{rpmversion}-%{pkg_release}\
+Provides: kernel-%{_target_cpu} = %{rpmversion}-%{pkg_release}\
+Provides: kernel-drm = 4.3.0\
+Provides: kernel-drm-nouveau = 6\
+Requires(pre): %{kernel_prereq}\
+Conflicts: %{kernel_dot_org_conflicts}\
+Conflicts: %{package_conflicts}\
+%{?1:%{expand:%%{?kernel_%1_conflicts:Conflicts: %%{kernel_%1_conflicts\
+%{?1:%{expand:%%{?kernel_%1_obsoletes:Obsoletes: %%{kernel_%1_obsoletes\
+# We can't let RPM do the dependencies automatic because it'll then pick up\
+# a correct but undesirable perl dependency from the module headers which\
+# isn't required for the kernel proper to function\
+AutoReq: no\
+AutoProv: yes\
+%{nil}
+
Name: kernel%{?variant}
Group: System Environment/Kernel
License: GPLv2
@@ -403,17 +436,11 @@ Release: %{pkg_release}
# SET %nobuildarches (ABOVE) INSTEAD
ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390x
alpha alphaev56
ExclusiveOS: Linux
-Provides: kernel-drm = 4.3.0
-Provides: kernel-drm-nouveau = 6
-Provides: kernel-%{_target_cpu} = %{rpmversion}-%{release}
-Requires(pre): %{kernel_prereq}
-Conflicts: %{kernel_dot_org_conflicts}
-Conflicts: %{package_conflicts}
-# We can't let RPM do the dependencies automatic because it'll then pick up
-# a correct but undesirable perl dependency from the module headers which
-# isn't required for the kernel proper to function
-AutoReq: no
-AutoProv: yes
+
+%kernel_reqprovconf
+%ifarch x86_64
+Obsoletes: kernel-smp
+%endif
#
@@ -601,24 +628,37 @@ Patch1230: linux-2.6-powerpc-spu-vicinit
BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root-%{_target_cpu}
-%ifarch x86_64
-Obsoletes: kernel-smp
-%endif
-
%description
The kernel package contains th
f7/rawhide utrace
The mondo powerpc update upstream today will take some substantial merging and rejiggery work, and I might do something different tonight instead. If you rebase rawhide before I get there, you will hit trouble. The conflicts outside powerpc are simple. I made a 2.6.22/ backport from the 2.6-current patches (probably same set now in rawhide). That should do fine for f7. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
> On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote:
> > On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote:
> > > > It's non-obvious to me what %{?buildid} is, but it seems to
> > > > auto-increment.
> > >
> > > buildid is the "please set this to .me" one.
> > > fedora_build is the one to bump on commit.
> >
> > Can't %{fedora_build} be set based on the $Revision$ keyword, to be
> > incremented automatically on commit, just like %{specrelease} was
> > auto-incremeted previously?
>
> Yes, it can. With..
>
> %define fedora_build %(R="$Revision: 1.3125 $"; RR="${R##: }"; echo %${RR%%?}
> | sed s/1\.//)
>
> Which would yield..
>
> kernel-2.6.22-0.3125.rc7.fc8
%define fedora_cvs_origin 3120
%define fedora_build %(R="$Revision: 1.3125 $"; R="${R%% \$}"; R="${R##: 1.}";
expr $R - %{fedora_cvs_origin})
Change fedora_cvs_origin to current $Revision$ s/1.// when you change sublevel.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
> It's non-obvious to me what %{?buildid} is, but it seems to
> auto-increment.
buildid is the "please set this to .me" one.
fedora_build is the one to bump on commit.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
What's Patch5? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
> I presume you're referring to the likes of say kernel 2.6.21-gitX, which > was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn't thought about that > case. Okay, will have to do some further twiddling to cover that case... Yes, that's what I meant. Faking it as "rc0" might be the easiest thing to keep the scheme's release numbers increasing. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
What about before the first -rcN tag? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
I think this is what will fix the kernel-vanilla-debuginfo-common problem.
--- kernel-2.6.spec 2 Jul 2007 17:07:41 - 1.3245
+++ kernel-2.6.spec 2 Jul 2007 20:28:13 -
@@ -1473,10 +1477,10 @@ BuildKernel %make_target %kernel_image k
%global __debug_package 1
%files debuginfo-common
%defattr(-,root,root)
-/usr/src/debug/%{name}-%{version}/linux-%{kversion}.%{_target_cpu}
+/usr/src/debug/kernel-%{version}/linux-%{kversion}.%{_target_cpu}
%if %{includexen}
%if %{with_xen}
-/usr/src/debug/%{name}-%{version}/xen
+/usr/src/debug/kernel-%{version}/xen
%endif
%endif
%dir /usr/src/debug
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
> So I finally got around to poking at these bits again myself (in
> relation to bug 240878), but ran into an issue with a vanilla/nopatches
> build:
>
> $ rpmbuild -bb --with baseonly --define 'nopatches 1' kernel-2.6.spec
> RPM build errors:
> File not found:
> /data/buildroot/tmp/kernel-2.6.21-1.3243.fc8-root-x86_64/usr/src/debug/kernel-vanilla-2.6.21/linux-2.6.21.x86_64
>
> There exists a .../debug/kernel-2.6.21/linux-2.6.21.x86_64 though.
> (Looking into it more now, but figured I'd throw it out there, in case
> someone already knows what's up).
Hmm. There are various magic things that use %{name} and others that use
"kernel" explicitly. I'm sure this worked when I checked the stuff in. So
something must have changed. I had to tweak something or other because of
this issue, probably the %setup -n arg, but I don't quite recall. I made
it use plain kernel-%{version} for the source dir name mostly so that an
rpmbuild in your working dir reuses the kernel-V/vanilla dir and links.
For having both installed in debuginfo rpms, it might make more sense to
let it all use %{name}.
> Also, anyone have thoughts on re-versioning, at least in the vanilla
> case, so as to more accurately describe what's being built? For example,
> the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets
> churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such
> thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
My gen-patches script used for the git-based rpms does something vaguely
like this based on: git describe | sed 's/-g[0-9a-f]*$//;s/-/./g;s/^v//'.
The -gitN names are not actual tags so git tools don't tell you about them,
but the newfangled git-describe "number of commits since" version number
makes for something that increases and can be resolved into an upstream rev.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
linux-2.6-elf-core-sysctl.patch
Without objection, I will throw this into rawhide. I want to get some
beating on it done before I send it upstream. The related bits that make
it cool may hit rawhide soonish.
If an F7 update got this too but with dump_dso_headers = 0 default, that
would be groovy. It is a no-op when disabled and having the option would
be nice for people wanting to play with the userland tools that like this,
who don't have a rawhide install.
Thanks,
Roland
---
[PATCH] Add sysctl controls on ELF core dump segments, dump first page of DSOs
This adds two sysctl items under fs.binfmt_elf for controlling how memory
segments are dumped in ELF core files. The dump_whole_segments option can
be set to have private file mappings dumped in their entirety.
The dump_dso_headers option is the new default. This dumps the first page
(only) of a read-only private file mapping if it appears to be a mapping of
an ELF file. Including these pages in the core dump may give sufficient
identifying information to associate the original DSO and executable file
images and their debugging information with a core file in a generic way
just from its contents.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c | 152 ++-
1 files changed, 128 insertions(+), 24 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index fa8ea33..ae63521 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1151,6 +1152,10 @@ out:
* Modelled on fs/exec.c:aout_core_dump()
* Jeremy Fitzhardinge <[EMAIL PROTECTED]>
*/
+
+static int dump_whole_segments = 0;
+static int dump_dso_headers = 1;
+
/*
* These are the only things you should do on a core-file: use only these
* functions to write out all the necessary info.
@@ -1183,31 +1188,60 @@ static int dump_seek(struct file *file, loff_t off)
}
/*
- * Decide whether a segment is worth dumping; default is yes to be
- * sure (missing info is worse than too much; etc).
- * Personally I'd include everything, and use the coredump limit...
- *
- * I think we should skip something. But I am not sure how. H.J.
+ * Decide what to dump of a segment, part, all or none.
*/
-static int maydump(struct vm_area_struct *vma)
+static unsigned long vma_dump_size(struct vm_area_struct *vma)
{
/* The vma can be set up to tell us the answer directly. */
if (vma->vm_flags & VM_ALWAYSDUMP)
- return 1;
+ goto whole;
/* Do not dump I/O mapped devices or special mappings */
if (vma->vm_flags & (VM_IO | VM_RESERVED))
return 0;
/* Dump shared memory only if mapped from an anonymous file. */
- if (vma->vm_flags & VM_SHARED)
- return vma->vm_file->f_path.dentry->d_inode->i_nlink == 0;
-
- /* If it hasn't been written to, don't write it out */
- if (!vma->anon_vma)
+ if (vma->vm_flags & VM_SHARED) {
+ if (vma->vm_file->f_path.dentry->d_inode->i_nlink == 0)
+ goto whole;
return 0;
+ }
- return 1;
+ /* Dump segments that have been written to. */
+ if (vma->anon_vma)
+ goto whole;
+
+ if (dump_whole_segments)
+ goto whole;
+
+ /*
+* If this looks like the beginning of a DSO or executable mapping,
+* check for an ELF header. If we find one, dump the first page to
+* aid in determining what was mapped here.
+*/
+ if (dump_dso_headers && vma->vm_file != NULL && vma->vm_pgoff == 0) {
+ u32 __user *header = (u32 __user *) vma->vm_start;
+ u32 word;
+ /*
+* Doing it this way gets the constant folded by GCC.
+*/
+ union {
+ u32 cmp;
+ char elfmag[SELFMAG];
+ } magic;
+ BUILD_BUG_ON(SELFMAG != sizeof word);
+ magic.elfmag[EI_MAG0] = ELFMAG0;
+ magic.elfmag[EI_MAG1] = ELFMAG1;
+ magic.elfmag[EI_MAG2] = ELFMAG2;
+ magic.elfmag[EI_MAG3] = ELFMAG3;
+ if (get_user(word, header) == 0 && word == magic.cmp)
+ return PAGE_SIZE;
+ }
+
+ return 0;
+
+whole:
+ return vma->vm_end - vma->vm_start;
}
/* An ELF note in memory */
@@ -1642,16 +1676,13 @@ static int elf_core_dump(long signr, struct pt_regs
*regs, struct file *file)
for (vma = first_vma(current, gate_vma); vma != NULL;
vma = next_vma(vma, gate_vma)) {
struct elf_phdr phdr;
- size_t sz;
-
- sz = vma->vm_end - vma->vm_start;
phdr.p
rawhide kernel fuzz
Dave disabled utrace because sched-cfs has a line that conflicts. It only
conflicts under -F1, and with default patching (-F2) utrace applies fine
after sched-cfs. This tweak to the spec file's ApplyPatch makes it easy to
make one patch use -F2 when you need it, instead of disabling a patch
because of a conflict that patch resolves just fine.
Thanks,
Roland
--- kernel-2.6.spec 21 Jun 2007 23:20:46 -0700 1.3233
+++ kernel-2.6.spec 21 Jun 2007 23:49:07 -0700
@@ -889,13 +890,15 @@ cd linux-%{kversion}.%{_target_cpu}
patch_command='patch -p1 -F1 -s'
ApplyPatch()
{
- if [ ! -f $RPM_SOURCE_DIR/$1 ]; then
+ local patch=$1
+ shift
+ if [ ! -f $RPM_SOURCE_DIR/$patch ]; then
exit 1;
fi
- case "$1" in
- *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$1" | $patch_command ;;
- *.gz) gunzip < "$RPM_SOURCE_DIR/$1" | $patch_command ;;
- *) $patch_command < "$RPM_SOURCE_DIR/$1" ;;
+ case "$patch" in
+ *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;;
+ *.gz) gunzip < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;;
+ *) $patch_command ${1+"$@"} < "$RPM_SOURCE_DIR/$patch" ;;
esac
}
@@ -914,9 +917,9 @@ ApplyPatch patch-2.6.22-rc5-git4.bz2
ApplyPatch linux-2.6-sched-cfs.patch
# Roland's utrace ptrace replacement.
-#ApplyPatch linux-2.6-utrace.patch
-# setuid /proc/self/maps fix. (dependant on utrace)
-#ApplyPatch linux-2.6-proc-self-maps-fix.patch
+ApplyPatch linux-2.6-utrace.patch -F2
+# setuid /proc/self/maps fix. (dependent on utrace)
+ApplyPatch linux-2.6-proc-self-maps-fix.patch
# Nouveau DRM
#ApplyPatch nouveau-drm.patch
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
eu-unstrip
There was some complaining here about problems dealing with separate debuginfo files. In elfutils-0.128, in an f6 and fc7 update near you, there is now eu-strip. This doesn't improve any non-elfutils tools you were using that weren't handling separate debuginfo well, but it makes it easy to recover a unified unstripped file to use them on. For a good time, try "mkdir foo; eu-unstrip -d foo -a -k". It is either more or less fun with -m, according to taste. For other uses you might want -K2.6.21-1.678.fc9 or -K/some/where, or other options available (see --help). I hope this is useful on occasion. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: fedora kernel utrace updates
> In FC6 kernel 2959, building now. Please test soon, I do need to get a kernel > out but really want to get this update in. If it's broken I can revert. I haven't gotten folks to test that build yet, but already I have a few more fixes (242694, 244162). The updated patches are on the web (all versions). Brew task 820195 is a scratch build of 1.2960.fc6 using a newer utrace patch. Hopefully I'll get some testing done on that when it finishes. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
