Race condition in module load causing undefined symbols
in [Kernel]
|
Next: Am1771 wireless driver?
From: Andi Kleen on 14 Jun 2005 13:00 Steve Lord <lord(a)xfs.org> writes: > > So is this some P4 specific optimization which is not working as > intended? The only pentium specific optimizations that are enabled by MPENTIUM4 is to tell the compiler to compile for pentium4 and a few settings in arch/i386/Kconfig. You could enable/disable these individually and see if you can track it down with a binary search. Most of this stuff should be fairly harmless though and be only microoptimizations; I cannot see how they should cause user visible races. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steve Lord on 14 Jun 2005 13:20 Andi Kleen wrote: > Steve Lord <lord(a)xfs.org> writes: > >>So is this some P4 specific optimization which is not working as >>intended? > > > The only pentium specific optimizations that are enabled by MPENTIUM4 > is to tell the compiler to compile for pentium4 and a few settings > in arch/i386/Kconfig. > > You could enable/disable these individually and see if you can track > it down with a binary search. > > Most of this stuff should be fairly harmless though and be only > microoptimizations; I cannot see how they should cause user visible > races. > > -Andi > I see what you mean about there not being a lot of difference between the two, however, the other difference between the builds would be -mtune=pentium3 and -mtune=pentium4. Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: K.R. Foley on 14 Jun 2005 13:20 Steve Lord wrote: <snip> > So is this some P4 specific optimization which is not working as > intended? > > Steve > > I'd say not since the first system I saw this on was a dual PIII Xeon. While I am not 100% sure that the problems are related, the problem that I saw on my 2.6 system also went away when I disabled hyper-threading in the bios. It really just seems to me like it is some hard-to-trigger race. -- kr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steve Lord on 14 Jun 2005 13:50 K.R. Foley wrote: > Steve Lord wrote: > <snip> > >> So is this some P4 specific optimization which is not working as >> intended? >> >> Steve >> >> > > I'd say not since the first system I saw this on was a dual PIII Xeon. > While I am not 100% sure that the problems are related, the problem that > I saw on my 2.6 system also went away when I disabled hyper-threading in > the bios. It really just seems to me like it is some hard-to-trigger race. > Not too hard for me :-( Definitely a race, and it appears to be somewhere in the fork/exec/wait complex at the very least. insmod is not built into nash, so is getting run as a seperate process. Since module loading itself is synchronous, the error would seem most likely to be happening in sys_wait4. It could be the compiler doing a bad optimization, it could be some other optimization code triggered by the Pentium 4 config option, or, as you say, it could be a race which is being opened up by the changed build flags. Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Prarit Bhargava on 14 Jun 2005 14:30
Colleagues, (Copied and edited from a post I made on linux-hotplug-devel last month.) I've privately emailed Steve with a quick-and-dirty solution for the problems he was experiencing with the system boot. I wasn't sure if he was having the same problems I've had with 2.6.12 and old packages but it looks like he was. I'm surprised we haven't had more people on this list wondering about the strange behaviour of their initrd/initramfs :) . When I looked at the original output Steve had posted I noticed that it looked like drivers were attempting to load at the same time and because of this he eventually hit an oops. I (and an engineer from another company working on another arch) have hit the same problem due to the requirements of our current work. (Unfortunately, I'm more familiar with RedHat/Fedora than I am with other distro's -- please bear with me.) The issue is that David Howells posted a patch that changed the behaviour of kallsyms/insmod/rmmod sometime ago. The patch *is correct* in what it does, however, the patch requires that /sbin/sh must be aware of pid returns by wait(). http://lkml.org/lkml/2005/1/17/132 There are two fixes that I'm aware of, and depending on what you're doing they are both "correct" (although in the case of developing in 2.6.12, IMO, you _must_ do the latter). The first fix is for the situation where you're developing for a specific distribution. If this is the case, then you should back out the patch above and continue moving forward. The second fix, and again you must do this if you're developing 2.6.12, is to *update the mkinitrd package* which has a new version of /bin/sh. P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |