- 03 Jul, 2006 12 commits
-
-
Ingo Molnar authored
Do 'make oldconfig' and accept all the defaults for new config options - reboot into the kernel and if everything goes well it should boot up fine and you should have /proc/lockdep and /proc/lockdep_stats files. Typically if the lock validator finds some problem it will print out voluminous debug output that begins with "BUG: ..." and which syslog output can be used by kernel developers to figure out the precise locking scenario. What does the lock validator do? It "observes" and maps all locking rules as they occur dynamically (as triggered by the kernel's natural use of spinlocks, rwlocks, mutexes and rwsems). Whenever the lock validator subsystem detects a new locking scenario, it validates this new rule against the existing set of rules. If this new rule is consistent with the existing set of rules then the new rule is added transparently and the kernel continues as normal. If the new rule could create a deadlock scenario then this condition is printed out. When determining validity of locking, all possible "deadlock scenarios" are considered: assuming arbitrary number of CPUs, arbitrary irq context and task context constellations, running arbitrary combinations of all the existing locking scenarios. In a typical system this means millions of separate scenarios. This is why we call it a "locking correctness" validator - for all rules that are observed the lock validator proves it with mathematical certainty that a deadlock could not occur (assuming that the lock validator implementation itself is correct and its internal data structures are not corrupted by some other kernel subsystem). [see more details and conditionals of this statement in include/linux/lockdep.h and Documentation/lockdep-design.txt] Furthermore, this "all possible scenarios" property of the validator also enables the finding of complex, highly unlikely multi-CPU multi-context races via single single-context rules, increasing the likelyhood of finding bugs drastically. In practical terms: the lock validator already found a bug in the upstream kernel that could only occur on systems with 3 or more CPUs, and which needed 3 very unlikely code sequences to occur at once on the 3 CPUs. That bug was found and reported on a single-CPU system (!). So in essence a race will be found "piecemail-wise", triggering all the necessary components for the race, without having to reproduce the race scenario itself! In its short existence the lock validator found and reported many bugs before they actually caused a real deadlock. To further increase the efficiency of the validator, the mapping is not per "lock instance", but per "lock-class". For example, all struct inode objects in the kernel have inode->inotify_mutex. If there are 10,000 inodes cached, then there are 10,000 lock objects. But ->inotify_mutex is a single "lock type", and all locking activities that occur against ->inotify_mutex are "unified" into this single lock-class. The advantage of the lock-class approach is that all historical ->inotify_mutex uses are mapped into a single (and as narrow as possible) set of locking rules - regardless of how many different tasks or inode structures it took to build this set of rules. The set of rules persist during the lifetime of the kernel. To see the rough magnitude of checking that the lock validator does, here's a portion of /proc/lockdep_stats, fresh after bootup: lock-classes: 694 [max: 2048] direct dependencies: 1598 [max: 8192] indirect dependencies: 17896 all direct dependencies: 16206 dependency chains: 1910 [max: 8192] in-hardirq chains: 17 in-softirq chains: 105 in-process chains: 1065 stack-trace entries: 38761 [max: 131072] combined max dependencies: 2033928 hardirq-safe locks: 24 hardirq-unsafe locks: 176 softirq-safe locks: 53 softirq-unsafe locks: 137 irq-safe locks: 59 irq-unsafe locks: 176 The lock validator has observed 1598 actual single-thread locking patterns, and has validated all possible 2033928 distinct locking scenarios. More details about the design of the lock validator can be found in Documentation/lockdep-design.txt, which can also found at: http://redhat.com/~mingo/lockdep-patches/lockdep-design.txt [bunk@stusta.de: cleanups] Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Ingo Molnar authored
Accurate hard-IRQ-flags and softirq-flags state tracing. This allows us to attach extra functionality to IRQ flags on/off events (such as trace-on/off). Signed-off-by:
-
Ingo Molnar authored
Framework to generate and save stacktraces quickly, without printing anything to the console. Signed-off-by:
-
Ingo Molnar authored
Locking init improvement: - introduce and use __SPIN_LOCK_UNLOCKED for array initializations, to pass in the name string of locks, used by debugging Signed-off-by:
-
Ingo Molnar authored
Work around weird section nesting build bug causing smp-alternatives failures under certain circumstances. Signed-off-by:
-
Ingo Molnar authored
Generic lock debugging: - generalized lock debugging framework. For example, a bug in one lock subsystem turns off debugging in all lock subsystems. - got rid of the caller address passing (__IP__/__IP_DECL__/etc.) from the mutex/rtmutex debugging code: it caused way too much prototype hackery, and lockdep will give the same information anyway. - ability to do silent tests - check lock freeing in vfree too. - more finegrained debugging options, to allow distributions to turn off more expensive debugging features. There's no separate 'held mutexes' list anymore - but there's a 'held locks' stack within lockdep, which unifies deadlock detection across all lock classes. (this is independent of the lockdep validation stuff - lockdep first checks whether we are holding a lock already) Here are the current debugging options: CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y which do: config DEBUG_MUTEXES bool "Mutex debugging, basic checks" config DEBUG_LOCK_ALLOC bool "Detect incorrect freeing of live mutexes" Signed-off-by: -
Ingo Molnar authored
With the lock validator we detect mutex deadlocks (and more), the mutex deadlock checking code is both redundant and slower. So remove it. Signed-off-by:
-
Ingo Molnar authored
cleanup: remove unused DEBUG_BUG_ON() defines. Signed-off-by:
-
Ingo Molnar authored
Rename DEBUG_WARN_ON() to the less generic DEBUG_LOCKS_WARN_ON() name, so that it's clear that this is a lock-debugging internal mechanism. Signed-off-by:
-
Ingo Molnar authored
Clean up rwsems. Signed-off-by:
-
Ingo Molnar authored
Add is_module_address() method - to be used by lockdep. Signed-off-by:
-
Christoph Lameter authored
It turns out that it is advantageous to leave a small portion of unmapped file backed pages if all of a zone's pages (or almost all pages) are allocated and so the page allocator has to go off-node. This allows recently used file I/O buffers to stay on the node and reduces the times that zone reclaim is invoked if file I/O occurs when we run out of memory in a zone. The problem is that zone reclaim runs too frequently when the page cache is used for file I/O (read write and therefore unmapped pages!) alone and we have almost all pages of the zone allocated. Zone reclaim may remove 32 unmapped pages. File I/O will use these pages for the next read/write requests and the unmapped pages increase. After the zone has filled up again zone reclaim will remove it again after only 32 pages. This cycle is too inefficient and there are potentially too many zone reclaim cycles. With the 1% boundary we may still remove all unmapped pages for file I/O in zone reclaim pass. However. it will take a large number of read and writes to get back to 1% again where we trigger zone reclaim again. The zone reclaim 2.6.16/17 does not show this behavior because we have a 30 second timeout. [akpm@osdl.org: rename the /proc file and the variable] Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
- 02 Jul, 2006 3 commits
-
-
Thomas Gleixner authored
The irqflags consolidation converted SA_PERCPU_IRQ to IRQF_PERCPU but did not define the new constant. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Thomas Gleixner authored
Linus: "The hacks in kernel/irq/handle.c are really horrid. REALLY horrid." They are indeed. Move the dyntick quirks to ARM where they belong. Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
- 01 Jul, 2006 10 commits
-
-
Thomas Gleixner authored
Patch from Thomas Gleixner From: Thomas Gleixner <tglx@linutronix.de> ARM has a couple of really dumb interrupt controllers. Implement a generic one and fixup the ARM migration. ARM reused the no_irq_chip for this purpose, but this does not work out for platforms which are not converted to the new interrupt type handling model. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Thomas Gleixner authored
Patch from Thomas Gleixner From: Thomas Gleixner <tglx@linutronix.de> Make the ARM dyntick implementation work with the generic irq code. This hopefully goes away once we consolidated the dyntick implementations. Signed-off-by:
-
Bjorn Helgaas authored
Make warnings more consistent. Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by:
-
Bjorn Helgaas authored
IRQ_PER_CPU is a bit in the struct irq_desc "status" field, not in the struct irqaction "flags", so the previous code checked the wrong bit. SA_PERCPU_IRQ is only used by drivers/char/mmtimer.c for SGI ia64 boxes. Signed-off-by:
-
Ingo Molnar authored
Fix futex_wake() exit condition bug when handling the robust-list with PI futexes on them. (reported by Ulrich Drepper, debugged by the lock validator.) Signed-off-by:
-
Vernon Mauery authored
lock_queue was getting called essentially twice in a row and was continually incrementing the mm_count ref count, thus causing a memory leak. Dinakar Guniguntala provided a proper fix for the problem that simply grabs the spinlock for the hash bucket queue rather than calling lock_queue. The second time we do a queue_lock in futex_lock_pi, we really only need to take the hash bucket lock. Signed-off-by:
Dinakar Guniguntala <dino@in.ibm.com> Signed-off-by:
Vernon Mauery <vernux@us.ibm.com> Acked-by:
Paul E. McKenney <paulmck@us.ibm.com> Signed-off-by:
-
Al Viro authored
Allow to tie upper bits of syscall bitmap in audit rules to kernel-defined sets of syscalls. Infrastructure, a couple of classes (with 32bit counterparts for biarch targets) and actual tie-in on i386, amd64 and ia64. Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Darrel Goeddel authored
This patch introduces object audit filters based on the elements of the SELinux context. Signed-off-by:
Darrel Goeddel <dgoeddel@trustedcs.com> Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> kernel/auditfilter.c | 25 +++++++++++++++++++++++++ kernel/auditsc.c | 40 ++++++++++++++++++++++++++++++++++++++++ security/selinux/ss/services.c | 18 +++++++++++++++++- 3 files changed, 82 insertions(+), 1 deletion(-) Signed-off-by:
-
Darrel Goeddel authored
This patch renames some audit constant definitions and adds additional definitions used by the following patch. The renaming avoids ambiguity with respect to the new definitions. Signed-off-by:
-
Amy Griffis authored
Add support for a rule key, which can be used to tie audit records to audit rules. This is useful when a watched file is accessed through a link or symlink, as well as for general audit log analysis. Because this patch uses a string key instead of an integer key, there is a bit of extra overhead to do the kstrdup() when a rule fires. However, we're also allocating memory for the audit record buffer, so it's probably not that significant. I went ahead with a string key because it seems more user-friendly. Note that the user must ensure that filterkeys are unique. The kernel only checks for duplicate rules. Signed-off-by:Amy Griffis <amy.griffis@hpd.com>
-
- 30 Jun, 2006 6 commits
-
-
Andrew Morton authored
Fix a bug identified by Zou Nan hai <nanhai.zou@intel.com>: If the system is in state SYSTEM_BOOTING, and need_resched() is true, cond_resched() returns true even though it didn't reschedule. Consequently need_resched() remains true and JBD locks up. Fix that by teaching cond_resched() to only return true if it really did call schedule(). cond_resched_lock() and cond_resched_softirq() have a problem too. If we're in SYSTEM_BOOTING state and need_resched() is true, these functions will drop the lock and will then try to call schedule(), but the SYSTEM_BOOTING state will prevent schedule() from being called. So on return, need_resched() will still be true, but cond_resched_lock() has to return 1 to tell the caller that the lock was dropped. The caller will probably lock up. Bottom line: if these functions dropped the lock, they _must_ call schedule() to clear need_resched(). Make it so. Also, uninline __cond_resched(). It's largeish, and slowpath. Acked-by:
-
David Quigley authored
This patch adds a call to the extended security_task_kill hook introduced by the prior patch to the kill_proc_info_as_uid function so that these signals can be properly mediated by security modules. It also updates the existing hook call in check_kill_permission. Signed-off-by:
David Quigley <dpquigl@tycho.nsa.gov> Signed-off-by:
James Morris <jmorris@namei.org> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: Chris Wright <chrisw@sous-sol.org> Signed-off-by:
-
Christoph Lameter authored
The zone_reclaim_interval was necessary because we were not able to determine how many unmapped pages exist in a zone. Therefore we had to scan in intervals to figure out if any pages were unmapped. With the zoned counters and NR_ANON_PAGES we now know the number of pagecache pages and the number of mapped pages in a zone. So we can simply skip the reclaim if there is an insufficient number of unmapped pages. We use SWAP_CLUSTER_MAX as the boundary. Drop all support for /proc/sys/vm/zone_reclaim_interval. Signed-off-by:
-
Jörn Engel authored
Signed-off-by:
Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by:
-
Pavel Machek authored
Remove SWSUSP_ENCRYPT config option; it is no longer implemented. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Adrian Bunk authored
Signed-off-by:
-
- 29 Jun, 2006 9 commits
-
-
Darrel Goeddel authored
This patch encapsulates the usage of eff_cap (in netlink_skb_params) within the security framework by extending security_netlink_recv to include a required capability parameter and converting all direct usage of eff_caps outside of the lsm modules to use the interface. It also updates the SELinux implementation of the security_netlink_send and security_netlink_recv hooks to take advantage of the sid in the netlink_skb_params struct. This also enables SELinux to perform auditing of netlink capability checks. Please apply, for 2.6.18 if possible. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ingo Molnar authored
Clean up the fastack concept by turning it into fasteoi and introducing the ->eoi() method for chips. This also allows the cleanup of an i386 EOI quirk - now the quirk is cleanly separated from the pure ACK implementation. Signed-off-by:
-
Benjamin Herrenschmidt authored
Note when a disable interrupt happened with the fasteoi handler as well so that delayed disable can be implemented with fasteoi-type controllers. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
-
Ingo Molnar authored
One frequent sign of IRQ handling bugs is the appearance of unexpected vectors. Print out all the IRQ state in that case. We dont want this patch upstream, but it is useful during initial testing. Signed-off-by:
-
Ingo Molnar authored
Rename no_irq_type to no_irq_chip. Signed-off-by:
-
Thomas Gleixner authored
Enable drivers to request an IRQ with a given irq-flow (trigger/polarity) setting. Signed-off-by:
-
Thomas Gleixner authored
Enable platforms to set the irq-wake (power-management) properties of an IRQ. Signed-off-by:
-
Ingo Molnar authored
Handle bad IRQ vectors via the irqchip mechanism. Signed-off-by:
-
Thomas Gleixner authored
Enable platforms to use the irq-chip and irq-flow abstractions: allow setting of the chip, the type and provide highlevel handlers for common irq-flows. [rostedt@goodmis.org: misroute-irq: Don't call desc->chip->end because of edge interrupts] Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
