)]}' { "log": [ { "commit": "8bc3bcc93a2b4e47d5d410146f6546bca6171663", "tree": "101f55a96f751749041c90c32ef1ba89f94dc4d1", "parents": [ "630d9c47274aa89bfa77fe6556d7818bdcb12992" ], "author": { "name": "Paul Gortmaker", "email": "paul.gortmaker@windriver.com", "time": "Wed Nov 16 21:29:17 2011 -0500" }, "committer": { "name": "Paul Gortmaker", "email": "paul.gortmaker@windriver.com", "time": "Wed Mar 07 15:04:04 2012 -0500" }, "message": "lib: reduce the use of module.h wherever possible\n\nFor files only using THIS_MODULE and/or EXPORT_SYMBOL, map\nthem onto including export.h -- or if the file isn\u0027t even\nusing those, then just delete the include. Fix up any implicit\ninclude dependencies that were being masked by module.h along\nthe way.\n\nSigned-off-by: Paul Gortmaker \u003cpaul.gortmaker@windriver.com\u003e\n" }, { "commit": "ba9f207c9f82115aba4ce04b22e0081af0ae300f", "tree": "469b255f597c4910306566d038496780a16e56a2", "parents": [ "80d02085d99039b3b7f3a73c8896226b0cb1ba07" ], "author": { "name": "Frederic Weisbecker", "email": "fweisbec@gmail.com", "time": "Fri May 20 02:09:54 2011 +0200" }, "committer": { "name": "Paul E. McKenney", "email": "paulmck@linux.vnet.ibm.com", "time": "Thu May 26 09:42:19 2011 -0700" }, "message": "rcu: Fix unpaired rcu_irq_enter() from locking selftests\n\nHARDIRQ_ENTER() maps to irq_enter() which calls rcu_irq_enter().\nBut HARDIRQ_EXIT() maps to __irq_exit() which doesn\u0027t call\nrcu_irq_exit().\n\nSo for every locking selftest that simulates hardirq disabled,\nwe create an imbalance in the rcu extended quiescent state\ninternal state.\n\nAs a result, after the first missing rcu_irq_exit(), subsequent\nirqs won\u0027t exit dyntick-idle mode after leaving the interrupt\nhandler. This means that RCU won\u0027t see the affected CPU as being\nin an extended quiescent state, resulting in long grace-period\ndelays (as in grace periods extending for hours).\n\nTo fix this, just use __irq_enter() to simulate the hardirq\ncontext. This is sufficient for the locking selftests as we\ndon\u0027t need to exit any extended quiescent state or perform\nany check that irqs normally do when they wake up from idle.\n\nAs a side effect, this patch makes it possible to restore\n\"rcu: Decrease memory-barrier usage based on semi-formal proof\",\nwhich eventually helped finding this bug.\n\nReported-and-tested-by: Yinghai Lu \u003cyinghai@kernel.org\u003e\nSigned-off-by: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nCc: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nCc: Ingo Molnar \u003cmingo@elte.hu\u003e\nCc: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nCc: Stable \u003cstable@kernel.org\u003e\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\n" }, { "commit": "d820ac4c2fa881079e6b689d2098adce337558ae", "tree": "39e4e989d22271cd401f6974c9ae7accc571d500", "parents": [ "3c1f67d60e2b4f4455563928999fd41cc653645d" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Mar 13 01:30:40 2009 +0100" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Mar 13 01:32:36 2009 +0100" }, "message": "locking: rename trace_softirq_[enter|exit] \u003d\u003e lockdep_softirq_[enter|exit]\n\nImpact: cleanup\n\nThe naming clashes with upcoming softirq tracepoints, so rename the\nAPIs to lockdep_*().\n\nRequested-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "2ee91f197c0bc654b24eed5831fd12aa0d566a7d", "tree": "85f9013d1cf17d6a947bbad723ce0cb5427a3dac", "parents": [ "50cc670aebf4fc64afaf533fb9fa1c8570f09d74" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Wed Dec 06 20:39:32 2006 -0800" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.osdl.org", "time": "Thu Dec 07 08:39:43 2006 -0800" }, "message": "[PATCH] lockdep: show more details about self-test failures\n\nMake the locking self-test failures (of \u0027FAILURE\u0027 type) easier to debug by\nprinting more information.\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n" }, { "commit": "6c9076ec9cd448f43bbda871352a7067f456ee26", "tree": "8691366aa511f20146eb9cfe942e0d94c4136e1a", "parents": [ "fbb9ce9530fd9b66096d5187fa6a115d16d9746c" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Mon Jul 03 00:24:51 2006 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@g5.osdl.org", "time": "Mon Jul 03 15:27:04 2006 -0700" }, "message": "[PATCH] lockdep: allow read_lock() recursion of same class\n\nFrom: Ingo Molnar \u003cmingo@elte.hu\u003e\n\nlockdep so far only allowed read-recursion for the same lock instance.\nThis is enough in the overwhelming majority of cases, but a hostap case\ntriggered and reported by Miles Lane relies on same-class\ndifferent-instance recursion. So we relax the restriction on read-lock\nrecursion.\n\n(This change does not allow rwsem read-recursion, which is still\nforbidden.)\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n" }, { "commit": "fbb9ce9530fd9b66096d5187fa6a115d16d9746c", "tree": "1151a55e5d56045bac17b9766e6a4696cff0a26f", "parents": [ "cae2ed9aa573415c6e5de9a09b7ff0d74af793bc" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Mon Jul 03 00:24:50 2006 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@g5.osdl.org", "time": "Mon Jul 03 15:27:03 2006 -0700" }, "message": "[PATCH] lockdep: core\n\nDo \u0027make oldconfig\u0027 and accept all the defaults for new config options -\nreboot into the kernel and if everything goes well it should boot up fine and\nyou should have /proc/lockdep and /proc/lockdep_stats files.\n\nTypically if the lock validator finds some problem it will print out\nvoluminous debug output that begins with \"BUG: ...\" and which syslog output\ncan be used by kernel developers to figure out the precise locking scenario.\n\nWhat does the lock validator do? It \"observes\" and maps all locking rules as\nthey occur dynamically (as triggered by the kernel\u0027s natural use of spinlocks,\nrwlocks, mutexes and rwsems). Whenever the lock validator subsystem detects a\nnew locking scenario, it validates this new rule against the existing set of\nrules. If this new rule is consistent with the existing set of rules then the\nnew rule is added transparently and the kernel continues as normal. If the\nnew rule could create a deadlock scenario then this condition is printed out.\n\nWhen determining validity of locking, all possible \"deadlock scenarios\" are\nconsidered: assuming arbitrary number of CPUs, arbitrary irq context and task\ncontext constellations, running arbitrary combinations of all the existing\nlocking scenarios. In a typical system this means millions of separate\nscenarios. This is why we call it a \"locking correctness\" validator - for all\nrules that are observed the lock validator proves it with mathematical\ncertainty that a deadlock could not occur (assuming that the lock validator\nimplementation itself is correct and its internal data structures are not\ncorrupted by some other kernel subsystem). [see more details and conditionals\nof this statement in include/linux/lockdep.h and\nDocumentation/lockdep-design.txt]\n\nFurthermore, this \"all possible scenarios\" property of the validator also\nenables the finding of complex, highly unlikely multi-CPU multi-context races\nvia single single-context rules, increasing the likelyhood of finding bugs\ndrastically. In practical terms: the lock validator already found a bug in\nthe upstream kernel that could only occur on systems with 3 or more CPUs, and\nwhich needed 3 very unlikely code sequences to occur at once on the 3 CPUs.\nThat bug was found and reported on a single-CPU system (!). So in essence a\nrace will be found \"piecemail-wise\", triggering all the necessary components\nfor the race, without having to reproduce the race scenario itself! In its\nshort existence the lock validator found and reported many bugs before they\nactually caused a real deadlock.\n\nTo further increase the efficiency of the validator, the mapping is not per\n\"lock instance\", but per \"lock-class\". For example, all struct inode objects\nin the kernel have inode-\u003einotify_mutex. If there are 10,000 inodes cached,\nthen there are 10,000 lock objects. But -\u003einotify_mutex is a single \"lock\ntype\", and all locking activities that occur against -\u003einotify_mutex are\n\"unified\" into this single lock-class. The advantage of the lock-class\napproach is that all historical -\u003einotify_mutex uses are mapped into a single\n(and as narrow as possible) set of locking rules - regardless of how many\ndifferent tasks or inode structures it took to build this set of rules. The\nset of rules persist during the lifetime of the kernel.\n\nTo see the rough magnitude of checking that the lock validator does, here\u0027s a\nportion of /proc/lockdep_stats, fresh after bootup:\n\n lock-classes: 694 [max: 2048]\n direct dependencies: 1598 [max: 8192]\n indirect dependencies: 17896\n all direct dependencies: 16206\n dependency chains: 1910 [max: 8192]\n in-hardirq chains: 17\n in-softirq chains: 105\n in-process chains: 1065\n stack-trace entries: 38761 [max: 131072]\n combined max dependencies: 2033928\n hardirq-safe locks: 24\n hardirq-unsafe locks: 176\n softirq-safe locks: 53\n softirq-unsafe locks: 137\n irq-safe locks: 59\n irq-unsafe locks: 176\n\nThe lock validator has observed 1598 actual single-thread locking patterns,\nand has validated all possible 2033928 distinct locking scenarios.\n\nMore details about the design of the lock validator can be found in\nDocumentation/lockdep-design.txt, which can also found at:\n\n http://redhat.com/~mingo/lockdep-patches/lockdep-design.txt\n\n[bunk@stusta.de: cleanups]\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Arjan van de Ven \u003carjan@linux.intel.com\u003e\nSigned-off-by: Adrian Bunk \u003cbunk@stusta.de\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n" }, { "commit": "cae2ed9aa573415c6e5de9a09b7ff0d74af793bc", "tree": "1a7bcea760681872bcc6020843886c5597130eb4", "parents": [ "1f194a4c393103ac925001d7e04b05fbb122580d" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Mon Jul 03 00:24:48 2006 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@g5.osdl.org", "time": "Mon Jul 03 15:27:03 2006 -0700" }, "message": "[PATCH] lockdep: locking API self tests\n\nIntroduce DEBUG_LOCKING_API_SELFTESTS, which uses the generic lock debugging\ncode\u0027s silent-failure feature to run a matrix of testcases. There are 210\ntestcases currently:\n\n +-----------------------\n | Locking API testsuite:\n +------------------------------+------+------+------+------+------+------+\n | spin |wlock |rlock |mutex | wsem | rsem |\n -------------------------------+------+------+------+------+------+------+\n A-A deadlock: ok | ok | ok | ok | ok | ok |\n A-B-B-A deadlock: ok | ok | ok | ok | ok | ok |\n A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok |\n A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok |\n A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok |\n A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | ok | ok |\n A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | ok | ok |\n double unlock: ok | ok | ok | ok | ok | ok |\n bad unlock order: ok | ok | ok | ok | ok | ok |\n --------------------------------------+------+------+------+------+------+\n recursive read-lock: | ok | | ok |\n --------------------------------------+------+------+------+------+------+\n non-nested unlock: ok | ok | ok | ok |\n --------------------------------------+------+------+------+\n hard-irqs-on + irq-safe-A/12: ok | ok | ok |\n soft-irqs-on + irq-safe-A/12: ok | ok | ok |\n hard-irqs-on + irq-safe-A/21: ok | ok | ok |\n soft-irqs-on + irq-safe-A/21: ok | ok | ok |\n sirq-safe-A \u003d\u003e hirqs-on/12: ok | ok | ok |\n sirq-safe-A \u003d\u003e hirqs-on/21: ok | ok | ok |\n hard-safe-A + irqs-on/12: ok | ok | ok |\n soft-safe-A + irqs-on/12: ok | ok | ok |\n hard-safe-A + irqs-on/21: ok | ok | ok |\n soft-safe-A + irqs-on/21: ok | ok | ok |\n hard-safe-A + unsafe-B #1/123: ok | ok | ok |\n soft-safe-A + unsafe-B #1/123: ok | ok | ok |\n hard-safe-A + unsafe-B #1/132: ok | ok | ok |\n soft-safe-A + unsafe-B #1/132: ok | ok | ok |\n hard-safe-A + unsafe-B #1/213: ok | ok | ok |\n soft-safe-A + unsafe-B #1/213: ok | ok | ok |\n hard-safe-A + unsafe-B #1/231: ok | ok | ok |\n soft-safe-A + unsafe-B #1/231: ok | ok | ok |\n hard-safe-A + unsafe-B #1/312: ok | ok | ok |\n soft-safe-A + unsafe-B #1/312: ok | ok | ok |\n hard-safe-A + unsafe-B #1/321: ok | ok | ok |\n soft-safe-A + unsafe-B #1/321: ok | ok | ok |\n hard-safe-A + unsafe-B #2/123: ok | ok | ok |\n soft-safe-A + unsafe-B #2/123: ok | ok | ok |\n hard-safe-A + unsafe-B #2/132: ok | ok | ok |\n soft-safe-A + unsafe-B #2/132: ok | ok | ok |\n hard-safe-A + unsafe-B #2/213: ok | ok | ok |\n soft-safe-A + unsafe-B #2/213: ok | ok | ok |\n hard-safe-A + unsafe-B #2/231: ok | ok | ok |\n soft-safe-A + unsafe-B #2/231: ok | ok | ok |\n hard-safe-A + unsafe-B #2/312: ok | ok | ok |\n soft-safe-A + unsafe-B #2/312: ok | ok | ok |\n hard-safe-A + unsafe-B #2/321: ok | ok | ok |\n soft-safe-A + unsafe-B #2/321: ok | ok | ok |\n hard-irq lock-inversion/123: ok | ok | ok |\n soft-irq lock-inversion/123: ok | ok | ok |\n hard-irq lock-inversion/132: ok | ok | ok |\n soft-irq lock-inversion/132: ok | ok | ok |\n hard-irq lock-inversion/213: ok | ok | ok |\n soft-irq lock-inversion/213: ok | ok | ok |\n hard-irq lock-inversion/231: ok | ok | ok |\n soft-irq lock-inversion/231: ok | ok | ok |\n hard-irq lock-inversion/312: ok | ok | ok |\n soft-irq lock-inversion/312: ok | ok | ok |\n hard-irq lock-inversion/321: ok | ok | ok |\n soft-irq lock-inversion/321: ok | ok | ok |\n hard-irq read-recursion/123: ok |\n soft-irq read-recursion/123: ok |\n hard-irq read-recursion/132: ok |\n soft-irq read-recursion/132: ok |\n hard-irq read-recursion/213: ok |\n soft-irq read-recursion/213: ok |\n hard-irq read-recursion/231: ok |\n soft-irq read-recursion/231: ok |\n hard-irq read-recursion/312: ok |\n soft-irq read-recursion/312: ok |\n hard-irq read-recursion/321: ok |\n soft-irq read-recursion/321: ok |\n --------------------------------+-----+----------------\n Good, all 210 testcases passed! |\n --------------------------------+\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Arjan van de Ven \u003carjan@linux.intel.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n" } ] }