- 16 Jun, 2008 2 commits
-
-
Lai Jiangshan authored
Since softirq works for rcu reclaimer, rcu_tasklet is unused now. Signed-off-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Cc: "Paul E. McKenney" <paulmck@us.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
This reverts commit 9aaffc89. That commit was a very bad idea. RCU_TORTURE found many boot timing bugs and other sorts of bugs in the past, so excluding it from boot images is very silly. The option already depends on DEBUG_KERNEL and is disabled by default. Even when it runs, the test threads are reniced. If it annoys people we could add a runtime sysctl.
-
- 22 May, 2008 1 commit
-
-
Ingo Molnar authored
Signed-off-by:
-
- 19 May, 2008 13 commits
-
-
Ingo Molnar authored
this file has rculist dependency but did not explicitly include it, which broke the build. Signed-off-by: -
Huang Weiyi authored
Removed duplicated include file <linux/rcupdate.h> in kernel/rcupreempt.c. Signed-off-by:
Huang Weiyi <weiyi.huang@gmail.com> Signed-off-by:
-
Huang Weiyi authored
Removed duplicated include file <linux/rcupdate.h> in kernel/rcupreempt_trace.c Signed-off-by:
-
Paul E. McKenney authored
RCU list iterators: should prefetch ever be optimised out with no side-effects, the current version will lose the barrier completely. Pointed-out-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
Paul E. McKenney authored
The comment was correct -- need to make the code match the comment. Without this patch, if a CPU goes dynticks idle (and stays there forever) in just the right phase of preemptible-RCU grace-period processing, grace periods stall. The offending sequence of events (courtesy of Promela/spin, at least after I got the liveness criterion coded correctly...) is as follows: o CPU 0 is in dynticks-idle mode. Its dynticks_progress_counter is (say) 10. o CPU 0 takes an interrupt, so rcu_irq_enter() increments CPU 0's dynticks_progress_counter to 11. o CPU 1 is doing RCU grace-period processing in rcu_try_flip_idle(), sees rcu_pending(), so invokes dyntick_save_progress_counter(), which in turn takes a snapshot of CPU 0's dynticks_progress_counter into CPU 0's rcu_dyntick_snapshot -- now set to 11. CPU 1 then updates the RCU grace-period state to rcu_try_flip_waitack(). o CPU 0 returns from its interrupt, so rcu_irq_exit() increments CPU 0's dynticks_progress_counter to 12. o CPU 1 later invokes rcu_try_flip_waitack(), which notices that CPU 0 has not yet responded, and hence in turn invokes rcu_try_flip_waitack_needed(). This function examines the state of CPU 0's dynticks_progress_counter and rcu_dyntick_snapshot variables, which it copies to curr (== 12) and snap (== 11), respectively. Because curr!=snap, the first condition fails. Because curr-snap is only 1 and snap is odd, the second condition fails. rcu_try_flip_waitack_needed() therefore incorrectly concludes that it must wait for CPU 0 to explicitly acknowledge the counter flip. o CPU 0 remains forever in dynticks-idle mode, never taking any more hardware interrupts or any NMIs, and never running any more tasks. (Of course, -something- will usually eventually happen, which might be why we haven't seen this one in the wild. Still should be fixed!) Therefore the grace period never ends. Fix is to make the code match the comment, as shown below. With this fix, the above scenario would be satisfied with curr being even, and allow the grace period to proceed. Signed-off-by:
-
Franck Bui-Huu authored
Make almost all list mutation primitives use rcu_assign_pointer(). The main point of this being readability improvement. Signed-off-by:
Franck Bui-Huu <fbuihuu@gmail.com> Cc: "Paul E. McKenney" <paulmck@us.ibm.com> Cc: Josh Triplett <josh@kernel.org> Signed-off-by:
-
Franck Bui-Huu authored
Move rcu-protected lists from list.h into a new header file rculist.h. This is done because list are a very used primitive structure all over the kernel and it's currently impossible to include other header files in this list.h without creating some circular dependencies. For example, list.h implements rcu-protected list and uses rcu_dereference() without including rcupdate.h. It actually compiles because users of rcu_dereference() are macros. Others RCU functions could be used too but aren't probably because of this. Therefore this patch creates rculist.h which includes rcupdates without to many changes/troubles. Signed-off-by:
Josh Triplett <josh@kernel.org> Signed-off-by:
-
Paul E. McKenney authored
Long-delayed update to the RCU documentation, including adding the new call_rcu_sched() and rcu_barrier_sched() APIs. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Paul E. McKenney authored
Add entry to rcu_torture_ops allowing the correct barrier function to be used upon exit from rcutorture. Also add torture options for the new call_rcu_sched() API. Signed-off-by:
-
Paul E. McKenney authored
Add rcu_barrier_sched() and rcu_barrier_bh(). With these in place, rcutorture no longer gives the occasional oops when repeatedly starting and stopping torturing rcu_bh. Also adds the API needed to flush out pre-existing call_rcu_sched() callbacks. Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by:
-
Paul E. McKenney authored
Add comments to the logic that infers quiescent states when interrupting from either user mode or the idle loop. Also add a memory barrier: it appears that James Huang was in fact onto something, as the scheduler is much less synchronization happy than it once was, so we can no longer rely on its memory barriers in all cases. Signed-off-by:
James Huang <jamesclhuang@yahoo.com> Signed-off-by:
-
Paul E. McKenney authored
Fourth cut of patch to provide the call_rcu_sched(). This is again to synchronize_sched() as call_rcu() is to synchronize_rcu(). Should be fine for experimental and -rt use, but not ready for inclusion. With some luck, I will be able to tell Andrew to come out of hiding on the next round. Passes multi-day rcutorture sessions with concurrent CPU hotplugging. Fixes since the first version include a bug that could result in indefinite blocking (spotted by Gautham Shenoy), better resiliency against CPU-hotplug operations, and other minor fixes. Fixes since the second version include reworking grace-period detection to avoid deadlocks that could happen when running concurrently with CPU hotplug, adding Mathieu's fix to avoid the softlockup messages, as well as Mathieu's fix to allow use earlier in boot. Fixes since the third version include a wrong-CPU bug spotted by Andrew, getting rid of the obsolete synchronize_kernel API that somehow snuck back in, merging spin_unlock() and local_irq_restore() in a few places, commenting the code that checks for quiescent states based on interrupting from user-mode execution or the idle loop, removing some inline attributes, and some code-style changes. Known/suspected shortcomings: o I still do not entirely trust the sleep/wakeup logic. Next step will be to use a private snapshot of the CPU online mask in rcu_sched_grace_period() -- if the CPU wasn't there at the start of the grace period, we don't need to hear from it. And the bit about accounting for changes in online CPUs inside of rcu_sched_grace_period() is ugly anyway. o It might be good for rcu_sched_grace_period() to invoke resched_cpu() when a given CPU wasn't responding quickly, but resched_cpu() is declared static... This patch also fixes a long-standing bug in the earlier preemptable-RCU implementation of synchronize_rcu() that could result in loss of concurrent external changes to a task's CPU affinity mask. I still cannot remember who reported this... Signed-off-by:
-
Steven Rostedt authored
rcu_batches_completed and rcu_patches_completed_bh are both declared in rcuclassic.h and rcupreempt.h. This patch removes the extra prototypes for them from rcupdate.h. rcu_batches_completed_bh is defined as a static inline in the rcupreempt.h header file. Trying to export this as EXPORT_SYMBOL_GPL causes linking problems with the powerpc linker. There's no need to export a static inlined function. Modules must be compiled with the same type of RCU implementation as the kernel they are for. Signed-off-by:
Steven Rostedt <srostedt@redhat.com> Signed-off-by:
-
- 18 May, 2008 24 commits
-
-
Linus Torvalds authored
-
git://jdelvare.pck.nerim.net/jdelvare-2.6Linus Torvalds authored
* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6: i2c/max6875: Really prevent 24RF08 corruption i2c-amd756: Fix functionality flags i2c: Kill the old driver matching scheme i2c: Convert remaining new-style drivers to use module aliasing i2c: Switch pasemi to the new device/driver matching scheme i2c: Clean up Blackfin BF527 I2C device declarations i2c-nforce2: Disable the second SMBus channel on the DFI Lanparty NF4 Expert i2c: New co-maintainer
-
Geert Uytterhoeven authored
Add multi_defconfig, to build a kernel for all supported m68k platforms, excluding Sun 3 (Sun 3 kernels are incompatible with all other m68k platforms) Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Geert Uytterhoeven authored
Update the m68k defconfigs Signed-off-by:
-
Geert Uytterhoeven authored
m68k: Correctly handle multi-ISA at runtime in multi-platform kernels Signed-off-by:
-
Geert Uytterhoeven authored
The *_ISA type defines are quite generic and cause namespace conflicts (e.g. with `AMIGAHW_DECLARE(GG2_ISA)' in <asm/amigahw.h>) for some kernel configurations. Use ISA_TYPE_* to avoid such conflicts. Signed-off-by:
-
Geert Uytterhoeven authored
UIO needs m68k_mmutype: ERROR: "m68k_mmutype" [drivers/uio/uio.ko] undefined! (noticed by Christian T. Steigies) Signed-off-by:
-
Geert Uytterhoeven authored
Mark Q40/Q60 floppy support broken: arch/m68k/q40/q40ints.c: In function 'q40_irq_handler': arch/m68k/q40/q40ints.c:214: error: implicit declaration of function 'floppy_hardint' Including <asm/floppy.h> doesn't help, as it causes a lot of additional error messages (cfr. Sun 3x). Signed-off-by: -
Geert Uytterhoeven authored
According to the tests in do_initcalls(), the proper error code in case no device is found is -ENODEV, not -ENXIO or -EIO. Signed-off-by:
-
Geert Uytterhoeven authored
Some input drivers do not check whether they're actually running on the correct platform, causing multi-platform kernels to crash if they are not. Signed-off-by:
-
Geert Uytterhoeven authored
Some network drivers do not check whether they're actually running on the correct platform, causing multi-platform kernels to crash if they are not. Signed-off-by:
-
Geert Uytterhoeven authored
The Apollo frame buffer device driver (dnfb) doesn't check whether it's actually running on Apollo hardware, causing a crash if it isn't. Signed-off-by:
-
Geert Uytterhoeven authored
The Macintosh IDE driver (macide) doesn't check whether it's actually running on Mac hardware, causing a crash if it isn't. Signed-off-by:
-
Geert Uytterhoeven authored
When running a HP300-enabled kernel on non-HP300 hardware, a test in the early startup code jumps to the wrong label, causing a double bus fault. Signed-off-by:
-
Geert Uytterhoeven authored
Use `__builtin_trap()' instead of `asm volatile("illegal")' in the m68k BUG() macros (as suggested by Andrew Pinski), to kill warnings in code that assumes BUG() does not return. Signed-off-by: -
Geert Uytterhoeven authored
m68k vme_scc: - make scc_ports[] static - kill unused global scc_initialized Signed-off-by:
-
Geert Uytterhoeven authored
The Hisoft Whippet PCMCIA serial driver has been removed a long time ago, but it's Kconfig symbol still existed. Signed-off-by:
-
Geert Uytterhoeven authored
Correct FB_HP300 dependencies: - FB_HP300 doesn't depend only on HP300, but also on DIO (which depends on HP300) - FB_HP300 does not need FB_CFB_FILLRECT Signed-off-by: -
Geert Uytterhoeven authored
CONFIG_FB_DAFB is a leftover from pre-Kconfig Signed-off-by:
-
Geert Uytterhoeven authored
Convert access_ok() from a macro to an inline function, so the compiler no longer complains about unused variables: fs/read_write.c: In function 'rw_copy_check_uvector': fs/read_write.c:556: warning: unused variable 'buf' Signed-off-by: -
Jean Delvare authored
i2c-core takes care of the possible corruption of 24RF08 chips for quite some times, so device devices no longer need to do it. And they really should not, as applying the prevention twice voids it. I thought that I had fixed all drivers long ago but apparently I had missed that one. Signed-off-by:Jean Delvare <khali@linux-fr.org> Cc: Ben Gardner <bgardner@wabtec.com>
-
Jean Delvare authored
The i2c-amd756 driver pretends to support SMBus process call transactions but actually does not. Fix it. Signed-off-by: -
Jean Delvare authored
Remove the old driver_name/type scheme for i2c driver matching. Only the standard aliasing model will be used from now on. Signed-off-by: -
Jean Delvare authored
Update all the remaining new-style i2c drivers to use standard module aliasing instead of the old driver_name/type driver matching scheme. Note that the tuner driver is a bit quirky at the moment, as it overwrites i2c_client.name with arbitrary strings. We write "tuner" back on remove, to make sure that driver cycling will work properly, but there may still be troublesome corner cases. Signed-off-by:
-
