- 08 Jan, 2005 40 commits
-
-
Pavel Machek authored
pm_access / pm_dev_idle was removed from recent kernels. This should stop confusion. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
James Nelson authored
I could not locate the original author or any active support effort being done. This is definitely an orphaned driver. Signed-off-by:
James Nelson <james4765@gmail.com> Signed-off-by:
-
James Nelson authored
Some updating and removal of dead links in the text file. The 5.5 package is not carried on the sunsite.unc.edu or tsx-11.mit.edu FTP servers, and the support@stallion.com address bounces. Signed-off-by:
-
James Nelson authored
Signed-off-by:
-
James Nelson authored
Signed-off-by:
-
James Nelson authored
The driver at Moxa's website is version 1.8. There is no need for this file. Signed-off-by:
-
James Nelson authored
After contacting Moxa, I found out that they no longer maintain the in-kernel driver, and instead maintain an updated driver as an external patch. This patch updates the documentation to reflect this. Signed-off-by:
-
Thomas Gleixner authored
Kernel core files converted to use the new lock initializers. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Thomas Gleixner authored
Character devices converted to use the new lock initializers. Signed-off-by:
-
Thomas Gleixner authored
First part of the patch series. Define initializer macros Often used structures in the kernel are almost all declared and initialized by macros in the form: DEFINE_TYPE(name) Spinlocks and rwlocks are declared and initialized by: type name = INITIALIZER; After converting the runtime initialization of spinlocks/rwlocks to macro form it is consequent to change the declaration and initializion of global and static locks to the macro form too. This conversion identifies those variables as "special", common code controlled entities similar to list_heads, mutexes... Besides consistency and code clearness this also helps automatic lock validators and debugging code. The patch converts -rwlock_t snd_card_rwlock = RW_LOCK_UNLOCKED; +DEFINE_RWLOCK(snd_card_rwlock); and -static spinlock_t slave_active_lock = SPIN_LOCK_UNLOCKED; +static DEFINE_SPINLOCK(slave_active_lock); There is no runtime overhead or actual code change resulting out of this patch, other than a small reduction in the kernel source code size. The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. This patch removes also a double init in icom.c Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
Dave Airlie <airlied@linux.ie> Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
"Luck, Tony" <tony.luck@intel.com> Signed-off-by:
-
Thomas Gleixner authored
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(&lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(&rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by:
-
Andrew Morton authored
- When invalidating pages, take care to shoot down any ptes which map them as well. This ensures that the next mmap access to the page will generate a major fault, so NFS's server-side modifications are picked up. This also allows us to call invalidate_complete_page() on all pages, so filesytems such as ext3 get a chance to invalidate the buffer_heads. - Don't mark in-pagetable pages as non-uptodate any more. That broke a previous guarantee that mapped-into-user-process pages are always uptodate. - Check the return value of invalidate_complete_page(). It can fail if someone redirties a page after generic_file_direct_IO() write it back. But we still have a problem. If invalidate_inode_pages2() calls unmap_mapping_range(), that can cause zap_pte_range() to dirty the pagecache pages. That will redirty the page's buffers and will cause invalidate_complete_page() to fail. So, in generic_file_direct_IO() we do a complete pte shootdown on the file up-front, prior to writing back dirty pagecache. This is only done for O_DIRECT writes. It _could_ be done for O_DIRECT reads too, providing full mmap-vs-direct-IO coherency for both O_DIRECT reads and O_DIRECT writes, but permitting the pte shootdown on O_DIRECT reads trivially allows people to nuke other people's mapped pagecache. NFS also uses invalidate_inode_pages2() for handling server-side modification notifications. But in the NFS case the clear_page_dirty() in invalidate_inode_pages2() is sufficient, because NFS doesn't have to worry about the "dirty buffers against a clean page" problem. (I think) Signed-off-by:
-
Andrew Morton authored
A while ago we merged a patch which tried to solve a problem wherein a concurrent read() and invalidate_inode_pages() would cause the read() to return -EIO because invalidate cleared PageUptodate() at the wrong time. That patch tests for (page_count(page) != 2) in invalidate_complete_page() and bales out if false. Problem is, the page may be in the per-cpu LRU front-ends over in lru_cache_add. This elevates the refcount pending spillage of the page onto the LRU for real. That causes a false positive in invalidate_complete_page(), causing the page to not get invalidated. This screws up the logic in my new O_DIRECT-vs-buffered coherency fix. So let's solve the invalidate-vs-read in a different manner. Over on the read() side, add an explicit check to see if the page was invalidated. If so, just drop it on the floor and redo the read from scratch. Note that only do_generic_mapping_read() needs treatment. filemap_nopage(), filemap_getpage() and read_cache_page() are already doing the oh-it-was-invalidated-so-try-again thing. Signed-off-by:
-
Rusty Russell authored
Vadim Lobanov points out that EXPORT_SYMBOL_NOVERS is no longer used; in fact, SH still uses it, but once we fix that, the kernel is clean. Remove it. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
H. Peter Anvin authored
This patch adds Altivec support for RAID-6, if appropriately configured on the ppc or ppc64 architectures. Note that it changes the compile flags for ppc64 in order to handle -maltivec correctly; this change was vetted on the ppc64 mailing list and OK'd by paulus. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
David Brownell authored
I got tired of not seeing the boot time penguin on my Shuttle SN41G2, and not having a decently large text display when I bypass X11. XFree86 says it's "Chipset GeForce4 MX Integrated GPU", and the kernel driver has hooks for this chip ID although it doesn't have a #define to match. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Kamezawa Hiroyuki authored
This patch is for ia64 kernel, and defines CONFIG_HOLES_IN_ZONE in arch/ia64/Kconfig. IA64 has memory holes smaller than its MAX_ORDER and its virtual memmap allows holes in a zone's memmap. This patch makes vmemmap aligned with IA64_GRANULE_SIZE in arch/ia64/mm/init.c. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Kamezawa Hiroyuki authored
This patch removes bitmaps from page allocator in mm/page_alloc.c. This buddy system uses page->private field to record free page's order instead of using bitmaps. The algorithm of the buddy system is unchanged. Only bitmaps are removed. In this buddy system, 2 pages,a page and "buddy", can be coalesced when (buddy->private & PG_private) && (page_order(page)) == (page_order(buddy)) && !PageReserved(buddy) && page_count(buddy) == 0 this also means "buddy" is a head of continuous free pages of length of (1 << page_order(buddy)). bad_range() is called from inner loop of __free_pages_bulk(). In many archs, bad_range() is only a sanity check, it will always return 0. But if a zone's memmap has a hole, it sometimes returns 1. An architecture with memory holes in a zone has to define CONFIG_HOLES_IN_ZONE. When CONFIG_HOLES_IN_ZONE is defined, pfn_valid() is called for checking whether a buddy pages is valid or not. Signed-off-by:
-
Kamezawa Hiroyuki authored
Followings are patches for removing bitmaps from the buddy allocator. This is benefical to memory-hot-plug stuffs, because this removes a data structure which must meet to a host's physical memory layout. This is one step to manage physical memory in nonlinear / discontiguous way and will reduce some amounts of codes to implement memory-hot-plug. This patch removes bitmaps from zone->free_area[] in include/linux/mmzone.h, and adds some comments on page->private field in include/linux/mm.h. non-atomic ops for changing PG_private bit is added in include/page-flags.h. zone->lock is always acquired when PG_private of "a free page" is changed. Signed-off-by:
-
William Lee Irwin III authored
All in-tree references to remap_page_range() have been removed by prior patches in the series. This patch, intended to be applied after some waiting period for people to adjust to the API change, notice __deprecated, etc., does the final removal of remap_page_range() as a function symbol declared within kernel headers and/or implemented in kernel sources. Signed-off-by:
-
Neil Brown authored
The hashtable that linear uses to find the right device stores two pointers for every entry. The second is always one of: The first plus 1 NULL When NULL, it is never accessed, so any value can be stored. Thus it could always be "first plus 1", and so we don't need to store it as it is trivial to calculate. This patch halves the size of this table, which results in some simpler code as well. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
Nathan Lynch authored
Fix (harmless?) smp_processor_id() usage in preemptible section of cpu_down. Signed-off-by:
Nathan Lynch <nathanl@austin.ibm.com> Signed-off-by:
-
Ingo Molnar authored
From: Peter Zijlstra <peter@programming.kicks-ass.net> I have to use oprofile a lot but do want to enable preemption checks. This gives some noise; I think andrew allready mentioned fixin this. The following patch fixes about half of the warnings. Signed-off-by:
-
Ingo Molnar authored
This is the current remove-BKL patch. I test-booted it on x86 and x64, trying every conceivable combination of SMP, PREEMPT and PREEMPT_BKL. All other architectures should compile as well. (most of the testing was done with the zaphod patch undone but it applies cleanly on vanilla -mm3 as well and should work fine.) this is the debugging-enabled variant of the patch which has two main debugging features: - debug potentially illegal smp_processor_id() use. Has caught a number of real bugs - e.g. look at the printk.c fix in the patch. - make it possible to enable/disable the BKL via a .config. If this goes upstream we dont want this of course, but for now it gives people a chance to find out whether any particular problem was caused by this patch. This patch has one important fix over the previous BKL patch: on PREEMPT kernels if we preempted BKL-using code then the code still auto-dropped the BKL by mistake. This caused a number of breakages for testers, which breakages went away once this bug was fixed. Also the debugging mechanism has been improved alot relative to the previous BKL patch. Would be nice to test-drive this in -mm. There will likely be some more smp_processor_id() false positives but they are 1) harmless 2) easy to fix up. We could as well find more real smp_processor_id() related breakages as well. The most noteworthy fact is that no BKL-using code was found yet that relied on smp_processor_id(), which is promising from a compatibility POV. Signed-off-by:
-
