user/sven/linux.git/kernel/module.c, branch v2.6.14.2

[PATCH] use add_taint() for setting tainted bit flags

2005-09-13T15:22:29Z

Use the add_taint() interface for setting tainted bit flags instead of doing it manually. Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] flush icache early when loading module

2005-09-07T23:57:26Z

Change the sequence of operations performed during module loading to flush the instruction cache before module parameters are processed. If a module has parameters of an unusual type that cannot be handled using the standard accessor functions param_set_xxx and param_get_xxx, it has to to provide a set of accessor functions for this type. This requires module code to be executed during parameter processing, which is of course only possible after the icache has been flushed. Signed-off-by: Thomas Koeller Cc: Rusty Russell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Module per-cpu alignment cannot always be met

2005-08-02T04:38:01Z

The module code assumes noone will ever ask for a per-cpu area more than SMP_CACHE_BYTES aligned. However, as these cases show, gcc asks sometimes asks for 32-byte alignment for the per-cpu section on a module, and if CONFIG_X86_L1_CACHE_SHIFT is 4, we hit that BUG_ON(). This is obviously an unusual combination, as there have been few reports, but better to warn than die. See: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0768.html And more recently: http://bugs.gentoo.org/show_bug.cgi?id=97006 Signed-off-by: Rusty Russell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] make various thing static

2005-06-24T07:06:43Z

Another rollup of patches which give various symbols static scope Signed-off-by: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] modules: add version and srcversion to sysfs

2005-06-24T07:06:40Z

This patch adds version and srcversion files to /sys/module/${modulename} containing the version and srcversion fields of the module's modinfo section (if present). /sys/module/e1000 |-- srcversion `-- version This patch differs slightly from the version posted in January, as it now uses the new kstrdup() call in -mm. Why put this in sysfs? a) Tools like DKMS, which deal with changing out individual kernel modules without replacing the whole kernel, can behave smarter if they can tell the version of a given module. The autoinstaller feature, for example, which determines if your system has a "good" version of a driver (i.e. if the one provided by DKMS has a newer verson than that provided by the kernel package installed), and to automatically compile and install a newer version if DKMS has it but your kernel doesn't yet have that version. b) Because sysadmins manually, or with tools like DKMS, can switch out modules on the file system, you can't count on 'modinfo foo.ko', which looks at /lib/modules/${kernelver}/... actually matching what is loaded into the kernel already. Hence asking sysfs for this. c) as the unbind-driver-from-device work takes shape, it will be possible to rebind a driver that's built-in (no .ko to modinfo for the version) to a newly loaded module. sysfs will have the currently-built-in version info, for comparison. d) tech support scripts can then easily grab the version info for what's running presently - a question I get often. There has been renewed interest in this patch on linux-scsi by driver authors. As the idea originated from GregKH, I leave his Signed-off-by: intact, though the implementation is nearly completely new. Compiled and run on x86 and x86_64. From: Matthew Dobson build fix From: Thierry Vignaud build fix From: Matthew Dobson warning fix Signed-off-by: Greg Kroah-Hartman Signed-off-by: Matt Domsch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] smp_processor_id() cleanup

2005-06-22T01:46:13Z

This patch implements a number of smp_processor_id() cleanup ideas that Arjan van de Ven and I came up with. The previous __smp_processor_id/_smp_processor_id/smp_processor_id API spaghetti was hard to follow both on the implementational and on the usage side. Some of the complexity arose from picking wrong names, some of the complexity comes from the fact that not all architectures defined __smp_processor_id. In the new code, there are two externally visible symbols: - smp_processor_id(): debug variant. - raw_smp_processor_id(): nondebug variant. Replaces all existing uses of _smp_processor_id() and __smp_processor_id(). Defined by every SMP architecture in include/asm-*/smp.h. There is one new internal symbol, dependent on DEBUG_PREEMPT: - debug_smp_processor_id(): internal debug variant, mapped to smp_processor_id(). Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new lib/smp_processor_id.c file. All related comments got updated and/or clarified. I have build/boot tested the following 8 .config combinations on x86: {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT} I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT. (Other architectures are untested, but should work just fine.) Signed-off-by: Ingo Molnar Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] flush icache in correct context

2005-05-31T21:54:18Z

flush_icache_range() is used in two different situation - in binfmt_elf.c & co for user space mappings and module.c for kernel modules. On m68k flush_icache_range() doesn't know which data to flush, as it has separate address spaces and the pointer argument can be valid in either address space. First I considered splitting flush_icache_range(), but this patch is simpler. Setting the correct context gives flush_icache_range() enough information to flush the correct data. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Change synchronize_kernel to _rcu and _sched

2005-05-01T15:59:04Z

This patch changes calls to synchronize_kernel(), deprecated in the earlier "Deprecate synchronize_kernel, GPL replacement" patch to instead call the new synchronize_rcu() and synchronize_sched() APIs. Signed-off-by: Paul E. McKenney Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Fix kallsyms/insmod/rmmod race

2005-03-08T01:48:29Z

The attached patch fixes a race between kallsyms and insmod/rmmod. The problem is this: (1) The various kallsyms functions poke around in the module list without any locking so that they can be called from the oops handler. (2) Although insmod and rmmod use locks to exclude each other, these have no effect on the kallsyms function. (3) Although rmmod modifies the module state with the machine "stopped", it hasn't removed the metadata from the module metadata list, meaning that as soon as the machine is "restarted", the metadata can be observed by kallsyms. It's not possible to say that an item in that list should be ignored if it's state is marked as inactive - you can't get at the state information because you can't trust the metadata in which it is embedded. Furthermore, list linkage information is embedded in the metadata too, so you can't trust that either... (4) kallsyms may be walking the module list without a lock whilst either insmod or rmmod are busy changing it. insmod probably isn't a problem since nothing is going a way, but rmmod is as it's deleting an entry. (5) Therefore nothing that uses these functions can in any way trust any pointers to "static" data (such as module symbol names or module names) that are returned. (6) On ppc64 the problems are exacerbated since the hypervisor may reschedule bits of the kernel, making operations that appear adjacent occur a long time apart. This patch fixes the race by only linking/unlinking modules into/from the master module list with the machine in the "stopped" state. This means that any "static" information can be trusted as far as the next kernel reschedule on any given CPU without the need to hold any locks. However, I'm not sure how this is affected by preemption. I suspect more work may need to be done in that case, but I'm not entirely sure. This also means that rmmod has to bump the machine into the stopped state twice... but since that shouldn't be a common operation, I don't think that's a problem. I've amended this patch to not get spinlocks whilst in the machine locked state - there's no point as nothing else can be holding spinlocks. Signed-Off-By: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Catch module parameter parsing failures

2005-01-11T11:18:21Z

Radheka Godse pointed out that parameter parsing failures allow a module still to be loaded. Trivial fix. Signed-off-by: Rusty Russell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds