Re: SMP kernels and linking

Keith Owens (kaos@ocs.com.au)
Wed, 27 Oct 1999 08:33:40 +1000


On Tue, 26 Oct 1999 16:29:25 +0200,
<Fabian.Frederick@prov-liege.be> wrote:
> Let's say I've got a kernel compiled using both 686 directive &
>SMP
> OTOH, one module is compiled with extern makefile using
> _only_ _D__MODULE and insmod(ing) works ... why ?
> IMHO, that module is 386 UP release.

Setting SMP changes the meaning and sizes of some structures,
especially spinlocks. So your kernel is compiled with SMP spinlocks
(which do something) but your module is compiled with UP spinlocks (do
nothing). You get away with it if your module does not use any
spinlocks or if there is no contention for the lock. But if there is
contention then your module thinks it owns the lock while the rest of
the kernel thinks the lock is free. Can you say "race conditions"?
Spinlocks are not the only thing affected by SMP, just the biggest
problem. Even if your module does not use locks, it might use other
structures that are compiled differently for SMP/UP.

insmod works because your kernel and module are compiled without kernel
symbols. The whole point of kernel symbols is to detect module/kernel
mismatches (including SMP/UP) and refuse to load the module. If you
choose to bypass an important kernel check, well this is Linux, you are
allowed to shoot yourself in the foot.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/