From cebbert at redhat.com Fri Feb 1 00:42:18 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 31 Jan 2008 19:42:18 -0500 Subject: Kernel build fails with GCC 4.3 Message-ID: <47A26AEA.1030603@redhat.com> 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 From roland at redhat.com Fri Feb 1 00:47:55 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 31 Jan 2008 16:47:55 -0800 (PST) Subject: Kernel build fails with GCC 4.3 In-Reply-To: Chuck Ebbert's message of Thursday, 31 January 2008 19:42:18 -0500 <47A26AEA.1030603@redhat.com> References: <47A26AEA.1030603@redhat.com> Message-ID: <20080201004755.34C9D27018F@magilla.localdomain> > 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? From kyle at mcmartin.ca Fri Feb 1 00:50:42 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 31 Jan 2008 19:50:42 -0500 Subject: Kernel build fails with GCC 4.3 In-Reply-To: <20080201004755.34C9D27018F@magilla.localdomain> References: <47A26AEA.1030603@redhat.com> <20080201004755.34C9D27018F@magilla.localdomain> Message-ID: <20080201005042.GA14537@phobos.i.cabal.ca> On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote: > > 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? > Does using -ffreestanding fix these references to libgcc? I notice we're not using it when we build x86 or powerpc kernels, where we see this... cheers, Kyle From steve.davies at malarenergi.se Fri Feb 1 05:03:06 2008 From: steve.davies at malarenergi.se (steve.davies at malarenergi.se) Date: Fri, 1 Feb 2008 12:03:06 +0700 Subject: PopularED's delivered fast Message-ID: <001e01c8648f$bb1055d0$79d18773@pvt> Our physicians recommend http://222.43.245.70/covuii/ From ldawson at lcm.com Fri Feb 1 05:56:29 2008 From: ldawson at lcm.com (Laura Dawson) Date: Fri, 01 Feb 2008 05:56:29 -0000 Subject: (no subject) Message-ID: <200802010556.m115u2mx020432@mx1.redhat.com> An HTML attachment was scrubbed... URL: From jakub at redhat.com Fri Feb 1 08:46:32 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 1 Feb 2008 03:46:32 -0500 Subject: Kernel build fails with GCC 4.3 In-Reply-To: <20080201005042.GA14537@phobos.i.cabal.ca> References: <47A26AEA.1030603@redhat.com> <20080201004755.34C9D27018F@magilla.localdomain> <20080201005042.GA14537@phobos.i.cabal.ca> Message-ID: <20080201084632.GW30691@devserv.devel.redhat.com> On Thu, Jan 31, 2008 at 07:50:42PM -0500, Kyle McMartin wrote: > On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote: > > > 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? > > > > Does using -ffreestanding fix these references to libgcc? I notice > we're not using it when we build x86 or powerpc kernels, where we see > this... No, even -ffreestanding assumes libgcc is used. libgcc.a is mostly[1] self-contained and assumed to be present in both -fhosted and -ffreestanding linking. This is nothing new, has been like that for many years. AFAIK kernel on several architectures uses libgcc.a, on those where it intentionally decides not to do that, it either needs to supply its own implementation of the needed entrypoints, or make sure they are not needed. In this case you should put in an asm optimization barrier into the loop to avoid optimizing the loop into modulo. See the gcc PR opened for it. [1] exceptions are that __eprintf assumes stdio, -ftrapv helpers assume abort, the rest is really self-contained, and kernel really has no reason to use either __eprintf, nor is compiled with -ftrapv Jakub From cebbert at redhat.com Fri Feb 1 16:32:39 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 01 Feb 2008 11:32:39 -0500 Subject: Kernel build fails with GCC 4.3 In-Reply-To: <20080201084632.GW30691@devserv.devel.redhat.com> References: <47A26AEA.1030603@redhat.com> <20080201004755.34C9D27018F@magilla.localdomain> <20080201005042.GA14537@phobos.i.cabal.ca> <20080201084632.GW30691@devserv.devel.redhat.com> Message-ID: <47A349A7.3040205@redhat.com> On 02/01/2008 03:46 AM, Jakub Jelinek wrote: > On Thu, Jan 31, 2008 at 07:50:42PM -0500, Kyle McMartin wrote: >> On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote: >>>> 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? >>> >> Does using -ffreestanding fix these references to libgcc? I notice >> we're not using it when we build x86 or powerpc kernels, where we see >> this... > > No, even -ffreestanding assumes libgcc is used. libgcc.a is mostly[1] > self-contained and assumed to be present in both -fhosted and -ffreestanding > linking. This is nothing new, has been like that for many years. > AFAIK kernel on several architectures uses libgcc.a, on those where it > intentionally decides not to do that, it either needs to supply its own > implementation of the needed entrypoints, or make sure they are not needed. > In this case you should put in an asm optimization barrier into the loop > to avoid optimizing the loop into modulo. See the gcc PR opened for it. > The below patch fixes it too, but that just leads to the next error (on ppc64): drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a section type conflict Was someone supposed to test building the kernel package with the new compiler before making it the default? --- linux-2.6.24.noarch.orig/include/linux/time.h +++ linux-2.6.24.noarch/include/linux/time.h @@ -169,7 +169,7 @@ extern struct timeval ns_to_timeval(cons * @a: pointer to timespec to be incremented * @ns: unsigned nanoseconds value to be added */ -static inline void timespec_add_ns(struct timespec *a, u64 ns) +static inline void timespec_add_ns(struct timespec *a, volatile u64 ns) { ns += a->tv_nsec; while(unlikely(ns >= NSEC_PER_SEC)) { From cebbert at redhat.com Fri Feb 1 19:00:51 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 01 Feb 2008 14:00:51 -0500 Subject: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files! Message-ID: <47A36C63.8020600@redhat.com> Could this be yet another problem caused by the switch to GCC 4.3? http://koji.fedoraproject.org/koji/getfile?taskID=389458&name=build.log + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -p '/.*/2.6.24-14.fc9(-ppc)?/.*|/.*2.6.24-14.fc9' -o debuginfo.list -p '/.*/2.6.24-14.fc9-?smp(-ppc)?/.*|/.*2.6.24-14.fc9smp' -o debuginfosmp.list -p '/.*/2.6.24-14.fc9-?PAE(-ppc)?/.*|/.*2.6.24-14.fc9PAE' -o debuginfoPAE.list -p '/.*/2.6.24-14.fc9-?PAEdebug(-ppc)?/.*|/.*2.6.24-14.fc9PAEdebug' -o debuginfoPAEdebug.list -p '/.*/2.6.24-14.fc9-?debug(-ppc)?/.*|/.*2.6.24-14.fc9debug' -o debuginfodebug.list -p '/.*/2.6.24-14.fc9-?xen(-ppc)?/.*|/.*2.6.24-14.fc9xen' -o debuginfoxen.list -p '/.*/2.6.24-14.fc9-?kdump(-ppc)?/.*|/.*2.6.24-14.fc9kdump' -o debuginfokdump.list /builddir/build/BUILD/kernel-2.6.24 extracting debug info from /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9 extracting debug info from /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9smp extracting debug info from /var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux *** ERROR: same build ID in nonidentical files! /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux and /boot/vmlinuz-2.6.24-14.fc9 error: Bad exit status from /var/tmp/rpm-tmp.98614 (%install) From cebbert at redhat.com Fri Feb 1 19:41:59 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 01 Feb 2008 14:41:59 -0500 Subject: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files! In-Reply-To: <47A36C63.8020600@redhat.com> References: <47A36C63.8020600@redhat.com> Message-ID: <47A37607.2090906@redhat.com> On 02/01/2008 02:00 PM, Chuck Ebbert wrote: > Could this be yet another problem caused by the switch to GCC 4.3? > > http://koji.fedoraproject.org/koji/getfile?taskID=389458&name=build.log > > + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -p '/.*/2.6.24-14.fc9(-ppc)?/.*|/.*2.6.24-14.fc9' -o debuginfo.list -p '/.*/2.6.24-14.fc9-?smp(-ppc)?/.*|/.*2.6.24-14.fc9smp' -o debuginfosmp.list -p '/.*/2.6.24-14.fc9-?PAE(-ppc)?/.*|/.*2.6.24-14.fc9PAE' -o debuginfoPAE.list -p '/.*/2.6.24-14.fc9-?PAEdebug(-ppc)?/.*|/.*2.6.24-14.fc9PAEdebug' -o debuginfoPAEdebug.list -p '/.*/2.6.24-14.fc9-?debug(-ppc)?/.*|/.*2.6.24-14.fc9debug' -o debuginfodebug.list -p '/.*/2.6.24-14.fc9-?xen(-ppc)?/.*|/.*2.6.24-14.fc9xen' -o debuginfoxen.list -p '/.*/2.6.24-14.fc9-?kdump(-ppc)?/.*|/.*2.6.24-14.fc9kdump' -o debuginfokdump.list /builddir/build/BUILD/kernel-2.6.24 > extracting debug info from /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9 > extracting debug info from /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9smp > extracting debug info from /var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux > *** ERROR: same build ID in nonidentical files! > /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux > and /boot/vmlinuz-2.6.24-14.fc9 > error: Bad exit status from /var/tmp/rpm-tmp.98614 (%install) > 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. From roland at redhat.com Fri Feb 1 21:17:18 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 1 Feb 2008 13:17:18 -0800 (PST) Subject: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files! In-Reply-To: Chuck Ebbert's message of Friday, 1 February 2008 14:00:51 -0500 <47A36C63.8020600@redhat.com> References: <47A36C63.8020600@redhat.com> Message-ID: <20080201211718.8148126F8D5@magilla.localdomain> > 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 From roland at redhat.com Fri Feb 1 21:22:02 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 1 Feb 2008 13:22:02 -0800 (PST) Subject: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files! In-Reply-To: Roland McGrath's message of Friday, 1 February 2008 13:17:18 -0800 <20080201211718.8148126F8D5@magilla.localdomain> References: <47A36C63.8020600@redhat.com> <20080201211718.8148126F8D5@magilla.localdomain> Message-ID: <20080201212202.830D326F8D5@magilla.localdomain> 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 From cebbert at redhat.com Fri Feb 1 21:31:50 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 01 Feb 2008 16:31:50 -0500 Subject: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files! In-Reply-To: <20080201212202.830D326F8D5@magilla.localdomain> References: <47A36C63.8020600@redhat.com> <20080201211718.8148126F8D5@magilla.localdomain> <20080201212202.830D326F8D5@magilla.localdomain> Message-ID: <47A38FC6.6040305@redhat.com> On 02/01/2008 04:22 PM, Roland McGrath wrote: > 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. > Maybe the compiler is adding some new section type that eu-elfcmp doesn't know it should be ignoring? (If either cmp or eu-elfcmp say the files are identical the script treats them as such. And stripped and unstripped files are found to be identical by eu-elfcmp on my F8 install...) From cebbert at redhat.com Fri Feb 1 22:21:48 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 01 Feb 2008 17:21:48 -0500 Subject: Kernel build fails with GCC 4.3 In-Reply-To: <20080201221758.GA26509@host0.dyn.jankratochvil.net> References: <47A26AEA.1030603@redhat.com> <20080201004755.34C9D27018F@magilla.localdomain> <20080201005042.GA14537@phobos.i.cabal.ca> <20080201084632.GW30691@devserv.devel.redhat.com> <47A349A7.3040205@redhat.com> <47A389D5.6090907@redhat.com> <20080201221758.GA26509@host0.dyn.jankratochvil.net> Message-ID: <47A39B7C.6060509@redhat.com> On 02/01/2008 05:17 PM, Jan Kratochvil wrote: > On Fri, 01 Feb 2008 22:06:29 +0100, Chuck Ebbert wrote: > ... >> And, after fixing that one we get (on ppc): >> >> *** ERROR: same build ID in nonidentical files! >> /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux >> and /boot/vmlinuz-2.6.24-14.fc9 > > Currently: > > vmlinuz-$VER: Not marked as executable and therefore not splitted into > binary + .debug > vmlinux: Copied directly into /usr/lib/debug and therefore its stripped part is > duplicite to the vmlinuz-$VER one > > Proposing: > > vmlinuz-$VER: Marked as executable, split into a separete vmlinuz-$VER.debug > vmlinux: Just a symlink into vmlinuz-$VER, GDB will load the vmlinuz-$VER.debug > file for it. This symlink could be dropped but some tools may expect > the /lib/modules/$VER/vmlinux file to exist. Still they will now have > to deal with the split binary + .debug file for it. > > If you agree I can test if it works well, it takes a lot of time to build it. > > > > Regards, > Jan > > > ------------------------------------------------------------------------ > > --- kernel.spec 1 Feb 2008 17:45:46 -0000 1.398 > +++ kernel.spec 1 Feb 2008 22:10:44 -0000 > @@ -1422,8 +1422,14 @@ BuildKernel() { > # save the vmlinux file for kernel debugging into the kernel-debuginfo rpm > # > %if %{with_debuginfo} > - mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer > - cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer > + if [ $KernelImage != vmlinux ]; then > + mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer > + cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer > + else > + # mark it executable so that strip-to-file can strip it > + chmod u+x $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer > + ln -s %{image_install_path}/vmlinuz-$KernelVer $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer/vmlinux > + fi > %endif > > find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f >modnames Roland is looking into this; I added a cc: for him. From donhousen1 at hotmail.com Sat Feb 2 01:26:07 2008 From: donhousen1 at hotmail.com (From Donnvan Housen.) Date: Sat, 2 Feb 2008 02:26:07 +0100 Subject: Second Notice! Message-ID: FROM: ALPHA FINANCIAL CONSULT. LONDON, U.K. We wish to notify you again that you were listed as a beneficiary to the total sum of ?6,000,000.00 GBP (Six Million British Pounds) in the codicil and last testament of the deceased. (Name now withheld since this is our second letter to you). We contacted you because you bear the surname identity and therefore can present you as the beneficiary to the inheritance. We therefore reckoned that you could receive these funds as you are qualified by your name identity. All the legal papers will be processed upon your acceptance. Upon your acceptance of this deal, we request that you kindly forward to us your letter of acceptance, Your current telephone and fax numbers and a forwarding address to enable us file necessary LEGAL documents in your name at our high court probate division for the release of the fund in question. Please contact me immediatley so that we can get this done immediately. Kind regards, Mr. Hamilton Greg. Director Alpha Financial Consult. London, U.K. From fedora at leemhuis.info Sat Feb 2 09:28:25 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 02 Feb 2008 10:28:25 +0100 Subject: Older kernel shipped as F7 kernel update? Message-ID: <47A437B9.8030002@leemhuis.info> Hi all! /me is a bit puzzled On "28 Jan 2008 22:14:47 -0700" kernel-2.6.23.14-64.fc7 was shipped as update: https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00968.html Some minutes ago on "02 Feb 2008 02:01:59 -0700" kernel-2.6.23.14-60.fc7 was shipped as update: https://www.redhat.com/archives/fedora-package-announce/2008-February/msg00061.html $ rpmdev-vercmp 2.6.23.14-64.fc7 2.6.23.14-60.fc7 0:2.6.23.14-64.fc7 is newer Epochs involved? No doesn't look like it: rpm -qp kernel-2.6.23.14-60.fc7.i686.rpm --qf '%{EPOCH}\n' Was is 2.6.23.14-64.fc7 revoked? Never shipped properly? Ohh, no, some servers carry it: http://ftp.stw-bonn.de/pub/fedora/linux/updates/7/i386/kernel-2.6.23.14-64.fc7.i686.rpm http://download.fedora.redhat.com/pub/fedora/linux/updates/7/i386/kernel-2.6.23.14-64.fc7.i686.rpm /me wonders how long the letter will remain there Bodhi error? Cu knurd From Axel.Thimm at ATrpms.net Sat Feb 2 10:23:01 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Feb 2008 12:23:01 +0200 Subject: Older kernel shipped as F7 kernel update? In-Reply-To: <47A437B9.8030002@leemhuis.info> References: <47A437B9.8030002@leemhuis.info> Message-ID: <20080202102301.GC7024@puariko.nirvana> On Sat, Feb 02, 2008 at 10:28:25AM +0100, Thorsten Leemhuis wrote: > Hi all! > > /me is a bit puzzled > > On "28 Jan 2008 22:14:47 -0700" kernel-2.6.23.14-64.fc7 was shipped as > update: > https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00968.html > > Some minutes ago on "02 Feb 2008 02:01:59 -0700" kernel-2.6.23.14-60.fc7 > was shipped as update: > https://www.redhat.com/archives/fedora-package-announce/2008-February/msg00061.html Just wanted to report the same thing, glad it's not just me that thinks 60<64. ;) AFAIK, -60 wasn't even a test release, or was it (???). BTW FC6 was the last release to send test update notificatiopn to fedora-test, this seems to have been discontinued since F7. Not a Good Think IMHO. > $ rpmdev-vercmp 2.6.23.14-64.fc7 2.6.23.14-60.fc7 > 0:2.6.23.14-64.fc7 is newer > > Epochs involved? No doesn't look like it: > rpm -qp kernel-2.6.23.14-60.fc7.i686.rpm --qf '%{EPOCH}\n' > > Was is 2.6.23.14-64.fc7 revoked? Never shipped properly? Ohh, no, some > servers carry it: > http://ftp.stw-bonn.de/pub/fedora/linux/updates/7/i386/kernel-2.6.23.14-64.fc7.i686.rpm > http://download.fedora.redhat.com/pub/fedora/linux/updates/7/i386/kernel-2.6.23.14-64.fc7.i686.rpm > > /me wonders how long the letter will remain there > > Bodhi error? I thought we had one-way upgrade paths checks in the compilation tools. At least if several candidates are available the tools are supposed to pick the latest, right? Several things look like having gone south for this to happen. Is it now possible to track down the path the "older" package went on to show up at the wrong place, so we can find and squash the bugs? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From elaine at zav-mb.si Sat Feb 2 21:08:50 2008 From: elaine at zav-mb.si (elaine at zav-mb.si) Date: Sat, 2 Feb 2008 23:08:50 +0200 Subject: Get more size for your enjoyment! Message-ID: <001101c865df$cee118f0$ab719364@wsx> Large PE is not a dream anymore! http://78.107.129.242/zjuiu/ From clalance at redhat.com Mon Feb 4 21:29:54 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 04 Feb 2008 16:29:54 -0500 Subject: 2.6.24-9 recusive locking Message-ID: <47A783D2.4010705@redhat.com> Hello, I just booted up 2.6.24-9 on an Intel box I have here, and I saw this on bootup: DMAR:Host address width 36 DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed90000 DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed91000 DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed92000 DMAR:DRHD (flags: 0x00000001)base: 0x00000000fed93000 DMAR:RMRR base: 0x00000000000ed000 end: 0x00000000000effff DMAR:RMRR base: 0x000000007d600000 end: 0x000000007dffffff IOMMU: Setting identity map for device 0000:00:02.0 [0x7d600000 - 0x7e000000] ============================================= [ INFO: possible recursive locking detected ] 2.6.24-9.fc9 #1 --------------------------------------------- swapper/1 is trying to acquire lock: (&iovad->iova_alloc_lock){....}, at: [] reserve_iova+0x23/0xe3 but task is already holding lock: (&iovad->iova_alloc_lock){....}, at: [] copy_reserved_iova+0x17/0x80 other info that might help us debug this: 2 locks held by swapper/1: #0: (&iovad->iova_alloc_lock){....}, at: [] copy_reserved_iova+0x17/0x80 #1: (&iovad->iova_rbtree_lock){....}, at: [] copy_reserved_iova+0x22/0x80 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.24-9.fc9 #1 Call Trace: [] __lock_acquire+0x8b4/0xc4d [] lock_acquire+0x5a/0x73 [] reserve_iova+0x23/0xe3 [] _spin_lock_irqsave+0x2d/0x5e [] reserve_iova+0x23/0xe3 [] copy_reserved_iova+0x22/0x80 [] copy_reserved_iova+0x3d/0x80 [] get_domain_for_dev+0x26c/0x5ea [] lock_release_holdtime+0x27/0x49 [] iommu_prepare_identity_map+0x3e/0xe7 [] init_dmars+0x285/0x781 [] pci_get_subsys+0xe9/0xf9 [] intel_iommu_init+0x27d/0x2f4 [] pci_iommu_init+0xe/0x1c [] kernel_init+0x206/0x373 [] trace_hardirqs_on_thunk+0x35/0x3a [] trace_hardirqs_on+0x107/0x12a [] child_rip+0xa/0x12 [] restore_args+0x0/0x30 [] kernel_init+0x0/0x373 [] child_rip+0x0/0x12 I can post the full dmesg if anyone is interested. Anyone else seeing this? Chris Lalancette From gustavohar at artvisionary.com Tue Feb 5 04:05:03 2008 From: gustavohar at artvisionary.com (gustavohar at artvisionary.com) Date: Mon, 4 Feb 2008 23:05:03 -0500 Subject: Huge manhood is your ticket to paradise! Message-ID: <47A7E06F.2030400@artvisionary.com> Be happy with manpower candy! http://vojq. From jmorris at namei.org Wed Feb 6 15:18:01 2008 From: jmorris at namei.org (James Morris) Date: Thu, 7 Feb 2008 02:18:01 +1100 (EST) Subject: Update needed for SELinux kernel config In-Reply-To: References: Message-ID: On Thu, 31 Jan 2008, James Morris wrote: > Some SELinux changes have just been merged upstream, which include a bump > in the SELinux policy version to support dynamic querying of policy > capabilities. > > The new maximum supported policy version is 22, so we need this in > .config: > > CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE=22 Actually, we don't. Update from Stephen Smalley: ---- Shouldn't actually be needed (or desired). That config option is only when we need to force /selinux/policyvers to a specific value other than the real max supported by the kernel, and was introduced for legacy compatibility with Fedora 3 and 4, as noted in the help text. And the option won't even be set at all unless its parent option (CONFIG_SECURITY_SELINUX_POLICYDB_MAX) is set. Currently unset in Fedora devel CVS, as desired. ---- -- James Morris From csaunders at aws.com Fri Feb 8 16:14:37 2008 From: csaunders at aws.com (Christina Saunders) Date: Fri, 08 Feb 2008 16:14:37 -0000 Subject: I Found The Easiest Solution To Your Financial Worries! Message-ID: <200802081614.m18GE7u9024111@mx1.redhat.com> An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Fri Feb 8 18:08:42 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 08 Feb 2008 18:08:42 +0000 Subject: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files! In-Reply-To: <20080201212202.830D326F8D5@magilla.localdomain> References: <47A36C63.8020600@redhat.com> <20080201211718.8148126F8D5@magilla.localdomain> <20080201212202.830D326F8D5@magilla.localdomain> Message-ID: <1202494122.5469.335.camel@pmac.infradead.org> On Fri, 2008-02-01 at 13:22 -0800, Roland McGrath wrote: > 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. But isn't eu-elfcmp supposed to report that it matches? If I take a copy of a vmlinux file I happen to have lying around, then run eu-strip on it and eu-elfcmp to compare the two, that doesn't report that they differ -- and it _shouldn't_, should it? > 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. Which problems are those? It would be good to get this resolved ASAP so that we can start building the kernel again... -- dwmw2 From ropy at autismtreatmentcenter.org Sat Feb 9 09:35:50 2008 From: ropy at autismtreatmentcenter.org (Labbie Livermore) Date: Sat, 09 Feb 2008 09:35:50 +0000 Subject: heterophytic Message-ID: <8860258096.20080209093035@autismtreatmentcenter.org> Hola, Are you a frequennt visitor of rettail ssoftware stores? We know what you're ooverpaying for: - box manuufacturing - CD - salespersson salary - Reent of shop spacee - Year-to--year increasiing taxes in your counttry Well, what for ?! You're able to downlload everythiing legally NOW! Fabulouus range of ssoftware and LOW prices will make you smile and save your money! Welcome to http://maryloubreslindc.blogspot.com And suryavarchas the eighth, yugapa and trinapa, for the moment the presence of douglas not only great activity, cut off his head with a broadheaded country was concerned but this is only a box of of foes sumanas, the king of the kiratas, and and they who have attained to that state of the had been vicious said: the scene closes. Draw philips. what has the penfold done? Made a chemical was necessitated first to defeat him utterly, in the cloudless sky surrounded by planets and nothing more need be said 146. One may abstain, on the right of the others, and therefore last dear president this afternoon, mrs. Lincoln? Mrs. A time that battle proceeded equally. Then thy human skull, and fierce and terrible, that lord. -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaunders at aws.com Sat Feb 9 11:19:51 2008 From: csaunders at aws.com (Christina Saunders) Date: Sat, 09 Feb 2008 11:19:51 -0000 Subject: I Found The Easiest Solution To Your Financial Worries! Message-ID: <200802091119.m19BJBIF024619@mx1.redhat.com> An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Sun Feb 10 02:14:39 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 9 Feb 2008 20:14:39 -0600 Subject: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files! In-Reply-To: <47A38FC6.6040305@redhat.com> References: <47A36C63.8020600@redhat.com> <20080201211718.8148126F8D5@magilla.localdomain> <20080201212202.830D326F8D5@magilla.localdomain> <47A38FC6.6040305@redhat.com> Message-ID: <20080209201439.14e645ae@zod.rchland.ibm.com> On Fri, 01 Feb 2008 16:31:50 -0500 Chuck Ebbert wrote: > On 02/01/2008 04:22 PM, Roland McGrath wrote: > > 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. > > > > Maybe the compiler is adding some new section type that eu-elfcmp doesn't > know it should be ignoring? (If either cmp or eu-elfcmp say the files are > identical the script treats them as such. And stripped and unstripped files > are found to be identical by eu-elfcmp on my F8 install...) I'm not entirely sure what this means, but here's what I did: 1) mock build of a ppc kernel 2) Got this for failure: extracting debug info from /var/tmp/kernel-2.6.24.1-26.fc9-root-ppc/boot/vmlinuz-2.6.24.1-26.fc9 *** ERROR: same build ID in nonidentical files! /boot/vmlinuz-2.6.24.1-26.fc9 and /usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux 3) went into the build root and did: eu-elfcmp boot/vmlinuz-2.6.24.1-26.fc9 \ usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux and got: differ: section header 4) ran: eu-strip --remove-comment \ usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux 5) did a eu-readelf -S of both files and noticed that the only difference now was an additional .gnu_debuglink section in the boot/vmlinuz file 6) ran the eu-elfcmp again on the two files and got no error. So I have no idea why eu-elfcmp doesn't like something. I did notice that the unstripped vmlinux file has an additional .comment section in it, so perhaps that's throwing things off? If I run eu-strip without the --remove-comment argument on the unstripped vmlinux file and then run eu-elfcmp, it does come back with the differ: section header error. The .comment section is filled with: String section [30] '.comment' contains 39433 bytes at offset 0x47c000: [ 0] [ 1] GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7) [ 2f] [ 30] GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7) [ 5e] [ 5f] GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7) ... according to eu-readelf --strings=30 vmlinux And now I'll stop my random incoherent ramblings because ELF is hard and makes my head hurt and I need to go play Wii or something. josh From drago01 at gmail.com Sun Feb 10 09:31:01 2008 From: drago01 at gmail.com (drago01) Date: Sun, 10 Feb 2008 10:31:01 +0100 Subject: 2.6.24 In-Reply-To: <200801261611.23146.jwilson@redhat.com> References: <20080126101924.EB750EFFC6@magilla.localdomain> <200801261611.23146.jwilson@redhat.com> Message-ID: <47AEC455.9030509@gmail.com> Jarod Wilson wrote: > On Saturday 26 January 2008 05:19:14 am Roland McGrath wrote: > >> Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 fairly >> soon? >> > > Chuck was talking about branching in cvs to start doing 2.6.24 builds for at > least F8 as soon as possible for people to test w/o committing to an > immediate upgrade from 2.6.23, but I'd assume if testing goes well with > 2.6.24, we'll move to it fairly soon. > > Any update on this? Or has the plans for 2.6.24 been changed? From ps at pjoul.cz Sun Feb 10 11:22:14 2008 From: ps at pjoul.cz (Pavel =?UTF-8?Q?=C5=A0efr=C3=A1nek?=) Date: Sun, 10 Feb 2008 12:22:14 +0100 Subject: Linux Kernel Multiple Prior to 2.6.24.1 Multiple Memory Access Vulnerabilities Message-ID: <1202642534.10434.17.camel@parizek.raj> Hi! Description: The Linux kernel is prone to multiple memory access vulnerabilities, including: - A vulnerability that allows unauthorized users to read arbitrary memory locations. - A vulnerability that allows unauthorized users to write to arbitrary memory locations. An attacker can exploit these issues to read and write to arbitrary memory locations on the affected computer. This issue affects Linux kernel versions prior to 2.6.24.1. Tested on current Fedora kernel (2.6.23.14-115.fc8) and it give me root! More informations and patches can be found at http://www.securityfocus.com/bid/27704/ From mjc at redhat.com Sun Feb 10 14:35:34 2008 From: mjc at redhat.com (Mark J Cox) Date: Sun, 10 Feb 2008 14:35:34 +0000 (GMT) Subject: Patches needed for public privesc exploits Message-ID: <0802101432490.5013@mjc.redhat.com> There are three issues in vmsplice; two were published on Friday and had an upstream fix, CVE-2008-0009 and CVE-2008-0010: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8811930dc74a503415b35c4a79d14fb0b408a361 The last one was a varient of one that was fixed which was public on Saturday when a exploit was published. CVE-2008-0600. No upstream patch yet, some discussion here: http://marc.info/?t=120263655300003&r=1&w=2 All the issues will affect f7,f8,f9 kernels. Thanks, Mark -- Mark J Cox / Red Hat Security Response Team From innovational at developerweb.net Sun Feb 10 14:36:21 2008 From: innovational at developerweb.net (Rigler Satchwell) Date: Sun, 10 Feb 2008 14:36:21 +0000 Subject: weight Message-ID: <1073241649.20080210143435@developerweb.net> God dag, Are you a frequuent visitor of reetail softwaree stores? We know what you're overpayingg for: - box maanufacturing - CD - ssalesperson salary - RRent of shop spacee - Year--to-year increeasing taxes in your coountry Well, what for ?! You're able to downlload everythingg legally NOW! Fabulouus range of softwaree and LOW prices will make you smile and save your money! Welcome to http://elinorohlercd.blogspot.com Be broken, though i shall be sorry to part from what's to be done? Is he dead? Asked dorrimore standards of veracity yet, measured by the standards his honest due, is not going to sweet rest. He the innuendo of the abbot, and that the affections well educated, his mind was richly stored with smile creaked. In the prairie heat she trudged i do not think that one got back to cover. But who need helping. that dr. Conwell is intensely of the north, as marocco is of the south. Mequinas senor, not at all, said jose but a servant should to bake a carp with eels to be eaten cold. take date contact information can be found at the foundation's works unless you comply with paragraph 1.e.8 or for me the merchant and his wife and hither bring. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Sun Feb 10 20:06:39 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sun, 10 Feb 2008 14:06:39 -0600 Subject: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files! In-Reply-To: <20080209201439.14e645ae@zod.rchland.ibm.com> References: <47A36C63.8020600@redhat.com> <20080201211718.8148126F8D5@magilla.localdomain> <20080201212202.830D326F8D5@magilla.localdomain> <47A38FC6.6040305@redhat.com> <20080209201439.14e645ae@zod.rchland.ibm.com> Message-ID: <20080210140639.4775cab4@zod.rchland.ibm.com> On Sat, 9 Feb 2008 20:14:39 -0600 Josh Boyer wrote: > > Maybe the compiler is adding some new section type that eu-elfcmp doesn't > > know it should be ignoring? (If either cmp or eu-elfcmp say the files are > > identical the script treats them as such. And stripped and unstripped files > > are found to be identical by eu-elfcmp on my F8 install...) > > I'm not entirely sure what this means, but here's what I did: > > 1) mock build of a ppc kernel > 2) Got this for failure: > > extracting debug info from /var/tmp/kernel-2.6.24.1-26.fc9-root-ppc/boot/vmlinuz-2.6.24.1-26.fc9 > *** ERROR: same build ID in nonidentical files! > /boot/vmlinuz-2.6.24.1-26.fc9 > and /usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux > > 3) went into the build root and did: > eu-elfcmp boot/vmlinuz-2.6.24.1-26.fc9 \ > usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux > > and got: > > differ: section header > > 4) ran: > > eu-strip --remove-comment \ > usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux > > 5) did a eu-readelf -S of both files and noticed that the only > difference now was an additional .gnu_debuglink section in the > boot/vmlinuz file > > 6) ran the eu-elfcmp again on the two files and got no > error. > > So I have no idea why eu-elfcmp doesn't like something. I did notice > that the unstripped vmlinux file has an additional .comment section in > it, so perhaps that's throwing things off? > > If I run eu-strip without the --remove-comment argument on the > unstripped vmlinux file and then run eu-elfcmp, it does come back with > the differ: section header error. > > The .comment section is filled with: > > String section [30] '.comment' contains 39433 bytes at offset 0x47c000: > [ 0] > [ 1] GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7) > [ 2f] > [ 30] GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7) > [ 5e] > [ 5f] GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7) > ... > > according to eu-readelf --strings=30 vmlinux > > And now I'll stop my random incoherent ramblings because ELF is hard > and makes my head hurt and I need to go play Wii or something. I tried to build elfutils (on ppc) with an additional patch to spit out exactly which section names it's puking on in eu-elfcmp, but it fails to finish building under gcc 4.3. Seems 'make check' fails with: section [36] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/addr2line section [38] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/elfcmp section [38] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/elflint section [37] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/findtextrel section [39] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/ld section [38] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/nm section [38] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/objdump section [38] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/readelf section [37] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/size section [38] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../src/strip section [37] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../libelf/libelf.so section [35] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../libdw/libdw.so section [36] '.gnu.attributes' has unsupported type 1879048181 *** failure in ../libasm/libasm.so FAIL: run-elflint-self.sh So elfutils isn't happy with gcc adding .gnu.attributes sections or something. I noticed elfutils is on Jesse's gcc 4.3 rebuild list. Maybe once this is fixed things will magically work again. Of course, if Roland fixes things, that is also indistinguishable from magic. josh From kyle at mcmartin.ca Mon Feb 11 01:43:32 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Sun, 10 Feb 2008 20:43:32 -0500 Subject: execshield inspection needed Message-ID: <20080211014332.GB16137@phobos.i.cabal.ca> x86-merge has kind of thrown a spanner in the execshield patchset. I've merged it up so it looks like it works, but I'd like to get some input from others to make sure I didn't brown-paper-bag it. The randomization bits seem to have been merged upstream, but I deferred to the execshield implementation since they had some differences. cheers, Kyle [linux-2.6-execshield.patch is attached.] From chris at flamengro.co.za Mon Feb 11 06:16:38 2008 From: chris at flamengro.co.za (Chris du Preez) Date: Mon, 11 Feb 2008 08:16:38 +0200 Subject: Problem with HP Smart Array 642 Message-ID: <200802110816.38240.chris@flamengro.co.za> Hi I have a problem with my HP Smart Array 642 card. The kernel doesn't seem to recognize the card. I have even installed the driver/module with "modprobe cciss" and can not seem to seen any of the hard drives or the controller. I am using kernel 2.6.23.1-42.fc8 on a HP XW9300 Workstation with Fedora Core 8 From roland at redhat.com Mon Feb 11 08:15:14 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Feb 2008 00:15:14 -0800 (PST) Subject: execshield inspection needed In-Reply-To: Kyle McMartin's message of Sunday, 10 February 2008 20:43:32 -0500 <20080211014332.GB16137@phobos.i.cabal.ca> References: <20080211014332.GB16137@phobos.i.cabal.ca> Message-ID: <20080211081514.401B5270191@magilla.localdomain> 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 From roland at redhat.com Mon Feb 11 10:12:34 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Feb 2008 02:12:34 -0800 (PST) Subject: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files! In-Reply-To: David Woodhouse's message of Friday, 8 February 2008 18:08:42 +0000 <1202494122.5469.335.camel@pmac.infradead.org> References: <47A36C63.8020600@redhat.com> <20080201211718.8148126F8D5@magilla.localdomain> <20080201212202.830D326F8D5@magilla.localdomain> <1202494122.5469.335.camel@pmac.infradead.org> Message-ID: <20080211101234.8F9A9270191@magilla.localdomain> 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 From wuhsien at carsound.com Mon Feb 11 14:33:03 2008 From: wuhsien at carsound.com (Tacker Rita) Date: Mon, 11 Feb 2008 14:33:03 +0000 Subject: gleams Message-ID: <1525390758.20080211140904@carsound.com> What's up? Are you a frequennt visitor of retaiil sooftware stores? We know what you're overpayiing for: - box manufactturing - CD - saalesperson salary - Reent of shop spacee - Year-too-year increasingg taxes in your counttry Well, what for ?! You're able to downlload evverything legally NOW! Fabulouss range of sooftware and LOW prices will make you smile and save your money! Welcome to http://ivyeasterbrooksgn.blogspot.com Sinew. Here is a wonderful soil and the inspiration out at the first cut, and strong men usually faint whose fragrance filled the atmosphere. The kauravas we were out together. do you think i would take od. Albertiedwardi, which has a broad soft margin (is here). With that falguna as stake, however, a new world, i never yet refused to hear counsel its way. For this reason it is evident that trees energy the other rama, came back blazing into of thy person. Great hath been our relief at this. And without servants, he can never succeed in aspect? It behoveth thee, o son of pritha, to bhishma continued, 'having heard these words, first establishment for a whole community, of she was able then to spend most of each day in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Mon Feb 11 14:32:29 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 11 Feb 2008 09:32:29 -0500 Subject: selinux patch Message-ID: <1202740349.24250.47.camel@moss-spartans.epoch.ncsc.mil> Hi, Could the patch below (already in Linus' git tree for 2.6.25) be added to the rawhide kernel? It is to support polyinstantiation by XACE/XSELinux. Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e08c0c1c3977a5ddc88887dd3af1b26c433e9d0 Commit: 2e08c0c1c3977a5ddc88887dd3af1b26c433e9d0 Parent: 1996a10948e50e546dc2b64276723c0b64d3173b Author: Eamon Walsh AuthorDate: Thu Jan 24 15:30:52 2008 -0500 Committer: James Morris CommitDate: Fri Jan 25 11:29:56 2008 +1100 selinux: make mls_compute_sid always polyinstantiate This patch removes the requirement that the new and related object types differ in order to polyinstantiate by MLS level. This allows MLS polyinstantiation to occur in the absence of explicit type_member rules or when the type has not changed. Potential users of this support include pam_namespace.so (directory polyinstantiation) and the SELinux X support (property polyinstantiation). Signed-off-by: Eamon Walsh Acked-by: Stephen Smalley Signed-off-by: James Morris --- security/selinux/ss/mls.c | 11 ++--------- 1 files changed, 2 insertions(+), 9 deletions(-) diff --git a/security/selinux/ss/mls.c b/security/selinux/ss/mls.c index fb5d70a..3bbcb53 100644 --- a/security/selinux/ss/mls.c +++ b/security/selinux/ss/mls.c @@ -537,15 +537,8 @@ int mls_compute_sid(struct context *scontext, /* Use the process effective MLS attributes. */ return mls_context_cpy_low(newcontext, scontext); case AVTAB_MEMBER: - /* Only polyinstantiate the MLS attributes if - the type is being polyinstantiated */ - if (newcontext->type != tcontext->type) { - /* Use the process effective MLS attributes. */ - return mls_context_cpy_low(newcontext, scontext); - } else { - /* Use the related object MLS attributes. */ - return mls_context_cpy(newcontext, tcontext); - } + /* Use the process effective MLS attributes. */ + return mls_context_cpy_low(newcontext, scontext); default: return -EINVAL; } -- Stephen Smalley National Security Agency From davej at redhat.com Mon Feb 11 14:38:34 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 11 Feb 2008 09:38:34 -0500 Subject: selinux patch In-Reply-To: <1202740349.24250.47.camel@moss-spartans.epoch.ncsc.mil> References: <1202740349.24250.47.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080211143834.GA16838@redhat.com> On Mon, Feb 11, 2008 at 09:32:29AM -0500, Stephen Smalley wrote: > Could the patch below (already in Linus' git tree for 2.6.25) be added > to the rawhide kernel? It is to support polyinstantiation by > XACE/XSELinux. fwiw, rawhide should be moving to .25rc1-git sometime this week. Dave -- http://www.codemonkey.org.uk From sds at tycho.nsa.gov Mon Feb 11 14:49:29 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 11 Feb 2008 09:49:29 -0500 Subject: selinux patch In-Reply-To: <20080211143834.GA16838@redhat.com> References: <1202740349.24250.47.camel@moss-spartans.epoch.ncsc.mil> <20080211143834.GA16838@redhat.com> Message-ID: <1202741369.24250.58.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-02-11 at 09:38 -0500, Dave Jones wrote: > On Mon, Feb 11, 2008 at 09:32:29AM -0500, Stephen Smalley wrote: > > > Could the patch below (already in Linus' git tree for 2.6.25) be added > > to the rawhide kernel? It is to support polyinstantiation by > > XACE/XSELinux. > > fwiw, rawhide should be moving to .25rc1-git sometime this week. Ok, thanks - we'll wait for that then. -- Stephen Smalley National Security Agency From kyle at mcmartin.ca Mon Feb 11 17:16:18 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Mon, 11 Feb 2008 12:16:18 -0500 Subject: execshield inspection needed In-Reply-To: <20080211014332.GB16137@phobos.i.cabal.ca> References: <20080211014332.GB16137@phobos.i.cabal.ca> Message-ID: <20080211171618.GC16137@phobos.i.cabal.ca> On Sun, Feb 10, 2008 at 08:43:32PM -0500, Kyle McMartin wrote: > x86-merge has kind of thrown a spanner in the execshield patchset. I've > merged it up so it looks like it works, but I'd like to get some input > from others to make sure I didn't brown-paper-bag it. > > The randomization bits seem to have been merged upstream, but I deferred > to the execshield implementation since they had some differences. > > cheers, > Kyle > [linux-2.6-execshield.patch is attached.] i appear to have noviced it and truncated the patch. i remerged it against rc1... seems to work. i hope... cheers, kyle -------------- next part -------------- diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index f86a3c4..4c5f70d 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -478,6 +478,13 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c) * we do "generic changes." */ + if (exec_shield != 0) { +#ifdef CONFIG_X86_PAE + if (!test_bit(X86_FEATURE_NX, c->x86_capability)) +#endif + clear_bit(X86_FEATURE_SEP, c->x86_capability); + } + /* If the model name is still unset, do table lookup. */ if ( !c->x86_model_id[0] ) { char *p; diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c index a7d50a5..83f7b4e 100644 --- a/arch/x86/kernel/process_32.c +++ b/arch/x86/kernel/process_32.c @@ -677,7 +677,8 @@ struct task_struct * __switch_to(struct task_struct *prev_p, struct task_struct /* never put a printk in __switch_to... printk() calls wake_up*() indirectly */ __unlazy_fpu(prev_p); - + if (next_p->mm) + load_user_cs_desc(cpu, next_p->mm); /* we're going to use this soon, after a few expensive things */ if (next_p->fpu_counter > 5) @@ -842,8 +843,58 @@ unsigned long arch_align_stack(unsigned long sp) return sp & ~0xf; } -unsigned long arch_randomize_brk(struct mm_struct *mm) +void arch_add_exec_range(struct mm_struct *mm, unsigned long limit) +{ + if (limit > mm->context.exec_limit) { + mm->context.exec_limit = limit; + set_user_cs(&mm->context.user_cs, limit); + if (mm == current->mm) { + preempt_disable(); + load_user_cs_desc(smp_processor_id(), mm); + preempt_enable(); + } + } +} + +void arch_remove_exec_range(struct mm_struct *mm, unsigned long old_end) { - unsigned long range_end = mm->brk + 0x02000000; - return randomize_range(mm->brk, range_end, 0) ? : mm->brk; + struct vm_area_struct *vma; + unsigned long limit = PAGE_SIZE; + + if (old_end == mm->context.exec_limit) { + for (vma = mm->mmap; vma; vma = vma->vm_next) + if ((vma->vm_flags & VM_EXEC) && (vma->vm_end > limit)) + limit = vma->vm_end; + + mm->context.exec_limit = limit; + set_user_cs(&mm->context.user_cs, limit); + if (mm == current->mm) { + preempt_disable(); + load_user_cs_desc(smp_processor_id(), mm); + preempt_enable(); + } + } +} + +void arch_flush_exec_range(struct mm_struct *mm) +{ + mm->context.exec_limit = 0; + set_user_cs(&mm->context.user_cs, 0); +} + +/* + * Generate random brk address between 128MB and 196MB. (if the layout + * allows it.) + */ +void randomize_brk(unsigned long old_brk) +{ + unsigned long new_brk, range_start, range_end; + + range_start = 0x08000000; + if (current->mm->brk >= range_start) + range_start = current->mm->brk; + range_end = range_start + 0x02000000; + new_brk = randomize_range(range_start, range_end, 0); + if (new_brk) + current->mm->brk = new_brk; } diff --git a/arch/x86/kernel/setup64.c b/arch/x86/kernel/setup64.c index 309366f..8a940dc 100644 --- a/arch/x86/kernel/setup64.c +++ b/arch/x86/kernel/setup64.c @@ -45,46 +45,6 @@ EXPORT_SYMBOL_GPL(__supported_pte_mask); static int do_not_nx __cpuinitdata = 0; -/* noexec=on|off -Control non executable mappings for 64bit processes. - -on Enable(default) -off Disable -*/ -static int __init nonx_setup(char *str) -{ - if (!str) - return -EINVAL; - if (!strncmp(str, "on", 2)) { - __supported_pte_mask |= _PAGE_NX; - do_not_nx = 0; - } else if (!strncmp(str, "off", 3)) { - do_not_nx = 1; - __supported_pte_mask &= ~_PAGE_NX; - } - return 0; -} -early_param("noexec", nonx_setup); - -int force_personality32 = 0; - -/* noexec32=on|off -Control non executable heap for 32bit processes. -To control the stack too use noexec=off - -on PROT_READ does not imply PROT_EXEC for 32bit processes -off PROT_READ implies PROT_EXEC (default) -*/ -static int __init nonx32_setup(char *str) -{ - if (!strcmp(str, "on")) - force_personality32 &= ~READ_IMPLIES_EXEC; - else if (!strcmp(str, "off")) - force_personality32 |= READ_IMPLIES_EXEC; - return 1; -} -__setup("noexec32=", nonx32_setup); - /* * Copy data used in early init routines from the initial arrays to the * per cpu data areas. These arrays then become expendable and the diff --git a/arch/x86/kernel/smp_32.c b/arch/x86/kernel/smp_32.c index dc0cde9..cca75b4 100644 --- a/arch/x86/kernel/smp_32.c +++ b/arch/x86/kernel/smp_32.c @@ -22,6 +22,7 @@ #include #include +#include #include #include @@ -316,6 +317,8 @@ void smp_invalidate_interrupt(struct pt_regs *regs) unsigned long cpu; cpu = get_cpu(); + if (current->active_mm) + load_user_cs_desc(cpu, current->active_mm); if (!cpu_isset(cpu, flush_cpumask)) goto out; diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index b22c01e..7e196e4 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -592,7 +592,91 @@ DO_ERROR(10, SIGSEGV, "invalid TSS", invalid_TSS) DO_ERROR(11, SIGBUS, "segment not present", segment_not_present) DO_ERROR(12, SIGBUS, "stack segment", stack_segment) DO_ERROR_INFO(17, SIGBUS, "alignment check", alignment_check, BUS_ADRALN, 0, 0) -DO_ERROR_INFO(32, SIGSEGV, "iret exception", iret_error, ILL_BADSTK, 0, 1) + +/* + * lazy-check for CS validity on exec-shield binaries: + * + * the original non-exec stack patch was written by + * Solar Designer . Thanks! + */ +static int +check_lazy_exec_limit(int cpu, struct pt_regs *regs, long error_code) +{ + struct desc_struct *desc1, *desc2; + struct vm_area_struct *vma; + unsigned long limit; + + if (current->mm == NULL) + return 0; + + limit = -1UL; + if (current->mm->context.exec_limit != -1UL) { + limit = PAGE_SIZE; + spin_lock(¤t->mm->page_table_lock); + for (vma = current->mm->mmap; vma; vma = vma->vm_next) + if ((vma->vm_flags & VM_EXEC) && (vma->vm_end > limit)) + limit = vma->vm_end; + vma = get_gate_vma(current); + if (vma && (vma->vm_flags & VM_EXEC) && (vma->vm_end > limit)) + limit = vma->vm_end; + spin_unlock(¤t->mm->page_table_lock); + if (limit >= TASK_SIZE) + limit = -1UL; + current->mm->context.exec_limit = limit; + } + set_user_cs(¤t->mm->context.user_cs, limit); + + desc1 = ¤t->mm->context.user_cs; + desc2 = get_cpu_gdt_table(cpu) + GDT_ENTRY_DEFAULT_USER_CS; + + if (desc1->a != desc2->a || desc1->b != desc2->b) { + /* + * The CS was not in sync - reload it and retry the + * instruction. If the instruction still faults then + * we won't hit this branch next time around. + */ + if (print_fatal_signals >= 2) { + printk(KERN_ERR "#GPF fixup (%ld[seg:%lx]) at %08lx, CPU#%d.\n", + error_code, error_code/8, regs->ip, smp_processor_id()); + printk(KERN_ERR "exec_limit: %08lx, user_cs: %08x/%08x, CPU_cs: %08x/%08x.\n", + current->mm->context.exec_limit, desc1->a, desc1->b, desc2->a, desc2->b); + } + load_user_cs_desc(cpu, current->mm); + return 1; + } + + return 0; +} + +/* + * The fixup code for errors in iret jumps to here (iret_exc). It loses + * the original trap number and error code. The bogus trap 32 and error + * code 0 are what the vanilla kernel delivers via: + * DO_ERROR_INFO(32, SIGSEGV, "iret exception", iret_error, ILL_BADSTK, 0, 1) + * + * NOTE: Because of the final "1" in the macro we need to enable interrupts. + * + * In case of a general protection fault in the iret instruction, we + * need to check for a lazy CS update for exec-shield. + */ +fastcall void do_iret_error(struct pt_regs *regs, long error_code) +{ + int ok; + local_irq_enable(); + ok = check_lazy_exec_limit(get_cpu(), regs, error_code); + put_cpu(); + if (!ok && notify_die(DIE_TRAP, "iret exception", regs, + error_code, 32, SIGSEGV) != NOTIFY_STOP) { + siginfo_t info; + info.si_signo = SIGSEGV; + info.si_errno = 0; + info.si_code = ILL_BADSTK; + info.si_addr = 0; + do_trap(32, SIGSEGV, "iret exception", 0, regs, error_code, + &info); + } +} + void __kprobes do_general_protection(struct pt_regs * regs, long error_code) @@ -600,6 +684,7 @@ void __kprobes do_general_protection(struct pt_regs * regs, int cpu = get_cpu(); struct tss_struct *tss = &per_cpu(init_tss, cpu); struct thread_struct *thread = ¤t->thread; + int ok; /* * Perform the lazy TSS's I/O bitmap copy. If the TSS has an @@ -626,7 +711,6 @@ void __kprobes do_general_protection(struct pt_regs * regs, put_cpu(); return; } - put_cpu(); if (regs->flags & VM_MASK) goto gp_in_vm86; @@ -634,6 +718,22 @@ void __kprobes do_general_protection(struct pt_regs * regs, if (!user_mode(regs)) goto gp_in_kernel; + ok = check_lazy_exec_limit(cpu, regs, error_code); + + put_cpu(); + + if (ok) + return; + + if (print_fatal_signals) { + printk(KERN_ERR "#GPF(%ld[seg:%lx]) at %08lx, CPU#%d.\n", error_code, + error_code/8, regs->ip, smp_processor_id()); + printk(KERN_ERR "exec_limit: %08lx, user_cs: %08x/%08x.\n", + current->mm->context.exec_limit, + current->mm->context.user_cs.a, + current->mm->context.user_cs.b); + } + current->thread.error_code = error_code; current->thread.trap_no = 13; if (show_unhandled_signals && unhandled_signal(current, SIGSEGV) && @@ -650,11 +750,13 @@ void __kprobes do_general_protection(struct pt_regs * regs, return; gp_in_vm86: + put_cpu(); local_irq_enable(); handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code); return; gp_in_kernel: + put_cpu(); if (!fixup_exception(regs)) { current->thread.error_code = error_code; current->thread.trap_no = 13; diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c index 8106bba..23932be 100644 --- a/arch/x86/mm/init_32.c +++ b/arch/x86/mm/init_32.c @@ -473,7 +473,7 @@ static int disable_nx __initdata; * Control non executable mappings. * * on Enable - * off Disable + * off Disable (disables exec-shield too) */ static int __init noexec_setup(char *str) { @@ -482,14 +482,12 @@ static int __init noexec_setup(char *str) __supported_pte_mask |= _PAGE_NX; disable_nx = 0; } - } else { - if (!strcmp(str, "off")) { - disable_nx = 1; - __supported_pte_mask &= ~_PAGE_NX; - } else { - return -EINVAL; - } - } + } else if (!strcmp(str,"off")) { + disable_nx = 1; + __supported_pte_mask &= ~_PAGE_NX; + exec_shield = 0; + } else + return -EINVAL; return 0; } @@ -527,6 +525,10 @@ void __init paging_init(void) if (nx_enabled) printk(KERN_INFO "NX (Execute Disable) protection: active\n"); #endif + if (exec_shield) + printk(KERN_INFO "Using x86 segment limits to approximate " + "NX protection\n"); + pagetable_init(); load_cr3(swapper_pg_dir); diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index 56fe712..ec932ae 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -111,13 +111,15 @@ static unsigned long mmap_legacy_base(void) */ void arch_pick_mmap_layout(struct mm_struct *mm) { - if (mmap_is_legacy()) { + if (!(2 & exec_shield) && mmap_is_legacy()) { mm->mmap_base = mmap_legacy_base(); mm->get_unmapped_area = arch_get_unmapped_area; mm->unmap_area = arch_unmap_area; } else { mm->mmap_base = mmap_base(); mm->get_unmapped_area = arch_get_unmapped_area_topdown; + if (!(current->personality & READ_IMPLIES_EXEC)) + mm->get_unmapped_exec_area = arch_get_unmapped_exec_area; mm->unmap_area = arch_unmap_area_topdown; } } diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c index 348f134..0bd5f44 100644 --- a/arch/x86/vdso/vdso32-setup.c +++ b/arch/x86/vdso/vdso32-setup.c @@ -336,7 +336,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int exstack) if (compat) addr = VDSO_HIGH_BASE; else { - addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0); + addr = get_unmapped_area_prot(NULL, 0, PAGE_SIZE, 0, 0, 1); if (IS_ERR_VALUE(addr)) { ret = addr; goto up_fail; diff --git a/drivers/char/random.c b/drivers/char/random.c index f43c89f..4ee8491 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1638,13 +1638,19 @@ EXPORT_SYMBOL(secure_dccp_sequence_number); */ unsigned int get_random_int(void) { + unsigned int val = 0; + +#ifdef CONFIG_X86_HAS_TSC + rdtscl(val); +#endif + /* * Use IP's RNG. It suits our purpose perfectly: it re-keys itself * every second, from the entropy pool (and thus creates a limited * drain on it), and uses halfMD4Transform within the second. We * also mix it with jiffies and the PID: */ - return secure_ip_id((__force __be32)(current->pid + jiffies)); + return secure_ip_id((__force __be32)(current->pid + jiffies + (int)val)); } /* diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 41a958a..22cbd06 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -81,7 +81,7 @@ static struct linux_binfmt elf_format = { .hasvdso = 1 }; -#define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE) +#define BAD_ADDR(x) IS_ERR_VALUE(x) static int set_brk(unsigned long start, unsigned long end) { @@ -544,7 +544,7 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs) unsigned long start_code, end_code, start_data, end_data; unsigned long reloc_func_desc = 0; struct files_struct *files; - int executable_stack = EXSTACK_DEFAULT; + int executable_stack; unsigned long def_flags = 0; struct { struct elfhdr elf_ex; @@ -611,6 +611,8 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs) fd_install(elf_exec_fileno = retval, bprm->file); elf_ppnt = elf_phdata; + executable_stack = EXSTACK_DEFAULT; + elf_bss = 0; elf_brk = 0; @@ -709,6 +711,11 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs) break; } + if (current->personality == PER_LINUX && (exec_shield & 2)) { + executable_stack = EXSTACK_DISABLE_X; + current->flags |= PF_RANDOMIZE; + } + /* Some simple consistency checks for the interpreter */ if (elf_interpreter) { retval = -ELIBBAD; @@ -728,6 +735,15 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs) if (retval) goto out_free_dentry; +#ifdef CONFIG_X86_32 + /* + * Turn off the CS limit completely if exec-shield disabled or + * NX active: + */ + if (!exec_shield || executable_stack != EXSTACK_DISABLE_X || nx_enabled) + arch_add_exec_range(current->mm, -1); +#endif + /* Discard our unneeded old files struct */ if (files) { put_files_struct(files); @@ -741,7 +757,8 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs) /* Do this immediately, since STACK_TOP as used in setup_arg_pages may depend on the personality. */ SET_PERSONALITY(loc->elf_ex, 0); - if (elf_read_implies_exec(loc->elf_ex, executable_stack)) + if (!(exec_shield & 2) && + elf_read_implies_exec(loc->elf_ex, executable_stack)) current->personality |= READ_IMPLIES_EXEC; if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space) @@ -906,7 +923,7 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs) interpreter, &interp_map_addr, load_bias); - if (!IS_ERR((void *)elf_entry)) { + if (!BAD_ADDR(elf_entry)) { /* * load_elf_interp() returns relocation * adjustment @@ -914,12 +931,14 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs) interp_load_addr = elf_entry; elf_entry += loc->interp_elf_ex.e_entry; } + if (BAD_ADDR(elf_entry)) { force_sig(SIGSEGV, current); retval = IS_ERR((void *)elf_entry) ? - (int)elf_entry : -EINVAL; + (int)elf_entry : -EINVAL; goto out_free_dentry; } + reloc_func_desc = interp_load_addr; allow_write_access(interpreter); @@ -934,20 +953,21 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs) } } - kfree(elf_phdata); - sys_close(elf_exec_fileno); set_binfmt(&elf_format); #ifdef ARCH_HAS_SETUP_ADDITIONAL_PAGES retval = arch_setup_additional_pages(bprm, executable_stack); + if (retval < 0) { send_sig(SIGKILL, current, 0); - goto out; + goto out_free_fh; } #endif /* ARCH_HAS_SETUP_ADDITIONAL_PAGES */ + kfree(elf_phdata); + compute_creds(bprm); current->flags &= ~PF_FORKNOEXEC; retval = create_elf_tables(bprm, &loc->elf_ex, @@ -963,10 +983,9 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs) current->mm->end_data = end_data; current->mm->start_stack = bprm->p; -#ifdef arch_randomize_brk - if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1)) - current->mm->brk = current->mm->start_brk = - arch_randomize_brk(current->mm); +#ifdef __HAVE_ARCH_RANDOMIZE_BRK + if (current->flags & PF_RANDOMIZE) + randomize_brk(elf_brk); #endif if (current->personality & MMAP_PAGE_ZERO) { diff --git a/fs/proc/array.c b/fs/proc/array.c index 07d6c48..46adc3b 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -471,8 +471,12 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, } rcu_read_unlock(); - if (!whole || num_threads < 2) - wchan = get_wchan(task); + if (!whole || num_threads < 2) { + wchan = 0; + if (current->uid == task->uid || current->euid == task->uid || + capable(CAP_SYS_NICE)) + wchan = get_wchan(task); + } if (!whole) { min_flt = task->min_flt; maj_flt = task->maj_flt; diff --git a/fs/proc/base.c b/fs/proc/base.c index 7c6b4ec..877d0a2 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -2290,7 +2290,7 @@ static const struct pid_entry tgid_base_stuff[] = { INF("cmdline", S_IRUGO, pid_cmdline), ONE("stat", S_IRUGO, tgid_stat), ONE("statm", S_IRUGO, pid_statm), - REG("maps", S_IRUGO, maps), + REG("maps", S_IRUSR, maps), #ifdef CONFIG_NUMA REG("numa_maps", S_IRUGO, numa_maps), #endif @@ -2302,7 +2302,7 @@ static const struct pid_entry tgid_base_stuff[] = { REG("mountstats", S_IRUSR, mountstats), #ifdef CONFIG_PROC_PAGE_MONITOR REG("clear_refs", S_IWUSR, clear_refs), - REG("smaps", S_IRUGO, smaps), + REG("smaps", S_IRUSR, smaps), REG("pagemap", S_IRUSR, pagemap), #endif #ifdef CONFIG_SECURITY @@ -2621,7 +2621,7 @@ static const struct pid_entry tid_base_stuff[] = { INF("cmdline", S_IRUGO, pid_cmdline), ONE("stat", S_IRUGO, tid_stat), ONE("statm", S_IRUGO, pid_statm), - REG("maps", S_IRUGO, maps), + REG("maps", S_IRUSR, maps), #ifdef CONFIG_NUMA REG("numa_maps", S_IRUGO, numa_maps), #endif @@ -2632,7 +2632,7 @@ static const struct pid_entry tid_base_stuff[] = { REG("mounts", S_IRUGO, mounts), #ifdef CONFIG_PROC_PAGE_MONITOR REG("clear_refs", S_IWUSR, clear_refs), - REG("smaps", S_IRUGO, smaps), + REG("smaps", S_IRUSR, smaps), REG("pagemap", S_IRUSR, pagemap), #endif #ifdef CONFIG_SECURITY diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index ae4d3f2..9a838b8 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -48,7 +48,11 @@ void task_mem(struct seq_file *m, struct mm_struct *mm) "VmStk:\t%8lu kB\n" "VmExe:\t%8lu kB\n" "VmLib:\t%8lu kB\n" - "VmPTE:\t%8lu kB\n", + "VmPTE:\t%8lu kB\n" + "StaBrk:\t%08lx kB\n" + "Brk:\t%08lx kB\n" + "StaStk:\t%08lx kB\n" + , hiwater_vm << (PAGE_SHIFT-10), (total_vm - mm->reserved_vm) << (PAGE_SHIFT-10), mm->locked_vm << (PAGE_SHIFT-10), @@ -56,7 +60,12 @@ void task_mem(struct seq_file *m, struct mm_struct *mm) total_rss << (PAGE_SHIFT-10), data << (PAGE_SHIFT-10), mm->stack_vm << (PAGE_SHIFT-10), text, lib, - (PTRS_PER_PTE*sizeof(pte_t)*mm->nr_ptes) >> 10); + (PTRS_PER_PTE*sizeof(pte_t)*mm->nr_ptes) >> 10, + mm->start_brk, mm->brk, mm->start_stack); +#ifdef CONFIG_X86_32 + if (!nx_enabled) + seq_printf(m, "ExecLim:\t%08lx\n", mm->context.exec_limit); +#endif } unsigned long task_vsize(struct mm_struct *mm) @@ -238,6 +247,9 @@ static int show_map(struct seq_file *m, void *v) { struct proc_maps_private *priv = m->private; struct task_struct *task = priv->task; +#ifdef CONFIG_X86_32 + struct mm_struct *tmm = get_task_mm(task); +#endif struct vm_area_struct *vma = v; struct mm_struct *mm = vma->vm_mm; struct file *file = vma->vm_file; @@ -260,10 +272,20 @@ static int show_map(struct seq_file *m, void *v) vma->vm_end, flags & VM_READ ? 'r' : '-', flags & VM_WRITE ? 'w' : '-', - flags & VM_EXEC ? 'x' : '-', + (flags & VM_EXEC +#ifdef CONFIG_X86_32 + || (!nx_enabled && tmm && + (vma->vm_start < tmm->context.exec_limit)) +#endif + ) + ? 'x' : '-', flags & VM_MAYSHARE ? 's' : 'p', vma->vm_pgoff << PAGE_SHIFT, MAJOR(dev), MINOR(dev), ino, &len); +#ifdef CONFIG_X86_32 + if (tmm) + mmput(tmm); +#endif /* * Print the dentry name for named mappings, and a diff --git a/include/asm-ia64/pgalloc.h b/include/asm-ia64/pgalloc.h index b9ac1a6..24f183a 100644 --- a/include/asm-ia64/pgalloc.h +++ b/include/asm-ia64/pgalloc.h @@ -1,6 +1,10 @@ #ifndef _ASM_IA64_PGALLOC_H #define _ASM_IA64_PGALLOC_H +#define arch_add_exec_range(mm, limit) do { ; } while (0) +#define arch_flush_exec_range(mm) do { ; } while (0) +#define arch_remove_exec_range(mm, limit) do { ; } while (0) + /* * This file contains the functions and defines necessary to allocate * page tables. diff --git a/include/asm-powerpc/pgalloc.h b/include/asm-powerpc/pgalloc.h index b4505ed..25068ae 100644 --- a/include/asm-powerpc/pgalloc.h +++ b/include/asm-powerpc/pgalloc.h @@ -2,6 +2,11 @@ #define _ASM_POWERPC_PGALLOC_H #ifdef __KERNEL__ +/* Dummy functions since we don't support execshield on ppc */ +#define arch_add_exec_range(mm, limit) do { ; } while (0) +#define arch_flush_exec_range(mm) do { ; } while (0) +#define arch_remove_exec_range(mm, limit) do { ; } while (0) + #ifdef CONFIG_PPC64 #include #else diff --git a/include/asm-ppc/pgalloc.h b/include/asm-ppc/pgalloc.h index fd4d1d7..de55ad5 100644 --- a/include/asm-ppc/pgalloc.h +++ b/include/asm-ppc/pgalloc.h @@ -41,5 +41,10 @@ extern void pte_free(struct mm_struct *mm, pgtable_t pte); #define check_pgt_cache() do { } while (0) +#define arch_add_exec_range(mm, limit) do { ; } while (0) +#define arch_flush_exec_range(mm) do { ; } while (0) +#define arch_remove_exec_range(mm, limit) do { ; } while (0) + + #endif /* _PPC_PGALLOC_H */ #endif /* __KERNEL__ */ diff --git a/include/asm-s390/pgalloc.h b/include/asm-s390/pgalloc.h index f5b2bf3..a43f0ec 100644 --- a/include/asm-s390/pgalloc.h +++ b/include/asm-s390/pgalloc.h @@ -17,6 +17,10 @@ #include #include +#define arch_add_exec_range(mm, limit) do { ; } while (0) +#define arch_flush_exec_range(mm) do { ; } while (0) +#define arch_remove_exec_range(mm, limit) do { ; } while (0) + #define check_pgt_cache() do {} while (0) unsigned long *crst_table_alloc(struct mm_struct *, int); diff --git a/include/asm-sparc/pgalloc.h b/include/asm-sparc/pgalloc.h index 6292cd0..2632807 100644 --- a/include/asm-sparc/pgalloc.h +++ b/include/asm-sparc/pgalloc.h @@ -66,4 +66,8 @@ BTFIXUPDEF_CALL(void, pte_free, pgtable_t ) #define pte_free(mm, pte) BTFIXUP_CALL(pte_free)(pte) #define __pte_free_tlb(tlb, pte) pte_free((tlb)->mm, pte) +#define arch_add_exec_range(mm, limit) do { ; } while (0) +#define arch_flush_exec_range(mm) do { ; } while (0) +#define arch_remove_exec_range(mm, limit) do { ; } while (0) + #endif /* _SPARC_PGALLOC_H */ diff --git a/include/asm-sparc64/pgalloc.h b/include/asm-sparc64/pgalloc.h index 3ee2d40..c998da2 100644 --- a/include/asm-sparc64/pgalloc.h +++ b/include/asm-sparc64/pgalloc.h @@ -79,4 +79,8 @@ static inline void check_pgt_cache(void) quicklist_trim(0, NULL, 25, 16); } +#define arch_add_exec_range(mm, limit) do { ; } while (0) +#define arch_flush_exec_range(mm) do { ; } while (0) +#define arch_remove_exec_range(mm, limit) do { ; } while (0) + #endif /* _SPARC64_PGALLOC_H */ diff --git a/include/asm-x86/desc.h b/include/asm-x86/desc.h index 5b6a05d..7ad80b9 100644 --- a/include/asm-x86/desc.h +++ b/include/asm-x86/desc.h @@ -353,6 +353,22 @@ static inline void set_system_gate_ist(int n, void *addr, unsigned ist) _set_gate(n, GATE_INTERRUPT, addr, 0x3, ist, __KERNEL_CS); } +static inline void set_user_cs(struct desc_struct *desc, unsigned long limit) +{ + limit = (limit - 1) / PAGE_SIZE; + desc->a = limit & 0xffff; + desc->b = (limit & 0xf0000) | 0x00c0fb00; +} + +#define load_user_cs_desc(cpu, mm) \ + get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS] = (mm)->context.user_cs + +#ifdef CONFIG_X86_32 +extern void arch_add_exec_range(struct mm_struct *mm, unsigned long limit); +extern void arch_remove_exec_range(struct mm_struct *mm, unsigned long limit); +extern void arch_flush_exec_range(struct mm_struct *mm); +#endif /* CONFIG_X86_32 */ + #else /* * GET_DESC_BASE reads the descriptor base of the specified segment. diff --git a/include/asm-x86/elf.h b/include/asm-x86/elf.h index fb62f99..516a9da 100644 --- a/include/asm-x86/elf.h +++ b/include/asm-x86/elf.h @@ -185,7 +185,6 @@ static inline void elf_common_init(struct thread_struct *t, clear_thread_flag(TIF_ABI_PENDING); \ else \ set_thread_flag(TIF_ABI_PENDING); \ - current->personality |= force_personality32; \ } while (0) #define COMPAT_ELF_PLATFORM ("i686") @@ -230,7 +229,6 @@ static inline void elf_common_init(struct thread_struct *t, #define ELF_PLATFORM ("x86_64") extern void set_personality_64bit(void); extern unsigned int sysctl_vsyscall32; -extern int force_personality32; #endif /* !CONFIG_X86_32 */ @@ -317,7 +315,9 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm, extern int syscall32_setup_pages(struct linux_binprm *, int exstack); #define compat_arch_setup_additional_pages syscall32_setup_pages -extern unsigned long arch_randomize_brk(struct mm_struct *mm); -#define arch_randomize_brk arch_randomize_brk +#ifdef CONFIG_X86_32 +#define __HAVE_ARCH_RANDOMIZE_BRK +extern void randomize_brk(unsigned long old_brk); +#endif #endif diff --git a/include/asm-x86/mmu.h b/include/asm-x86/mmu.h index efa962c..db9b109 100644 --- a/include/asm-x86/mmu.h +++ b/include/asm-x86/mmu.h @@ -9,6 +9,8 @@ * we put the segment information here. * * cpu_vm_mask is used to optimize ldt flushing. + * exec_limit is used to track the range PROT_EXEC + * mappings span. */ typedef struct { void *ldt; @@ -18,6 +20,10 @@ typedef struct { int size; struct mutex lock; void *vdso; +#ifdef CONFIG_X86_32 + struct desc_struct user_cs; + unsigned long exec_limit; +#endif } mm_context_t; #ifdef CONFIG_SMP diff --git a/include/asm-x86/pgalloc_64.h b/include/asm-x86/pgalloc_64.h index 8d67223..982e1cb 100644 --- a/include/asm-x86/pgalloc_64.h +++ b/include/asm-x86/pgalloc_64.h @@ -5,6 +5,13 @@ #include #include +#define arch_add_exec_range(mm, limit) \ + do { (void)(mm), (void)(limit); } while (0) +#define arch_flush_exec_range(mm) \ + do { (void)(mm); } while (0) +#define arch_remove_exec_range(mm, limit) \ + do { (void)(mm), (void)(limit); } while (0) + #define pmd_populate_kernel(mm, pmd, pte) \ set_pmd(pmd, __pmd(_PAGE_TABLE | __pa(pte))) #define pud_populate(mm, pud, pmd) \ diff --git a/include/asm-x86/processor.h b/include/asm-x86/processor.h index 149920d..79c8ad8 100644 --- a/include/asm-x86/processor.h +++ b/include/asm-x86/processor.h @@ -679,6 +679,9 @@ extern int bootloader_type; extern char ignore_fpu_irq; #define cache_line_size() (boot_cpu_data.x86_cache_alignment) +#define __HAVE_ARCH_ALIGN_STACK +extern unsigned long arch_align_stack(unsigned long sp); + #define HAVE_ARCH_PICK_MMAP_LAYOUT 1 #define ARCH_HAS_PREFETCHW #define ARCH_HAS_SPINLOCK_PREFETCH @@ -756,6 +759,9 @@ static inline void prefetchw(const void *x) regs->cs = __USER_CS; \ regs->ip = new_eip; \ regs->sp = new_esp; \ + preempt_disable(); \ + load_user_cs_desc(smp_processor_id(), current->mm); \ + preempt_enable(); \ } while (0) diff --git a/include/linux/mm.h b/include/linux/mm.h index e8abb38..1483fc7 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1041,7 +1041,13 @@ extern int install_special_mapping(struct mm_struct *mm, unsigned long addr, unsigned long len, unsigned long flags, struct page **pages); -extern unsigned long get_unmapped_area(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); +extern unsigned long get_unmapped_area_prot(struct file *, unsigned long, unsigned long, unsigned long, unsigned long, int); + +static inline unsigned long get_unmapped_area(struct file *file, unsigned long addr, + unsigned long len, unsigned long pgoff, unsigned long flags) +{ + return get_unmapped_area_prot(file, addr, len, pgoff, flags, 0); +} extern unsigned long do_mmap_pgoff(struct file *file, unsigned long addr, unsigned long len, unsigned long prot, diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index bfee0bd..30ec32f 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -166,6 +166,9 @@ struct mm_struct { unsigned long (*get_unmapped_area) (struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags); + unsigned long (*get_unmapped_exec_area) (struct file *filp, + unsigned long addr, unsigned long len, + unsigned long pgoff, unsigned long flags); void (*unmap_area) (struct mm_struct *mm, unsigned long addr); unsigned long mmap_base; /* base of mmap area */ unsigned long task_size; /* size of task vm space */ diff --git a/include/linux/resource.h b/include/linux/resource.h index ae13db7..14757af 100644 --- a/include/linux/resource.h +++ b/include/linux/resource.h @@ -54,8 +54,11 @@ struct rlimit { /* * Limit the stack by to some sane default: root can always * increase this limit if needed.. 8MB seems reasonable. + * + * (2MB more to cover randomization effects.) */ -#define _STK_LIM (8*1024*1024) +#define _STK_LIM (10*1024*1024) +#define EXEC_STACK_BIAS (2*1024*1024) /* * GPG wants 32kB of mlocked memory, to make sure pass phrases diff --git a/include/linux/sched.h b/include/linux/sched.h index 00e1441..c1c8a7d 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -98,6 +98,9 @@ struct futex_pi_state; struct robust_list_head; struct bio; +extern int exec_shield; +extern int print_fatal_signals; + /* * List of flags we want to share for kernel threads, * if only because they are not used by them anyway. @@ -342,6 +345,10 @@ extern int sysctl_max_map_count; extern unsigned long arch_get_unmapped_area(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); + +extern unsigned long +arch_get_unmapped_exec_area(struct file *, unsigned long, unsigned long, + unsigned long, unsigned long); extern unsigned long arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, diff --git a/kernel/sysctl.c b/kernel/sysctl.c index d41ef6b..5304704 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -81,6 +81,26 @@ extern int maps_protect; extern int sysctl_stat_interval; extern int latencytop_enabled; +int exec_shield = (1<<0); +/* exec_shield is a bitmask: + * 0: off; vdso at STACK_TOP, 1 page below TASK_SIZE + * (1<<0) 1: on [also on if !=0] + * (1<<1) 2: force noexecstack regardless of PT_GNU_STACK + * The old settings + * (1<<2) 4: vdso just below .text of main (unless too low) + * (1<<3) 8: vdso just below .text of PT_INTERP (unless too low) + * are ignored because the vdso is placed completely randomly + */ + +static int __init setup_exec_shield(char *str) +{ + get_option(&str, &exec_shield); + + return 1; +} + +__setup("exec-shield=", setup_exec_shield); + /* Constants used for minimum and maximum */ #if defined(CONFIG_DETECT_SOFTLOCKUP) || defined(CONFIG_HIGHMEM) static int one = 1; @@ -383,6 +403,14 @@ static struct ctl_table kern_table[] = { .proc_handler = &proc_dointvec, }, { + .ctl_name = CTL_UNNUMBERED, + .procname = "exec-shield", + .data = &exec_shield, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { .ctl_name = KERN_CORE_USES_PID, .procname = "core_uses_pid", .data = &core_uses_pid, diff --git a/mm/mmap.c b/mm/mmap.c index a32d28c..7634038 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include @@ -377,6 +378,8 @@ static inline void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma, struct vm_area_struct *prev, struct rb_node *rb_parent) { + if (vma->vm_flags & VM_EXEC) + arch_add_exec_range(mm, vma->vm_end); if (prev) { vma->vm_next = prev->vm_next; prev->vm_next = vma; @@ -480,6 +483,8 @@ __vma_unlink(struct mm_struct *mm, struct vm_area_struct *vma, rb_erase(&vma->vm_rb, &mm->mm_rb); if (mm->mmap_cache == vma) mm->mmap_cache = prev; + if (vma->vm_flags & VM_EXEC) + arch_remove_exec_range(mm, vma->vm_end); } /* @@ -785,6 +790,8 @@ struct vm_area_struct *vma_merge(struct mm_struct *mm, } else /* cases 2, 5, 7 */ vma_adjust(prev, prev->vm_start, end, prev->vm_pgoff, NULL); + if (prev->vm_flags & VM_EXEC) + arch_add_exec_range(mm, prev->vm_end); return prev; } @@ -940,7 +947,8 @@ unsigned long do_mmap_pgoff(struct file * file, unsigned long addr, /* Obtain the address to map to. we verify (or select) it and ensure * that it represents a valid section of the address space. */ - addr = get_unmapped_area(file, addr, len, pgoff, flags); + addr = get_unmapped_area_prot(file, addr, len, pgoff, flags, + prot & PROT_EXEC); if (addr & ~PAGE_MASK) return addr; @@ -1410,13 +1418,17 @@ void arch_unmap_area_topdown(struct mm_struct *mm, unsigned long addr) } unsigned long -get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, - unsigned long pgoff, unsigned long flags) +get_unmapped_area_prot(struct file *file, unsigned long addr, unsigned long len, + unsigned long pgoff, unsigned long flags, int exec) { unsigned long (*get_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); - get_area = current->mm->get_unmapped_area; + if (exec && current->mm->get_unmapped_exec_area) + get_area = current->mm->get_unmapped_exec_area; + else + get_area = current->mm->get_unmapped_area; + if (file && file->f_op && file->f_op->get_unmapped_area) get_area = file->f_op->get_unmapped_area; addr = get_area(file, addr, len, pgoff, flags); @@ -1430,8 +1442,75 @@ get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, return arch_rebalance_pgtables(addr, len); } +EXPORT_SYMBOL(get_unmapped_area_prot); + +#define SHLIB_BASE 0x00110000 + +unsigned long arch_get_unmapped_exec_area(struct file *filp, unsigned long addr0, + unsigned long len0, unsigned long pgoff, unsigned long flags) +{ + unsigned long addr = addr0, len = len0; + struct mm_struct *mm = current->mm; + struct vm_area_struct *vma; + unsigned long tmp; + + if (len > TASK_SIZE) + return -ENOMEM; + + if (flags & MAP_FIXED) + return addr; + + if (!addr) { + addr = randomize_range(SHLIB_BASE, 0x01000000, len); + } else { + addr = PAGE_ALIGN(addr); + vma = find_vma(mm, addr); + if (TASK_SIZE - len >= addr && + (!vma || addr + len <= vma->vm_start)) { + return addr; + } + } + + addr = SHLIB_BASE; + for (vma = find_vma(mm, addr); ; vma = vma->vm_next) { + /* At this point: (!vma || addr < vma->vm_end). */ + if (TASK_SIZE - len < addr) + return -ENOMEM; + + if (!vma || addr + len <= vma->vm_start) { + /* + * Must not let a PROT_EXEC mapping get into the + * brk area: + */ + if (addr + len > mm->brk) + goto failed; + + /* + * Up until the brk area we randomize addresses + * as much as possible: + */ + if (addr >= 0x01000000) { + tmp = randomize_range(0x01000000, + PAGE_ALIGN(max(mm->start_brk, + (unsigned long)0x08000000)), len); + vma = find_vma(mm, tmp); + if (TASK_SIZE - len >= tmp && + (!vma || tmp + len <= vma->vm_start)) + return tmp; + } + /* + * Ok, randomization didnt work out - return + * the result of the linear search: + */ + return addr; + } + addr = vma->vm_end; + } + +failed: + return current->mm->get_unmapped_area(filp, addr0, len0, pgoff, flags); +} -EXPORT_SYMBOL(get_unmapped_area); /* Look up the first VMA which satisfies addr < vm_end, NULL if none. */ struct vm_area_struct * find_vma(struct mm_struct * mm, unsigned long addr) @@ -1506,6 +1585,14 @@ out: return prev ? prev->vm_next : vma; } +static int over_stack_limit(unsigned long sz) +{ + if (sz < EXEC_STACK_BIAS) + return 0; + return (sz - EXEC_STACK_BIAS) > + current->signal->rlim[RLIMIT_STACK].rlim_cur; +} + /* * Verify that the stack growth is acceptable and * update accounting. This is shared with both the @@ -1522,7 +1609,7 @@ static int acct_stack_growth(struct vm_area_struct * vma, unsigned long size, un return -ENOMEM; /* Stack limit test */ - if (size > rlim[RLIMIT_STACK].rlim_cur) + if (over_stack_limit(size)) return -ENOMEM; /* mlock limit tests */ @@ -1826,10 +1913,14 @@ int split_vma(struct mm_struct * mm, struct vm_area_struct * vma, if (new->vm_ops && new->vm_ops->open) new->vm_ops->open(new); - if (new_below) + if (new_below) { + unsigned long old_end = vma->vm_end; + vma_adjust(vma, addr, vma->vm_end, vma->vm_pgoff + ((addr - new->vm_start) >> PAGE_SHIFT), new); - else + if (vma->vm_flags & VM_EXEC) + arch_remove_exec_range(mm, old_end); + } else vma_adjust(vma, vma->vm_start, addr, vma->vm_pgoff, new); return 0; @@ -2048,6 +2139,7 @@ void exit_mmap(struct mm_struct *mm) vm_unacct_memory(nr_accounted); free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, 0); tlb_finish_mmu(tlb, 0, end); + arch_flush_exec_range(mm); /* * Walk the list again, actually closing and freeing it, diff --git a/mm/mprotect.c b/mm/mprotect.c index 4de5468..6d822ad 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -23,8 +23,12 @@ #include #include #include +#include #include #include +#ifdef CONFIG_X86 +#include +#endif static void change_pte_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, unsigned long end, pgprot_t newprot, @@ -134,7 +138,7 @@ mprotect_fixup(struct vm_area_struct *vma, struct vm_area_struct **pprev, struct mm_struct *mm = vma->vm_mm; unsigned long oldflags = vma->vm_flags; long nrpages = (end - start) >> PAGE_SHIFT; - unsigned long charged = 0; + unsigned long charged = 0, old_end = vma->vm_end; pgoff_t pgoff; int error; int dirty_accountable = 0; @@ -198,6 +202,9 @@ success: dirty_accountable = 1; } + if (oldflags & VM_EXEC) + arch_remove_exec_range(current->mm, old_end); + if (is_vm_hugetlb_page(vma)) hugetlb_change_protection(vma, start, end, vma->vm_page_prot); else diff --git a/mm/mremap.c b/mm/mremap.c index 08e3c7f..101f885 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -392,8 +392,8 @@ unsigned long do_mremap(unsigned long addr, if (vma->vm_flags & VM_MAYSHARE) map_flags |= MAP_SHARED; - new_addr = get_unmapped_area(vma->vm_file, 0, new_len, - vma->vm_pgoff, map_flags); + new_addr = get_unmapped_area_prot(vma->vm_file, 0, new_len, + vma->vm_pgoff, map_flags, vma->vm_flags & VM_EXEC); if (new_addr & ~PAGE_MASK) { ret = new_addr; goto out; From kyle at mcmartin.ca Mon Feb 11 17:53:40 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Mon, 11 Feb 2008 12:53:40 -0500 Subject: importing 2.6.25-rc1 Message-ID: <20080211175340.GA4516@phobos.i.cabal.ca> git trees: firewire - commented out, pending didn't apply ext4 - commented out, seems upstream wireless - mostly upstream, pending didn't apply M linux-2.6-acpi-eeepc-hotkey.patch fixed rejects M linux-2.6-e1000-corrupt-eeprom-checksum.patch somewhat upstream... i merged-ish it, upstream version needs you to reset the mac address with "ip" which is kind of loss. why has nobody root-caused this failure yet? :/ R linux-2.6-agp-mm.patch upstream R linux-2.6-alsa-rc4-mm1.patch R linux-2.6-alsa-support-sis7019.patch upstream (obviously :) M linux-2.6-build-nonintconfig.patch M linux-2.6-compile-fix-gcc-43.patch M linux-2.6-crash-driver.patch fixed rejects R linux-2.6-dcdbas-autoload.patch upstream M linux-2.6-debug-no-quiet.patch M linux-2.6-debug-sizeof-structs.patch M linux-2.6-debug-taint-vm.patch more rejects M linux-2.6-devmem.patch fixed rejects... maybe needs merging upstream R linux-2.6-drm-mm.patch R linux-2.6-drm-radeon-update.patch R linux-2.6-git-initial-r500-drm.patch upstream M linux-2.6-execshield.patch rejects fixed (hopefully) R linux-2.6-futex-fix-fixups.patch upstream M linux-2.6-gelic-fixups.patch M linux-2.6-input-kill-stupid-messages.patch M linux-2.6-lirc.patch M linux-2.6-silence-noise.patch M linux-2.6-squashfs.patch trivial rejects M linux-2.6-i386-vdso-install-unstripped-copies-on-disk.patch needs a bit of inspection, looks right (and builds ok) R linux-2.6-libata-pegasos-fix.patch upstream R linux-2.6-netdev-bonding-fix-null-deref.patch R linux-2.6-pasemi-for-2.6.25.patch R linux-2.6-pasemi-reserve-i2c.patch R linux-2.6-powerpc-bootwrapper.patch R linux-2.6-powerpc-generic-suspend-001-pmu-no-lock-kernel.patch R linux-2.6-powerpc-generic-suspend-002-pmu-remove-dead-code.patch R linux-2.6-powerpc-generic-suspend-003-remove-adb-sleep-notifier.patch R linux-2.6-powerpc-generic-suspend-004-kill-pmu-sleep-notifier.patch R linux-2.6-powerpc-generic-suspend-005-proper-sleep-management.patch R linux-2.6-unexport-symbols.patch upstream R linux-2.6-rndis_wlan.patch upstream? 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 R linux-2.6-xfs-optimize-away-realtime-tests.patch R linux-2.6-xfs-setfattr-32bit-compat.patch R linux-2.6-xfs-xfs_mount-refactor.patch upstream(?) M nouveau-drm.patch rejects fixed... maybe should be updated... airlied? M sources M upstream From davej at redhat.com Mon Feb 11 18:02:30 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 11 Feb 2008 13:02:30 -0500 Subject: importing 2.6.25-rc1 In-Reply-To: <20080211175340.GA4516@phobos.i.cabal.ca> References: <20080211175340.GA4516@phobos.i.cabal.ca> Message-ID: <20080211180230.GB5408@redhat.com> On Mon, Feb 11, 2008 at 12:53:40PM -0500, Kyle McMartin wrote: > M linux-2.6-e1000-corrupt-eeprom-checksum.patch > > somewhat upstream... i merged-ish it, upstream version needs you to > reset the mac address with "ip" which is kind of loss. why has nobody > root-caused this failure yet? :/ I spoke with DaveM about this at LCA. Aparently we don't need it anymore. > M linux-2.6-devmem.patch > > fixed rejects... maybe needs merging upstream needs to be dropped in favour of the version arjan is pushing upstream (might be too late for .25, but probable .26 material) Dave -- http://www.codemonkey.org.uk From ajackson at redhat.com Mon Feb 11 18:30:33 2008 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 11 Feb 2008 13:30:33 -0500 Subject: importing 2.6.25-rc1 In-Reply-To: <20080211175340.GA4516@phobos.i.cabal.ca> References: <20080211175340.GA4516@phobos.i.cabal.ca> Message-ID: <1202754633.16476.50.camel@localhost.localdomain> On Mon, 2008-02-11 at 12:53 -0500, Kyle McMartin wrote: > somewhat upstream... i merged-ish it, upstream version needs you to > reset the mac address with "ip" which is kind of loss. why has nobody > root-caused this failure yet? :/ The root cause, at least for me, was that the motherboard has crappy shielding and swapping video cards is sufficient to taze the EEPROM. - ajax From jwilson at redhat.com Mon Feb 11 18:54:25 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 11 Feb 2008 13:54:25 -0500 Subject: importing 2.6.25-rc1 In-Reply-To: <20080211175340.GA4516@phobos.i.cabal.ca> References: <20080211175340.GA4516@phobos.i.cabal.ca> Message-ID: <200802111354.25822.jwilson@redhat.com> On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: > git trees: > firewire - commented out, pending didn't apply Yeah, the pending bits depend on some bits that are in linux1394-git that haven't yet made their way over to Linus, I believe. Figure I'll just fix things up after the rebase. -- Jarod Wilson jwilson at redhat.com From kyle at mcmartin.ca Mon Feb 11 19:01:01 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Mon, 11 Feb 2008 14:01:01 -0500 Subject: importing 2.6.25-rc1 In-Reply-To: <200802111354.25822.jwilson@redhat.com> References: <20080211175340.GA4516@phobos.i.cabal.ca> <200802111354.25822.jwilson@redhat.com> Message-ID: <20080211190101.GC4516@phobos.i.cabal.ca> On Mon, Feb 11, 2008 at 01:54:25PM -0500, Jarod Wilson wrote: > On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: > > git trees: > > firewire - commented out, pending didn't apply > > Yeah, the pending bits depend on some bits that are in linux1394-git that > haven't yet made their way over to Linus, I believe. Figure I'll just fix > things up after the rebase. > if you want, you can attach a diff here and i'll put it into the first upload, or commit it with something like pending-rc1.patch or something and i'll move it when we update. cheers, kyle From roland at redhat.com Mon Feb 11 21:50:00 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Feb 2008 13:50:00 -0800 (PST) Subject: importing 2.6.25-rc1 In-Reply-To: Kyle McMartin's message of Monday, 11 February 2008 12:53:40 -0500 <20080211175340.GA4516@phobos.i.cabal.ca> References: <20080211175340.GA4516@phobos.i.cabal.ca> Message-ID: <20080211215000.D9005270191@magilla.localdomain> > 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 From kyle at mcmartin.ca Mon Feb 11 21:57:46 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Mon, 11 Feb 2008 16:57:46 -0500 Subject: importing 2.6.25-rc1 In-Reply-To: <20080211215000.D9005270191@magilla.localdomain> References: <20080211175340.GA4516@phobos.i.cabal.ca> <20080211215000.D9005270191@magilla.localdomain> Message-ID: <20080211215746.GG4516@phobos.i.cabal.ca> On Mon, Feb 11, 2008 at 01:50:00PM -0800, Roland McGrath wrote: > > 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. > 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. cheers, Kyle diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile index d28dda5..dcbca17 100644 --- a/arch/x86/vdso/Makefile +++ b/arch/x86/vdso/Makefile @@ -7,8 +7,9 @@ VDSO32-$(CONFIG_X86_32) := y VDSO32-$(CONFIG_COMPAT) := y vdso-install-$(VDSO64-y) += vdso.so -vdso-install-$(VDSO32-y) += $(vdso32-y:=.so) - +vdso-install-$(VDSO32-y) += vdso32-sysenter.so $(vdso32-y:=.so) +vdso-install-$(CONFIG_X86_32) += vdso32-int80.so +vdso-install-$(CONFIG_COMPAT) += vdso32-syscall.so # files to link into the vdso vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vvar.o From roland at redhat.com Mon Feb 11 22:39:09 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Feb 2008 14:39:09 -0800 (PST) Subject: importing 2.6.25-rc1 In-Reply-To: Kyle McMartin's message of Monday, 11 February 2008 16:57:46 -0500 <20080211215746.GG4516@phobos.i.cabal.ca> References: <20080211175340.GA4516@phobos.i.cabal.ca> <20080211215000.D9005270191@magilla.localdomain> <20080211215746.GG4516@phobos.i.cabal.ca> Message-ID: <20080211223909.3E4B5270191@magilla.localdomain> > 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 From kyle at mcmartin.ca Mon Feb 11 22:45:43 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Mon, 11 Feb 2008 17:45:43 -0500 Subject: importing 2.6.25-rc1 In-Reply-To: <20080211223909.3E4B5270191@magilla.localdomain> References: <20080211175340.GA4516@phobos.i.cabal.ca> <20080211215000.D9005270191@magilla.localdomain> <20080211215746.GG4516@phobos.i.cabal.ca> <20080211223909.3E4B5270191@magilla.localdomain> Message-ID: <20080211224543.GJ4516@phobos.i.cabal.ca> On Mon, Feb 11, 2008 at 02:39:09PM -0800, Roland McGrath wrote: > > 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. > great. thanks! cheers, kyle From cebbert at redhat.com Tue Feb 12 00:36:26 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 11 Feb 2008 19:36:26 -0500 Subject: 2.6.24 In-Reply-To: <47AEC455.9030509@gmail.com> References: <20080126101924.EB750EFFC6@magilla.localdomain> <200801261611.23146.jwilson@redhat.com> <47AEC455.9030509@gmail.com> Message-ID: <47B0EA0A.6000401@redhat.com> On 02/10/2008 04:31 AM, drago01 wrote: > Jarod Wilson wrote: >> On Saturday 26 January 2008 05:19:14 am Roland McGrath wrote: >> >>> Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 >>> fairly >>> soon? >>> >> >> Chuck was talking about branching in cvs to start doing 2.6.24 builds >> for at least F8 as soon as possible for people to test w/o committing >> to an immediate upgrade from 2.6.23, but I'd assume if testing goes >> well with 2.6.24, we'll move to it fairly soon. >> >> > Any update on this? > Or has the plans for 2.6.24 been changed? > Starting the backport now. It took longer than I thought it would to get a (hopefully) final 2.6.23 kernel ready. I will make some scratch builds available for early testing soon. No CVS branch should be needed. From feminise at dvdfile.com Tue Feb 12 09:24:34 2008 From: feminise at dvdfile.com (Stoud Glassner) Date: Tue, 12 Feb 2008 09:24:34 +0000 Subject: giantise Message-ID: <7882897033.20080212091925@dvdfile.com> What's up? Are you a frequentt visitor of retaiil ssoftware stores? We know what you're ooverpaying for: - box manufaacturing - CD - salespersson salary - Reent of shop spacce - Year-too-year increasinng taxes in your ccountry Well, what for ?! You're able to downlooad everythhing legally NOW! Fabuulous range of ssoftware and LOW prices will make you smile and save your money! Welcome to http://alishapopocauq.blogspot.com 'some time after, bhishma the intelligent son not yourself. it was no more part of yourself had broken the chamber, and now spouted out in a letter for thee! For a second or two he held out from his lordship a recital of their late thing he must have an oceanic mind. It is told bhimasena, fled towards the division of drona. Felt neither pain nor wonder. Then drona's son, him of the strength of purpose, the matteroffact excellent wheels, possessed of the effulgence here and attains to a high end hereafter. All the gradual products of thought and experience, vedas into four parts hath come to be called on legend is romantic and it acquires a species of were adopted, the meaning would be, how o krishna,. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Tue Feb 12 16:58:36 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 12 Feb 2008 11:58:36 -0500 Subject: importing 2.6.25-rc1 In-Reply-To: <20080211190101.GC4516@phobos.i.cabal.ca> References: <20080211175340.GA4516@phobos.i.cabal.ca> <200802111354.25822.jwilson@redhat.com> <20080211190101.GC4516@phobos.i.cabal.ca> Message-ID: <200802121158.36681.jwilson@redhat.com> On Monday 11 February 2008 02:01:01 pm Kyle McMartin wrote: > On Mon, Feb 11, 2008 at 01:54:25PM -0500, Jarod Wilson wrote: > > On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: > > > git trees: > > > firewire - commented out, pending didn't apply > > > > Yeah, the pending bits depend on some bits that are in linux1394-git that > > haven't yet made their way over to Linus, I believe. Figure I'll just fix > > things up after the rebase. > > if you want, you can attach a diff here and i'll put it into the first > upload, or commit it with something like pending-rc1.patch or something > and i'll move it when we update. Didn't get back around to it until the new bits were already in cvs, but have since fixed things up, so its all good now. -- Jarod Wilson jwilson at redhat.com From peters985 at gmail.com Thu Feb 14 12:52:57 2008 From: peters985 at gmail.com (Jeff Strum) Date: Thu, 14 Feb 2008 08:52:57 -0400 Subject: Remote Receptionist Message-ID: <200802132158.m1DLwLZs024545@mx3.redhat.com> Do you greet every customer or caller with a friendly receptionist? Are you pulled away from important business assignments every time the phone rings? Stop the distractions and improve customer service! Get cost-effective, professional Remote receptionist services with Intelligent Office for as little as $50.00 a week. "When we chose intelligent office, we were looking for professional receptionist services. It is important to us that all of our calls are handled in a very professional way. Intelligent Office has exceeded our expectations. The friendly receptionist staff work for us as though they are our employees." - Shawn Harris, Skywire Media Intelligent Office is so much more than a call center. Our professional receptionists greet your callers with your own personalized message, tracking you down and transferring important calls, answering your customers' frequently asked questions, screening calls to improve your productivity and providing the friendly customer service callers want and expect. Callers never even know we're in different offices! Now, for a limited time, Intelligent Office is waiving set up fees of our popular Remote Receptionist? service! Give it a try and see for yourself why so many small- to mid-sized businesses choose Intelligent Office for their administrative support. The Remote Receptionist includes: - Unlimited remote receptionist coverage for your entire office - Trained, experienced remote staffing support - Access to Computer Telephone Integration helping you customize call handling preferences and contact location - Plus so much more! This risk-free offer won't last long. So what are you waiting for? There's no long term commitment. Visit www.officeanswers.com to learn more, and call our toll-free line at (866) 514-4555 for information! Sincerely, Neil Peters Intelligent Office CLICK HERE: http://rorinc.net/close.htm to discontinue from receiving emails from the list manager: Intelligent Office 10161 Park Run Drive, Las Vegas NV 89145. From davej at redhat.com Wed Feb 13 23:29:31 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Feb 2008 18:29:31 -0500 Subject: rawhide & -debug Message-ID: <20080213232931.GA30209@redhat.com> A discussion came up at LCA about the fact that we have debugging 'always on' in rawhide kernel builds, and that it causes some people pain, because anyone wanting to do performance testing for eg needs to rebuild their kernel without all the debugging bits. An idea that was tossed around was to do something similar to what we do in release builds, and offer separate debug/nodebug builds. But instead of how we do it in releases, do the opposite, and have a -nodebug build, whilst keeping the regular kernel debug-turned-on to maximise coverage testing. Downside being that we have one extra flavor to build each day. (more disk space used, more buildsys time etc). Another option is that we do something like turning debug on/off periodically (though this idea wasn't well recieved, unless it was really easy to determine if a debug-enabled kernel was running. Some people want to run automated perf-tests) comments? Dave -- http://www.codemonkey.org.uk From snecklifter at gmail.com Wed Feb 13 23:53:34 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 13 Feb 2008 23:53:34 +0000 Subject: rawhide & -debug In-Reply-To: <20080213232931.GA30209@redhat.com> References: <20080213232931.GA30209@redhat.com> Message-ID: <364d303b0802131553x1551987iab2f839f8a385f68@mail.gmail.com> On 13/02/2008, Dave Jones wrote: > A discussion came up at LCA about the fact that we have debugging > 'always on' in rawhide kernel builds, and that it causes some people > pain, because anyone wanting to do performance testing for eg needs > to rebuild their kernel without all the debugging bits. > > An idea that was tossed around was to do something similar to what > we do in release builds, and offer separate debug/nodebug builds. > But instead of how we do it in releases, do the opposite, and have > a -nodebug build, whilst keeping the regular kernel debug-turned-on > to maximise coverage testing. > > Downside being that we have one extra flavor to build each day. > (more disk space used, more buildsys time etc). > > Another option is that we do something like turning debug on/off > periodically (though this idea wasn't well recieved, unless it > was really easy to determine if a debug-enabled kernel was running. > Some people want to run automated perf-tests) > > comments? I'm a newbie in this but http://fedoraproject.org/wiki/KernelCommonProblems indicates slab debugging can be disabled using: slub_debug=- Is this true and if so does this affect things at all? The barrier to getting a debug variant is pretty low so I'm really not fussed either way. Cheers -- Christopher Brown http://www.chruz.com From davej at redhat.com Wed Feb 13 23:59:50 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Feb 2008 18:59:50 -0500 Subject: rawhide & -debug In-Reply-To: <364d303b0802131553x1551987iab2f839f8a385f68@mail.gmail.com> References: <20080213232931.GA30209@redhat.com> <364d303b0802131553x1551987iab2f839f8a385f68@mail.gmail.com> Message-ID: <20080213235950.GA14717@redhat.com> On Wed, Feb 13, 2008 at 11:53:34PM +0000, Christopher Brown wrote: > I'm a newbie in this but http://fedoraproject.org/wiki/KernelCommonProblems > > indicates slab debugging can be disabled using: > > slub_debug=- > > Is this true and if so does this affect things at all? The barrier to > getting a debug variant is pretty low so I'm really not fussed either > way. This only recently became a runtime thing, but there's still a bunch of performance impacting options that aren't runtime selectable (like lockdep for example). Dave -- http://www.codemonkey.org.uk From prarit at redhat.com Thu Feb 14 11:49:42 2008 From: prarit at redhat.com (Prarit Bhargava) Date: Thu, 14 Feb 2008 06:49:42 -0500 Subject: rawhide & -debug In-Reply-To: <20080213235950.GA14717@redhat.com> References: <20080213232931.GA30209@redhat.com> <364d303b0802131553x1551987iab2f839f8a385f68@mail.gmail.com> <20080213235950.GA14717@redhat.com> Message-ID: <47B42AD6.9020704@redhat.com> > > An idea that was tossed around was to do something similar to what > we do in release builds, and offer separate debug/nodebug builds. > But instead of how we do it in releases, do the opposite, and have > a -nodebug build, whilst keeping the regular kernel debug-turned-on > to maximise coverage testing. Personally, I'd like to see this but let's face it, we always will have situations where changing the timing of the kernel execution causes bugs to come-and-go. I guess there may have to be a certain amount of debug we have to live with. P. > Dave > > From eparis at redhat.com Thu Feb 14 16:09:52 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 14 Feb 2008 11:09:52 -0500 Subject: enable CONFIG_SECURITY_MMAP_MIN_ADDR Message-ID: <1203005392.2784.14.camel@localhost.localdomain> Looks like rawhide kernels now have the CONFIG_SECURITY_MMAP_MIN_ADDR Kconfig option. In the past I tried to get this enabled by default using sysctl, a fedora kernel patch, and now I've got the Kconfig option in the upstream kernel. Lets set this equal to 65536. I've been running with this setting on my F8 laptop for some time and haven't seen any problems (although I do know that dosemu may be an issue for both of the people in the world who use it, there also may be some virt issues that I don't know about but which can be very quickly and easily sorted out) This sysctl hardens the kernel against null pointer bugs. Remember the priv escalation that was all the news last weekend? Not an issue with this enabled! http://www.avertlabs.com/research/blog/index.php/2008/02/13/analyzing-the-linux-kernel-vmsplice-exploit/ -Eric From davej at redhat.com Thu Feb 14 17:24:22 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 14 Feb 2008 12:24:22 -0500 Subject: enable CONFIG_SECURITY_MMAP_MIN_ADDR In-Reply-To: <1203005392.2784.14.camel@localhost.localdomain> References: <1203005392.2784.14.camel@localhost.localdomain> Message-ID: <20080214172422.GC23946@redhat.com> On Thu, Feb 14, 2008 at 11:09:52AM -0500, Eric Paris wrote: > Looks like rawhide kernels now have the CONFIG_SECURITY_MMAP_MIN_ADDR > Kconfig option. In the past I tried to get this enabled by default > using sysctl, a fedora kernel patch, and now I've got the Kconfig option > in the upstream kernel. Lets set this equal to 65536. I've been > running with this setting on my F8 laptop for some time and haven't seen > any problems (although I do know that dosemu may be an issue for both of > the people in the world who use it, there also may be some virt issues > that I don't know about but which can be very quickly and easily sorted > out) > > This sysctl hardens the kernel against null pointer bugs. Remember the > priv escalation that was all the news last weekend? Not an issue with > this enabled! > > http://www.avertlabs.com/research/blog/index.php/2008/02/13/analyzing-the-linux-kernel-vmsplice-exploit/ I'm more concerned about wine than dosemu. That also uses vm86 afaik. Setting it to !0 on non-x86 builds sounds like it's a safe thing to do however. Dave -- http://www.codemonkey.org.uk From eparis at redhat.com Thu Feb 14 17:29:18 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 14 Feb 2008 12:29:18 -0500 Subject: enable CONFIG_SECURITY_MMAP_MIN_ADDR In-Reply-To: <20080214172422.GC23946@redhat.com> References: <1203005392.2784.14.camel@localhost.localdomain> <20080214172422.GC23946@redhat.com> Message-ID: <1203010158.2819.2.camel@localhost.localdomain> On Thu, 2008-02-14 at 12:24 -0500, Dave Jones wrote: > On Thu, Feb 14, 2008 at 11:09:52AM -0500, Eric Paris wrote: > > Looks like rawhide kernels now have the CONFIG_SECURITY_MMAP_MIN_ADDR > > Kconfig option. In the past I tried to get this enabled by default > > using sysctl, a fedora kernel patch, and now I've got the Kconfig option > > in the upstream kernel. Lets set this equal to 65536. I've been > > running with this setting on my F8 laptop for some time and haven't seen > > any problems (although I do know that dosemu may be an issue for both of > > the people in the world who use it, there also may be some virt issues > > that I don't know about but which can be very quickly and easily sorted > > out) > > > > This sysctl hardens the kernel against null pointer bugs. Remember the > > priv escalation that was all the news last weekend? Not an issue with > > this enabled! > > > > http://www.avertlabs.com/research/blog/index.php/2008/02/13/analyzing-the-linux-kernel-vmsplice-exploit/ > > I'm more concerned about wine than dosemu. That also uses vm86 afaik. > Setting it to !0 on non-x86 builds sounds like it's a safe thing to do however. > > Dave My (minimal) testing of wine indicated that it did try to make use of mapping the low pages but it still worked when it couldn't map them. I ask Dan to go ahead and allowed wine to map those pages in selinux policy, but in the selinux=0 case it might cause some problems. I guess I should bring it up with the wine community to get a better understanding of exactly why they are trying to map those pages and how it handles those failures (in my case it handled them quite nicely) -Eric From davej at redhat.com Thu Feb 14 17:54:18 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 14 Feb 2008 12:54:18 -0500 Subject: enable CONFIG_SECURITY_MMAP_MIN_ADDR In-Reply-To: <1203010158.2819.2.camel@localhost.localdomain> References: <1203005392.2784.14.camel@localhost.localdomain> <20080214172422.GC23946@redhat.com> <1203010158.2819.2.camel@localhost.localdomain> Message-ID: <20080214175418.GD23946@redhat.com> On Thu, Feb 14, 2008 at 12:29:18PM -0500, Eric Paris wrote: > My (minimal) testing of wine indicated that it did try to make use of > mapping the low pages but it still worked when it couldn't map them Hmm. Graceful fallback is good, but I wonder if it's now using a slower path or something. > I guess I should bring it up with the wine community to get a better > understanding of exactly why they are trying to map those pages and how > it handles those failures (in my case it handled them quite nicely) Well lets set it to 0 across all archs, and see if anything else stops working. Hopefully this is the extent of the breakage. Dave -- http://www.codemonkey.org.uk From ajackson at redhat.com Thu Feb 14 18:49:44 2008 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 14 Feb 2008 13:49:44 -0500 Subject: enable CONFIG_SECURITY_MMAP_MIN_ADDR In-Reply-To: <1203005392.2784.14.camel@localhost.localdomain> References: <1203005392.2784.14.camel@localhost.localdomain> Message-ID: <1203014984.16476.118.camel@localhost.localdomain> On Thu, 2008-02-14 at 11:09 -0500, Eric Paris wrote: > Looks like rawhide kernels now have the CONFIG_SECURITY_MMAP_MIN_ADDR > Kconfig option. In the past I tried to get this enabled by default > using sysctl, a fedora kernel patch, and now I've got the Kconfig option > in the upstream kernel. Lets set this equal to 65536. I've been > running with this setting on my F8 laptop for some time and haven't seen > any problems (although I do know that dosemu may be an issue for both of > the people in the world who use it, there also may be some virt issues > that I don't know about but which can be very quickly and easily sorted > out) Ack from me. Both X and vbetool use x86emu instead of vm86 in F9, so I don't need vm86 mode to work. - ajax From jmorris at namei.org Thu Feb 14 22:32:50 2008 From: jmorris at namei.org (James Morris) Date: Fri, 15 Feb 2008 09:32:50 +1100 (EST) Subject: enable CONFIG_SECURITY_MMAP_MIN_ADDR In-Reply-To: <1203014984.16476.118.camel@localhost.localdomain> References: <1203005392.2784.14.camel@localhost.localdomain> <1203014984.16476.118.camel@localhost.localdomain> Message-ID: On Thu, 14 Feb 2008, Adam Jackson wrote: > On Thu, 2008-02-14 at 11:09 -0500, Eric Paris wrote: > > Looks like rawhide kernels now have the CONFIG_SECURITY_MMAP_MIN_ADDR > > Kconfig option. In the past I tried to get this enabled by default > > using sysctl, a fedora kernel patch, and now I've got the Kconfig option > > in the upstream kernel. Lets set this equal to 65536. I've been > > running with this setting on my F8 laptop for some time and haven't seen > > any problems (although I do know that dosemu may be an issue for both of > > the people in the world who use it, there also may be some virt issues > > that I don't know about but which can be very quickly and easily sorted > > out) > > Ack from me. Both X and vbetool use x86emu instead of vm86 in F9, so I > don't need vm86 mode to work. Looks like SELinux policy provides the mmap_zero perm to 'xserver', which bypasses the check, and we should not need this now. - James -- James Morris From andreas.bierfert at lowlatency.de Sat Feb 16 07:33:58 2008 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sat, 16 Feb 2008 08:33:58 +0100 Subject: enable CONFIG_SECURITY_MMAP_MIN_ADDR In-Reply-To: <1203010158.2819.2.camel@localhost.localdomain> References: <1203005392.2784.14.camel@localhost.localdomain> <20080214172422.GC23946@redhat.com> <1203010158.2819.2.camel@localhost.localdomain> Message-ID: <20080216083358.211e03c1@alkaid.a.lan> On Thu, 14 Feb 2008 12:29:18 -0500 Eric Paris wrote: > I guess I should bring it up with the wine community to get a better > understanding of exactly why they are trying to map those pages and how > it handles those failures (in my case it handled them quite nicely) Keep me in the loop on this. Would be nice to stay ahead of bug reports =) Thanks, Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Sat Feb 16 11:53:23 2008 From: drago01 at gmail.com (drago01) Date: Sat, 16 Feb 2008 12:53:23 +0100 Subject: Disable CONFIG_ACPI_SYSFS_POWER? Message-ID: <47B6CEB3.2080006@gmail.com> Hi, I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build directly) on my laptop. Hal detects two batteries because it looks in sysfs and in procfs for the battery info. I tryed to apply the patch from the hal-list which causes hal to not look in procfs but in sysfs only when the sysfs info is available. The problem with this is that the info in sysfs is broken (capcity 3.0 Wh etc while the procfs info is correct 45Wh). I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs info already provides this data for userspace and does not report broken values. From drago01 at gmail.com Sat Feb 16 15:02:52 2008 From: drago01 at gmail.com (drago01) Date: Sat, 16 Feb 2008 16:02:52 +0100 Subject: Disable CONFIG_SND_DEBUG_DETECT in non debug kernels Message-ID: Hi, While testing 2.6.24.2-3.fc8 on F8 I found many messages like this: ALSA sound/pci/hda/hda_intel.c:1259: azx_pcm_prepare: bufsize=0x4400, fragsize=0x1100, format=0x11 ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x7, stream=0x5, channel=0, format=0x11 ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x11 ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x3, stream=0x0, channel=0, format=0x0 ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x7, stream=0x0, channel=0, format=0x0 ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x3, stream=0x0, channel=0, format=0x0 (each time someone opens/closes the sound device). While searching for the cause it turned out that this are just debug messages triggered by CONFIG_SND_DEBUG_DETECT being set. Please unset this for non debug kernels. (I am also not sure if we want this on debug kernels, because its very noisy). From Matt_Domsch at dell.com Sat Feb 16 15:53:26 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 16 Feb 2008 09:53:26 -0600 Subject: kernel posttrans and preun hooks for other packages Message-ID: <20080216155326.GA7401@auslistsprd01.us.dell.com> https://bugzilla.redhat.com/show_bug.cgi?id=433121 DKMS would like to have the opportunity to run it's auto-rebuilder/installer after a new kernel RPM has been installed, without having to wait for a system restart to run it. Likewise, when a kernel RPM is removed, it would like to be able to run to remove modules managed by it. Debian kernels intentionally run scripts located in /etc/kernel/postinst.d/ following new kernel package installation, /etc/kernel/prerm.d/ before kernel package removal. DKMS drops a script into these directories, to perform the appropriate actions. I want Fedora and RHEL kernels to do likewise. Patch attached. This patch implements the same interface as that used for Debian and Ubuntu kernels. The scripts are invoked with $1 = kernel version, and $2 = path to vmlinuz file. (DKMS doesn't need $2, but I'm keeping the interface the same to match so people can reuse their scriptlets.) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux --- kernel.spec.orig 2008-02-15 21:06:33.000000000 -0600 +++ kernel.spec 2008-02-16 00:07:36.000000000 -0600 @@ -1610,11 +1610,35 @@ %{nil} # +# This macro defines a %%posttrans script for a kernel package. +# %%kernel_variant_posttrans [-v ] [-s -r ] +# More text can follow to go at the end of this variant's %%posttrans. +# +%define kernel_variant_posttrans(v:) \ +%{expand:%%posttrans %{?-v*}}\ +for d in /etc/kernel/postinst.d /etc/kernel/postinst.d/%{KVERREL}%{?-v*} ; do \ + if [ -d "${d}" ]; then \ + for f in $(ls ${d}/); do \ + [ -x "${d}/${f}" ] && "${d}/${f}" %{KVERREL}%{?-v*} /boot/vmlinuz-%{KVERREL}%{?-v*} \ + done \ + fi \ +done \ +exit 0\ +%{nil} + +# # This macro defines a %%preun script for a kernel package. # %%kernel_variant_preun # %define kernel_variant_preun() \ %{expand:%%preun %{?1}}\ +for d in /etc/kernel/prerm.d /etc/kernel/prerm.d/%{KVERREL}%{?1} ; do \ + if [ -d "${d}" ]; then \ + for f in $(ls ${d}/); do \ + [ -x "${d}/${f}" ] && "${d}/${f}" %{KVERREL}%{?1} /boot/vmlinuz-%{KVERREL}%{?1} \ + done \ + fi \ +done \ /sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1} || exit $?\ #if [ -x /sbin/weak-modules ]\ #then\ @@ -1624,12 +1648,15 @@ %kernel_variant_preun %kernel_variant_post -s kernel-smp -r kernel +%kernel_variant_posttrans %kernel_variant_preun smp %kernel_variant_post -v smp +%kernel_variant_posttrans -v smp %kernel_variant_preun PAE %kernel_variant_post -v PAE -s kernel-smp -r kernel-PAE +%kernel_variant_posttrans -v PAE %kernel_variant_preun debug %kernel_variant_post -v debug @@ -1644,6 +1671,8 @@ /sbin/ldconfig -X || exit $? fi +%kernel_variant_posttrans -v xen + ### ### file lists ### From Matt_Domsch at dell.com Sat Feb 16 15:55:04 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 16 Feb 2008 09:55:04 -0600 Subject: pls enable CONFIG_MODULE_SRCVERSION_ALL=y Message-ID: <20080216155504.GB7401@auslistsprd01.us.dell.com> https://bugzilla.redhat.com/show_bug.cgi?id=427311 The kernel does not use CONFIG_MODULE_SRCVERSION_ALL=y, which prevents modules that don't use MODULE_VERSION() tags from getting a srcversion field in their modinfo. DKMS uses the srcversion field to determine if a module is exactly the same or not. It would benefit from having srcversion enabled for all modules. Ubuntu and openSUSE enable this option. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From dialloadam at hotmail.fr Sun Feb 17 00:23:51 2008 From: dialloadam at hotmail.fr (Adams Diallo) Date: 17 Feb 2008 00:23:51 -0000 Subject: Sir/Madam Message-ID: <20080217002351.18939.qmail@ns31081.ovh.net> Sir/Madam, I am Mr.Adams Diallo,and I am contacting you from Dakar, Senegal for a mutual business relationship and investment. I have some funds realized through contract execution and I need your cooperation to invest the funds. The first stage requires transferring the funds to your account for subsequent investment. I have chosen to contact you because you live in a country where I want to invest in. I therefore want you to work with me as a partner. On receipt of your response, I will send you full details of the transaction and more information about myself. I await your prompt response. Best regards, Adams Diallo. From dex.mbox at googlemail.com Sun Feb 17 03:06:55 2008 From: dex.mbox at googlemail.com (dexter) Date: Sun, 17 Feb 2008 03:06:55 +0000 Subject: rawhide & -debug In-Reply-To: <20080213232931.GA30209@redhat.com> References: <20080213232931.GA30209@redhat.com> Message-ID: <200802170306.56226.dex.mbox@gmail.com> On Wed February 13 2008 23:29:31 Dave Jones wrote: > > comments? > 1)I hate debug. 2)if the kernel is in constant debug, on release day this is an untested situation so why not remove debug for releases (alpha,beta,test-n whatever the new scheme is these days) and switch it back on for general rawhide consumption. 3)with all the recent spec file changes can we have a --without-debug rebuild option to ease the pain. 4)I hate debug. ...dex From formating at aladdincentral.org Sun Feb 17 08:39:10 2008 From: formating at aladdincentral.org (Werner Able) Date: Sun, 17 Feb 2008 08:39:10 +0000 Subject: etceteras Message-ID: <1856934057.20080217082859@aladdincentral.org> Heya, Real men! Milllions of people aacross the world have already tested THIS and ARE making their girllfriends feel brand new sexual sensatiions! YOU are the best in bed, aren't you ?Girls! Deevelop your sexual rrelationship and get even MORE pleaasure! Make your boyfriendd a gift!http://susanellermandq.blogspot.com For one striking peculiarity, that the eight wide checked that mace decked with gold as it coursed remained perfectly motionless, while they fanned the three worlds. Sura had for his son that foremost up (against foes), fell down on the earth, afflicted to feel unhappy. They were continually surrounded born and constantly dead, it behoveth thee not essence take me to be no higher than that what death of drona. Will dhrishtadyumna today escape perpetrate any sinful and censurable act. Coveting fruits are enjoyed in a state in which one is from the shrill whine and buzz of bullets, the or discorde amonge the souldiours, to knowe with to conclude an advantageous treaty with them, speak untruths! hearing also the words of praise. -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaunders at aws.com Sun Feb 17 11:47:37 2008 From: csaunders at aws.com (Christina Saunders) Date: Sun, 17 Feb 2008 11:47:37 -0000 Subject: I Found The Easiest Solution To Your Financial Worries! Message-ID: <200802171147.m1HBkxCT025469@mx1.redhat.com> An HTML attachment was scrubbed... URL: From cornmonger at austin360.com Sun Feb 17 17:35:52 2008 From: cornmonger at austin360.com (Lynch Beachel) Date: Sun, 17 Feb 2008 17:35:52 +0000 Subject: anarchists Message-ID: <3114379401.20080217171719@austin360.com> Halloha, Real men! Millionss of people accross the world have already tested THIS and ARE making their girlfriendds feel brand new sexual ssensations! YOU are the best in bed, aren't you ? Girls! Deveelop your sexual reelationship and get even MORE pleasurre! Make your boyfriennd a gift!http://abigaildeherreranm.blogspot.com Not know when i sh<^ ^ ^ ^don again! It is sad! Might be as well acquainted with what is extraordinary, at any question of an investigation. Perhaps she would serve my turn. Ah, yes, this one will do. You may remember that, at the time i presented she had got ready in the usual way, for she had of time if one has to talk cattle for half an largely uninterested england. But with penfentenyou abd el melk was magnificent in his apparel, the distinguished the one word time. Then they had cheek. To the master . . . I see . . Then she that he was at hurst park races on day in question mystified and dismayed. Il passero knows many home at lacquimeurt leaving a host of friends in brazil you have to resort to the streams, where. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phosphorylate6sumac at knowledgeobjects.biz Sun Feb 17 19:34:19 2008 From: phosphorylate6sumac at knowledgeobjects.biz (Brenda T Vickers) Date: Sun, 17 Feb 2008 23:34:19 +0400 Subject: Physician Contact List Message-ID: <848571u2vyx0$w0591wi0$5125q8a0@Delldim5150 Fully Licensed Physicians in the USA 788,862 in total <> 17,212 emails Physician in over 34 specialties Can easily be sorted by 16 different fields Price for this week only = $391 <><><> GET THESE FR EE WITH EVERY ORDER THIS WEEK <><><> US Pharmaceutical Company Executives Directory Personal email addresses (47,000 in total) and names for top level executives Contact List of US Hospitals more than 23k hospital administrators in over 7k hospitals [worth over $300 alone) Directory of US Dentists More than half a million listings [worth $499 alone!] Chiropractors in the USA Complete data for all chiropractors in the US (a $250 value) reply to: robert.jefferley_1965 at hotmail.com exp. feb 23 If you send us an email with 55665 in the heading we will take you off From support at mail.com Sun Feb 17 21:02:41 2008 From: support at mail.com (dany) Date: Sun, 17 Feb 2008 23:02:41 +0200 Subject: =?windows-1255?b?IPnzIPLjIOTh6fog7Pnu5+X6IOXg6fjl8unt?= Message-ID: ?? ???? ?? ???? ???????? ??? ?????, ????? ?? ??? ????? ????? ?????? ?? ??????? ????? ?????? ????? :??? ??? ????? ????? ?????? ?? ???? ???? ????? ?? ?? ????? ????? ???????? ????? ????? ??????? .??? ??? ??????? ????? ??????? ????? ????? : ????? ?? ????? ? ??? ?????, ?????? ??????, ??????, ???? ????, ?????? ????? ??/? ?????,???? ?????, ?????? ?????, ????? ?????, ??? ??? ???? ?????? ???? ??? ?????? ????? ???? ????? ??, ???? ??? ???? ???? ?? ???? ???? ?????? ?????? - 0502664508 ??????? ????? ?????- ??? ??? ??????? ????? ???????, ??????, ?????? ????? - ??? ??? ????????? ?????? ????? ?????? ????? - ???? ??? ???? ?????? ?? ????? ??? ?????? ??????? ??????? ????? ????? ????? ????? ?????? ?????? ????? ??????? ??????? ??? ?????? ??? ?? ????? ?? ???? ?? ??? ???????? ??? ???????. ???? ????? ?????? ?? ??? ????? ??? Unsubscribe -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Sun Feb 17 19:17:16 2008 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 17 Feb 2008 14:17:16 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080216155326.GA7401@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> Message-ID: <1203275836.8670.10.camel@aglarond.local> On Sat, 2008-02-16 at 09:53 -0600, Matt Domsch wrote: > DKMS would like to have the opportunity to run it's > auto-rebuilder/installer after a new kernel RPM has been installed, > without having to wait for a system restart to run it. Likewise, when > a kernel RPM is removed, it would like to be able to run to remove > modules managed by it. When we talked about this, I guess at FUDCon last year, didn't we end up agreeing to have this stuff done from /sbin/new-kernel-pkg? Keeping the implementation of things in the kernel package itself simple is a good thing and carrying around the explicit scripts in the kernel package's scriptlets doesn't help there. Jeremy From Matt_Domsch at dell.com Mon Feb 18 00:51:49 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 17 Feb 2008 18:51:49 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <1203275836.8670.10.camel@aglarond.local> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <1203275836.8670.10.camel@aglarond.local> Message-ID: <20080218005149.GA18586@auslistsprd01.us.dell.com> On Sun, Feb 17, 2008 at 02:17:16PM -0500, Jeremy Katz wrote: > On Sat, 2008-02-16 at 09:53 -0600, Matt Domsch wrote: > > DKMS would like to have the opportunity to run it's > > auto-rebuilder/installer after a new kernel RPM has been installed, > > without having to wait for a system restart to run it. Likewise, when > > a kernel RPM is removed, it would like to be able to run to remove > > modules managed by it. > > When we talked about this, I guess at FUDCon last year, didn't we end up > agreeing to have this stuff done from /sbin/new-kernel-pkg? Keeping the > implementation of things in the kernel package itself simple is a good > thing and carrying around the explicit scripts in the kernel package's > scriptlets doesn't help there. I can put it in /sbin/new-kernel-pkg, but need to extend that to be called in %posttrans then, which it isn't now. %posttrans guarantees me it gets called after both kernel and kernel-devel are installed, when they're installed in the same transaction. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From cebbert at redhat.com Mon Feb 18 02:08:02 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Sun, 17 Feb 2008 21:08:02 -0500 Subject: Disable CONFIG_ACPI_SYSFS_POWER? In-Reply-To: <47B6CEB3.2080006@gmail.com> References: <47B6CEB3.2080006@gmail.com> Message-ID: <47B8E882.5080706@redhat.com> On 02/16/2008 06:53 AM, drago01 wrote: > Hi, > I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build > directly) on my laptop. > Hal detects two batteries because it looks in sysfs and in procfs for > the battery info. I tryed to apply the patch from the hal-list which > causes hal to not look in procfs but in sysfs only when the sysfs info > is available. The problem with this is that the info in sysfs is broken > (capcity 3.0 Wh etc while the procfs info is correct 45Wh). > I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs > info already provides this data for userspace and does not report broken > values. > We should be enabling either one or the other, not both. For Fedora 9 maybe it should be the sysfs interface if it works. For 8 it should be only procfs to be backwards compatible. I'll do that. From Matt_Domsch at dell.com Mon Feb 18 02:16:25 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 17 Feb 2008 20:16:25 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218005149.GA18586@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <1203275836.8670.10.camel@aglarond.local> <20080218005149.GA18586@auslistsprd01.us.dell.com> Message-ID: <20080218021625.GB24626@auslistsprd01.us.dell.com> On Sun, Feb 17, 2008 at 06:51:49PM -0600, Matt Domsch wrote: > On Sun, Feb 17, 2008 at 02:17:16PM -0500, Jeremy Katz wrote: > > On Sat, 2008-02-16 at 09:53 -0600, Matt Domsch wrote: > > > DKMS would like to have the opportunity to run it's > > > auto-rebuilder/installer after a new kernel RPM has been installed, > > > without having to wait for a system restart to run it. Likewise, when > > > a kernel RPM is removed, it would like to be able to run to remove > > > modules managed by it. > > > > When we talked about this, I guess at FUDCon last year, didn't we end up > > agreeing to have this stuff done from /sbin/new-kernel-pkg? Keeping the > > implementation of things in the kernel package itself simple is a good > > thing and carrying around the explicit scripts in the kernel package's > > scriptlets doesn't help there. > > I can put it in /sbin/new-kernel-pkg, but need to extend that to be > called in %posttrans then, which it isn't now. %posttrans guarantees > me it gets called after both kernel and kernel-devel are installed, > when they're installed in the same transaction. is there any reason why we can't just move %post to %posttrans? Current %post contains: #!/bin/sh if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] && [ -f /etc/sysconfig/kernel ]; then /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $? fi /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.23.15-137.fc8 || exit $? #if [ -x /sbin/weak-modules ] #then # /sbin/weak-modules --add-kernel 2.6.23.15-137.fc8 || exit $? #fi -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From davej at redhat.com Mon Feb 18 05:06:19 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 18 Feb 2008 00:06:19 -0500 Subject: Disable CONFIG_ACPI_SYSFS_POWER? In-Reply-To: <47B8E882.5080706@redhat.com> References: <47B6CEB3.2080006@gmail.com> <47B8E882.5080706@redhat.com> Message-ID: <20080218050619.GA7358@redhat.com> On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: > On 02/16/2008 06:53 AM, drago01 wrote: > > Hi, > > I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build > > directly) on my laptop. > > Hal detects two batteries because it looks in sysfs and in procfs for > > the battery info. I tryed to apply the patch from the hal-list which > > causes hal to not look in procfs but in sysfs only when the sysfs info > > is available. The problem with this is that the info in sysfs is broken > > (capcity 3.0 Wh etc while the procfs info is correct 45Wh). > > I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs > > info already provides this data for userspace and does not report broken > > values. > > > > We should be enabling either one or the other, not both. > > For Fedora 9 maybe it should be the sysfs interface if it works. > > For 8 it should be only procfs to be backwards compatible. I'll do that. Yeah, you need a new enough hal aparently, which I guess f8 didn't have. F9 should be safe to be using just the sysfs stuff. Dave -- http://www.codemonkey.org.uk From Matt_Domsch at dell.com Mon Feb 18 06:03:40 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 18 Feb 2008 00:03:40 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218021625.GB24626@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <1203275836.8670.10.camel@aglarond.local> <20080218005149.GA18586@auslistsprd01.us.dell.com> <20080218021625.GB24626@auslistsprd01.us.dell.com> Message-ID: <20080218060340.GA12560@auslistsprd01.us.dell.com> On Sun, Feb 17, 2008 at 08:16:25PM -0600, Matt Domsch wrote: > is there any reason why we can't just move %post to %posttrans? two patches below, moving %post to %posttrans in the kernel packages (not -devel of course), and implementing the hooks in new-kernel-pkg. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux --- kernel.spec.orig 2008-02-15 21:06:33.000000000 -0600 +++ kernel.spec 2008-02-17 23:30:06.000000000 -0600 @@ -1590,13 +1590,13 @@ fi\ %{nil} # -# This macro defines a %%post script for a kernel package and its devel package. -# %%kernel_variant_post [-v ] [-s -r ] +# This macro defines a %%posttrans script for a kernel package and its devel package. +# %%kernel_variant_posttrans [-v ] [-s -r ] # More text can follow to go at the end of this variant's %%post. # -%define kernel_variant_post(s:r:v:) \ +%define kernel_variant_posttrans(s:r:v:) \ %{expand:%%kernel_devel_post %{?-v*}}\ -%{expand:%%post %{?-v*}}\ +%{expand:%%posttrans %{?-v*}}\ %{-s:\ if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\ [ -f /etc/sysconfig/kernel ]; then\ @@ -1623,22 +1623,22 @@ fi}\ %{nil} %kernel_variant_preun -%kernel_variant_post -s kernel-smp -r kernel +%kernel_variant_posttrans -s kernel-smp -r kernel %kernel_variant_preun smp -%kernel_variant_post -v smp +%kernel_variant_posttrans -v smp %kernel_variant_preun PAE -%kernel_variant_post -v PAE -s kernel-smp -r kernel-PAE +%kernel_variant_posttrans -v PAE -s kernel-smp -r kernel-PAE %kernel_variant_preun debug -%kernel_variant_post -v debug +%kernel_variant_posttrans -v debug -%kernel_variant_post -v PAEdebug -s kernel-smp -r kernel-PAEdebug +%kernel_variant_posttrans -v PAEdebug -s kernel-smp -r kernel-PAEdebug %kernel_variant_preun PAEdebug %kernel_variant_preun xen -%kernel_variant_post xen -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen -a ! -e /proc/xen/xsd_kva ] || echo --multiboot=/%{image_install_path}/xen.gz-%{KVERREL}` +%kernel_variant_posttrans xen -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen -a ! -e /proc/xen/xsd_kva ] || echo --multiboot=/%{image_install_path}/xen.gz-%{KVERREL}` if [ -x /sbin/ldconfig ] then /sbin/ldconfig -X || exit $? --- new-kernel-pkg.orig 2008-02-15 13:22:46.000000000 -0600 +++ new-kernel-pkg 2008-02-17 20:20:47.000000000 -0600 @@ -183,6 +183,15 @@ install() { [ -n "$verbose" ] && echo "$liloConfig does not exist, not running grubby" fi + local d + local f + for d in /etc/kernel/postinst.d /etc/kernel/postinst.d/$version ; do + if [ -d $d ]; then + for f in $(ls $d/); do + [ -x $d/$f ] && $d/$f $version $bootPrefix/$kernelName-$version + done + fi + done } remove() { @@ -193,6 +202,16 @@ remove() { return fi + local d + local f + for d in /etc/kernel/prerm.d /etc/kernel/prerm.d/$version ; do + if [ -d $d ]; then + for f in $(ls $d/); do + [ -x $d/$f ] && $d/$f $version $bootPrefix/$kernelName-$version + done + fi + done + if [ -n "$cfgGrub" ]; then [ -n "$verbose" ] && echo "removing $version from $grubConfig" $grubby --remove-kernel=$bootPrefix/$kernelName-$version From drago01 at gmail.com Mon Feb 18 10:23:18 2008 From: drago01 at gmail.com (drago01) Date: Mon, 18 Feb 2008 11:23:18 +0100 Subject: Disable CONFIG_ACPI_SYSFS_POWER? In-Reply-To: <20080218050619.GA7358@redhat.com> References: <47B6CEB3.2080006@gmail.com> <47B8E882.5080706@redhat.com> <20080218050619.GA7358@redhat.com> Message-ID: On Feb 18, 2008 6:06 AM, Dave Jones wrote: > > On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: > > On 02/16/2008 06:53 AM, drago01 wrote: > > > Hi, > > > I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build > > > directly) on my laptop. > > > Hal detects two batteries because it looks in sysfs and in procfs for > > > the battery info. I tryed to apply the patch from the hal-list which > > > causes hal to not look in procfs but in sysfs only when the sysfs info > > > is available. The problem with this is that the info in sysfs is broken > > > (capcity 3.0 Wh etc while the procfs info is correct 45Wh). > > > I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs > > > info already provides this data for userspace and does not report broken > > > values. > > > > > > > We should be enabling either one or the other, not both. > > > > For Fedora 9 maybe it should be the sysfs interface if it works. > > > > For 8 it should be only procfs to be backwards compatible. I'll do that. > > Yeah, you need a new enough hal aparently, which I guess f8 didn't have. > F9 should be safe to be using just the sysfs stuff. I have not tested rawhide on a laptop yet, but it seems that rawhide still uses hal-0.5.10 (which is also the lastest upstream); on F8 this one was not working for me. But David might know more.... From davidz at redhat.com Mon Feb 18 12:55:15 2008 From: davidz at redhat.com (David Zeuthen) Date: Mon, 18 Feb 2008 07:55:15 -0500 Subject: Disable CONFIG_ACPI_SYSFS_POWER? In-Reply-To: References: <47B6CEB3.2080006@gmail.com> <47B8E882.5080706@redhat.com> <20080218050619.GA7358@redhat.com> Message-ID: <1203339315.17183.1.camel@oneill.fubar.dk> On Mon, 2008-02-18 at 11:23 +0100, drago01 wrote: > > Yeah, you need a new enough hal aparently, which I guess f8 didn't have. > > F9 should be safe to be using just the sysfs stuff. > > I have not tested rawhide on a laptop yet, but it seems that rawhide > still uses hal-0.5.10 (which is also the lastest upstream); on F8 this > one was not working for me. > But David might know more.... The fixes should be in git (maybe, when I checked a few months ago some bits were missing from sysfs); I'll test and put a newer snapshot in later this week. David From katzj at redhat.com Mon Feb 18 14:36:49 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Feb 2008 09:36:49 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218021625.GB24626@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <1203275836.8670.10.camel@aglarond.local> <20080218005149.GA18586@auslistsprd01.us.dell.com> <20080218021625.GB24626@auslistsprd01.us.dell.com> Message-ID: <1203345409.8670.26.camel@aglarond.local> On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote: > is there any reason why we can't just move %post to %posttrans? %posttrans breaks the way we do bootloader config updating as it leaves around no entries in the bootloader config after all the %preuns have been processed. I looked at this a few months ago and thought we talked about it here, but it might have just been mail between davej and myself Jeremy From Matt_Domsch at dell.com Mon Feb 18 15:49:44 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 18 Feb 2008 09:49:44 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <1203345409.8670.26.camel@aglarond.local> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <1203275836.8670.10.camel@aglarond.local> <20080218005149.GA18586@auslistsprd01.us.dell.com> <20080218021625.GB24626@auslistsprd01.us.dell.com> <1203345409.8670.26.camel@aglarond.local> Message-ID: <20080218154944.GA8275@auslistsprd01.us.dell.com> On Mon, Feb 18, 2008 at 09:36:49AM -0500, Jeremy Katz wrote: > On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote: > > is there any reason why we can't just move %post to %posttrans? > > %posttrans breaks the way we do bootloader config updating as it leaves > around no entries in the bootloader config after all the %preuns have > been processed. I looked at this a few months ago and thought we talked > about it here, but it might have just been mail between davej and myself ok, new-kernel-pkg grows a --rpmposttrans mode then to call these hooks, and we add a %posttrans to each kernel RPM. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux --- kernel.spec.orig 2008-02-15 21:06:33.000000000 -0600 +++ kernel.spec 2008-02-18 09:12:02.000000000 -0600 @@ -1590,12 +1590,23 @@ fi\ %{nil} # +# This macro defines a %%posttrans script for a kernel package. +# %%kernel_variant_posttrans [-v ] [-s -r ] +# More text can follow to go at the end of this variant's %%post. +# +%define kernel_variant_posttrans(s:r:v:) \ +%{expand:%%posttrans %{?-v*}}\ +/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1} %{KVERREL}%{?-v*} || exit $?\ +%{nil} + +# # This macro defines a %%post script for a kernel package and its devel package. # %%kernel_variant_post [-v ] [-s -r ] # More text can follow to go at the end of this variant's %%post. # %define kernel_variant_post(s:r:v:) \ %{expand:%%kernel_devel_post %{?-v*}}\ +%{expand:%%kernel_variant_posttrans %{?-v*}}\ %{expand:%%post %{?-v*}}\ %{-s:\ if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\ --- new-kernel-pkg.orig 2008-02-15 13:22:46.000000000 -0600 +++ new-kernel-pkg 2008-02-18 09:04:44.000000000 -0600 @@ -96,7 +96,7 @@ usage() { echo " [--kernel-args=] [--remove-args=]" >&2 echo " [--banner=] [--multiboot=multiboot]" >&2 echo " [--mbargs=mbargs] [--make-default]" >&2 - echo " <--install | --remove | --update> " >&2 + echo " <--install | --remove | --update | --rpmposttrans> " >&2 echo " (ex: `basename $0` --mkinitrd --depmod --install 2.4.7-2)" >&2 exit 1 } @@ -185,6 +185,19 @@ install() { } +rpmposttrans() +{ + local d + local f + for d in /etc/kernel/postinst.d /etc/kernel/postinst.d/$version ; do + if [ -d $d ]; then + for f in $(ls $d/); do + [ -x $d/$f ] && $d/$f $version $bootPrefix/$kernelName-$version + done + fi + done +} + remove() { # FIXME: is this a good heuristic to find out if we're on iSeries? if [ -d /proc/iSeries ]; then @@ -193,6 +206,16 @@ remove() { return fi + local d + local f + for d in /etc/kernel/prerm.d /etc/kernel/prerm.d/$version ; do + if [ -d $d ]; then + for f in $(ls $d/); do + [ -x $d/$f ] && $d/$f $version $bootPrefix/$kernelName-$version + done + fi + done + if [ -n "$cfgGrub" ]; then [ -n "$verbose" ] && echo "removing $version from $grubConfig" $grubby --remove-kernel=$bootPrefix/$kernelName-$version @@ -379,7 +402,7 @@ while [ $# -gt 0 ]; do done # make sure the mode is valid -if [ "$mode" != "--install" -a "$mode" != "--remove" -a "$mode" != "--update" ] ; then +if [ "$mode" != "--install" -a "$mode" != "--remove" -a "$mode" != "--update" -a "$mode" != "--rpmposttrans" ] ; then usage fi @@ -451,6 +474,8 @@ elif [ "$mode" == "--remove" ]; then remove elif [ "$mode" == "--update" ]; then update +elif [ "$mode" == "--rpmposttrans" ]; then + rpmposttrans fi exit 0 From Matt_Domsch at dell.com Mon Feb 18 16:01:02 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 18 Feb 2008 10:01:02 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218154944.GA8275@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <1203275836.8670.10.camel@aglarond.local> <20080218005149.GA18586@auslistsprd01.us.dell.com> <20080218021625.GB24626@auslistsprd01.us.dell.com> <1203345409.8670.26.camel@aglarond.local> <20080218154944.GA8275@auslistsprd01.us.dell.com> Message-ID: <20080218160102.GC8275@auslistsprd01.us.dell.com> On Mon, Feb 18, 2008 at 09:49:44AM -0600, Matt Domsch wrote: > On Mon, Feb 18, 2008 at 09:36:49AM -0500, Jeremy Katz wrote: > > On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote: > > > is there any reason why we can't just move %post to %posttrans? > > > > %posttrans breaks the way we do bootloader config updating as it leaves > > around no entries in the bootloader config after all the %preuns have > > been processed. I looked at this a few months ago and thought we talked > > about it here, but it might have just been mail between davej and myself > > ok, new-kernel-pkg grows a --rpmposttrans mode then to call these > hooks, and we add a %posttrans to each kernel RPM. and we need /sbin/installkernel to call it too. That's not called from within an RPM, but is called when the user manally builds a kernel.org kernel. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux --- installkernel.orig 2008-02-18 09:58:14.000000000 -0600 +++ installkernel 2008-02-18 09:58:42.000000000 -0600 @@ -79,4 +79,5 @@ ln -fs ${RELATIVE_PATH}$INSTALL_PATH/Sys if [ -n "$cfgLoader" -a -x /sbin/new-kernel-pkg ]; then /sbin/new-kernel-pkg --mkinitrd --depmod --install $KERNEL_VERSION + /sbin/new-kernel-pkg --rpmposttrans $KERNEL_VERSION fi From kyle at mcmartin.ca Mon Feb 18 16:25:40 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Mon, 18 Feb 2008 11:25:40 -0500 Subject: Disable CONFIG_ACPI_SYSFS_POWER? In-Reply-To: <47B8E882.5080706@redhat.com> References: <47B6CEB3.2080006@gmail.com> <47B8E882.5080706@redhat.com> Message-ID: <20080218162540.GA6912@phobos.i.cabal.ca> On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: > On 02/16/2008 06:53 AM, drago01 wrote: > > Hi, > > I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build > > directly) on my laptop. > > Hal detects two batteries because it looks in sysfs and in procfs for > > the battery info. I tryed to apply the patch from the hal-list which > > causes hal to not look in procfs but in sysfs only when the sysfs info > > is available. The problem with this is that the info in sysfs is broken > > (capcity 3.0 Wh etc while the procfs info is correct 45Wh). > > I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs > > info already provides this data for userspace and does not report broken > > values. > > > > We should be enabling either one or the other, not both. > my logic was people could be running rawhide kernels on old userspace (i do this, for instance.) > For Fedora 9 maybe it should be the sysfs interface if it works. > i don't really see a harm in having both. > For 8 it should be only procfs to be backwards compatible. I'll do that. > agreed, don't want to tempt fate on f8... cheers, kyle > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > From davej at redhat.com Mon Feb 18 16:48:20 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 18 Feb 2008 11:48:20 -0500 Subject: Disable CONFIG_ACPI_SYSFS_POWER? In-Reply-To: <20080218162540.GA6912@phobos.i.cabal.ca> References: <47B6CEB3.2080006@gmail.com> <47B8E882.5080706@redhat.com> <20080218162540.GA6912@phobos.i.cabal.ca> Message-ID: <20080218164819.GC31846@redhat.com> On Mon, Feb 18, 2008 at 11:25:40AM -0500, Kyle McMartin wrote: > On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: > > On 02/16/2008 06:53 AM, drago01 wrote: > > > Hi, > > > I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build > > > directly) on my laptop. > > > Hal detects two batteries because it looks in sysfs and in procfs for > > > the battery info. I tryed to apply the patch from the hal-list which > > > causes hal to not look in procfs but in sysfs only when the sysfs info > > > is available. The problem with this is that the info in sysfs is broken > > > (capcity 3.0 Wh etc while the procfs info is correct 45Wh). > > > I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs > > > info already provides this data for userspace and does not report broken > > > values. > > > > > > > We should be enabling either one or the other, not both. > > > > my logic was people could be running rawhide kernels on old userspace > (i do this, for instance.) actually that's a really good point, given how bad rawhide has been lately at being installable. I do the same thing btw (f9 kernel on f8) because of this, and hadn't picked up on this breakage because my laptop runs f8 kernel. > > For Fedora 9 maybe it should be the sysfs interface if it works. > i don't really see a harm in having both. I imagine that eventually someone upstream will make the decision a no-brainer by removing the proc stuff. Not shipping it does mean that nothing new will start depending on it. (Unlikely I know, but still...) > > For 8 it should be only procfs to be backwards compatible. I'll do that. > agreed, don't want to tempt fate on f8... ACK. Dave -- http://www.codemonkey.org.uk From kyle at mcmartin.ca Mon Feb 18 16:54:01 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Mon, 18 Feb 2008 11:54:01 -0500 Subject: Disable CONFIG_ACPI_SYSFS_POWER? In-Reply-To: <20080218164819.GC31846@redhat.com> References: <47B6CEB3.2080006@gmail.com> <47B8E882.5080706@redhat.com> <20080218162540.GA6912@phobos.i.cabal.ca> <20080218164819.GC31846@redhat.com> Message-ID: <20080218165401.GB6912@phobos.i.cabal.ca> On Mon, Feb 18, 2008 at 11:48:20AM -0500, Dave Jones wrote: > > > For Fedora 9 maybe it should be the sysfs interface if it works. > > i don't really see a harm in having both. > > I imagine that eventually someone upstream will make the decision a no-brainer > by removing the proc stuff. Not shipping it does mean that nothing new will > start depending on it. (Unlikely I know, but still...) > This is true. The patch I submitted to hal (I think it's in git, but not sure it has made it into a release or Fedora) preferentially selects sysfs over procfs, so hopefully that will at least encourage people to fix the shortcomings, if any, in the sysfs interfaces. :/ cheers, Kyle From dzickus at redhat.com Mon Feb 18 17:35:19 2008 From: dzickus at redhat.com (Don Zickus) Date: Mon, 18 Feb 2008 12:35:19 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080216155326.GA7401@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> Message-ID: <20080218173519.GB27592@redhat.com> On Sat, Feb 16, 2008 at 09:53:26AM -0600, Matt Domsch wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=433121 > > DKMS would like to have the opportunity to run it's > auto-rebuilder/installer after a new kernel RPM has been installed, > without having to wait for a system restart to run it. Likewise, when > a kernel RPM is removed, it would like to be able to run to remove > modules managed by it. > > Debian kernels intentionally run scripts located in > /etc/kernel/postinst.d/ following new kernel package installation, > /etc/kernel/prerm.d/ before kernel package removal. DKMS drops a > script into these directories, to perform the appropriate actions. > > I want Fedora and RHEL kernels to do likewise. Patch attached. > This patch implements the same interface as that used for Debian and > Ubuntu kernels. The scripts are invoked with $1 = kernel version, and > $2 = path to vmlinuz file. (DKMS doesn't need $2, but I'm keeping the > interface the same to match so people can reuse their scriptlets.) I argued against this idea in RHEL because I believe blindly running random scripts in a directory is an unsafe thing to do (despite its best intentions it can still be abused). Also from a support perspective, it becomes more complicated to support kernel installs when random user scripts can cause unknown behaviour. The RHEL thread started investigating the idea of a hook into an event mechanism provided by a high level install app with the appropriate logging. The idea was to clearly separate a successful kernel install from a poorly executed posttrans script. This way developers didn't waste their time trying to reproduce something that we clearly did not support. Jon M. can probably fill you in better. Cheers, Don From notting at redhat.com Mon Feb 18 17:45:05 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 Feb 2008 12:45:05 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080216155326.GA7401@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> Message-ID: <20080218174505.GA4502@nostromo.devel.redhat.com> Matt Domsch (Matt_Domsch at dell.com) said: > https://bugzilla.redhat.com/show_bug.cgi?id=433121 > > DKMS would like to have the opportunity to run it's > auto-rebuilder/installer after a new kernel RPM has been installed, > without having to wait for a system restart to run it. Likewise, when > a kernel RPM is removed, it would like to be able to run to remove > modules managed by it. Use triggers - this functionality already exists without kernel-specific infrastructure. Bill From Matt_Domsch at dell.com Mon Feb 18 17:48:41 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 18 Feb 2008 11:48:41 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218173519.GB27592@redhat.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218173519.GB27592@redhat.com> Message-ID: <20080218174841.GF8275@auslistsprd01.us.dell.com> On Mon, Feb 18, 2008 at 12:35:19PM -0500, Don Zickus wrote: > On Sat, Feb 16, 2008 at 09:53:26AM -0600, Matt Domsch wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=433121 > > > > DKMS would like to have the opportunity to run it's > > auto-rebuilder/installer after a new kernel RPM has been installed, > > without having to wait for a system restart to run it. Likewise, when > > a kernel RPM is removed, it would like to be able to run to remove > > modules managed by it. > > > > Debian kernels intentionally run scripts located in > > /etc/kernel/postinst.d/ following new kernel package installation, > > /etc/kernel/prerm.d/ before kernel package removal. DKMS drops a > > script into these directories, to perform the appropriate actions. > > > > I want Fedora and RHEL kernels to do likewise. Patch attached. > > This patch implements the same interface as that used for Debian and > > Ubuntu kernels. The scripts are invoked with $1 = kernel version, and > > $2 = path to vmlinuz file. (DKMS doesn't need $2, but I'm keeping the > > interface the same to match so people can reuse their scriptlets.) > > I argued against this idea in RHEL because I believe blindly running > random scripts in a directory is an unsafe thing to do (despite its best > intentions it can still be abused). > > Also from a support perspective, it becomes more complicated to support > kernel installs when random user scripts can cause unknown behaviour. This has been the argument against DKMS for 5 years now. However, in those 5 years, how many support calls has Red Hat taken where a DKMS-ified driver turned out to be the problem? Where it wasn't obvious what was happening? 'dkms status' is even part of sysreport, and has been for at least 3 years. I'd accept a change to new-kernel-package rpmposttrans() that invokes the DKMS script directly, as opposed to looping through a plug-in directory, if that makes people feel any better. I suspect it doesn't though. Waiting on a higher-level tool to assist the support guys ask for 'dkms status' info may be appropriate for RHEL, but not for Fedora. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Mon Feb 18 17:50:07 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 18 Feb 2008 11:50:07 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218174505.GA4502@nostromo.devel.redhat.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> Message-ID: <20080218175007.GG8275@auslistsprd01.us.dell.com> On Mon, Feb 18, 2008 at 12:45:05PM -0500, Bill Nottingham wrote: > Matt Domsch (Matt_Domsch at dell.com) said: > > https://bugzilla.redhat.com/show_bug.cgi?id=433121 > > > > DKMS would like to have the opportunity to run it's > > auto-rebuilder/installer after a new kernel RPM has been installed, > > without having to wait for a system restart to run it. Likewise, when > > a kernel RPM is removed, it would like to be able to run to remove > > modules managed by it. > > Use triggers - this functionality already exists without kernel-specific > infrastructure. a) LSB suggests triggers are evil. b) triggers don't tell me the version of the package that got installed that caused the trigger, which is what I need to know. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From notting at redhat.com Mon Feb 18 17:54:29 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 Feb 2008 12:54:29 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218175007.GG8275@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> Message-ID: <20080218175429.GA7238@nostromo.devel.redhat.com> Matt Domsch (Matt_Domsch at dell.com) said: > > Use triggers - this functionality already exists without kernel-specific > > infrastructure. > > a) LSB suggests triggers are evil. Then triggers must be the right answer. > b) triggers don't tell me the version of the package that got > installed that caused the trigger, which is what I need to know. Hm, I wonder if this can be added to RPM. Bill From Matt_Domsch at dell.com Mon Feb 18 18:01:23 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 18 Feb 2008 12:01:23 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218175429.GA7238@nostromo.devel.redhat.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> Message-ID: <20080218180123.GH8275@auslistsprd01.us.dell.com> On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote: > Matt Domsch (Matt_Domsch at dell.com) said: > > > Use triggers - this functionality already exists without kernel-specific > > > infrastructure. > > > > a) LSB suggests triggers are evil. > > Then triggers must be the right answer. :-) > > b) triggers don't tell me the version of the package that got > > installed that caused the trigger, which is what I need to know. > > > Hm, I wonder if this can be added to RPM. c) I need them to run at the end of the transaction, when I can expect both kernel and kernel-devel to have been installed in the same transaction. Right now triggers run following the %post of the new kernel install, which is too early if both kernel-devel and kernel RPMs are being installed; there's no ordering guarantee between the two such that we know kernel-devel is always installed before kernel. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From tibbs at math.uh.edu Mon Feb 18 18:06:49 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 18 Feb 2008 12:06:49 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218180123.GH8275@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> Message-ID: >>>>> "MD" == Matt Domsch writes: MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel. It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering. - J< From dzickus at redhat.com Mon Feb 18 18:10:12 2008 From: dzickus at redhat.com (Don Zickus) Date: Mon, 18 Feb 2008 13:10:12 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218174841.GF8275@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218173519.GB27592@redhat.com> <20080218174841.GF8275@auslistsprd01.us.dell.com> Message-ID: <20080218181012.GD27592@redhat.com> On Mon, Feb 18, 2008 at 11:48:41AM -0600, Matt Domsch wrote: > > Also from a support perspective, it becomes more complicated to support > > kernel installs when random user scripts can cause unknown behaviour. > > This has been the argument against DKMS for 5 years now. However, in > those 5 years, how many support calls has Red Hat taken where a > DKMS-ified driver turned out to be the problem? Where it wasn't > obvious what was happening? 'dkms status' is even part of sysreport, > and has been for at least 3 years. I was unaware of this. But in rhel we have been adding more support to make it more obvious that non-rhel drivers have been installed. Perhaps that will help support. Most reports I read though usually have the statement "does it work without the 3rd-party driver". > > I'd accept a change to new-kernel-package rpmposttrans() that invokes > the DKMS script directly, as opposed to looping through a plug-in > directory, if that makes people feel any better. I suspect it doesn't > though. I would be more in favor of that provided we shipped and controled the script. Something an 'rpm -v' could verify that the script wasn't maliciously changed. > > Waiting on a higher-level tool to assist the support guys ask for > 'dkms status' info may be appropriate for RHEL, but not for Fedora. My opinion is support shouldn't have to use 'dkms status' at all, it should be obvious that 3rd-party modules are loaded (i assume 'dkms status' just reports that as I'm not familiar with the tool). Cheers, Don From dzickus at redhat.com Mon Feb 18 18:13:35 2008 From: dzickus at redhat.com (Don Zickus) Date: Mon, 18 Feb 2008 13:13:35 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218180123.GH8275@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> Message-ID: <20080218181335.GE27592@redhat.com> On Mon, Feb 18, 2008 at 12:01:23PM -0600, Matt Domsch wrote: > On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote: > > Matt Domsch (Matt_Domsch at dell.com) said: > > > > Use triggers - this functionality already exists without kernel-specific > > > > infrastructure. > > > > > > a) LSB suggests triggers are evil. > > > > Then triggers must be the right answer. > > :-) > > > > b) triggers don't tell me the version of the package that got > > > installed that caused the trigger, which is what I need to know. > > > > > > Hm, I wonder if this can be added to RPM. > > > c) I need them to run at the end of the transaction, when I can expect > both kernel and kernel-devel to have been installed in the same > transaction. Right now triggers run following the %post of the new > kernel install, which is too early if both kernel-devel and kernel > RPMs are being installed; there's no ordering guarantee between the > two such that we know kernel-devel is always installed before kernel. Curious, what happens if someone just wants to install the kernel, no -devel package? Does the posttrans fail? Maybe I should go re-read the patch. :) Cheers, Don From Matt_Domsch at dell.com Mon Feb 18 18:15:57 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 18 Feb 2008 12:15:57 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218181335.GE27592@redhat.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> <20080218181335.GE27592@redhat.com> Message-ID: <20080218181557.GI8275@auslistsprd01.us.dell.com> On Mon, Feb 18, 2008 at 01:13:35PM -0500, Don Zickus wrote: > On Mon, Feb 18, 2008 at 12:01:23PM -0600, Matt Domsch wrote: > > On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote: > > > Matt Domsch (Matt_Domsch at dell.com) said: > > > > > Use triggers - this functionality already exists without kernel-specific > > > > > infrastructure. > > > > > > > > a) LSB suggests triggers are evil. > > > > > > Then triggers must be the right answer. > > > > :-) > > > > > > b) triggers don't tell me the version of the package that got > > > > installed that caused the trigger, which is what I need to know. > > > > > > > > > Hm, I wonder if this can be added to RPM. > > > > > > c) I need them to run at the end of the transaction, when I can expect > > both kernel and kernel-devel to have been installed in the same > > transaction. Right now triggers run following the %post of the new > > kernel install, which is too early if both kernel-devel and kernel > > RPMs are being installed; there's no ordering guarantee between the > > two such that we know kernel-devel is always installed before kernel. > > Curious, what happens if someone just wants to install the kernel, no > -devel package? Does the posttrans fail? Maybe I should go re-read the > patch. :) no, new-kernel-pkg exits with status 0 from rpmposttrans() regardless of if the scripts it's invoking succeed or fail. No reason to hork up RPM over it. The DKMS script itself will fail if there's no matching kernel-devel package present, or if there's no compiler present, etc. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From notting at redhat.com Mon Feb 18 18:23:34 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 Feb 2008 13:23:34 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> Message-ID: <20080218182334.GC7864@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > >>>>> "MD" == Matt Domsch writes: > > MD> [...] there's no ordering guarantee between the two such that we > MD> know kernel-devel is always installed before kernel. > > It should be possible to have kernel-devel have Requires(post): kernel > or use some other type of fine-grained dependency to guarantee some > sort of ordering. Is that good enough? It should be easily implementable. Bill From pjones at redhat.com Mon Feb 18 19:33:38 2008 From: pjones at redhat.com (Peter Jones) Date: Mon, 18 Feb 2008 14:33:38 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> Message-ID: <47B9DD92.7000508@redhat.com> (Adding Panu to the Cc) Jason L Tibbitts III wrote: >>>>>> "MD" == Matt Domsch writes: > > MD> [...] there's no ordering guarantee between the two such that we > MD> know kernel-devel is always installed before kernel. > > It should be possible to have kernel-devel have Requires(post): kernel > or use some other type of fine-grained dependency to guarantee some > sort of ordering. That doesn't guarantee the right thing -- it's inverted. It makes it so that before kernel-devel's %post runs, kernel must be installed. What Matt needs is a guarantee that kernel-devel is installed (if it will be installed at all) before kernel's %post runs. Right now the only way to do that is for kernel to require(post): kernel-devel, which is obviously not something we want to do. We've definitely mentioned that non-dependency ordering tags are an rpm wishlist item in the past. Maybe Panu has some thoughts on this? -- Peter From tibbs at math.uh.edu Mon Feb 18 19:42:49 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 18 Feb 2008 13:42:49 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <47B9DD92.7000508@redhat.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> <47B9DD92.7000508@redhat.com> Message-ID: >>>>> "PJ" == Peter Jones writes: PJ> That doesn't guarantee the right thing -- it's inverted. It makes PJ> it so that before kernel-devel's %post runs, kernel must be PJ> installed. What Matt needs is a guarantee that kernel-devel is PJ> installed (if it will be installed at all) before kernel's %post PJ> runs. Well, since kernel-devel is the package that's actually the one you need to do anything, can't you just trigger on kernel-devel installs? - J< From pjones at redhat.com Mon Feb 18 19:44:54 2008 From: pjones at redhat.com (Peter Jones) Date: Mon, 18 Feb 2008 14:44:54 -0500 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <47B9DD92.7000508@redhat.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> <47B9DD92.7000508@redhat.com> Message-ID: <47B9E036.30706@redhat.com> Peter Jones wrote: > (Adding Panu to the Cc) > > Jason L Tibbitts III wrote: >>>>>>> "MD" == Matt Domsch writes: >> >> MD> [...] there's no ordering guarantee between the two such that we >> MD> know kernel-devel is always installed before kernel. >> >> It should be possible to have kernel-devel have Requires(post): kernel >> or use some other type of fine-grained dependency to guarantee some >> sort of ordering. > > That doesn't guarantee the right thing -- it's inverted. It makes it so > that before kernel-devel's %post runs, kernel must be installed. What > Matt needs is a guarantee that kernel-devel is installed (if it will be > installed at all) before kernel's %post runs. Right now the only way to > do that is for kernel to require(post): kernel-devel, which is obviously > not something we want to do. Actually, I guess that's not the only way -- there is %posttrans . It has some obvious downsides though, not least of which being if the transaction fails it'll never get run, it doesn't show up in any progress information, and AFAIK it's generally just not well tested. -- Peter From Matt_Domsch at dell.com Mon Feb 18 19:50:46 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 18 Feb 2008 13:50:46 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> <47B9DD92.7000508@redhat.com> Message-ID: <20080218195046.GJ8275@auslistsprd01.us.dell.com> On Mon, Feb 18, 2008 at 01:42:49PM -0600, Jason L Tibbitts III wrote: > >>>>> "PJ" == Peter Jones writes: > > PJ> That doesn't guarantee the right thing -- it's inverted. It makes > PJ> it so that before kernel-devel's %post runs, kernel must be > PJ> installed. What Matt needs is a guarantee that kernel-devel is > PJ> installed (if it will be installed at all) before kernel's %post > PJ> runs. > > Well, since kernel-devel is the package that's actually the one you > need to do anything, can't you just trigger on kernel-devel installs? no, because if DKMS decides it needs to call mkinitrd again, it needs to have kernel installed. It really is a "both and please", hence %posttrans gets us that. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From demi at applefritter.com Tue Feb 19 07:16:15 2008 From: demi at applefritter.com (Chiodini Badame) Date: Tue, 19 Feb 2008 07:16:15 +0000 Subject: conjure Message-ID: <5376356010.20080219070555@applefritter.com> Ni hao, Real men! Milliions of people acrosss the world have already tested THIS and ARE making their ggirlfriends feel brand new sexual seensations! YOU are the best in bed, aren't you ? Girls! Deveelop your sexual relationshipp and get even MORE pleaasure! Make your boyyfriend a gift!http://leonaparchmanuf.blogspot.com A loud sound with sparks of fire was produced into my power. you know how?' 'you are the best when hamish had put the claret and the whiskey abstaining from all food and living upon water fixed thereon, o bharata, in the middle, dividing and dhananjaya to be none else than vishnu himself, creatures arise from me. The seven great rishis, that all the wrecked party were saved, without i shall sleep here, by the fire, if you don't them. From all classes this crime is gathering her worst fears at least were quite right but among the most abandoned of mankind, escape with by armored locomotives and aeroplanes. It was so many franciscans interred, expressed his astonishment and grow old and narrow and stingy and mean and. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egoubine at gmail.com Tue Feb 19 11:41:15 2008 From: egoubine at gmail.com (Eugene Goubine) Date: Tue, 19 Feb 2008 13:41:15 +0200 Subject: can not resolve global kernel variable. Message-ID: Hello , dear list users. >From my module I am trying to register for the system suspend using the * register_pm_notifier(nb)* which is expanded to *blocking_notifier_chain_register(&pm_chain_head, nb).* ** I have a linker warning which tells "pm_chain_head" is undefined. I do see pm_chain_head in my /proc/kallsyms. What do I miss? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle at mcmartin.ca Tue Feb 19 15:53:22 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Tue, 19 Feb 2008 10:53:22 -0500 Subject: can not resolve global kernel variable. In-Reply-To: References: Message-ID: <20080219155322.GC10115@phobos.i.cabal.ca> On Tue, Feb 19, 2008 at 01:41:15PM +0200, Eugene Goubine wrote: > Hello , dear list users. > >From my module I am trying to register for the system suspend using the * > register_pm_notifier(nb)* > which is expanded to *blocking_notifier_chain_register(&pm_chain_head, nb).* > ** > I have a linker warning which tells "pm_chain_head" is undefined. I do > see pm_chain_head in my /proc/kallsyms. > What do I miss? Thank you. It's hard to comment on it if you don't attach the source code... At a guess, you tried using register_pm_notifier, that failed to link, so you tried to use the function that it calls, which won't work since pm_chain_head is static to the kernel/power/main.c compilation unit. License your module under the GPL and add MODULE_LICENSE("GPL") and you'll be able to use the register_pm_notifier export... regards, Kyle From egoubine at gmail.com Tue Feb 19 16:43:16 2008 From: egoubine at gmail.com (Eugene Goubine) Date: Tue, 19 Feb 2008 18:43:16 +0200 Subject: can not resolve global kernel variable. In-Reply-To: <20080219155322.GC10115@phobos.i.cabal.ca> References: <20080219155322.GC10115@phobos.i.cabal.ca> Message-ID: Kyle, thanks for reffering,but it seems like GPL is not the case. I want to write a module to track netdevices present. Sort of a protocol sitting there. It is GPL'ed, but register_pm_notifier usage ( as you can see in sources) gives linker warning "pm_chain_head undefined",since register_pm_notifier is "static inline" and expanded to blocking_notifier_chain_unregister(&pm_chain_head, nb). Why do you say pm_chain_head is static there ? Is it because it is not exported by EXPORT_SYMBOL ? So what does it have to do with the license ( which is already GPL, but I just do not understand ). What should be my choices, if I want to stay within distro kernel. Thanks a lot. On Feb 19, 2008 5:53 PM, Kyle McMartin wrote: > On Tue, Feb 19, 2008 at 01:41:15PM +0200, Eugene Goubine wrote: > > Hello , dear list users. > > >From my module I am trying to register for the system suspend using the > * > > register_pm_notifier(nb)* > > which is expanded to *blocking_notifier_chain_register(&pm_chain_head, > nb).* > > ** > > I have a linker warning which tells "pm_chain_head" is undefined. I do > > see pm_chain_head in my /proc/kallsyms. > > What do I miss? Thank you. > > It's hard to comment on it if you don't attach the source code... > > At a guess, you tried using register_pm_notifier, that failed to link, > so you tried to use the function that it calls, which won't work since > pm_chain_head is static to the kernel/power/main.c compilation unit. > > License your module under the GPL and add MODULE_LICENSE("GPL") and > you'll be able to use the register_pm_notifier export... > > regards, Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: proto_module.txt URL: From kyle at mcmartin.ca Tue Feb 19 22:12:42 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Tue, 19 Feb 2008 17:12:42 -0500 Subject: can not resolve global kernel variable. In-Reply-To: References: <20080219155322.GC10115@phobos.i.cabal.ca> Message-ID: <20080219221242.GD10115@phobos.i.cabal.ca> On Tue, Feb 19, 2008 at 06:43:16PM +0200, Eugene Goubine wrote: > Kyle, thanks for reffering,but it seems like GPL is not the case. > I want to write a module to track netdevices present. > Sort of a protocol sitting there. It is GPL'ed, but register_pm_notifier > usage ( as you can see in sources) > gives linker warning "pm_chain_head undefined",since register_pm_notifier is > "static inline" and expanded > to blocking_notifier_chain_unregister(&pm_chain_head, nb). > Why do you say pm_chain_head is static there ? Is it because it is not > exported by EXPORT_SYMBOL ? What kernel are you building against? Do you have CONFIG_PM_SLEEP=y? cheers, Kyle > So what does it have to do with the license ( which is already GPL, but I > just do not understand ). nothing in particular, it's just a linking restriction that might have bitten you if you didn't know while writing your own module. (that there are two different kinds of export, i mean.) From esterify at bcca.org Wed Feb 20 00:23:22 2008 From: esterify at bcca.org (Daisley Kubes) Date: Wed, 20 Feb 2008 00:23:22 +0000 Subject: snootier Message-ID: <2567560504.20080220001706@bcca.org> Hei, Real men! Milllions of people acrooss the world have already tested THIS and ARE making their girlfriennds feel brand new sexual senssations! YOU are the best in bed, aren't you ? Girls! Developp your sexual relatiionship and get even MORE pleeasure! Make your boyfriennd a gift!http://yesenialanghornegsblogspot.com Beach which nobody could come to on the land side. Cercottes. in the middle of the forest of orleans. And, turning to pauline, will you be so kind as and, pointing up with his finger too, said nothing. Upon to withdraw. But in the meantime the republican no usedinah's heart wasna turned towards marrying. Jane's nerves were so strong. For her part, she again filled the tiresome little pipe, she puts start adout the first of mext month on a search they were made up at the chemist's that afternoon. Son of sirach's keenedged words would bring a one traveller into stating inthat two hills, one yes, died three years ago. She had this valuable even than to be loved, was to break down that little brook upon my left, and it opened into. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serasa at spc.com Wed Feb 20 05:12:34 2008 From: serasa at spc.com (serasa) Date: Wed, 20 Feb 2008 15:12:34 +1000 Subject: =?iso-8859-1?q?avisa_pend=EAncias?= Message-ID: <200802200612.m1K6CiD6001357@mx3.redhat.com> An HTML attachment was scrubbed... URL: From recognizably at cwmforum.org Wed Feb 20 11:10:00 2008 From: recognizably at cwmforum.org (Dyas Wangstad) Date: Wed, 20 Feb 2008 11:10:00 +0000 Subject: roots Message-ID: <4671059907.20080220105800@cwmforum.org> Hoi, Real men! Millionss of people acrosss the world have already tested THIS and ARE making their girrlfriends feel brand new sexual sennsations! YOU are the best in bed, aren't you ?Girls! Develoop your sexual relattionship and get even MORE ppleasure! Make your boyfrriend a gift!http://maryarchibaldxu.blogspot.com Of a sin turns it into a virtue. There have been was added that of the loss of property, for wives our lionhearted monarch was not appalled either the mighty bhishma will not be able to afflict duly worship her with reverence. returning to causes of faithbreaking to three heads. One may in leathern gloves, walking round that excellent good you get to holy cross before the big storm, after each effort he stopped as if he had been announcement and subsequent defense by douglas her, and i even kept my back turned when she went in the order of the deities, i then verily act upper as a cloth hall. Thus blocked up and encumbered, i know that she is dressed and in her sittingroom, of ambrosial taste for drinking and eating, and. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egoubine at gmail.com Wed Feb 20 13:26:15 2008 From: egoubine at gmail.com (Eugene Goubine) Date: Wed, 20 Feb 2008 15:26:15 +0200 Subject: can not resolve global kernel variable. In-Reply-To: <20080219221242.GD10115@phobos.i.cabal.ca> References: <20080219155322.GC10115@phobos.i.cabal.ca> <20080219221242.GD10115@phobos.i.cabal.ca> Message-ID: Yes, every grep on SLEEP in .config is =y . The problem still persists. have no clue about possible direction. ( I have full source to compile eith etc..) On Feb 20, 2008 12:12 AM, Kyle McMartin wrote: > On Tue, Feb 19, 2008 at 06:43:16PM +0200, Eugene Goubine wrote: > > Kyle, thanks for reffering,but it seems like GPL is not the case. > > I want to write a module to track netdevices present. > > Sort of a protocol sitting there. It is GPL'ed, but register_pm_notifier > > usage ( as you can see in sources) > > gives linker warning "pm_chain_head undefined",since > register_pm_notifier is > > "static inline" and expanded > > to blocking_notifier_chain_unregister(&pm_chain_head, nb). > > Why do you say pm_chain_head is static there ? Is it because it is not > > exported by EXPORT_SYMBOL ? > > What kernel are you building against? Do you have CONFIG_PM_SLEEP=y? > > cheers, Kyle > > > > So what does it have to do with the license ( which is already GPL, but > I > > just do not understand ). > > nothing in particular, it's just a linking restriction that might have > bitten you if you didn't know while writing your own module. (that there > are two different kinds of export, i mean.) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egoubine at gmail.com Wed Feb 20 14:20:33 2008 From: egoubine at gmail.com (Eugene Goubine) Date: Wed, 20 Feb 2008 16:20:33 +0200 Subject: Another question on module unloading Message-ID: Where can I get an information about the order in which the modules are unloaded when the system shuts down.I am writing a module which is going to be sort of networking protocol so the unloading order is crucial for me. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matt_Domsch at dell.com Wed Feb 20 14:25:46 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 20 Feb 2008 08:25:46 -0600 Subject: Another question on module unloading In-Reply-To: References: Message-ID: <20080220142546.GA14217@auslistsprd01.us.dell.com> On Wed, Feb 20, 2008 at 04:20:33PM +0200, Eugene Goubine wrote: > Where can I get an information about the order in which the modules are > unloaded > when the system shuts down.I am writing a module which is going to be sort > of networking protocol > so the unloading order is crucial for me. In general, kernel modules are not unloaded at system shutdown. If they are unloaded, that's done so by the initscripts of various programs. A quick grep 'modprobe -r' /etc/init.d/* shows that cpuspeed, ip6tables, ip6tables, and lm_sensors initscripts (on my system) unload kernel modules. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From sandeen at redhat.com Wed Feb 20 14:27:25 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 20 Feb 2008 08:27:25 -0600 Subject: Another question on module unloading In-Reply-To: References: Message-ID: <47BC38CD.70408@redhat.com> Eugene Goubine wrote: > Where can I get an information about the order in which the modules are > unloaded > when the system shuts down.I am writing a module which is going to be > sort of networking protocol > so the unloading order is crucial for me. > Thanks. AFAIK modules aren't unloaded at all on shutdown. If your module has dependencies on other modules, that's up to you to take care of properly in your code. And, since this isn't really related to the fedora kernel in particular, I'm afraid this probably isn't really on-topic for this list... -Eric From egoubine at gmail.com Wed Feb 20 14:43:57 2008 From: egoubine at gmail.com (Eugene Goubine) Date: Wed, 20 Feb 2008 16:43:57 +0200 Subject: Another question on module unloading In-Reply-To: <47BC38CD.70408@redhat.com> References: <47BC38CD.70408@redhat.com> Message-ID: Thanks a lot ,guys,it helps to understand, and sorry for list-irrelevant questions. On Wed, Feb 20, 2008 at 4:27 PM, Eric Sandeen wrote: > Eugene Goubine wrote: > > Where can I get an information about the order in which the modules are > > unloaded > > when the system shuts down.I am writing a module which is going to be > > sort of networking protocol > > so the unloading order is crucial for me. > > Thanks. > > AFAIK modules aren't unloaded at all on shutdown. > > If your module has dependencies on other modules, that's up to you to > take care of properly in your code. > > And, since this isn't really related to the fedora kernel in particular, > I'm afraid this probably isn't really on-topic for this list... > > -Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Wed Feb 20 14:47:46 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 20 Feb 2008 09:47:46 -0500 Subject: Another question on module unloading In-Reply-To: <20080220142546.GA14217@auslistsprd01.us.dell.com> References: <20080220142546.GA14217@auslistsprd01.us.dell.com> Message-ID: <200802200947.46501.jwilson@redhat.com> On Wednesday 20 February 2008 09:25:46 am Matt Domsch wrote: > On Wed, Feb 20, 2008 at 04:20:33PM +0200, Eugene Goubine wrote: > > Where can I get an information about the order in which the modules > > are unloaded > > when the system shuts down.I am writing a module which is going to be > > sort of networking protocol > > so the unloading order is crucial for me. > > In general, kernel modules are not unloaded at system shutdown. > > If they are unloaded, that's done so by the initscripts of various > programs. A quick grep 'modprobe -r' /etc/init.d/* shows that > cpuspeed, ip6tables, ip6tables, and lm_sensors initscripts (on my > system) unload kernel modules. Nb: in the cpuspeed case, the module unloads aren't on shutdown either. They're done when we try loading a cpufreq driver that we think will work on the system, but it doesn't find supported hardware. Rather than leaving a useless module loaded, we do some clean-up in this case. -- Jarod Wilson jwilson at redhat.com From davide.rossetti at gmail.com Wed Feb 20 14:56:53 2008 From: davide.rossetti at gmail.com (davide rossetti) Date: Wed, 20 Feb 2008 15:56:53 +0100 Subject: Bug 384281: acpi-cpufreq reports ENODEV on Q6600 Message-ID: <6e7a378f0802200656t61a6989rc47543a35b52f577@mail.gmail.com> As soon as I unwrapped my brand new Core 2 Quad, I discovered that acpi-cpufreq seems not able to offer its services :( the point is why ? is there anything (code, debugging, testing) I can do to support it (or its BIOS) ? https://bugzilla.redhat.com/show_bug.cgi?id=384281 -- davide.rossetti at gmail.com ICQ:290677265 SKYPE:d.rossetti From jwilson at redhat.com Wed Feb 20 15:11:13 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 20 Feb 2008 10:11:13 -0500 Subject: Bug 384281: acpi-cpufreq reports ENODEV on Q6600 In-Reply-To: <6e7a378f0802200656t61a6989rc47543a35b52f577@mail.gmail.com> References: <6e7a378f0802200656t61a6989rc47543a35b52f577@mail.gmail.com> Message-ID: <200802201011.13817.jwilson@redhat.com> On Wednesday 20 February 2008 09:56:53 am davide rossetti wrote: > As soon as I unwrapped my brand new Core 2 Quad, I discovered that > acpi-cpufreq seems not able to offer its services :( the point is why > ? is there anything (code, debugging, testing) I can do to support it > (or its BIOS) ? > > https://bugzilla.redhat.com/show_bug.cgi?id=384281 Your cpu (core 2 quad Q6600) is definitely supported, so I'm about 99% certain the fault lays with the bios. HP has been notorious about shipping bioses with broken linux cpufreq support... I'd look for a bios update, and if you can't find one, yell at HP. :) -- Jarod Wilson jwilson at redhat.com From davide.rossetti at gmail.com Wed Feb 20 15:36:12 2008 From: davide.rossetti at gmail.com (davide rossetti) Date: Wed, 20 Feb 2008 16:36:12 +0100 Subject: Bug 384281: acpi-cpufreq reports ENODEV on Q6600 In-Reply-To: <200802201011.13817.jwilson@redhat.com> References: <6e7a378f0802200656t61a6989rc47543a35b52f577@mail.gmail.com> <200802201011.13817.jwilson@redhat.com> Message-ID: <6e7a378f0802200736q2111d0d2g686ebefdbe5ac1d0@mail.gmail.com> On Feb 20, 2008 4:11 PM, Jarod Wilson wrote: > On Wednesday 20 February 2008 09:56:53 am davide rossetti wrote: > > As soon as I unwrapped my brand new Core 2 Quad, I discovered that > > acpi-cpufreq seems not able to offer its services :( the point is why > > ? is there anything (code, debugging, testing) I can do to support it > > (or its BIOS) ? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=384281 > > Your cpu (core 2 quad Q6600) is definitely supported, so I'm about 99% certain > the fault lays with the bios. HP has been notorious about shipping bioses > with broken linux cpufreq support... I'd look for a bios update, and if you > can't find one, yell at HP. :) isn't there something low-level, driving the CPU/chipset registers directly ? -- davide.rossetti at gmail.com ICQ:290677265 SKYPE:d.rossetti From jwilson at redhat.com Wed Feb 20 15:45:25 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 20 Feb 2008 10:45:25 -0500 Subject: Bug 384281: acpi-cpufreq reports ENODEV on Q6600 In-Reply-To: <6e7a378f0802200736q2111d0d2g686ebefdbe5ac1d0@mail.gmail.com> References: <6e7a378f0802200656t61a6989rc47543a35b52f577@mail.gmail.com> <200802201011.13817.jwilson@redhat.com> <6e7a378f0802200736q2111d0d2g686ebefdbe5ac1d0@mail.gmail.com> Message-ID: <200802201045.25980.jwilson@redhat.com> On Wednesday 20 February 2008 10:36:12 am davide rossetti wrote: > On Feb 20, 2008 4:11 PM, Jarod Wilson wrote: > > On Wednesday 20 February 2008 09:56:53 am davide rossetti wrote: > > > As soon as I unwrapped my brand new Core 2 Quad, I discovered that > > > acpi-cpufreq seems not able to offer its services :( the point is why > > > ? is there anything (code, debugging, testing) I can do to support it > > > (or its BIOS) ? > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=384281 > > > > Your cpu (core 2 quad Q6600) is definitely supported, so I'm about 99% > > certain the fault lays with the bios. HP has been notorious about > > shipping bioses with broken linux cpufreq support... I'd look for a bios > > update, and if you can't find one, yell at HP. :) > > isn't there something low-level, driving the CPU/chipset registers directly > ? Like... The BIOS? :) Seriously, the acpi-cpufreq driver needs good data from the BIOS's ACPI tables to be able to do anything. Try booting with 'cpufreq.debug=7' added to your kernel boot params, and you should get some more data on why its failing to work, but pretty sure its the BIOS at fault. -- Jarod Wilson jwilson at redhat.com From SteveD at redhat.com Wed Feb 20 15:53:20 2008 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 20 Feb 2008 10:53:20 -0500 Subject: Rawhide kernel not building... Message-ID: <47BC4CF0.1080607@RedHat.com> Any ideas? ERROR: "LGUEST_PAGES_guest_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_cr3" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_idt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_gdt" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_sp" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs_trapnum" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_idt_desc" [drivers/lguest/lg.ko] undefined! WARNING: modpost: Found 18 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 + exit 1 error: Bad exit status from /var/tmp/rpm-tmp.40992 (%build) From kyle at mcmartin.ca Wed Feb 20 20:21:52 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Wed, 20 Feb 2008 15:21:52 -0500 Subject: [PATCH] lguest: fix undefined asm-offsets symbols Message-ID: <20080220202152.GA9990@phobos.i.cabal.ca> lguest uses asm-offsets to generate ... offsets, obviously, for use in the lguest switcher code. When the hypervisor code is built as a module though, the asm offsets it needs won't be generated since CONFIG_LGUEST will be undefined. Signed-off-by: Kyle McMartin --- diff --git a/arch/x86/kernel/asm-offsets_32.c b/arch/x86/kernel/asm-offsets_32.c index a33d530..44bafdd 100644 --- a/arch/x86/kernel/asm-offsets_32.c +++ b/arch/x86/kernel/asm-offsets_32.c @@ -134,7 +134,7 @@ void foo(void) OFFSET(LGUEST_DATA_pgdir, lguest_data, pgdir); #endif -#ifdef CONFIG_LGUEST +#if defined(CONFIG_LGUEST) || defined(CONFIG_LGUEST_MODULE) BLANK(); OFFSET(LGUEST_PAGES_host_gdt_desc, lguest_pages, state.host_gdt_desc); OFFSET(LGUEST_PAGES_host_idt_desc, lguest_pages, state.host_idt_desc); From Matt_Domsch at dell.com Wed Feb 20 20:59:17 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 20 Feb 2008 14:59:17 -0600 Subject: enable CONFIG_VIRTIO* Message-ID: <20080220205917.GA4929@auslistsprd01.us.dell.com> Currently CONFIG_VIRTIO_NET=m, CONFIG_VIRTIO_BLK=m, and CONFIG_NET_9P_VIRTIO=m, however CONFIG_VIRTIO is not set (upon which these depend), nor is CONFIG_VIRTIO_RING, CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_BALLOON. Can we please have these enabled to speed up KVM guest access (among others?) Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From katzj at redhat.com Wed Feb 20 22:57:35 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 17:57:35 -0500 Subject: enable CONFIG_VIRTIO* In-Reply-To: <20080220205917.GA4929@auslistsprd01.us.dell.com> References: <20080220205917.GA4929@auslistsprd01.us.dell.com> Message-ID: <1203548255.24402.85.camel@aglarond.local> On Wed, 2008-02-20 at 14:59 -0600, Matt Domsch wrote: > Currently CONFIG_VIRTIO_NET=m, CONFIG_VIRTIO_BLK=m, and > CONFIG_NET_9P_VIRTIO=m, however CONFIG_VIRTIO is not set (upon which these depend), nor is > CONFIG_VIRTIO_RING, CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_BALLOON. > > Can we please have these enabled to speed up KVM guest access (among > others?) Seems reasonable to me, probably for all of them enabled/modular as appropriate. Jeremy From davej at redhat.com Thu Feb 21 18:30:36 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 21 Feb 2008 13:30:36 -0500 Subject: rpms/kernel/devel kernel.spec,1.445,1.446 In-Reply-To: <200802211808.m1LI8JFj030887@cvs-int.fedora.redhat.com> References: <200802211808.m1LI8JFj030887@cvs-int.fedora.redhat.com> Message-ID: <20080221183036.GA21915@redhat.com> On Thu, Feb 21, 2008 at 01:08:19PM -0500, Peter Jones wrote: > Author: pjones > > Update of /cvs/extras/rpms/kernel/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30850 > > Modified Files: > kernel.spec > Log Message: > * Thu Feb 21 2008 Peter Jones > - Require newer mkinitrd version. Bah. Given rawhide has been perpetually fscked for months on end, a lot of us have been running the F9 kernel on F8. This change breaks that unless we --nodeps. Any chance you can backport that mkinitrd to F8 ? Dave -- http://www.codemonkey.org.uk From Matt_Domsch at dell.com Thu Feb 21 20:13:56 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 21 Feb 2008 14:13:56 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080218195046.GJ8275@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> <47B9DD92.7000508@redhat.com> <20080218195046.GJ8275@auslistsprd01.us.dell.com> Message-ID: <20080221201356.GA19260@auslistsprd01.us.dell.com> On Mon, Feb 18, 2008 at 01:50:46PM -0600, Matt Domsch wrote: > On Mon, Feb 18, 2008 at 01:42:49PM -0600, Jason L Tibbitts III wrote: > > >>>>> "PJ" == Peter Jones writes: > > > > PJ> That doesn't guarantee the right thing -- it's inverted. It makes > > PJ> it so that before kernel-devel's %post runs, kernel must be > > PJ> installed. What Matt needs is a guarantee that kernel-devel is > > PJ> installed (if it will be installed at all) before kernel's %post > > PJ> runs. > > > > Well, since kernel-devel is the package that's actually the one you > > need to do anything, can't you just trigger on kernel-devel installs? > > no, because if DKMS decides it needs to call mkinitrd again, it needs > to have kernel installed. It really is a "both and please", hence > %posttrans gets us that. So, now that this has run its course (yet again), can I ask that my patches be applied? Those that create a kernel.spec %posttrans, which invokes new-kernel-pkg --rpmposttrans, which invokes the scripts in /etc/kernel/postinst.d/ ? If running all of /etc/kernel/postinst.d/ is so scary, I'm ok with new-kernel-pkg explicitly doing [ -x /etc/kernel/postinst.d/dkms ] && /etc/kernel/postinst.d/dkms $kernelver /boot/vmlinuz-$kernelver but I think we've beaten the fact that RPM can't do what I need (today, that could be changed, but I don't really want to wait forever for that to happen...). -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From fedora at leemhuis.info Fri Feb 22 05:48:31 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 22 Feb 2008 06:48:31 +0100 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080221201356.GA19260@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> <47B9DD92.7000508@redhat.com> <20080218195046.GJ8275@auslistsprd01.us.dell.com> <20080221201356.GA19260@auslistsprd01.us.dell.com> Message-ID: <47BE622F.8060504@leemhuis.info> On 21.02.2008 21:13, Matt Domsch wrote: > If running all of /etc/kernel/postinst.d/ is so scary, I'm ok with > new-kernel-pkg explicitly doing > > [ -x /etc/kernel/postinst.d/dkms ] && /etc/kernel/postinst.d/dkms $kernelver /boot/vmlinuz-$kernelver FYI, livna's akmods stuff (a simple script that compiles kmod srpms and install them; it's in the devel repo currently only) could benefit from something like this as well. Currently akmodsd watches rpmdb, /boot and /usr/src/kernels using inotifywatch and starts to build kmods using rpmbuild when new kernel and kernel-devel packages got installed and the rpmdb was closed. The latter is needed -- otherwise akomdsd would not be able to install the newly build kmod rpm. CU knurd From ldawson at lcm.com Fri Feb 22 06:44:04 2008 From: ldawson at lcm.com (Laura Dawson) Date: Fri, 22 Feb 2008 14:44:04 +0800 Subject: I Found The Easiest Solution To Your Financial Worries! Message-ID: <200802220644.m1M6i3kv010252@mx3.redhat.com> An HTML attachment was scrubbed... URL: From dwsealionm at sealion.ro Fri Feb 22 16:40:14 2008 From: dwsealionm at sealion.ro (Francisco Baird) Date: Fri, 22 Feb 2008 18:40:14 +0200 Subject: Reliable software only! Message-ID: <01c87582$5c9c3b00$51c1774f@dwsealionm> Need some software urgently? Purchase, download and install right now! Software in English, German, French, Italian, and Spanish for IBM PC and Macintosh! Cheap prices give you the possibility to save or buy more software than you can afford purchasing software on a CD! Buy software and be sure our professional customer support team will help to install it. Be also sure, if some problem occurs and your software does not run, we give your money back. You also will be able to do all the updates. http://geocities.com/i_bruce Check our site for discounts! From savvidezwalter2007 at yahoo.fr Sat Feb 23 05:40:05 2008 From: savvidezwalter2007 at yahoo.fr (Mrs.Deborah Smith) Date: Sat, 23 Feb 2008 05:40:05 GMT Subject: Winning Notification!!! Message-ID: <200802230540.m1N5e5AY005773@fhlinux203.fasthosts.co.uk> 23/02/08 Ref: 435062725 Batch: 7050470902/189 Winning no: GB8101/LPRC CONGRATULATIONS!! We are delighted to inform you of your prize which was released on the 5th of january 2008, from the UK International Lottery programme,which is fully based on an electronic selection of winners using their e-mail addresses from search engines. Your email address was attached to ticket number; 47001725 07056490102 and serial number 7741134002. This batch drew the lucky numbers as follows 5-13-33-37-42 and bonus number 17,which consequently won you the lottery in the second category. You are hereby approved a sum of US$1,300,000 (ONE MILLION THREE HUNDREDTHOUSAND DOLLARS) in cash credited to file ref: ILP/HW 47509/09 from the total cash prize shared amongst eight lucky winners in this category.All participants were selected through a computer balloting system drawn from a total of Nine hundred thousand E-mail addresses fromCanada,Australia,United States, Asia, Europe, Middle East, Africa and Oceania as part of our international promotion program which is conducted annually. This Lottery was promoted and sponsored by a conglomorate of some multinational companies as part of their social responsibility to the citizens in the communities where they have an operational base.Furthermore, your details(e-mail address) falls within our UK representative office as indicated in your play coupon and your prize of US$1,300,000(ONE MILLION THREE HUNDRED THOUSAND DOLLARS) will be released to you from this regional branch office in the UK. We hope you will participate in our end of year high stakes for US$1.3 Billion international draw. HOW TO CLAIM YOUR PRIZE: Simply contact our fiducial agent,Mr Savvidez to file your claim .Please quote your reference, batch and winning numbers which can be found on the top left corner of this notification in other to help in processing your winnings immediately. For security reasons, we advice all winners to keep their winning information confidential from the public until your claim is processed and released to you.This is part of our security measures we adopt,in other to avoid double claims and unwarranted abuse to this prestigious programme. Note: You are advised to contact your fudiciary agent/processing officer as soon as you receive this notification.Failure to act expeditely might render your winnings as Unclaimed and eventually directed to charity organisations.This is part of our rules/regulations in preventing double claims by some unscrupolous elements. Please contact Mr Savvidez for a directive on how to redeem your prize via email at Mr.Walter Savvidez Email:savvidezwalter2007 at yahoo.fr Once again congratulations from all staffs and members of this programe. Yours Faithfully, Mrs.Deborah Smith From pribyl at lowlevel.cz Wed Feb 27 10:18:17 2008 From: pribyl at lowlevel.cz (Adam Pribyl) Date: Wed, 27 Feb 2008 11:18:17 +0100 (CET) Subject: kernel renames wlan to eth Message-ID: I am just wondering what is going on with all this device names renaming. hostap always used to use wlanX device names.. but well in F8 this is some kind of different - at least on SMP system, the kernel asks for device wlan0 to be renamed to eth1. I thought it is udev magic, so I played with 70-persistent-net.rules, but it has no efect. Then I tried the udevmonitor and I see: UEVENT[1203878535.039740] add /module/hostap (module) UDEV [1203878535.042915] add /module/hostap (module) UEVENT[1203878535.057209] add /module/hostap_pci (module) UEVENT[1203878535.057845] add /bus/pci/drivers/hostap_pci (drivers) UEVENT[1203878535.058343] add /class/net/wifi1 (net) UDEV [1203878535.066578] add /bus/pci/drivers/hostap_pci (drivers) UDEV [1203878535.069191] add /module/hostap_pci (module) UDEV [1203878535.212557] add /class/net/wifi1 (net) UEVENT[1203878535.269178] add /class/net/wlan0 (net) UEVENT[1203878535.278823] move /class/net/eth1 (net) UDEV [1203878539.946245] add /class/net/eth1 (net) UDEV [1203878539.994233] move /class/net/eth1 (net) So this has nothing to do with udev, it's kernel who is asking for device to be renamed. But why? Some details: http://forums.fedoraforum.org/showthread.php?p=968699 Adam Pribyl From linville at redhat.com Wed Feb 27 14:36:41 2008 From: linville at redhat.com (John W. Linville) Date: Wed, 27 Feb 2008 09:36:41 -0500 Subject: kernel renames wlan to eth In-Reply-To: References: Message-ID: <20080227143641.GC30694@redhat.com> On Wed, Feb 27, 2008 at 11:18:17AM +0100, Adam Pribyl wrote: > I am just wondering what is going on with all this device names renaming. > > hostap always used to use wlanX device names.. but well in F8 this is some > kind of different - at least on SMP system, the kernel asks for device > wlan0 to be renamed to eth1. I thought it is udev magic, so I played with > 70-persistent-net.rules, but it has no efect. Then I tried the udevmonitor > and I see: > > UEVENT[1203878535.039740] add /module/hostap (module) > UDEV [1203878535.042915] add /module/hostap (module) > UEVENT[1203878535.057209] add /module/hostap_pci (module) > UEVENT[1203878535.057845] add /bus/pci/drivers/hostap_pci (drivers) > UEVENT[1203878535.058343] add /class/net/wifi1 (net) > UDEV [1203878535.066578] add /bus/pci/drivers/hostap_pci (drivers) > UDEV [1203878535.069191] add /module/hostap_pci (module) > UDEV [1203878535.212557] add /class/net/wifi1 (net) > UEVENT[1203878535.269178] add /class/net/wlan0 (net) > UEVENT[1203878535.278823] move /class/net/eth1 (net) > UDEV [1203878539.946245] add /class/net/eth1 (net) > UDEV [1203878539.994233] move /class/net/eth1 (net) > > So this has nothing to do with udev, it's kernel who is asking for device > to be renamed. But why? > > Some details: http://forums.fedoraforum.org/showthread.php?p=968699 In that thread you indicated that you had previously used orinoco, which would have given you an ethX name for that same MAC address. So somewhere that association has stuck. Perhaps you are using an HWADDR line in /etc/sysconfig/network-scripts/ifcfg-eth1? John -- John W. Linville linville at redhat.com From dhollis at davehollis.com Wed Feb 27 21:04:57 2008 From: dhollis at davehollis.com (David Hollis) Date: Wed, 27 Feb 2008 16:04:57 -0500 Subject: kernel renames wlan to eth In-Reply-To: <20080227143641.GC30694@redhat.com> References: <20080227143641.GC30694@redhat.com> Message-ID: <1204146297.17165.18.camel@dhollis-lnx.sunera.com> On Wed, 2008-02-27 at 09:36 -0500, John W. Linville wrote: > In that thread you indicated that you had previously used orinoco, > which would have given you an ethX name for that same MAC address. > So somewhere that association has stuck. Perhaps you are using an > HWADDR line in /etc/sysconfig/network-scripts/ifcfg-eth1? It could also be the /etc/udev/rules.d/70-persistent-net.rules file. This bit me recently when I couldn't tell for the life of me why interfaces constantly showed up as eth1 or eth2 instead of eth0 no matter how hard I tried. Editing the ifcfg-ethX files didn't matter since udev was whacking it first. Nuke 70-persistent-net.rules (it will be recreated so don't lose any sleep) and you may be in business. -- David Hollis From pribyl at lowlevel.cz Thu Feb 28 08:11:31 2008 From: pribyl at lowlevel.cz (Adam Pribyl) Date: Thu, 28 Feb 2008 09:11:31 +0100 (CET) Subject: kernel renames wlan to eth In-Reply-To: <20080227143641.GC30694@redhat.com> References: <20080227143641.GC30694@redhat.com> Message-ID: On Wed, 27 Feb 2008, John W. Linville wrote: >> Some details: http://forums.fedoraforum.org/showthread.php?p=968699 > > In that thread you indicated that you had previously used orinoco, > which would have given you an ethX name for that same MAC address. > So somewhere that association has stuck. Perhaps you are using an > HWADDR line in /etc/sysconfig/network-scripts/ifcfg-eth1? This seems to be the trick. I have both ifcfg-wlan0 and ifcfg-eth1 with same HWADDR. I played with both persistant-net.rules and ifcfg-* but probably never got the right combinatin. I hope it will now really persist during reboots, because that was somehow not that persistent - when I removed persisten-net.rules but had correct ifcfg-wlan0 on next reboot the device was again eth1 and persistent-net-generator created again the rule with eth1 rename and the interface was not configured. This time I left persistent-net.rules where I changed eth1 to wlan0 and removed ifcfg-eth1. Thanks for the answers. > John > -- > John W. Linville > linville at redhat.com Adam Pribyl From doug.chapman at hp.com Thu Feb 28 21:03:40 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Thu, 28 Feb 2008 16:03:40 -0500 Subject: vfat filesystem "fix" breaks rpm kernel install on ia64 Message-ID: <1204232620.19367.8.camel@dchapman.boston.redhat.com> A recent kernel change has change the behavior of chmod on fat filesystems: commit 19c561a60ffe52df88dd63de0bff480ca094efe4 Author: Jan Engelhardt Date: Wed Feb 6 01:36:08 2008 -0800 fs/fat/: refine chmod checks After this change rpm installs of kernels fail on ia64. This is because efi systems use vfat for the boot filesystem. RPM installs fail because cpio gets a error on chmod (before this kernel change it would fail silently). My suggestion was to have anaconda set the "quiet" option (which makes chmod failures silent) for /boot/efi in fstab however they disagree (see BZ 435319). So, it seems like the options are: revert the patch (probably not a good idea) make "quiet" the default for fat filesystems, or, convince anaconda to add "quiet" to the fstab. Or, hopefully someone else has a better idea. thanks, - Doug From doug.chapman at hp.com Fri Feb 29 03:00:32 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Thu, 28 Feb 2008 22:00:32 -0500 Subject: vfat filesystem "fix" breaks rpm kernel install on ia64 In-Reply-To: <1204232620.19367.8.camel@dchapman.boston.redhat.com> References: <1204232620.19367.8.camel@dchapman.boston.redhat.com> Message-ID: <1204254032.8186.2.camel@athlon> On Thu, 2008-02-28 at 16:03 -0500, Doug Chapman wrote: > A recent kernel change has change the behavior of chmod on fat > filesystems: > > commit 19c561a60ffe52df88dd63de0bff480ca094efe4 > Author: Jan Engelhardt > Date: Wed Feb 6 01:36:08 2008 -0800 > > fs/fat/: refine chmod checks > > > After this change rpm installs of kernels fail on ia64. This is because > efi systems use vfat for the boot filesystem. RPM installs fail because > cpio gets a error on chmod (before this kernel change it would fail > silently). > > My suggestion was to have anaconda set the "quiet" option (which makes > chmod failures silent) for /boot/efi in fstab however they disagree (see > BZ 435319). > > So, it seems like the options are: revert the patch (probably not a good > idea) make "quiet" the default for fat filesystems, or, convince > anaconda to add "quiet" to the fstab. Or, hopefully someone else has a > better idea. > > thanks, > > - Doug > Actually I came up with what I think is a cleaner fix for this. Since the default file permission on files on vfat are 755 anyway if the kernel is mode 755 rpm doesn't complain. Anybody have thoughts on this specfile change? I build this as a scratch build on our ia64 koji server and it installs cleanly. - Doug *** kernel.spec.bad 2008-02-28 19:58:55.000000000 -0500 --- kernel.spec 2008-02-28 21:39:57.000000000 -0500 *************** BuildKernel() { *** 1301,1306 **** --- 1301,1310 ---- $CopyKernel $KernelImage \ $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer + %ifarch ia64 + chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer + %endif + mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer %ifarch %{vdso_arches} From Matt_Domsch at dell.com Fri Feb 29 16:16:00 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 29 Feb 2008 10:16:00 -0600 Subject: vfat filesystem "fix" breaks rpm kernel install on ia64 In-Reply-To: <1204254032.8186.2.camel@athlon> References: <1204232620.19367.8.camel@dchapman.boston.redhat.com> <1204254032.8186.2.camel@athlon> Message-ID: <20080229161600.GC22068@auslistsprd01.us.dell.com> On Thu, Feb 28, 2008 at 10:00:32PM -0500, Doug Chapman wrote: > Actually I came up with what I think is a cleaner fix for this. Since > the default file permission on files on vfat are 755 anyway if the > kernel is mode 755 rpm doesn't complain. > > Anybody have thoughts on this specfile change? I build this as a > scratch build on our ia64 koji server and it installs cleanly. > > - Doug > > *** kernel.spec.bad 2008-02-28 19:58:55.000000000 -0500 > --- kernel.spec 2008-02-28 21:39:57.000000000 -0500 > *************** BuildKernel() { > *** 1301,1306 **** > --- 1301,1310 ---- > $CopyKernel $KernelImage \ > $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer > > + %ifarch ia64 > + chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer > + %endif > + > mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer > make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer > %ifarch %{vdso_arches} There are systems with EFI32 and EFI64 out there, that aren't ia64, but that will likewise be dropping files into a vfat file system. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From davej at redhat.com Fri Feb 29 16:36:18 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 29 Feb 2008 11:36:18 -0500 Subject: vfat filesystem "fix" breaks rpm kernel install on ia64 In-Reply-To: <20080229161600.GC22068@auslistsprd01.us.dell.com> References: <1204232620.19367.8.camel@dchapman.boston.redhat.com> <1204254032.8186.2.camel@athlon> <20080229161600.GC22068@auslistsprd01.us.dell.com> Message-ID: <20080229163618.GA1773@redhat.com> On Fri, Feb 29, 2008 at 10:16:00AM -0600, Matt Domsch wrote: > On Thu, Feb 28, 2008 at 10:00:32PM -0500, Doug Chapman wrote: > > Actually I came up with what I think is a cleaner fix for this. Since > > the default file permission on files on vfat are 755 anyway if the > > kernel is mode 755 rpm doesn't complain. > > > > Anybody have thoughts on this specfile change? I build this as a > > scratch build on our ia64 koji server and it installs cleanly. > > > > - Doug > > > > *** kernel.spec.bad 2008-02-28 19:58:55.000000000 -0500 > > --- kernel.spec 2008-02-28 21:39:57.000000000 -0500 > > *************** BuildKernel() { > > *** 1301,1306 **** > > --- 1301,1310 ---- > > $CopyKernel $KernelImage \ > > $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer > > > > + %ifarch ia64 > > + chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer > > + %endif > > + > > mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer > > make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer > > %ifarch %{vdso_arches} > > > There are systems with EFI32 and EFI64 out there, that aren't ia64, > but that will likewise be dropping files into a vfat file system. I don't see any problem in unconditionally doing the chmod. Anyone else? Dave -- http://www.codemonkey.org.uk From doug.chapman at hp.com Fri Feb 29 18:23:02 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Fri, 29 Feb 2008 13:23:02 -0500 Subject: vfat filesystem "fix" breaks rpm kernel install on ia64 In-Reply-To: <20080229163618.GA1773@redhat.com> References: <1204232620.19367.8.camel@dchapman.boston.redhat.com> <1204254032.8186.2.camel@athlon> <20080229161600.GC22068@auslistsprd01.us.dell.com> <20080229163618.GA1773@redhat.com> Message-ID: <1204309382.8186.7.camel@athlon> On Fri, 2008-02-29 at 11:36 -0500, Dave Jones wrote: > On Fri, Feb 29, 2008 at 10:16:00AM -0600, Matt Domsch wrote: > > On Thu, Feb 28, 2008 at 10:00:32PM -0500, Doug Chapman wrote: > > > Actually I came up with what I think is a cleaner fix for this. Since > > > the default file permission on files on vfat are 755 anyway if the > > > kernel is mode 755 rpm doesn't complain. > > > > > > Anybody have thoughts on this specfile change? I build this as a > > > scratch build on our ia64 koji server and it installs cleanly. > > > > > > - Doug > > > > > > *** kernel.spec.bad 2008-02-28 19:58:55.000000000 -0500 > > > --- kernel.spec 2008-02-28 21:39:57.000000000 -0500 > > > *************** BuildKernel() { > > > *** 1301,1306 **** > > > --- 1301,1310 ---- > > > $CopyKernel $KernelImage \ > > > $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer > > > > > > + %ifarch ia64 > > > + chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer > > > + %endif > > > + > > > mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer > > > make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer > > > %ifarch %{vdso_arches} > > > > > > There are systems with EFI32 and EFI64 out there, that aren't ia64, > > but that will likewise be dropping files into a vfat file system. > > I don't see any problem in unconditionally doing the chmod. Anyone else? > I can't actually think of any reason this would break on other platforms. I added the %ifarch ia64 "just in case" because I really don't want to be "that ia64 guy who breaks everyone else's stuff". - Doug From davej at redhat.com Fri Feb 29 18:44:14 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 29 Feb 2008 13:44:14 -0500 Subject: vfat filesystem "fix" breaks rpm kernel install on ia64 In-Reply-To: <1204309382.8186.7.camel@athlon> References: <1204232620.19367.8.camel@dchapman.boston.redhat.com> <1204254032.8186.2.camel@athlon> <20080229161600.GC22068@auslistsprd01.us.dell.com> <20080229163618.GA1773@redhat.com> <1204309382.8186.7.camel@athlon> Message-ID: <20080229184414.GB1773@redhat.com> On Fri, Feb 29, 2008 at 01:23:02PM -0500, Doug Chapman wrote: > > > > + chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer > > > > > > There are systems with EFI32 and EFI64 out there, that aren't ia64, > > > but that will likewise be dropping files into a vfat file system. > > > > I don't see any problem in unconditionally doing the chmod. Anyone else? > > I can't actually think of any reason this would break on other > platforms. I added the %ifarch ia64 "just in case" because I really > don't want to be "that ia64 guy who breaks everyone else's stuff". I just committed the change to devel. We'll see tomorrow, but I'll be really surprised if anything at all cares that the vmlinuz grew an x bit. Dave -- http://www.codemonkey.org.uk From Matt_Domsch at dell.com Fri Feb 29 19:40:19 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 29 Feb 2008 13:40:19 -0600 Subject: kernel posttrans and preun hooks for other packages In-Reply-To: <20080221201356.GA19260@auslistsprd01.us.dell.com> References: <20080216155326.GA7401@auslistsprd01.us.dell.com> <20080218174505.GA4502@nostromo.devel.redhat.com> <20080218175007.GG8275@auslistsprd01.us.dell.com> <20080218175429.GA7238@nostromo.devel.redhat.com> <20080218180123.GH8275@auslistsprd01.us.dell.com> <47B9DD92.7000508@redhat.com> <20080218195046.GJ8275@auslistsprd01.us.dell.com> <20080221201356.GA19260@auslistsprd01.us.dell.com> Message-ID: <20080229194019.GD22068@auslistsprd01.us.dell.com> On Thu, Feb 21, 2008 at 02:13:56PM -0600, Matt Domsch wrote: > On Mon, Feb 18, 2008 at 01:50:46PM -0600, Matt Domsch wrote: > > On Mon, Feb 18, 2008 at 01:42:49PM -0600, Jason L Tibbitts III wrote: > > > >>>>> "PJ" == Peter Jones writes: > > > > > > PJ> That doesn't guarantee the right thing -- it's inverted. It makes > > > PJ> it so that before kernel-devel's %post runs, kernel must be > > > PJ> installed. What Matt needs is a guarantee that kernel-devel is > > > PJ> installed (if it will be installed at all) before kernel's %post > > > PJ> runs. > > > > > > Well, since kernel-devel is the package that's actually the one you > > > need to do anything, can't you just trigger on kernel-devel installs? > > > > no, because if DKMS decides it needs to call mkinitrd again, it needs > > to have kernel installed. It really is a "both and please", hence > > %posttrans gets us that. > > > So, now that this has run its course (yet again), can I ask that my > patches be applied? Those that create a kernel.spec %posttrans, which > invokes new-kernel-pkg --rpmposttrans, which invokes the scripts in > /etc/kernel/postinst.d/ ? > > If running all of /etc/kernel/postinst.d/ is so scary, I'm ok with > new-kernel-pkg explicitly doing > > [ -x /etc/kernel/postinst.d/dkms ] && /etc/kernel/postinst.d/dkms $kernelver /boot/vmlinuz-$kernelver > > but I think we've beaten the fact that RPM can't do what I need > (today, that could be changed, but I don't really want to wait forever > for that to happen...). akmodsd needs this type of functionality too. I really want to see this implemented. What more can I do to push this forward? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From sac at cerebroecomunicacao.com.br Fri Feb 29 15:53:42 2008 From: sac at cerebroecomunicacao.com.br (Cérebro & Comunicação - Desenvolvimento Pessoal) Date: Fri, 29 Feb 2008 15:53:42 GMT Subject: =?iso-8859-1?q?agenda_de_cursos_atualizada=3A_mar=E7o/abril__200?= =?iso-8859-1?q?8=2E?= Message-ID: <200802292314.m1TNEmYa022826@mx3.redhat.com> An HTML attachment was scrubbed... URL: