Re: [GIT PATCH] driver core patches against 2.6.24
On Sunday 27 January 2008 17:42:28 Linus Torvalds wrote: > My problem is that the *driver* already exists (because it's compiled in), > and has already initialized itself, and has already registered. > > Then, initrd tries to load an old module for that driver. I hate to say it, but this is user error. And it used to be that for some drivers you'd actually end up with two in-kernel if you did that. But if even *you* don't get this right, it should finally prompt us to fix this... Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
Peter Zijlstra wrote: My wish is that distros would just boot without requiring an initrd. I know how to make them for redhat and debian based distros, but the fact that you can't (easily) cross-build them makes it a very tedious construct. Debian is easy enough - make sure the drivers for the root device and root fs is built-in, and you can drop the initrd. Takes a second or two off the boot, and some more off the build. Helge Hafting -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Sunday 27 January 2008 17:42:28 Linus Torvalds wrote: My problem is that the *driver* already exists (because it's compiled in), and has already initialized itself, and has already registered. Then, initrd tries to load an old module for that driver. I hate to say it, but this is user error. And it used to be that for some drivers you'd actually end up with two in-kernel if you did that. But if even *you* don't get this right, it should finally prompt us to fix this... Thanks, Rusty. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
Peter Zijlstra wrote: My wish is that distros would just boot without requiring an initrd. I know how to make them for redhat and debian based distros, but the fact that you can't (easily) cross-build them makes it a very tedious construct. Debian is easy enough - make sure the drivers for the root device and root fs is built-in, and you can drop the initrd. Takes a second or two off the boot, and some more off the build. Helge Hafting -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Sat, 26 Jan 2008, Rusty Russell wrote:
>
> module.c:1832 (in load_module)
>
> if (find_module(mod->name)) {
> err = -EEXIST;
> goto free_mod;
> }
>
> That's pretty early, and before this backtrace.
>
> Even for simultaneous loads, there's a mutex which protects from here to the
> list insertion.
My problem isn't trying to load the same module twice.
My problem is that the *driver* already exists (because it's compiled in),
and has already initialized itself, and has already registered.
Then, initrd tries to load an old module for that driver.
So no simultaneous loading, no two modules, simple two *drivers* with the
same module names - but one was compiled in, and the other will fail
because it doesn't have the required linkages (ie it will failt the
modversions checks).
But even before it fails the modversion checks, it apparently does various
ugly things that clash with the built-in driver.
At least that seems to be the case.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Saturday 26 January 2008 16:35:09 Greg KH wrote: > On Sat, Jan 26, 2008 at 03:50:57PM +1100, Rusty Russell wrote: > > That's pretty early, and before this backtrace. > > But that doesn't catch the case here, of trying to load a module when > the code itself is already built into the kernel. Ah, I missed that, sorry. > For that we are > relying on the sysfs core to tell us we have a duplicate name problem, > which happens much later. > > Is there any test you can do sooner, or is relying on the sysfs test > acceptable? As you pointed out, that's always been a "configure your kernel correctly, stupid" kind of bug. Nicer would be to have a list of in-kernel "modules" generated by the build system, but sysfs is there and it's easy to hang our hats off... So, no objections to this with that as a FIXME, and a change so the message says "module is already built into the kernel". Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Saturday 26 January 2008 16:35:09 Greg KH wrote: On Sat, Jan 26, 2008 at 03:50:57PM +1100, Rusty Russell wrote: That's pretty early, and before this backtrace. But that doesn't catch the case here, of trying to load a module when the code itself is already built into the kernel. Ah, I missed that, sorry. For that we are relying on the sysfs core to tell us we have a duplicate name problem, which happens much later. Is there any test you can do sooner, or is relying on the sysfs test acceptable? As you pointed out, that's always been a configure your kernel correctly, stupid kind of bug. Nicer would be to have a list of in-kernel modules generated by the build system, but sysfs is there and it's easy to hang our hats off... So, no objections to this with that as a FIXME, and a change so the message says module is already built into the kernel. Thanks, Rusty. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 25 Jan 2008 11:11:48 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Fri, 25 Jan 2008, Greg KH wrote: > > > > That's really wierd, I don't see that at all here just running with > > your 2.6.24 + my git tree and lots of USB drivers built into the > > kernel also (like ehci_hcd). > > But do you use an initrd that tries to load the same driver too? > > I'm too lazy to want to do my own initrd. I just use the prepackaged > ones and rely on the fact that my private kernel will refuse to load > modules that aren't meant for it anyway. > you know about "make install" right? That copies the needed files to /boot, adds them to grub AND makes an initrd for you.. all for free ;) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Sat, Jan 26, 2008 at 03:50:57PM +1100, Rusty Russell wrote:
> On Saturday 26 January 2008 06:42:19 Greg KH wrote:
> > On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote:
> > > On Thu, 24 Jan 2008, Greg KH wrote:
> > > > Here are a pretty large number of kobject, documentation, and driver
> > > > core patches against your 2.6.24 git tree.
> > >
> > > I've merged it all, but it causes lots of scary warnings:
> > >
> > > - from the purely broken ones:
> > >
> > > ehci_hcd: no version for "struct_module" found: kernel tainted.
> >
> > Ok, in looking at the code, this should also be showing up for you on a
> > "clean" 2.6.24 release, I didn't change anything in this code path.
> >
> > That is what taints your kernel with the "F" flag.
> >
> > > - to the scary ones:
> > >
> > > sysfs: duplicate filename 'ehci_hcd' can not be created
> > > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > > Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28
> > >
> > > Call Trace:
> > >[] sysfs_add_one+0x54/0xbd
> > >[] create_dir+0x4f/0x87
> > >[] sysfs_create_dir+0x35/0x4a
> > >[] kobject_get+0x12/0x17
> > >[] kobject_add_internal+0xd9/0x194
> > >[] kobject_add_varg+0x54/0x61
> > >[] __alloc_pages+0x66/0x2ee
> > >[] kobject_init+0x42/0x82
> > >[] kobject_init_and_add+0x9a/0xa7
> > >[] __vmalloc_area_node+0x111/0x135
> > >[] mod_sysfs_init+0x6e/0x83
> > >[] sys_init_module+0xa3d/0x1833
> > >[] dput+0x1c/0x10b
> > >[] system_call+0x7e/0x83
> >
> > This is the sysfs core telling you that someone did something stupid :)
> >
> > Yes, that's new, but the "error" was always there, I just made the
> > warning more visible to get people to pay attention to it, and find the
> > real errors where this happens (and it has found them, which is a good
> > thing.)
> >
> > But in this case, it doesn't look like the module loading code will
> > detect that we are trying to load a module that is already present until
> > the kobjects are set up here. It's been this way for a long time :(
> >
> > Rusty, any ideas of us adding a different check for "duplicate" modules
> > like this earlier in the load_module() function, so we don't spend so
> > much effort in building everything up when we don't need to?
>
> module.c:1832 (in load_module)
>
> if (find_module(mod->name)) {
> err = -EEXIST;
> goto free_mod;
> }
>
> That's pretty early, and before this backtrace.
But that doesn't catch the case here, of trying to load a module when
the code itself is already built into the kernel. For that we are
relying on the sysfs core to tell us we have a duplicate name problem,
which happens much later.
Is there any test you can do sooner, or is relying on the sysfs test
acceptable?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Saturday 26 January 2008 06:42:19 Greg KH wrote:
> On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote:
> > On Thu, 24 Jan 2008, Greg KH wrote:
> > > Here are a pretty large number of kobject, documentation, and driver
> > > core patches against your 2.6.24 git tree.
> >
> > I've merged it all, but it causes lots of scary warnings:
> >
> > - from the purely broken ones:
> >
> > ehci_hcd: no version for "struct_module" found: kernel tainted.
>
> Ok, in looking at the code, this should also be showing up for you on a
> "clean" 2.6.24 release, I didn't change anything in this code path.
>
> That is what taints your kernel with the "F" flag.
>
> > - to the scary ones:
> >
> > sysfs: duplicate filename 'ehci_hcd' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28
> >
> > Call Trace:
> > [] sysfs_add_one+0x54/0xbd
> > [] create_dir+0x4f/0x87
> > [] sysfs_create_dir+0x35/0x4a
> > [] kobject_get+0x12/0x17
> > [] kobject_add_internal+0xd9/0x194
> > [] kobject_add_varg+0x54/0x61
> > [] __alloc_pages+0x66/0x2ee
> > [] kobject_init+0x42/0x82
> > [] kobject_init_and_add+0x9a/0xa7
> > [] __vmalloc_area_node+0x111/0x135
> > [] mod_sysfs_init+0x6e/0x83
> > [] sys_init_module+0xa3d/0x1833
> > [] dput+0x1c/0x10b
> > [] system_call+0x7e/0x83
>
> This is the sysfs core telling you that someone did something stupid :)
>
> Yes, that's new, but the "error" was always there, I just made the
> warning more visible to get people to pay attention to it, and find the
> real errors where this happens (and it has found them, which is a good
> thing.)
>
> But in this case, it doesn't look like the module loading code will
> detect that we are trying to load a module that is already present until
> the kobjects are set up here. It's been this way for a long time :(
>
> Rusty, any ideas of us adding a different check for "duplicate" modules
> like this earlier in the load_module() function, so we don't spend so
> much effort in building everything up when we don't need to?
module.c:1832 (in load_module)
if (find_module(mod->name)) {
err = -EEXIST;
goto free_mod;
}
That's pretty early, and before this backtrace.
Even for simultaneous loads, there's a mutex which protects from here to the
list insertion.
Puzzled,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Sat, 26 Jan 2008 01:05:26 +0100, Ingo Molnar said: > all it takes for me on Fedora is to boot a modular distro kernel once, > then copy the /dev to the real (persistent) /dev: > >mkdir /tmp2 >mount /dev/sda1 /tmp2 >cp -a /dev/* /tmp2/dev/ > > and from that point on a bzImage/vmlinuz can boot up on Fedora without > any problems (as long as it has the right drivers built in), and the > initrd line can be removed from grub.conf. Tried something like that once - it didn't play nice with the fact that I have root-on-LVM, so you need an initrd to do the 'lvm vgchange -a' and get it online. pgpJjqf9nRzjE.pgp Description: PGP signature
Re: [GIT PATCH] driver core patches against 2.6.24
On Sat, 2008-01-26 at 01:27 +0100, Peter Zijlstra wrote: > On Sat, 2008-01-26 at 01:05 +0100, Ingo Molnar wrote: > > * Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > > My wish is that distros would just boot without requiring an initrd. I > > > know how to make them for redhat and debian based distros, but the > > > fact that you can't (easily) cross-build them makes it a very tedious > > > construct. > > > > all it takes for me on Fedora is to boot a modular distro kernel once, > > then copy the /dev to the real (persistent) /dev: > > > >mkdir /tmp2 > >mount /dev/sda1 /tmp2 > >cp -a /dev/* /tmp2/dev/ > > > > and from that point on a bzImage/vmlinuz can boot up on Fedora without > > any problems (as long as it has the right drivers built in), and the > > initrd line can be removed from grub.conf. > > Yeah, I usually do the same but with a bind mount, still it would be > grand if such things would not be needed. Agreed. But it's not likely to be a priority - all the vendors want completely modular kernels. But now we see what Linus wants to do, perhaps we can try to be a bit more friendly toward that. It's not actually rocket science, after all. I was concerned that he wanted to use the modules in the initrd, but now I see Linus, and everyone else, just want to do what I also secretly do, and just not use an initrd. Isn't it funny. We all secretly hate using initrds ourselves :) Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Sat, 2008-01-26 at 01:05 +0100, Ingo Molnar wrote: > * Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > My wish is that distros would just boot without requiring an initrd. I > > know how to make them for redhat and debian based distros, but the > > fact that you can't (easily) cross-build them makes it a very tedious > > construct. > > all it takes for me on Fedora is to boot a modular distro kernel once, > then copy the /dev to the real (persistent) /dev: > >mkdir /tmp2 >mount /dev/sda1 /tmp2 >cp -a /dev/* /tmp2/dev/ > > and from that point on a bzImage/vmlinuz can boot up on Fedora without > any problems (as long as it has the right drivers built in), and the > initrd line can be removed from grub.conf. Yeah, I usually do the same but with a bind mount, still it would be grand if such things would not be needed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
* Peter Zijlstra <[EMAIL PROTECTED]> wrote: > My wish is that distros would just boot without requiring an initrd. I > know how to make them for redhat and debian based distros, but the > fact that you can't (easily) cross-build them makes it a very tedious > construct. all it takes for me on Fedora is to boot a modular distro kernel once, then copy the /dev to the real (persistent) /dev: mkdir /tmp2 mount /dev/sda1 /tmp2 cp -a /dev/* /tmp2/dev/ and from that point on a bzImage/vmlinuz can boot up on Fedora without any problems (as long as it has the right drivers built in), and the initrd line can be removed from grub.conf. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 2008-01-25 at 13:58 -0800, Jeremy Fitzhardinge wrote: > Linus Torvalds wrote: > > On Fri, 25 Jan 2008, Jon Masters wrote: > > > >> Right. I assumed that Linus was calling mkinitrd but was being bitten by > >> one of the occasional assumptions (I believe we make in that script) > >> > > > > No. I really am not. My /etc/grub.conf looks like this: > > > > title Linux > > root (hd0,0) > > kernel /vmlinuz ro root=/dev/VolGroup00/LogVol00 rhgb quiet > > initrd /initrd-2.6.23.14-107.fc8.img > > > > ie I literally run the fedora initrd. > > > > I switch kernels, not initrd's. I don't even want to know if the initrd > > contains some distro-specific setup... > > The distro mkinird can reconstruct it containing your freshly built > modules (if any) and any other distro goo which needs to go in there. > /initrd-2.6.23.14-107.fc8.img doesn't come out of an rpm; its built by > an installer script when you install the kernel, and you can run the > same script on your kernels. > > Does you use "make modules_install install" when you build the kernel? > It just does the right thing for me under F8, including rebuilding > initrd and updating grub.conf. My wish is that distros would just boot without requiring an initrd. I know how to make them for redhat and debian based distros, but the fact that you can't (easily) cross-build them makes it a very tedious construct. I can butcher the distros into booting and ignore the errors on bootup that whine that modules are missing, but really. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
Linus Torvalds wrote: On Fri, 25 Jan 2008, Jon Masters wrote: Right. I assumed that Linus was calling mkinitrd but was being bitten by one of the occasional assumptions (I believe we make in that script) No. I really am not. My /etc/grub.conf looks like this: title Linux root (hd0,0) kernel /vmlinuz ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.23.14-107.fc8.img ie I literally run the fedora initrd. I switch kernels, not initrd's. I don't even want to know if the initrd contains some distro-specific setup... The distro mkinird can reconstruct it containing your freshly built modules (if any) and any other distro goo which needs to go in there. /initrd-2.6.23.14-107.fc8.img doesn't come out of an rpm; its built by an installer script when you install the kernel, and you can run the same script on your kernels. Does you use "make modules_install install" when you build the kernel? It just does the right thing for me under F8, including rebuilding initrd and updating grub.conf. J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 25 Jan 2008, Jon Masters wrote: > > Right. I assumed that Linus was calling mkinitrd but was being bitten by > one of the occasional assumptions (I believe we make in that script) No. I really am not. My /etc/grub.conf looks like this: title Linux root (hd0,0) kernel /vmlinuz ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.23.14-107.fc8.img ie I literally run the fedora initrd. I switch kernels, not initrd's. I don't even want to know if the initrd contains some distro-specific setup... Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 2008-01-25 at 11:56 -0800, Jeremy Fitzhardinge wrote: > Linus Torvalds wrote: > > I'm too lazy to want to do my own initrd. I just use the prepackaged ones > > and rely on the fact that my private kernel will refuse to load modules > > that aren't meant for it anyway. > initrds generally aren't prepackaged, but generated on install (at least > with Fedora). You can regenerate them with "mkinitrd -f > /boot/initrd-2.6.24.img 2.6.24". Also, I find that "make > modules_install install" does it automatically from a kernel build. Right. I assumed that Linus was calling mkinitrd but was being bitten by one of the occasional assumptions (I believe we make in that script) that certain things are always modular. I just mailed the maintainer, suggesting we screen against the one of the Modules.* files (perhaps Modules.order might become a good candidate in due course...). Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 2008-01-25 at 10:44 -0800, Linus Torvalds wrote: > and the problem seems to be that it does all these checks even for modules > that will never be loaded, because I use my own kernel, but with the > default Fedora initrd (which is trying to load modules for stuff that I > already have built in). Thanks Linus. I'll pass this on to the mkinitrd maintainer. We'll try to get this sorted out for you :) Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 12:23:25PM -0800, Linus Torvalds wrote: > On Fri, 25 Jan 2008, Greg KH wrote: > > Linus, does the patch below (built tested only) fix the above call trace > > noise for you? It shouldn't change the taint flag, that's a different > > issue it seems. > > Sadly, I'm now in the process of shutting down all my machines to prepare > for "the flight from hell(tm)", so I won't have time to check this right > now. Ok, I'll queue it up myself in my trees and send it to you in a few days. Have a nice trip, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 25 Jan 2008, Greg KH wrote: > On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote: > > > > - from the purely broken ones: > > > > ehci_hcd: no version for "struct_module" found: kernel tainted. > > Ok, in looking at the code, this should also be showing up for you on a > "clean" 2.6.24 release, I didn't change anything in this code path. Ok, I just never noticed, because without any warnings or oopses, it didn't much matter... > Linus, does the patch below (built tested only) fix the above call trace > noise for you? It shouldn't change the taint flag, that's a different > issue it seems. Sadly, I'm now in the process of shutting down all my machines to prepare for "the flight from hell(tm)", so I won't have time to check this right now. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
Linus Torvalds wrote: I'm too lazy to want to do my own initrd. I just use the prepackaged ones and rely on the fact that my private kernel will refuse to load modules that aren't meant for it anyway. initrds generally aren't prepackaged, but generated on install (at least with Fedora). You can regenerate them with "mkinitrd -f /boot/initrd-2.6.24.img 2.6.24". Also, I find that "make modules_install install" does it automatically from a kernel build. J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote:
>
>
> On Thu, 24 Jan 2008, Greg KH wrote:
> >
> > Here are a pretty large number of kobject, documentation, and driver
> > core patches against your 2.6.24 git tree.
>
> I've merged it all, but it causes lots of scary warnings:
>
> - from the purely broken ones:
>
> ehci_hcd: no version for "struct_module" found: kernel tainted.
Ok, in looking at the code, this should also be showing up for you on a
"clean" 2.6.24 release, I didn't change anything in this code path.
That is what taints your kernel with the "F" flag.
> - to the scary ones:
>
> sysfs: duplicate filename 'ehci_hcd' can not be created
> WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28
>
> Call Trace:
>[] sysfs_add_one+0x54/0xbd
>[] create_dir+0x4f/0x87
>[] sysfs_create_dir+0x35/0x4a
>[] kobject_get+0x12/0x17
>[] kobject_add_internal+0xd9/0x194
>[] kobject_add_varg+0x54/0x61
>[] __alloc_pages+0x66/0x2ee
>[] kobject_init+0x42/0x82
>[] kobject_init_and_add+0x9a/0xa7
>[] __vmalloc_area_node+0x111/0x135
>[] mod_sysfs_init+0x6e/0x83
>[] sys_init_module+0xa3d/0x1833
>[] dput+0x1c/0x10b
>[] system_call+0x7e/0x83
This is the sysfs core telling you that someone did something stupid :)
Yes, that's new, but the "error" was always there, I just made the
warning more visible to get people to pay attention to it, and find the
real errors where this happens (and it has found them, which is a good
thing.)
But in this case, it doesn't look like the module loading code will
detect that we are trying to load a module that is already present until
the kobjects are set up here. It's been this way for a long time :(
Rusty, any ideas of us adding a different check for "duplicate" modules
like this earlier in the load_module() function, so we don't spend so
much effort in building everything up when we don't need to?
I think it's down in the apply_relocate() function where we would
finally figure out that something bad is going on here, which seems a
bit late to me.
I guess we could just check the list of module names loaded when we try
to set up the kobject, that would be simple and easy.
Linus, does the patch below (built tested only) fix the above call trace
noise for you? It shouldn't change the taint flag, that's a different
issue it seems.
thanks,
greg k-h
-
From: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Subject: module: bail out of loading duplicate modules early
This should fix the long calltrace when trying to load a module that has
been built into the kernel allready.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
diff --git a/kernel/module.c b/kernel/module.c
index dcb8a2c..3a76a4d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1210,6 +1210,7 @@ void module_remove_modinfo_attrs(struct module *mod)
int mod_sysfs_init(struct module *mod)
{
int err;
+ struct kobject *kobj;
if (!module_sysfs_initialized) {
printk(KERN_ERR "%s: module sysfs not initialized\n",
@@ -1217,6 +1218,15 @@ int mod_sysfs_init(struct module *mod)
err = -EINVAL;
goto out;
}
+
+ kobj = kset_find_obj(module_kset, mod->name);
+ if (kobj) {
+ printk(KERN_ERR "%s: module is already loaded\n", mod->name);
+ kobject_put(kobj);
+ err = -EINVAL;
+ goto out;
+ }
+
mod->mkobj.mod = mod;
memset(>mkobj.kobj, 0, sizeof(mod->mkobj.kobj));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 11:11:48AM -0800, Linus Torvalds wrote: > > > On Fri, 25 Jan 2008, Greg KH wrote: > > > > That's really wierd, I don't see that at all here just running with your > > 2.6.24 + my git tree and lots of USB drivers built into the kernel also > > (like ehci_hcd). > > But do you use an initrd that tries to load the same driver too? Ah, now I get it, sorry, I'll go check that error path, not exactly a normal one :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 11:11:48AM -0800, Linus Torvalds wrote: > > > On Fri, 25 Jan 2008, Greg KH wrote: > > > > That's really wierd, I don't see that at all here just running with your > > 2.6.24 + my git tree and lots of USB drivers built into the kernel also > > (like ehci_hcd). > > But do you use an initrd that tries to load the same driver too? > > I'm too lazy to want to do my own initrd. I just use the prepackaged ones > and rely on the fact that my private kernel will refuse to load modules > that aren't meant for it anyway. No, I don't use any initrd at all. You should just get a message saying that the version magic doesn't match, so the initrd modules will not load. That's what happens to me when I try to force old modules to load. > > $ cat /proc/sys/kernel/tainted > > 0 > > Mine says "2". > > > $ uname -r > > 2.6.24-ge374a2bf-dirty > > > > Strange, I thought that the uname id would show the git version that you > > were running, but that doesn't show a valid id. But that's probably a > > different issue in the build system somewhere... > > That *is* the git version you're running: e374a2bf. > > The "-g" is for "git" and the "-dirty" is because you have some > non-checked-in changes in addition. > > I works for me: > > [EMAIL PROTECTED] linux]$ git show --abbrev-commit -s --pretty=oneline > e374a2bf > e374a2b... Kobject: fix coding style issues in kobject c files > > so that looks like a valid version.. Ah taking the "g" off the search works, didn't realize that. And I didn't have any unchecked in files, 'git status' shows no modified files, but other stuff in the main directory, like patches that shouldn't matter, but perhaps they do. But oh well, I'm still building your tree now to try to reproduce this... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 25 Jan 2008, Greg KH wrote: > > That's really wierd, I don't see that at all here just running with your > 2.6.24 + my git tree and lots of USB drivers built into the kernel also > (like ehci_hcd). But do you use an initrd that tries to load the same driver too? I'm too lazy to want to do my own initrd. I just use the prepackaged ones and rely on the fact that my private kernel will refuse to load modules that aren't meant for it anyway. > $ cat /proc/sys/kernel/tainted > 0 Mine says "2". > $ uname -r > 2.6.24-ge374a2bf-dirty > > Strange, I thought that the uname id would show the git version that you > were running, but that doesn't show a valid id. But that's probably a > different issue in the build system somewhere... That *is* the git version you're running: e374a2bf. The "-g" is for "git" and the "-dirty" is because you have some non-checked-in changes in addition. I works for me: [EMAIL PROTECTED] linux]$ git show --abbrev-commit -s --pretty=oneline e374a2bf e374a2b... Kobject: fix coding style issues in kobject c files so that looks like a valid version.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote: > > > On Thu, 24 Jan 2008, Greg KH wrote: > > > > Here are a pretty large number of kobject, documentation, and driver > > core patches against your 2.6.24 git tree. > > I've merged it all, but it causes lots of scary warnings: > > - from the purely broken ones: > > ehci_hcd: no version for "struct_module" found: kernel tainted. > > - to the scary ones: > > sysfs: duplicate filename 'ehci_hcd' can not be created > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() > Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28 > > Call Trace: >[] sysfs_add_one+0x54/0xbd >[] create_dir+0x4f/0x87 >[] sysfs_create_dir+0x35/0x4a >[] kobject_get+0x12/0x17 >[] kobject_add_internal+0xd9/0x194 >[] kobject_add_varg+0x54/0x61 >[] __alloc_pages+0x66/0x2ee >[] kobject_init+0x42/0x82 >[] kobject_init_and_add+0x9a/0xa7 >[] __vmalloc_area_node+0x111/0x135 >[] mod_sysfs_init+0x6e/0x83 >[] sys_init_module+0xa3d/0x1833 >[] dput+0x1c/0x10b >[] system_call+0x7e/0x83 > > and the problem seems to be that it does all these checks even for modules > that will never be loaded, because I use my own kernel, but with the > default Fedora initrd (which is trying to load modules for stuff that I > already have built in). > > Very annoying. That's really wierd, I don't see that at all here just running with your 2.6.24 + my git tree and lots of USB drivers built into the kernel also (like ehci_hcd). I'll try to reproduce it on your merged git tree now... > Can we please do that *after* the module loading symbol checks have run, > so that when you try to load a module that will not load, it won't > complain about these silly things? > > (You can probably trigger this by simply trying to load a module that was > compiled for another kernel version - it will fail fine, but in failing it > will then generate all these incorrect warnings!) > > Now it incorrectly taints my kernel, for no good reason. $ cat /proc/sys/kernel/tainted 0 Odd... $ uname -r 2.6.24-ge374a2bf-dirty Strange, I thought that the uname id would show the git version that you were running, but that doesn't show a valid id. But that's probably a different issue in the build system somewhere... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Thu, 24 Jan 2008, Greg KH wrote: > > Here are a pretty large number of kobject, documentation, and driver > core patches against your 2.6.24 git tree. I've merged it all, but it causes lots of scary warnings: - from the purely broken ones: ehci_hcd: no version for "struct_module" found: kernel tainted. - to the scary ones: sysfs: duplicate filename 'ehci_hcd' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28 Call Trace: [] sysfs_add_one+0x54/0xbd [] create_dir+0x4f/0x87 [] sysfs_create_dir+0x35/0x4a [] kobject_get+0x12/0x17 [] kobject_add_internal+0xd9/0x194 [] kobject_add_varg+0x54/0x61 [] __alloc_pages+0x66/0x2ee [] kobject_init+0x42/0x82 [] kobject_init_and_add+0x9a/0xa7 [] __vmalloc_area_node+0x111/0x135 [] mod_sysfs_init+0x6e/0x83 [] sys_init_module+0xa3d/0x1833 [] dput+0x1c/0x10b [] system_call+0x7e/0x83 and the problem seems to be that it does all these checks even for modules that will never be loaded, because I use my own kernel, but with the default Fedora initrd (which is trying to load modules for stuff that I already have built in). Very annoying. Can we please do that *after* the module loading symbol checks have run, so that when you try to load a module that will not load, it won't complain about these silly things? (You can probably trigger this by simply trying to load a module that was compiled for another kernel version - it will fail fine, but in failing it will then generate all these incorrect warnings!) Now it incorrectly taints my kernel, for no good reason. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 11:11:48AM -0800, Linus Torvalds wrote: On Fri, 25 Jan 2008, Greg KH wrote: That's really wierd, I don't see that at all here just running with your 2.6.24 + my git tree and lots of USB drivers built into the kernel also (like ehci_hcd). But do you use an initrd that tries to load the same driver too? Ah, now I get it, sorry, I'll go check that error path, not exactly a normal one :) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 11:11:48AM -0800, Linus Torvalds wrote: On Fri, 25 Jan 2008, Greg KH wrote: That's really wierd, I don't see that at all here just running with your 2.6.24 + my git tree and lots of USB drivers built into the kernel also (like ehci_hcd). But do you use an initrd that tries to load the same driver too? I'm too lazy to want to do my own initrd. I just use the prepackaged ones and rely on the fact that my private kernel will refuse to load modules that aren't meant for it anyway. No, I don't use any initrd at all. You should just get a message saying that the version magic doesn't match, so the initrd modules will not load. That's what happens to me when I try to force old modules to load. $ cat /proc/sys/kernel/tainted 0 Mine says 2. $ uname -r 2.6.24-ge374a2bf-dirty Strange, I thought that the uname id would show the git version that you were running, but that doesn't show a valid id. But that's probably a different issue in the build system somewhere... That *is* the git version you're running: e374a2bf. The -g is for git and the -dirty is because you have some non-checked-in changes in addition. I works for me: [EMAIL PROTECTED] linux]$ git show --abbrev-commit -s --pretty=oneline e374a2bf e374a2b... Kobject: fix coding style issues in kobject c files so that looks like a valid version.. Ah taking the g off the search works, didn't realize that. And I didn't have any unchecked in files, 'git status' shows no modified files, but other stuff in the main directory, like patches that shouldn't matter, but perhaps they do. But oh well, I'm still building your tree now to try to reproduce this... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
Linus Torvalds wrote: I'm too lazy to want to do my own initrd. I just use the prepackaged ones and rely on the fact that my private kernel will refuse to load modules that aren't meant for it anyway. initrds generally aren't prepackaged, but generated on install (at least with Fedora). You can regenerate them with mkinitrd -f /boot/initrd-2.6.24.img 2.6.24. Also, I find that make modules_install install does it automatically from a kernel build. J -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
* Peter Zijlstra [EMAIL PROTECTED] wrote: My wish is that distros would just boot without requiring an initrd. I know how to make them for redhat and debian based distros, but the fact that you can't (easily) cross-build them makes it a very tedious construct. all it takes for me on Fedora is to boot a modular distro kernel once, then copy the /dev to the real (persistent) /dev: mkdir /tmp2 mount /dev/sda1 /tmp2 cp -a /dev/* /tmp2/dev/ and from that point on a bzImage/vmlinuz can boot up on Fedora without any problems (as long as it has the right drivers built in), and the initrd line can be removed from grub.conf. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Saturday 26 January 2008 06:42:19 Greg KH wrote:
On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote:
On Thu, 24 Jan 2008, Greg KH wrote:
Here are a pretty large number of kobject, documentation, and driver
core patches against your 2.6.24 git tree.
I've merged it all, but it causes lots of scary warnings:
- from the purely broken ones:
ehci_hcd: no version for struct_module found: kernel tainted.
Ok, in looking at the code, this should also be showing up for you on a
clean 2.6.24 release, I didn't change anything in this code path.
That is what taints your kernel with the F flag.
- to the scary ones:
sysfs: duplicate filename 'ehci_hcd' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28
Call Trace:
[802bd63c] sysfs_add_one+0x54/0xbd
[802bdbc0] create_dir+0x4f/0x87
[802bdc2d] sysfs_create_dir+0x35/0x4a
[803154c8] kobject_get+0x12/0x17
[80315607] kobject_add_internal+0xd9/0x194
[8031579c] kobject_add_varg+0x54/0x61
[80261efe] __alloc_pages+0x66/0x2ee
[80315321] kobject_init+0x42/0x82
[80315843] kobject_init_and_add+0x9a/0xa7
[802722c0] __vmalloc_area_node+0x111/0x135
[8025546b] mod_sysfs_init+0x6e/0x83
[802561e8] sys_init_module+0xa3d/0x1833
[8028ebd5] dput+0x1c/0x10b
[8020b3be] system_call+0x7e/0x83
This is the sysfs core telling you that someone did something stupid :)
Yes, that's new, but the error was always there, I just made the
warning more visible to get people to pay attention to it, and find the
real errors where this happens (and it has found them, which is a good
thing.)
But in this case, it doesn't look like the module loading code will
detect that we are trying to load a module that is already present until
the kobjects are set up here. It's been this way for a long time :(
Rusty, any ideas of us adding a different check for duplicate modules
like this earlier in the load_module() function, so we don't spend so
much effort in building everything up when we don't need to?
module.c:1832 (in load_module)
if (find_module(mod-name)) {
err = -EEXIST;
goto free_mod;
}
That's pretty early, and before this backtrace.
Even for simultaneous loads, there's a mutex which protects from here to the
list insertion.
Puzzled,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Sat, Jan 26, 2008 at 03:50:57PM +1100, Rusty Russell wrote:
On Saturday 26 January 2008 06:42:19 Greg KH wrote:
On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote:
On Thu, 24 Jan 2008, Greg KH wrote:
Here are a pretty large number of kobject, documentation, and driver
core patches against your 2.6.24 git tree.
I've merged it all, but it causes lots of scary warnings:
- from the purely broken ones:
ehci_hcd: no version for struct_module found: kernel tainted.
Ok, in looking at the code, this should also be showing up for you on a
clean 2.6.24 release, I didn't change anything in this code path.
That is what taints your kernel with the F flag.
- to the scary ones:
sysfs: duplicate filename 'ehci_hcd' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28
Call Trace:
[802bd63c] sysfs_add_one+0x54/0xbd
[802bdbc0] create_dir+0x4f/0x87
[802bdc2d] sysfs_create_dir+0x35/0x4a
[803154c8] kobject_get+0x12/0x17
[80315607] kobject_add_internal+0xd9/0x194
[8031579c] kobject_add_varg+0x54/0x61
[80261efe] __alloc_pages+0x66/0x2ee
[80315321] kobject_init+0x42/0x82
[80315843] kobject_init_and_add+0x9a/0xa7
[802722c0] __vmalloc_area_node+0x111/0x135
[8025546b] mod_sysfs_init+0x6e/0x83
[802561e8] sys_init_module+0xa3d/0x1833
[8028ebd5] dput+0x1c/0x10b
[8020b3be] system_call+0x7e/0x83
This is the sysfs core telling you that someone did something stupid :)
Yes, that's new, but the error was always there, I just made the
warning more visible to get people to pay attention to it, and find the
real errors where this happens (and it has found them, which is a good
thing.)
But in this case, it doesn't look like the module loading code will
detect that we are trying to load a module that is already present until
the kobjects are set up here. It's been this way for a long time :(
Rusty, any ideas of us adding a different check for duplicate modules
like this earlier in the load_module() function, so we don't spend so
much effort in building everything up when we don't need to?
module.c:1832 (in load_module)
if (find_module(mod-name)) {
err = -EEXIST;
goto free_mod;
}
That's pretty early, and before this backtrace.
But that doesn't catch the case here, of trying to load a module when
the code itself is already built into the kernel. For that we are
relying on the sysfs core to tell us we have a duplicate name problem,
which happens much later.
Is there any test you can do sooner, or is relying on the sysfs test
acceptable?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Sat, 2008-01-26 at 01:05 +0100, Ingo Molnar wrote: * Peter Zijlstra [EMAIL PROTECTED] wrote: My wish is that distros would just boot without requiring an initrd. I know how to make them for redhat and debian based distros, but the fact that you can't (easily) cross-build them makes it a very tedious construct. all it takes for me on Fedora is to boot a modular distro kernel once, then copy the /dev to the real (persistent) /dev: mkdir /tmp2 mount /dev/sda1 /tmp2 cp -a /dev/* /tmp2/dev/ and from that point on a bzImage/vmlinuz can boot up on Fedora without any problems (as long as it has the right drivers built in), and the initrd line can be removed from grub.conf. Yeah, I usually do the same but with a bind mount, still it would be grand if such things would not be needed. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
Linus Torvalds wrote: On Fri, 25 Jan 2008, Jon Masters wrote: Right. I assumed that Linus was calling mkinitrd but was being bitten by one of the occasional assumptions (I believe we make in that script) No. I really am not. My /etc/grub.conf looks like this: title Linux root (hd0,0) kernel /vmlinuz ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.23.14-107.fc8.img ie I literally run the fedora initrd. I switch kernels, not initrd's. I don't even want to know if the initrd contains some distro-specific setup... The distro mkinird can reconstruct it containing your freshly built modules (if any) and any other distro goo which needs to go in there. /initrd-2.6.23.14-107.fc8.img doesn't come out of an rpm; its built by an installer script when you install the kernel, and you can run the same script on your kernels. Does you use make modules_install install when you build the kernel? It just does the right thing for me under F8, including rebuilding initrd and updating grub.conf. J -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 2008-01-25 at 10:44 -0800, Linus Torvalds wrote: and the problem seems to be that it does all these checks even for modules that will never be loaded, because I use my own kernel, but with the default Fedora initrd (which is trying to load modules for stuff that I already have built in). Thanks Linus. I'll pass this on to the mkinitrd maintainer. We'll try to get this sorted out for you :) Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 25 Jan 2008, Greg KH wrote: On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote: - from the purely broken ones: ehci_hcd: no version for struct_module found: kernel tainted. Ok, in looking at the code, this should also be showing up for you on a clean 2.6.24 release, I didn't change anything in this code path. Ok, I just never noticed, because without any warnings or oopses, it didn't much matter... Linus, does the patch below (built tested only) fix the above call trace noise for you? It shouldn't change the taint flag, that's a different issue it seems. Sadly, I'm now in the process of shutting down all my machines to prepare for the flight from hell(tm), so I won't have time to check this right now. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Thu, 24 Jan 2008, Greg KH wrote: Here are a pretty large number of kobject, documentation, and driver core patches against your 2.6.24 git tree. I've merged it all, but it causes lots of scary warnings: - from the purely broken ones: ehci_hcd: no version for struct_module found: kernel tainted. - to the scary ones: sysfs: duplicate filename 'ehci_hcd' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28 Call Trace: [802bd63c] sysfs_add_one+0x54/0xbd [802bdbc0] create_dir+0x4f/0x87 [802bdc2d] sysfs_create_dir+0x35/0x4a [803154c8] kobject_get+0x12/0x17 [80315607] kobject_add_internal+0xd9/0x194 [8031579c] kobject_add_varg+0x54/0x61 [80261efe] __alloc_pages+0x66/0x2ee [80315321] kobject_init+0x42/0x82 [80315843] kobject_init_and_add+0x9a/0xa7 [802722c0] __vmalloc_area_node+0x111/0x135 [8025546b] mod_sysfs_init+0x6e/0x83 [802561e8] sys_init_module+0xa3d/0x1833 [8028ebd5] dput+0x1c/0x10b [8020b3be] system_call+0x7e/0x83 and the problem seems to be that it does all these checks even for modules that will never be loaded, because I use my own kernel, but with the default Fedora initrd (which is trying to load modules for stuff that I already have built in). Very annoying. Can we please do that *after* the module loading symbol checks have run, so that when you try to load a module that will not load, it won't complain about these silly things? (You can probably trigger this by simply trying to load a module that was compiled for another kernel version - it will fail fine, but in failing it will then generate all these incorrect warnings!) Now it incorrectly taints my kernel, for no good reason. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 2008-01-25 at 13:58 -0800, Jeremy Fitzhardinge wrote: Linus Torvalds wrote: On Fri, 25 Jan 2008, Jon Masters wrote: Right. I assumed that Linus was calling mkinitrd but was being bitten by one of the occasional assumptions (I believe we make in that script) No. I really am not. My /etc/grub.conf looks like this: title Linux root (hd0,0) kernel /vmlinuz ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.23.14-107.fc8.img ie I literally run the fedora initrd. I switch kernels, not initrd's. I don't even want to know if the initrd contains some distro-specific setup... The distro mkinird can reconstruct it containing your freshly built modules (if any) and any other distro goo which needs to go in there. /initrd-2.6.23.14-107.fc8.img doesn't come out of an rpm; its built by an installer script when you install the kernel, and you can run the same script on your kernels. Does you use make modules_install install when you build the kernel? It just does the right thing for me under F8, including rebuilding initrd and updating grub.conf. My wish is that distros would just boot without requiring an initrd. I know how to make them for redhat and debian based distros, but the fact that you can't (easily) cross-build them makes it a very tedious construct. I can butcher the distros into booting and ignore the errors on bootup that whine that modules are missing, but really. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 2008-01-25 at 11:56 -0800, Jeremy Fitzhardinge wrote: Linus Torvalds wrote: I'm too lazy to want to do my own initrd. I just use the prepackaged ones and rely on the fact that my private kernel will refuse to load modules that aren't meant for it anyway. initrds generally aren't prepackaged, but generated on install (at least with Fedora). You can regenerate them with mkinitrd -f /boot/initrd-2.6.24.img 2.6.24. Also, I find that make modules_install install does it automatically from a kernel build. Right. I assumed that Linus was calling mkinitrd but was being bitten by one of the occasional assumptions (I believe we make in that script) that certain things are always modular. I just mailed the maintainer, suggesting we screen against the one of the Modules.* files (perhaps Modules.order might become a good candidate in due course...). Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote: On Thu, 24 Jan 2008, Greg KH wrote: Here are a pretty large number of kobject, documentation, and driver core patches against your 2.6.24 git tree. I've merged it all, but it causes lots of scary warnings: - from the purely broken ones: ehci_hcd: no version for struct_module found: kernel tainted. - to the scary ones: sysfs: duplicate filename 'ehci_hcd' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28 Call Trace: [802bd63c] sysfs_add_one+0x54/0xbd [802bdbc0] create_dir+0x4f/0x87 [802bdc2d] sysfs_create_dir+0x35/0x4a [803154c8] kobject_get+0x12/0x17 [80315607] kobject_add_internal+0xd9/0x194 [8031579c] kobject_add_varg+0x54/0x61 [80261efe] __alloc_pages+0x66/0x2ee [80315321] kobject_init+0x42/0x82 [80315843] kobject_init_and_add+0x9a/0xa7 [802722c0] __vmalloc_area_node+0x111/0x135 [8025546b] mod_sysfs_init+0x6e/0x83 [802561e8] sys_init_module+0xa3d/0x1833 [8028ebd5] dput+0x1c/0x10b [8020b3be] system_call+0x7e/0x83 and the problem seems to be that it does all these checks even for modules that will never be loaded, because I use my own kernel, but with the default Fedora initrd (which is trying to load modules for stuff that I already have built in). Very annoying. That's really wierd, I don't see that at all here just running with your 2.6.24 + my git tree and lots of USB drivers built into the kernel also (like ehci_hcd). I'll try to reproduce it on your merged git tree now... Can we please do that *after* the module loading symbol checks have run, so that when you try to load a module that will not load, it won't complain about these silly things? (You can probably trigger this by simply trying to load a module that was compiled for another kernel version - it will fail fine, but in failing it will then generate all these incorrect warnings!) Now it incorrectly taints my kernel, for no good reason. $ cat /proc/sys/kernel/tainted 0 Odd... $ uname -r 2.6.24-ge374a2bf-dirty Strange, I thought that the uname id would show the git version that you were running, but that doesn't show a valid id. But that's probably a different issue in the build system somewhere... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 25 Jan 2008, Greg KH wrote: That's really wierd, I don't see that at all here just running with your 2.6.24 + my git tree and lots of USB drivers built into the kernel also (like ehci_hcd). But do you use an initrd that tries to load the same driver too? I'm too lazy to want to do my own initrd. I just use the prepackaged ones and rely on the fact that my private kernel will refuse to load modules that aren't meant for it anyway. $ cat /proc/sys/kernel/tainted 0 Mine says 2. $ uname -r 2.6.24-ge374a2bf-dirty Strange, I thought that the uname id would show the git version that you were running, but that doesn't show a valid id. But that's probably a different issue in the build system somewhere... That *is* the git version you're running: e374a2bf. The -g is for git and the -dirty is because you have some non-checked-in changes in addition. I works for me: [EMAIL PROTECTED] linux]$ git show --abbrev-commit -s --pretty=oneline e374a2bf e374a2b... Kobject: fix coding style issues in kobject c files so that looks like a valid version.. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 10:44:59AM -0800, Linus Torvalds wrote:
On Thu, 24 Jan 2008, Greg KH wrote:
Here are a pretty large number of kobject, documentation, and driver
core patches against your 2.6.24 git tree.
I've merged it all, but it causes lots of scary warnings:
- from the purely broken ones:
ehci_hcd: no version for struct_module found: kernel tainted.
Ok, in looking at the code, this should also be showing up for you on a
clean 2.6.24 release, I didn't change anything in this code path.
That is what taints your kernel with the F flag.
- to the scary ones:
sysfs: duplicate filename 'ehci_hcd' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Pid: 610, comm: insmod Tainted: GF 2.6.24-gb47711bf #28
Call Trace:
[802bd63c] sysfs_add_one+0x54/0xbd
[802bdbc0] create_dir+0x4f/0x87
[802bdc2d] sysfs_create_dir+0x35/0x4a
[803154c8] kobject_get+0x12/0x17
[80315607] kobject_add_internal+0xd9/0x194
[8031579c] kobject_add_varg+0x54/0x61
[80261efe] __alloc_pages+0x66/0x2ee
[80315321] kobject_init+0x42/0x82
[80315843] kobject_init_and_add+0x9a/0xa7
[802722c0] __vmalloc_area_node+0x111/0x135
[8025546b] mod_sysfs_init+0x6e/0x83
[802561e8] sys_init_module+0xa3d/0x1833
[8028ebd5] dput+0x1c/0x10b
[8020b3be] system_call+0x7e/0x83
This is the sysfs core telling you that someone did something stupid :)
Yes, that's new, but the error was always there, I just made the
warning more visible to get people to pay attention to it, and find the
real errors where this happens (and it has found them, which is a good
thing.)
But in this case, it doesn't look like the module loading code will
detect that we are trying to load a module that is already present until
the kobjects are set up here. It's been this way for a long time :(
Rusty, any ideas of us adding a different check for duplicate modules
like this earlier in the load_module() function, so we don't spend so
much effort in building everything up when we don't need to?
I think it's down in the apply_relocate() function where we would
finally figure out that something bad is going on here, which seems a
bit late to me.
I guess we could just check the list of module names loaded when we try
to set up the kobject, that would be simple and easy.
Linus, does the patch below (built tested only) fix the above call trace
noise for you? It shouldn't change the taint flag, that's a different
issue it seems.
thanks,
greg k-h
-
From: Greg Kroah-Hartman [EMAIL PROTECTED]
Subject: module: bail out of loading duplicate modules early
This should fix the long calltrace when trying to load a module that has
been built into the kernel allready.
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
diff --git a/kernel/module.c b/kernel/module.c
index dcb8a2c..3a76a4d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1210,6 +1210,7 @@ void module_remove_modinfo_attrs(struct module *mod)
int mod_sysfs_init(struct module *mod)
{
int err;
+ struct kobject *kobj;
if (!module_sysfs_initialized) {
printk(KERN_ERR %s: module sysfs not initialized\n,
@@ -1217,6 +1218,15 @@ int mod_sysfs_init(struct module *mod)
err = -EINVAL;
goto out;
}
+
+ kobj = kset_find_obj(module_kset, mod-name);
+ if (kobj) {
+ printk(KERN_ERR %s: module is already loaded\n, mod-name);
+ kobject_put(kobj);
+ err = -EINVAL;
+ goto out;
+ }
+
mod-mkobj.mod = mod;
memset(mod-mkobj.kobj, 0, sizeof(mod-mkobj.kobj));
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, Jan 25, 2008 at 12:23:25PM -0800, Linus Torvalds wrote: On Fri, 25 Jan 2008, Greg KH wrote: Linus, does the patch below (built tested only) fix the above call trace noise for you? It shouldn't change the taint flag, that's a different issue it seems. Sadly, I'm now in the process of shutting down all my machines to prepare for the flight from hell(tm), so I won't have time to check this right now. Ok, I'll queue it up myself in my trees and send it to you in a few days. Have a nice trip, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] driver core patches against 2.6.24
On Fri, 25 Jan 2008, Jon Masters wrote: Right. I assumed that Linus was calling mkinitrd but was being bitten by one of the occasional assumptions (I believe we make in that script) No. I really am not. My /etc/grub.conf looks like this: title Linux root (hd0,0) kernel /vmlinuz ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.23.14-107.fc8.img ie I literally run the fedora initrd. I switch kernels, not initrd's. I don't even want to know if the initrd contains some distro-specific setup... Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] driver core patches against 2.6.24
Due to the low level nature of these patches, and because they touch so many different parts of the kernel, a number of the subsystem maintainers have asked me to get them in first to make merging other trees easier. Here are a pretty large number of kobject, documentation, and driver core patches against your 2.6.24 git tree. They can be broken down into these major areas: - Documentation updates (language translations and fixes, as well as kobject and kset documenatation updates.) - major kset/kobject/ktype rework and fixes. This cleans up the kset and kobject and ktype relationship and architecture, making sense of things now, and good documenation and samples are provided for others to use. Also the attributes for kobjects are much easier to handle now. This cleaned up a LOT of code all through the kernel, making kobjects easier to use if you want to. - struct bus_type has been reworked to now handle the lifetime rules properly, as the kobject is properly dynamic. - struct driver has also been reworked, and now the lifetime issues are resolved. - the block subsystem has been converted to use struct device now, and not "raw" kobjects. This patch has been in the -mm tree for over a year now, and finally all the issues are worked out with it. Older distros now properly work with new kernels, and no userspace updates are needed at all. - nozomi driver is added. This has also been in -mm for a long time, and many people have asked for it to go in. It is now in good enough shape to do so. - lots of class_device conversions to use struct device instead. The tree is almost all cleaned up now, only SCSI and IB is the remaining code to fix up... Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ All of these patches have been in the -mm tree for a number of months. Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h Documentation/kobject.txt | 489 +++-- Documentation/pnp.txt |4 +- Documentation/s390/cds.txt |2 +- Documentation/vm/slabinfo.c|2 +- Documentation/vm/slub.txt |2 +- Documentation/zh_CN/CodingStyle| 701 +++ Documentation/zh_CN/HOWTO | 10 +- Documentation/zh_CN/SubmittingDrivers | 168 ++ Documentation/zh_CN/SubmittingPatches | 416 Documentation/zh_CN/oops-tracing.txt | 212 +++ Documentation/zh_CN/sparse.txt | 100 + Documentation/zh_CN/stable_kernel_rules.txt| 66 + .../zh_CN/volatile-considered-harmful.txt | 113 ++ arch/arm/kernel/time.c |4 +- arch/arm/mach-integrator/integrator_ap.c |2 +- arch/arm/mach-omap1/pm.c | 23 +- arch/arm/mach-pxa/cm-x270.c|2 +- arch/arm/mach-pxa/lpd270.c |2 +- arch/arm/mach-pxa/lubbock.c|2 +- arch/arm/mach-pxa/mainstone.c |2 +- arch/arm/mach-s3c2410/s3c2410.c|2 +- arch/arm/mach-s3c2412/s3c2412.c|2 +- arch/arm/mach-s3c2440/mach-osiris.c|2 +- arch/arm/mach-s3c2443/s3c2443.c|2 +- arch/arm/mach-sa1100/irq.c |2 +- arch/arm/oprofile/common.c |2 +- arch/arm/plat-omap/gpio.c |2 +- arch/arm/plat-s3c24xx/dma.c|2 +- arch/arm/plat-s3c24xx/s3c244x.c|4 +- arch/avr32/kernel/time.c |2 +- arch/cris/arch-v32/drivers/iop_fw_load.c | 11 + arch/ia64/kernel/topology.c| 26 +- arch/mips/kernel/i8259.c |2 +- arch/powerpc/platforms/cell/spu_base.c |2 +- arch/powerpc/platforms/powermac/pic.c |2 +- arch/powerpc/platforms/pseries/power.c | 32 +- arch/powerpc/sysdev/ipic.c |2 +- arch/powerpc/sysdev/mpic.c |2 +- arch/powerpc/sysdev/qe_lib/qe_ic.c |2 +- arch/ppc/syslib/ipic.c |2 +- arch/ppc/syslib/open_pic.c |2 +- arch/ppc/syslib/open_pic2.c|2 +- arch/s390/hypfs/inode.c| 13 +- arch/s390/kernel/ipl.c | 147 +- arch/s390/kernel/time.c|2 +-
[GIT PATCH] driver core patches against 2.6.24
Due to the low level nature of these patches, and because they touch so many different parts of the kernel, a number of the subsystem maintainers have asked me to get them in first to make merging other trees easier. Here are a pretty large number of kobject, documentation, and driver core patches against your 2.6.24 git tree. They can be broken down into these major areas: - Documentation updates (language translations and fixes, as well as kobject and kset documenatation updates.) - major kset/kobject/ktype rework and fixes. This cleans up the kset and kobject and ktype relationship and architecture, making sense of things now, and good documenation and samples are provided for others to use. Also the attributes for kobjects are much easier to handle now. This cleaned up a LOT of code all through the kernel, making kobjects easier to use if you want to. - struct bus_type has been reworked to now handle the lifetime rules properly, as the kobject is properly dynamic. - struct driver has also been reworked, and now the lifetime issues are resolved. - the block subsystem has been converted to use struct device now, and not raw kobjects. This patch has been in the -mm tree for over a year now, and finally all the issues are worked out with it. Older distros now properly work with new kernels, and no userspace updates are needed at all. - nozomi driver is added. This has also been in -mm for a long time, and many people have asked for it to go in. It is now in good enough shape to do so. - lots of class_device conversions to use struct device instead. The tree is almost all cleaned up now, only SCSI and IB is the remaining code to fix up... Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ All of these patches have been in the -mm tree for a number of months. Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h Documentation/kobject.txt | 489 +++-- Documentation/pnp.txt |4 +- Documentation/s390/cds.txt |2 +- Documentation/vm/slabinfo.c|2 +- Documentation/vm/slub.txt |2 +- Documentation/zh_CN/CodingStyle| 701 +++ Documentation/zh_CN/HOWTO | 10 +- Documentation/zh_CN/SubmittingDrivers | 168 ++ Documentation/zh_CN/SubmittingPatches | 416 Documentation/zh_CN/oops-tracing.txt | 212 +++ Documentation/zh_CN/sparse.txt | 100 + Documentation/zh_CN/stable_kernel_rules.txt| 66 + .../zh_CN/volatile-considered-harmful.txt | 113 ++ arch/arm/kernel/time.c |4 +- arch/arm/mach-integrator/integrator_ap.c |2 +- arch/arm/mach-omap1/pm.c | 23 +- arch/arm/mach-pxa/cm-x270.c|2 +- arch/arm/mach-pxa/lpd270.c |2 +- arch/arm/mach-pxa/lubbock.c|2 +- arch/arm/mach-pxa/mainstone.c |2 +- arch/arm/mach-s3c2410/s3c2410.c|2 +- arch/arm/mach-s3c2412/s3c2412.c|2 +- arch/arm/mach-s3c2440/mach-osiris.c|2 +- arch/arm/mach-s3c2443/s3c2443.c|2 +- arch/arm/mach-sa1100/irq.c |2 +- arch/arm/oprofile/common.c |2 +- arch/arm/plat-omap/gpio.c |2 +- arch/arm/plat-s3c24xx/dma.c|2 +- arch/arm/plat-s3c24xx/s3c244x.c|4 +- arch/avr32/kernel/time.c |2 +- arch/cris/arch-v32/drivers/iop_fw_load.c | 11 + arch/ia64/kernel/topology.c| 26 +- arch/mips/kernel/i8259.c |2 +- arch/powerpc/platforms/cell/spu_base.c |2 +- arch/powerpc/platforms/powermac/pic.c |2 +- arch/powerpc/platforms/pseries/power.c | 32 +- arch/powerpc/sysdev/ipic.c |2 +- arch/powerpc/sysdev/mpic.c |2 +- arch/powerpc/sysdev/qe_lib/qe_ic.c |2 +- arch/ppc/syslib/ipic.c |2 +- arch/ppc/syslib/open_pic.c |2 +- arch/ppc/syslib/open_pic2.c|2 +- arch/s390/hypfs/inode.c| 13 +- arch/s390/kernel/ipl.c | 147 +- arch/s390/kernel/time.c|2 +-
