user/sven/linux.git/lib/bust_spinlocks.c, branch v3.4.46

oops handling: ensure that any oops is flushed to the mtdoops console

2009-01-06T23:59:11Z

This used to work unpatched with older kernels, during the development phase of mtdoops. Before commit e3e8a75d2acfc61ebf25524666a0a2c6abb0620c a space was printed with console_loglevel set to 15, which probably flushed the oops message as a side effect. This is another patch from the Nokia N810 kernel. Signed-off-by: Viktor Rosendahl Cc: Alan Cox Cc: Ingo Molnar Cc: David Woodhouse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

handle recursive calls to bust_spinlocks()

2007-10-17T15:42:56Z

Various architectures may call bust_spinlocks() recursively; the function itself, however, doesn't appear to be meant to be called in this manner. Nevertheless, this doesn't appear to be a problem as long as bust_spinlocks(0) doesn't get called twice in a row (otherwise, unblank_screen() may enter the scheduler). However, at least on i386 die() has been capable of returning (and on other architectures this should really be that way, too) when notify_die() returns NOTIFY_STOP. Short of getting a reply to a respective query, this patch makes bust_spinlocks() increment/decrement oops_in_progress, and wake klogd only when the count drops back to zero. Signed-off-by: Jan Beulich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Extract and use wake_up_klogd()

2007-02-11T18:51:34Z

Remove hack with printing space to wake up klogd. Use explicit wake_up_klogd(). See earlier discussion http://groups.google.com/group/fa.linux.kernel/browse_frm/thread/75f496668409f58d/1a8f28983a51e1ff?lnk=st&q=wake_up_klogd+group%3Afa.linux.kernel&rnum=2#1a8f28983a51e1ff Signed-off-by: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Consolidate bust_spinlocks()

2007-02-11T18:51:34Z

Part of long forgotten patch http://groups.google.com/group/fa.linux.kernel/msg/e98e941ce1cf29f6?dmode=source Since then, m32r grabbed two copies. Leave s390 copy because of important absence of CONFIG_VT, but remove references to non-existent timerlist_lock. ia64 also loses timerlist_lock. Signed-off-by: Alexey Dobriyan Acked-by: Martin Schwidefsky Cc: Andi Kleen Cc: "Luck, Tony" Cc: Hirokazu Takata Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Remove obsolete #include

2006-06-30T17:25:36Z

Signed-off-by: Jörn Engel Signed-off-by: Adrian Bunk

[PATCH] smptimers, old BH removal, tq-cleanup

2002-09-29T04:00:25Z

This is the smptimers patch plus the removal of old BHs and a rewrite of task-queue handling. Basically with the removal of TIMER_BH i think the time is right to get rid of old BHs forever, and to do a massive cleanup of all related fields. The following five basic 'execution context' abstractions are supported by the kernel: - hardirq - softirq - tasklet - keventd-driven task-queues - process contexts I've done the following cleanups/simplifications to task-queues: - removed the ability to define your own task-queue, what can be done is to schedule_task() a given task to keventd, and to flush all pending tasks. This is actually a quite easy transition, since 90% of all task-queue users in the kernel used BH_IMMEDIATE - which is very similar in functionality to keventd. I believe task-queues should not be removed from the kernel altogether. It's true that they were written as a candidate replacement for BHs originally, but they do make sense in a different way: it's perhaps the easiest interface to do deferred processing from IRQ context, in performance-uncritical code areas. They are easier to use than tasklets. code that cares about performance should convert to tasklets - as the timer code and the serial subsystem has done already. For extreme performance softirqs should be used - the net subsystem does this. and we can do this for 2.6 - there are only a couple of areas left after fixing all the BH_IMMEDIATE places. i have moved all the taskqueue handling code into kernel/context.c, and only kept the basic 'queue a task' definitions in include/linux/tqueue.h. I've converted three of the most commonly used BH_IMMEDIATE users: tty_io.c, floppy.c and random.c. [random.c might need more thought though.] i've also cleaned up kernel/timer.c over that of the stock smptimers patch: privatized the timer-vec definitions (nothing needs it, init_timer() used it mistakenly) and cleaned up the code. Plus i've moved some code around that does not belong into timer.c, and within timer.c i've organized data and functions along functionality and further separated the base timer code from the NTP bits. net_bh_lock: i have removed it, since it would synchronize to nothing. The old protocol handlers should still run on UP, and on SMP the kernel prints a warning upon use. Alexey, is this approach fine with you? scalable timers: i've further improved the patch ported to 2.5 by wli and Dipankar. There is only one pending issue i can see, the question of whether to migrate timers in mod_timer() or not. I'm quite convinced that they should be migrated, but i might be wrong. It's a 10 lines change to switch between migrating and non-migrating timers, we can do performance tests later on. The current, more complex migration code is pretty fast and has been stable under extremely high networking loads in the past 2 years, so we can immediately switch to the simpler variant if someone proves it improves performance. (I'd say if non-migrating timers improve Apache performance on one of the bigger NUMA boxes then the point is proven, no further though will be needed.)

v2.4.9.10 -> v2.4.9.11

2002-02-05T04:18:55Z

- Neil Brown: md cleanups/fixes - Andrew Morton: console locking merge - Andrea Arkangeli: major VM merge