The cisco.com address will stop working soon, and besides no one can
remember the second "d" in "rolandd" or how to spell "rdreier."
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Probably no one has used this driver on big-endian systems, since it was
setting up descriptor swapping if CONFIG_BIG_ENDIAN is set, which it
never is, since that symbol is not mentioned anywhere else in the kernel
source. Switch this test to a check for __BIG_ENDIAN so it has a chance
at working.
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Jeff Garzik <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
CONFIG_CHELSIO_T1_COUGAR cannot be set (it appears nowhere in any
Kconfig files), and the code it protects could never build (cspi.h was
never added to the kernel tree). Therefore it's pretty safe to remove
all vestiges of this dead code.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Quite a few Kconfig symbols contain lowercase letters. The current
checkkconfigsymbols.sh code only contains A-Z in the regexp it uses to
find config symbols in source code, so it comes up with the wrong symbol
to look for in Kconfig files and then generates false positives when it
doesn't find that wrong symbol. For example checking drivers/net
generates a false positive for MAC89 because the the actual config
option is MAC89x0.
Fix this by also adding a-z to the regexp.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.31-2-generic #14~rbd3
> ---------------------------------------------
> firefox-3.5/4162 is trying to acquire lock:
> (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] lock_rename+0x41/0xf0
>
> but task is already holding lock:
> (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] lock_rename+0x41/0xf0
>
> other info that might help us debug this:
> 3 locks held by firefox-3.5/4162:
> #0: (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] lock_rename+0x41/0xf0
> #1: (&sb->s_type->i_mutex_key#11/1){+.+.+.}, at: [<ffffffff81139d5a>] lock_rename+0x6a/0xf0
> #2: (&sb->s_type->i_mutex_key#11/2){+.+.+.}, at: [<ffffffff81139d6f>] lock_rename+0x7f/0xf0
>
> stack backtrace:
> Pid: 4162, comm: firefox-3.5 Tainted: G C 2.6.31-2-generic #14~rbd3
> Call Trace:
> [<ffffffff8108ae74>] print_deadlock_bug+0xf4/0x100
> [<ffffffff8108ce26>] validate_chain+0x4c6/0x750
> [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430
> [<ffffffff8108d585>] lock_acquire+0xa5/0x150
> [<ffffffff81139d31>] ? lock_rename+0x41/0xf0
> [<ffffffff815526ad>] __mutex_lock_common+0x4d/0x3d0
> [<ffffffff81139d31>] ? lock_rename+0x41/0xf0
> [<ffffffff81139d31>] ? lock_rename+0x41/0xf0
> [<ffffffff8120eaf9>] ? ecryptfs_rename+0x99/0x170
> [<ffffffff81552b36>] mutex_lock_nested+0x46/0x60
> [<ffffffff81139d31>] lock_rename+0x41/0xf0
> [<ffffffff8120eb2a>] ecryptfs_rename+0xca/0x170
> [<ffffffff81139a9e>] vfs_rename_dir+0x13e/0x160
> [<ffffffff8113ac7e>] vfs_rename+0xee/0x290
> [<ffffffff8113c212>] ? __lookup_hash+0x102/0x160
> [<ffffffff8113d512>] sys_renameat+0x252/0x280
> [<ffffffff81133eb4>] ? cp_new_stat+0xe4/0x100
> [<ffffffff8101316a>] ? sysret_check+0x2e/0x69
> [<ffffffff8108c34d>] ? trace_hardirqs_on_caller+0x14d/0x190
> [<ffffffff8113d55b>] sys_rename+0x1b/0x20
> [<ffffffff81013132>] system_call_fastpath+0x16/0x1b
The trace above is totally reproducible by doing a cross-directory
rename on an ecryptfs directory.
The issue seems to be that sys_renameat() does lock_rename() then calls
into the filesystem; if the filesystem is ecryptfs, then
ecryptfs_rename() again does lock_rename() on the lower filesystem, and
lockdep can't tell that the two s_vfs_rename_mutexes are different. It
seems an annotation like the following is sufficient to fix this (it
does get rid of the lockdep trace in my simple tests); however I would
like to make sure I'm not misunderstanding the locking, hence the CC
list...
Signed-off-by: Roland Dreier <[email protected]>
Cc: Tyler Hicks <[email protected]>
Cc: Dustin Kirkland <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Al Viro <[email protected]>
If cxgb3i_pdu_init() fails, then it appears that cxgb3i_iscsi_init()
will not be cleaned up, leading to the iscsi transport being left
registered. Fix this by adding a call to cxgb3i_iscsi_cleanup() on the
error path.
Signed-off-by: Roland Dreier <[email protected]>
Reviewed-by: Mike Christie <[email protected]>
Cc: Karen Xie <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Also put t4_write_indirect() inside "#if 0" to avoid a "defined but not
used" compile warning.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Use the correct direction of byte-swapping function to fix a mistake
shown by sparse endianness checking -- c.fl0id is __be16.
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Dimitris Michailidis <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Add BUILD_BUG_ON_NOT_POWER_OF_2()
When code relies on a constant being a power of 2:
#define FOO 512 /* must be a power of 2 */
it would be nice to be able to do:
BUILD_BUG_ON(!is_power_of_2(FOO));
However applying an inline function does not result in a compile-time
constant that can be used with BUILD_BUG_ON(), so trying that gives
results in:
error: bit-field '<anonymous>' width not an integer constant
As suggested by akpm, rather than monkeying around with is_power_of_2()
and risking gcc warts about constant expressions, just create a macro
BUILD_BUG_ON_NOT_POWER_OF_2() to encapsulate this common requirement.
Signed-off-by: Roland Dreier <[email protected]>
Cc: Bart Van Assche <[email protected]>
Cc: David Dillow <[email protected]>
Cc: "Robert P. J. Day" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
It seems a couple places such as arch/ia64/kernel/perfmon.c and
drivers/infiniband/core/uverbs_main.c could use anon_inode_getfile()
instead of a private pseudo-fs + alloc_file(), if only there were a way
to get a read-only file. So provide this by having anon_inode_getfile()
create a read-only file if we pass O_RDONLY in flags.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Al Viro <[email protected]>
When alloc_file() and init_file() were combined, the error handling of
mnt_clone_write() was taken into alloc_file() in a somewhat obfuscated
way. Since we don't use the error code for anything except warning,
we might as well warn directly without an extra variable.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Not all awk implementations (including the default awk in Ubuntu 9.10)
support POSIX character classes. Since x86-opcode-map.txt is plain
ASCII, we can just use explicit ranges for lower case, alphabetic, and
alphanumeric characters instead.
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Commit 3d1e4631 ("get rid of init_file()") removed the export of
alloc_file() -- possibly inadvertently, since that commit mainly
consisted of deleting the lines between the end of alloc_file() and
the start of the code in init_file().
There is in fact one modular use of alloc_file() in the tree, in
drivers/infiniband/core/uverbs_main.c, so re-add the export to fix:
ERROR: "alloc_file" [drivers/infiniband/core/ib_uverbs.ko] undefined!
when CONFIG_INFINIBAND_USER_ACCESS=m.
Cc: Al Viro <[email protected]>
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The MCE initialization code explicitly says it doesn't handle
asymmetric configurations where different CPUs support different
numbers of MCE banks, and it prints a big warning in that case.
Therefore, printing the "mce: CPU supports <x> MCE banks"
message into the kernel log for every CPU is pure redundancy
that clutters the log significantly for systems with lots of
CPUs.
Signed-off-by: Roland Dreier <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
I was recently lucky enough to get a 64-CPU system. The processors
actually have T-states, so my kernel log ends up with 64 lines like:
ACPI: Processor [CPU0] (supports xx throttling states)
This is pretty useless clutter because
- this info is already available after boot from
/proc/acpi/processor/CPUnn/throttling
- there's also an ACPI_DEBUG_PRINT() in processor_throttling.c that
gives the same info on boot for anyone who *really* cares.
So just delete the code that prints the throttling states in
processor_core.c.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Len Brown <[email protected]>
I was recently lucky enough to get a 64-CPU system, so my kernel log
ends up with 64 lines like:
ACPI: CPU0 (power states: C1[C1] C2[C3])
This is pretty useless clutter because this info is already available
after boot from both /sys/devices/system/cpu/cpu*/cpuidle/state?/ as
well as /proc/acpi/processor/CPU*/power.
So just delete the code that prints the C-states in processor_idle.c.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Len Brown <[email protected]>
On big systems, printing <number of CPUs> copies of
Switched to high resolution mode on CPU nnn
clutters up the kernel log for minimal gain. Just get rid of them.
Signed-off-by: Roland Dreier <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
I recently got a system where the DMAR table included a couple of RHSA
(remapping hardware static affinity) entries. Rather than printing a
message about an "Unknown DMAR structure," it would probably be more
useful to dump the RHSA structure (as other DMAR structures are dumped).
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
On modern systems, the kernel prints the message
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
once for every CPU.
This gets kind of ridiculous on huge systems; for example, on a
64-thread system I was lucky enough to get:
dmesg| grep 'PAT enabled' | wc
64 704 5174
There is already a BUG() if non-boot CPUs have PAT capabilities
that don't match the boot CPU, so just print the message on the
boot CPU. (I kept the print after the wrmsrl() that enables PAT,
so that the log output continues to mean that the system survived
enabling PAT on the boot CPU)
Signed-off-by: Roland Dreier <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Venkatesh Pallipadi <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
On modern systems, the kernel prints the message
Skipping synchronization checks as TSC is reliable.
once for every non-boot CPU.
This gets kind of ridiculous on huge systems; for example, on a
64-thread system I was lucky enough to get:
$ dmesg | grep 'TSC is reliable' | wc
63 567 4221
There's no point to doing this for every CPU, since the code is
just checking the boot CPU anyway, so change this to a
printk_once() to make the message appears only once.
Signed-off-by: Roland Dreier <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
We might as well print the type of the DMAR structure we don't know how
to handle when skipping it. Then someone getting this message has a
chance of telling whether the structure is just bogus, or if there
really is something valid that the kernel doesn't know how to handle.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Holding agent->lock across cancel_delayed_work() (which does
del_timer_sync()) in ib_cancel_rmpp_recvs() leads to lockdep reports of
possible lock-timer deadlocks if a consumer ever does something that
connects agent->lock to a lock taken in IRQ context (cf
http://marc.info/?l=linux-rdma&m=125243699026045).
Fix this by changing the list items to a new state "CANCELING" while
holding the lock, and then canceling the delayed work without holding
the lock. If the delayed work runs after the lock is dropped, it will
see the state is CANCELING and return immediately, so the list will
stay stable while we traverse it with the lock not held.
Reviewed-by: Sean Hefty <[email protected]>
Signed-off-by: Roland Dreier <[email protected]>
Using the type bool (instead of int) for the __print_once flag in the
printk_once() macro matches the intent of the code better, and allows the
compiler to generate smaller code; eg a typical callsite with gcc 4.3.3 on
i386:
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-6 (-6)
function old new delta
static.__print_once 4 1 -3
get_cpu_vendor 146 143 -3
Saving 6 bytes of object size per callsite by slightly improving the
readability of the source seems like a win to me.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Lockdep reports the following valid-looking possible AB-BA deadlock with
global_auth_tok_list_mutex and keysig_list_mutex:
ecryptfs_new_file_context() ->
ecryptfs_copy_mount_wide_sigs_to_inode_sigs() ->
mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex);
-> ecryptfs_add_keysig() ->
mutex_lock(&crypt_stat->keysig_list_mutex);
vs
ecryptfs_generate_key_packet_set() ->
mutex_lock(&crypt_stat->keysig_list_mutex);
-> ecryptfs_find_global_auth_tok_for_sig() ->
mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex);
ie the two mutexes are taken in opposite orders in the two different
code paths. I'm not sure if this is a real bug where two threads could
actually hit the two paths in parallel and deadlock, but it at least
makes lockdep impossible to use with ecryptfs since this report triggers
every time and disables future lockdep reporting.
Since ecryptfs_add_keysig() is called only from the single callsite in
ecryptfs_copy_mount_wide_sigs_to_inode_sigs(), the simplest fix seems to
be to move the lock of keysig_list_mutex back up outside of the where
global_auth_tok_list_mutex is taken. This patch does that, and fixes
the lockdep report on my system (and ecryptfs still works OK).
The full output of lockdep fixed by this patch is:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.31-2-generic #14~rbd2
-------------------------------------------------------
gdm/2640 is trying to acquire lock:
(&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}, at: [<ffffffff8121591e>] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
but task is already holding lock:
(&crypt_stat->keysig_list_mutex){+.+.+.}, at: [<ffffffff81217728>] ecryptfs_generate_key_packet_set+0x58/0x2b0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&crypt_stat->keysig_list_mutex){+.+.+.}:
[<ffffffff8108c897>] check_prev_add+0x2a7/0x370
[<ffffffff8108cfc1>] validate_chain+0x661/0x750
[<ffffffff8108d2e7>] __lock_acquire+0x237/0x430
[<ffffffff8108d585>] lock_acquire+0xa5/0x150
[<ffffffff815526cd>] __mutex_lock_common+0x4d/0x3d0
[<ffffffff81552b56>] mutex_lock_nested+0x46/0x60
[<ffffffff8121526a>] ecryptfs_add_keysig+0x5a/0xb0
[<ffffffff81213299>] ecryptfs_copy_mount_wide_sigs_to_inode_sigs+0x59/0xb0
[<ffffffff81214b06>] ecryptfs_new_file_context+0xa6/0x1a0
[<ffffffff8120e42a>] ecryptfs_initialize_file+0x4a/0x140
[<ffffffff8120e54d>] ecryptfs_create+0x2d/0x60
[<ffffffff8113a7d4>] vfs_create+0xb4/0xe0
[<ffffffff8113a8c4>] __open_namei_create+0xc4/0x110
[<ffffffff8113d1c1>] do_filp_open+0xa01/0xae0
[<ffffffff8112d8d9>] do_sys_open+0x69/0x140
[<ffffffff8112d9f0>] sys_open+0x20/0x30
[<ffffffff81013132>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
-> #0 (&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}:
[<ffffffff8108c675>] check_prev_add+0x85/0x370
[<ffffffff8108cfc1>] validate_chain+0x661/0x750
[<ffffffff8108d2e7>] __lock_acquire+0x237/0x430
[<ffffffff8108d585>] lock_acquire+0xa5/0x150
[<ffffffff815526cd>] __mutex_lock_common+0x4d/0x3d0
[<ffffffff81552b56>] mutex_lock_nested+0x46/0x60
[<ffffffff8121591e>] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
[<ffffffff812177d5>] ecryptfs_generate_key_packet_set+0x105/0x2b0
[<ffffffff81212f49>] ecryptfs_write_headers_virt+0xc9/0x120
[<ffffffff8121306d>] ecryptfs_write_metadata+0xcd/0x200
[<ffffffff8120e44b>] ecryptfs_initialize_file+0x6b/0x140
[<ffffffff8120e54d>] ecryptfs_create+0x2d/0x60
[<ffffffff8113a7d4>] vfs_create+0xb4/0xe0
[<ffffffff8113a8c4>] __open_namei_create+0xc4/0x110
[<ffffffff8113d1c1>] do_filp_open+0xa01/0xae0
[<ffffffff8112d8d9>] do_sys_open+0x69/0x140
[<ffffffff8112d9f0>] sys_open+0x20/0x30
[<ffffffff81013132>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
other info that might help us debug this:
2 locks held by gdm/2640:
#0: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [<ffffffff8113cb8b>] do_filp_open+0x3cb/0xae0
#1: (&crypt_stat->keysig_list_mutex){+.+.+.}, at: [<ffffffff81217728>] ecryptfs_generate_key_packet_set+0x58/0x2b0
stack backtrace:
Pid: 2640, comm: gdm Tainted: G C 2.6.31-2-generic #14~rbd2
Call Trace:
[<ffffffff8108b988>] print_circular_bug_tail+0xa8/0xf0
[<ffffffff8108c675>] check_prev_add+0x85/0x370
[<ffffffff81094912>] ? __module_text_address+0x12/0x60
[<ffffffff8108cfc1>] validate_chain+0x661/0x750
[<ffffffff81017275>] ? print_context_stack+0x85/0x140
[<ffffffff81089c68>] ? find_usage_backwards+0x38/0x160
[<ffffffff8108d2e7>] __lock_acquire+0x237/0x430
[<ffffffff8108d585>] lock_acquire+0xa5/0x150
[<ffffffff8121591e>] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
[<ffffffff8108b0b0>] ? check_usage_backwards+0x0/0xb0
[<ffffffff815526cd>] __mutex_lock_common+0x4d/0x3d0
[<ffffffff8121591e>] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
[<ffffffff8121591e>] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
[<ffffffff8108c02c>] ? mark_held_locks+0x6c/0xa0
[<ffffffff81125b0d>] ? kmem_cache_alloc+0xfd/0x1a0
[<ffffffff8108c34d>] ? trace_hardirqs_on_caller+0x14d/0x190
[<ffffffff81552b56>] mutex_lock_nested+0x46/0x60
[<ffffffff8121591e>] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
[<ffffffff812177d5>] ecryptfs_generate_key_packet_set+0x105/0x2b0
[<ffffffff81212f49>] ecryptfs_write_headers_virt+0xc9/0x120
[<ffffffff8121306d>] ecryptfs_write_metadata+0xcd/0x200
[<ffffffff81210240>] ? ecryptfs_init_persistent_file+0x60/0xe0
[<ffffffff8120e44b>] ecryptfs_initialize_file+0x6b/0x140
[<ffffffff8120e54d>] ecryptfs_create+0x2d/0x60
[<ffffffff8113a7d4>] vfs_create+0xb4/0xe0
[<ffffffff8113a8c4>] __open_namei_create+0xc4/0x110
[<ffffffff8113d1c1>] do_filp_open+0xa01/0xae0
[<ffffffff8129a93e>] ? _raw_spin_unlock+0x5e/0xb0
[<ffffffff8155410b>] ? _spin_unlock+0x2b/0x40
[<ffffffff81139e9b>] ? getname+0x3b/0x240
[<ffffffff81148a5a>] ? alloc_fd+0xfa/0x140
[<ffffffff8112d8d9>] do_sys_open+0x69/0x140
[<ffffffff81553b8f>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff8112d9f0>] sys_open+0x20/0x30
[<ffffffff81013132>] system_call_fastpath+0x16/0x1b
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Tyler Hicks <[email protected]>
The ioatdma module is missing aliases for the PCI devices it supports,
so it is not autoloaded on boot. Add a MODULE_DEVICE_TABLE() to get
these aliases.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
The generic atomic64_t implementation in lib/ did not export the functions
it defined, which means that modules that use atomic64_t would not link on
platforms (such as 32-bit powerpc). For example, trying to build a kernel
with CONFIG_NET_RDS on such a platform would fail with:
ERROR: "atomic64_read" [net/rds/rds.ko] undefined!
ERROR: "atomic64_set" [net/rds/rds.ko] undefined!
Fix this by exporting the atomic64_t functions to modules. (I export the
entire API even if it's not all currently used by in-tree modules to avoid
having to continue fixing this in dribs and drabs)
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Paul Mackerras <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Commit c3a8c5b6 ("cxgb3: move away from LLTX") exposed a bug in how
cxgb3 looks up the netdev_queue it stashes away in a qset during
initialization. For multiport devices, the TX queue index it uses is
offset by the first_qset index of each port. This leads to a crash
once LLTX is removed, since hard_start_xmit is called with one TX
queue lock held, while the TX reclaim timer task grabs a different
(wrong) TX queue lock when it frees skbs.
Fix this by removing the first_qset offset used to look up the TX
queue passed into t3_sge_alloc_qset() from setup_sge_qsets().
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Divy Le Ray <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Commit ad361c98 ("Remove multiple KERN_ prefixes from printk formats")
broke the build for fealnx because it added some "printk(PR_CONT ..."
calls, when PR_CONT doesn't exist; it should be "printk(KERN_CONT ..."
Signed-off-by: Roland Dreier <[email protected]>
Cc: Joe Perches <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
If creating a workqueue fails, don't jump to the error path where that
same workqueue is destroyed, since destroy_workqueue() can't handle a
NULL pointer.
This was spotted by the Coverity checker (CID 2617).
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
The PAT work on x86 has finally made pgprot_writecombine() a usable API
for modular drivers. As the comment indicates, this is exactly what we
want to use in mlx4_ib to map BlueFlame pages up to userspace, since
using WC for these pages improves small message latency significantly.
Signed-off-by: Roland Dreier <[email protected]>
When net-next and infiniband were merged upstream, each branch deleted
one of a pair of adjacent lines from nes_nic.c, but when Linus fixed the
conflict up, he brought back both of the lines. Fix up to the intended
final tree state.
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: David S. Miller <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Lockdep warns that i915_gem_execbuffer() can trigger a page fault (which
takes mmap_sem) while holding dev->struct_mutex, while drm_vm_open()
(which is called with mmap_sem already held) takes dev->struct_mutex.
So this is a potential AB-BA deadlock.
The way that i915_gem_execbuffer() triggers a page fault is by doing
copy_to_user() when returning new buffer offsets back to userspace;
however there is no reason to hold the struct_mutex when doing this
copy, since what is being copied is the contents of an array private to
i915_gem_execbuffer() anyway. So we can fix the potential deadlock (and
get rid of the lockdep warning) by simply moving the copy_to_user()
outside of where struct_mutex is held.
This fixes <http://bugzilla.kernel.org/show_bug.cgi?id=12491>.
Reported-by: Jesse Brandeburg <[email protected]>
Tested-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
The "devid <xxx> transid <xxx>" printk in btrfs_scan_one_device()
actually follows another printk that doesn't end in a newline (since the
intention is for the two printks to make one line of output), so the
KERN_INFO just ends up messing up the output:
device label exp <6>devid 1 transid 9 /dev/sda5
Fix this by changing the extra KERN_INFO to KERN_CONT.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Commit 3ada8b7e ("block: struct device - replace bus_id with dev_name(),
dev_set_name()") deleted the code in register_disk() that changed a '/'
to a '!' in the device name when registering a disk, but dev_set_name()
does not perform this conversion.
This leads to amusing problems with disks that have '/' in their names:
for example a failure to boot with the root partition on a cciss device,
even though the kernel says it knows about the root device:
VFS: Cannot open root device "cciss/c0d0p6" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
6800 71652960 cciss/c0d0 driver: cciss
6802 1 cciss/c0d0p2
6805 2931831 cciss/c0d0p5
6806 34354908 cciss/c0d0p6
6810 71652960 cciss/c0d1 driver: cciss
Fix this by adding code to change '/' to '!' in dev_set_name() to handle
this until dev_set_name() is converted to use kobject_set_name().
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Kay Sievers <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
If INET=y and INFINIBAND=y, but IPV6=m then INFINIBAND_ADDR_TRANS is set
to n and the RDMA CM functions rdma_connect() et al are not built.
However, the current config dependencies allow NET_9P_RDMA to be selected
in this, which leads to a build failure. Fix this by adding a dependency
on INFINIBAND_ADDR_TRANS to disallow NET_9P_RDMA in this case.
Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Impact: cleanup, reduce kernel size a bit
The current kernel build warns:
WARNING: vmlinux.o(.text+0x11458): Section mismatch in reference from the function swiotlb_alloc_boot() to the function .init.text:__alloc_bootmem_low()
The function swiotlb_alloc_boot() references
the function __init __alloc_bootmem_low().
This is often because swiotlb_alloc_boot lacks a __init
annotation or the annotation of __alloc_bootmem_low is wrong.
WARNING: vmlinux.o(.text+0x1011f2): Section mismatch in reference from the function swiotlb_late_init_with_default_size() to the function .init.text:__alloc_bootmem_low()
The function swiotlb_late_init_with_default_size() references
the function __init __alloc_bootmem_low().
This is often because swiotlb_late_init_with_default_size lacks a __init
annotation or the annotation of __alloc_bootmem_low is wrong.
and indeed the functions calling __alloc_bootmem_low() can be marked
__init as well.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Phillip O'Donnell <[email protected]> pointed out that the same
sign extension bug that was fixed in commit ba14a9c2 ("libata: Avoid
overflow in ata_tf_to_lba48() when tf->hba_lbal > 127") also appears to
exist in ata_tf_read_block(). Fix this by adding a cast to u64.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
In ata_tf_to_lba48(), when evaluating
(tf->hob_lbal & 0xff) << 24
the expression is promoted to signed int (since int can hold all values
of u8). However, if hob_lbal is 128 or more, then it is treated as a
negative signed value and sign-extended when promoted to u64 to | into
sectors, which leads to the MSB 32 bits of section getting set
incorrectly.
For example, Phillip O'Donnell <[email protected]> reported
that a 1.5GB drive caused:
ata3.00: HPA detected: current 2930277168, native 18446744072344861488
where 2930277168 == 0xAEA87B30 and 18446744072344861488 == 0xffffffffaea87b30
which shows the problem when hob_lbal is 0xae.
Fix this by adding a cast to u64, just as is used by for hob_lbah and
hob_lbam in the function.
Reported-by: Phillip O'Donnell <[email protected]>
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Commit 147e70e6 ("cxgb3: Use SKB list interfaces instead of home-grown
implementation.") causes a crash in t3_l2t_send_slow() when an iWARP
connection request is received. This is because the new l2t_entry.arpq
skb queue is never initialized, and therefore trying to add an skb to
it causes a NULL dereference. With the old code there was no need to
initialize the queues because the l2t_entry structures were zeroed,
and the code used NULL to mean empty.
Fix this by adding __skb_queue_head_init() when all the l2t_entry
structures get allocated.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Commit 8b150478 ("ppc: make phys_mem_access_prot() work with pfns
instead of addresses") fixed page_is_ram() in arch/ppc to avoid overflow
for addresses above 4G on 32-bit kernels. However arch/powerpc's
page_is_ram() is missing the same fix -- it computes a physical address
by doing pfn << PAGE_SHIFT, which overflows if pfn corresponds to a page
above 4G.
In particular this causes pages above 4G to be mapped with the wrong
caching attribute; for example many ppc440-based SoCs have PCI space
above 4G, and mmap()ing MMIO space may end up with a mapping that has
caching enabled.
Fix this by working with the pfn and avoiding the conversion to
physical address that causes the overflow. This patch compares the
pfn to max_pfn, which is a semantic change from the old code -- that
code compared the physical address to high_memory, which corresponds
to max_low_pfn. However, I think that was is another bug, since
highmem pages are still RAM.
Reported-by: vb <[email protected]>
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Commit 70f1bba4 ("x86: use ignore macro instead of hash comment") breaks
the 64-bit x86 build on toolchains that have CONFIG_AS_CFI undefined with:
arch/x86/lib/csum-copy_64.S:48: Error: Macro `ignore' was already defined
because <asm/dwarf2.h> now uses the ignore macro name itself. Fix this
by changing to __cfi_ignore in dwarf2.h.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Remove explicit lock_kernel() calls and document why the code is safe.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Remove explicit lock_kernel() calls and document why the code is safe.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
iph->tot_len is stored in network byte order, so access it using
ntohs(). This doesn't have any real world impact on pasemi_mac, since
the device only exists as part of a big-endian system-on-chip, but
fixing this gets rid of a sparse warning and avoids having a bad example
in the tree.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
iph->tot_len is stored in network byte order, so access it using
ntohs(). This doesn't have any real world impact on ehea, since ehea
only exists for big-endian platfroms (at the moment at least) but fixing
this gets rid of a sparse warning and avoids having a bad example in the
tree.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
It seems that the current implementaton of wait_for_completion_timeout()
has a small problem under very high load for the common pattern:
if (!wait_for_completion_timeout(&done, timeout))
/* handle failure */
because the implementation very roughly does (lots of code deleted to
show the basic flow):
static inline long __sched
do_wait_for_common(struct completion *x, long timeout, int state)
{
if (x->done)
return timeout;
do {
timeout = schedule_timeout(timeout);
if (!timeout)
return timeout;
} while (!x->done);
return timeout;
}
so if the system is very busy and x->done is not set when
do_wait_for_common() is entered, it is possible that the first call to
schedule_timeout() returns 0 because the task doing wait_for_completion
doesn't get rescheduled for a long time, even if it is woken up early
enough.
In this case, wait_for_completion_timeout() returns 0 without even
checking x->done again, and the code above falls into its failure case
purely for scheduler reasons, even if the hardware event or whatever was
being waited for happened early enough.
It would make sense to add an extra test to do_wait_for() in the timeout
case and return 1 if x->done is actually set.
A quick audit (not exhaustive) of wait_for_completion_timeout() callers
seems to indicate that no one actually cares about the return value in
the success case -- they just test for 0 (timed out) versus non-zero
(wait succeeded).
Signed-off-by: Ingo Molnar <[email protected]>
Commit 1a747ee0 ("locks: don't call ->copy_lock methods on return of
conflicting locks") changed fs/lockd/svclock.c to call
__locks_copy_lock() instead of locks_copy_lock(), but lockd can be built
as a module and __locks_copy_lock() is not exported, which causes a
build error
ERROR: "__locks_copy_lock" [fs/lockd/lockd.ko] undefined!
with CONFIG_LOCKD=m.
Fix this by exporting __locks_copy_lock().
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Commit b716bb91 ("iwlwifi: Cancel scanning upon association") moved the
test of priv->vif in iwl{3945,4964}_mac_config_interface() outside of
where priv->mutex is held, but still tries to do mutex_unlock() on
return. This is clearly wrong and triggers a nasty lockdep warning when
this codepath is triggered. Fix this by removing the mutex_unlock().
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Because of a typo in iwch_accept_cr(), the cxgb3 connection handling
code programs the hardware IRD (incoming RDMA read queue depth) with
the value that is passed in for the ORD (outgoing RDMA read queue
depth). In particular this means that if an application passes in IRD
> 0 and ORD = 0 (which is a completely sane and valid thing to do for
an app that expects only incoming RDMA read requests), then the
hardware will end up programmed with IRD = 0 and the app will fail in
a mysterious way.
Fix this by using "ep->ird" instead of "ep->ord" in the intended place.
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Steve Wise <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Using iWARP with a Chelsio T3 NIC generates the following lockdep warning:
=================================
[ INFO: inconsistent lock state ]
2.6.25-rc6 #50
---------------------------------
inconsistent {softirq-on-W} -> {in-softirq-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
(&adap->sge.reg_lock){-+..}, at: [<ffffffff880e5ee2>] cxgb_offload_ctl+0x3af/0x507 [cxgb3]
The problem is that reg_lock is used with plain spin_lock() in
drivers/net/cxgb3/sge.c but is used with spin_lock_irqsave() in
drivers/net/cxgb3/cxgb3_offload.c. This is technically a false
positive, since the uses in sge.c are only in the initialization and
cleanup paths and cannot overlap with any use in interrupt context.
The best fix is probably just to use spin_lock_irq() with reg_lock in
sge.c. Even though it's not strictly required for correctness, it
avoids triggering lockdep and the extra overhead of disabling
interrupts is not important at all in the initialization and cleanup
slow paths.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
The iWARP protocol limits RDMA read requests to a single scatter
entry. NFS/RDMA has code in rdma_read_max_sge() that is supposed to
limit the sge_count for RDMA read requests to 1, but the code to do
that is inside an #ifdef RDMA_TRANSPORT_IWARP block. In the mainline
kernel at least, RDMA_TRANSPORT_IWARP is an enum and not a
preprocessor #define, so the #ifdef'ed code is never compiled.
In my test of a kernel build with -j8 on an NFS/RDMA mount, this
problem eventually leads to trouble starting with:
svcrdma: Error posting send = -22
svcrdma : RDMA_READ error = -22
and things go downhill from there.
The trivial fix is to delete the #ifdef guard. The check seems to be
a remnant of when the NFS/RDMA code was not merged and needed to
compile against multiple kernel versions, although I don't think it
ever worked as intended. In any case now that the code is upstream
there's no need to test whether the RDMA_TRANSPORT_IWARP constant is
defined or not.
Without this patch, my kernel build on an NFS/RDMA mount using NetEffect
adapters quickly and 100% reproducibly failed with an error like:
ld: final link failed: Software caused connection abort
With the patch applied I was able to complete a kernel build on the
same setup.
(Tom Tucker says this is "actually an _ancient_ remnant when it had to
compile against iWARP vs. non-iWARP enabled OFA trees.")
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Tom Tucker <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Commit c18bab80 ("Input: i8042 - non-x86 build fix") introduced the
following warning on non-x86 builds:
drivers/input/serio/i8042.c: In function 'i8042_probe':
drivers/input/serio/i8042.c:1154: warning: unused variable 'param'
Fix this by moving the parameter variable declaration into the #ifdef too.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
We can simplify the code by deleting all of the duplicated DMI table
walking code and using the kernel's existing dmi_walk() interface to
find the DMI entry the driver is looking for.
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Thomas Mingarelli <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
The return value of smbios_scan_machine() is never used, and when it
succeeds it doesn't return anything, so just make it void. This fixes:
drivers/watchdog/hpwdt.c: In function 'smbios_scan_machine':
drivers/watchdog/hpwdt.c:562: warning: control reaches end of non-void function
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Thomas Mingarelli <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
On my HP DL380 G5 system running a 64-bit kernel, loading the hpwdt
driver causes a crash because the driver attempts to ioremap an
invalid physical address. This is because the driver has an incorrect
definition of the SMBIOS table entry point structure: the table
address is only a 32-bit quantity, and making it a u64 means that the
high-order 32 bits end up containing garbage.
Correcting the structure definition fixes the driver so that it loads
without any problems on my system.
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Thomas Mingarelli <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
The libertas driver exports a number of symbols with no in-tree users;
remove these unused exports. lbs_reset_device() is completely unused, with
no callers at all, so remove the function completely.
A couple of these unused exported symbols are static, which causes the
following build error on ia64 with gcc 4.2.3:
drivers/net/wireless/libertas/main.c:1375: error: __ksymtab_lbs_remove_mesh causes a section type conflict
drivers/net/wireless/libertas/main.c:1354: error: __ksymtab_lbs_add_mesh causes a section type conflict
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Holger Schurig <[email protected]>
Acked-by: Dan Williams <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
net/sunrpc/xprtrdma/svc_rdma_sendto.c:160: warning: format '%llx'
expects type 'long long unsigned int', but argument 3 has type 'u64'
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
When PCI error recovery was added to cxgb3, a function t3_io_slot_reset()
was added. This function can call back into t3_prep_adapter() at any
time, so t3_prep_adapter() can no longer be marked __devinit.
This patch removes the __devinit annotation from t3_prep_adapter() and
all the functions that it calls, which fixes
WARNING: drivers/net/cxgb3/built-in.o(.text+0x2427): Section mismatch in reference from the function t3_io_slot_reset() to the function .devinit.text:t3_prep_adapter()
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Commit da3dedd9 ("[NET]: Make NAPI polling independent of struct
net_device objects.") changed the interface to NAPI polling. Fix up
the ibm_newemac driver so that it works with this new interface. This
is actually a nice cleanup because ibm_newemac is one of the drivers
that wants to have multiple NAPI structures for a single net_device.
Compile-tested only as I don't have a system that uses the ibm_newemac
driver. This conversion the conversion for the ibm_emac driver that
was tested on real PowerPC 440SPe hardware.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Commit da3dedd9 ("[NET]: Make NAPI polling independent of struct
net_device objects.") changed the interface to NAPI polling. Fix up
the ibm_emac driver so that it works with this new interface. This is
actually a nice cleanup because ibm_emac is one of the drivers that
wants to have multiple NAPI structures for a single net_device.
Tested with the internal MAC of a PowerPC 440SPe SoC with an AMCC
'Yucca' evaluation board.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
The conversion to use netdevice internal stats left an unused variable
in ipoib_neigh_free(), since there's no longer any reason to get
netdev_priv() in order to increment dropped packets. Delete the
unused priv variable.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
The comparison with ZERO_SIZE_PTR in ZERO_OR_NULL_PTR() needs to be <=
(not just <) so that ZERO_OR_NULL_PTR(ZERO_SIZE_PTR) is 1.
Signed-off-by: Roland Dreier <[email protected]>
[ Duh! - Linus ]
Signed-off-by: Linus Torvalds <[email protected]>
When adding the cputable entry for 440SPe Rev. B, we also need to
adjust the existing entries for 440SP Rev. A and 440SPe Rev. B so that
they look more bits of the PVR. The 440SPe Rev. B has PVR 53421891,
which would match the current 440SP Rev. A pattern of 53xxx891. To
distinguish between 440SP and 440SPe, we need to use the first three
digits of the PVR, which are respectively 532 and 534.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
Chelsio without NAPI enabled has been broken (won't compile) since
3de00b89 ("chelsio: NAPI speed improvement"):
drivers/net/chelsio/sge.c: In function `t1_interrupt`:
drivers/net/chelsio/sge.c:1716: error: `Q` undeclared (first use in this function)
The change below seems to add back in the declaration and
initialization of `Q` that was removed by mistake, and at least makes
the driver compile for me, although I have no hardware and hence no
way to test whether this actually works.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
On ia64, drivers/base/dma-mapping.c doesn't build because it calls
dma_alloc_noncoherent() and dma_free_noncoherent(), which appear to be
terminally broken; the calls end up generating errors like
drivers/base/dma-mapping.c: In function 'dmam_noncoherent_release':
drivers/base/dma-mapping.c:32: error: 'struct ia64_machine_vector' has no member named 'platform_dma_free_coherent'
because the multiple levels of macro expansion in <asm/dma-mapping.h> and
<asm/machvec.h> end up turning a call to dma_free_noncoherent() into
ia64_mv.platform_dma_free_coherent (instead of the intended
ia64_mv.dma_free_coherent).
This patch fixes this by converting dma_{alloc,free}_noncoherent() into
inline functions that call the corresponding coherent functions, instead of
trying to do this with macros.
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Tony Luck <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
I've seen my box paralyzed by an endless spew of
rtc: lost some interrupts at 1024Hz.
messages on the serial console. What seems to be happening is that
something real causes an interrupt to be lost and triggers the
message. But then printing the message to the serial console (from
the hpet interrupt handler) takes more than 1/1024th of a second, and
then some more interrupts are lost, so the message triggers again....
Fix this by adding a printk_ratelimit() before printing the warning.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Andi Kleen <[email protected]>
The current PowerPC code makes pci_unmap_addr(), pci_unmap_addr_set(),
and friends trivial for all 32-bit kernels. This is reasonable, since
for those kernels it is true that pci_unmap_single() does not need the
DMA address from the original DMA mapping -- in fact, it is a NOP.
However, I recently tried the tg3 driver on a PowerPC 440SPe machine,
which runs a 32-bit kernel and has non-cache-coherent PCI DMA. I
found that the tg3 driver crashed in pci_dma_sync_single_for_cpu(),
since for non-coherent systems, that function must invalidate the
cache for the DMA address range requested, and therefore it does use
the address passed in. tg3 uses a DMA address it stashes away with
pci_unmap_addr_set() and retrieves with pci_unmap_addr(). Of course,
since pci_unmap_addr() is defined to (0) right now, this doesn't work.
It seems to me that the tg3 driver is using pci_unmap_addr() in a
legitimate way -- I wouldn't want to have to teach all drivers that
they should use pci_unmap_addr() if they only need the address for
unmapping functions, but if they want the pci_dma_sync functions, then
they have to store the DMA address without the helper macros.
The right fix therefore seems to be in the definition of the macros in
<asm/pci.h> -- we should use the trivial versions only for 32-bit
kernels for coherent systems, and the real versions for both 64-bit
kernels and non-coherent systems.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
Currently, the code in lib/idr.c uses a bare spin_lock(&idp->lock) to do
internal locking. This is a nasty trap for code that might call idr
functions from different contexts; for example, it seems perfectly
reasonable to call idr_get_new() from process context and idr_remove() from
interrupt context -- but with the current locking this would lead to a
potential deadlock.
The simplest fix for this is to just convert the idr locking to use
spin_lock_irqsave().
In particular, this fixes a very complicated locking issue detected by
lockdep, involving the ib_ipoib driver's priv->lock and dev->_xmit_lock,
which get involved with the ib_sa module's query_idr.lock.
Cc: Arjan van de Ven <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Zach Brown <[email protected]>,
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
With CONFIG_NUMA set, kmem_cache_destroy() may fail and say "Can't
free all objects." The problem is caused by sequences such as the
following (suppose we are on a NUMA machine with two nodes, 0 and 1):
* Allocate an object from cache on node 0.
* Free the object on node 1. The object is put into node 1's alien
array_cache for node 0.
* Call kmem_cache_destroy(), which ultimately ends up in __cache_shrink().
* __cache_shrink() does drain_cpu_caches(), which loops through all nodes.
For each node it drains the shared array_cache and then handles the
alien array_cache for the other node.
However this means that node 0's shared array_cache will be drained,
and then node 1 will move the contents of its alien[0] array_cache
into that same shared array_cache. node 0's shared array_cache is
never looked at again, so the objects left there will appear to be in
use when __cache_shrink() calls __node_shrink() for node 0. So
__node_shrink() will return 1 and kmem_cache_destroy() will fail.
This patch fixes this by having drain_cpu_caches() do
drain_alien_cache() on every node before it does drain_array() on the
nodes' shared array_caches.
The problem was originally reported by Or Gerlitz <[email protected]>.
Signed-off-by: Roland Dreier <[email protected]>
Acked-by: Christoph Lameter <[email protected]>
Acked-by: Pekka Enberg <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Several structs in <scsi/srp.h> get padded to a multiple of 8 bytes on
64-bit architectures and end up with a size that does not match the
definition in the SRP spec:
SRP spec 64-bit
sizeof (struct indirect_buf) 20 24
sizeof (struct srp_login_rsp) 52 56
sizeof (struct srp_rsp) 36 40
Fix this by adding __attribute__((packed)) to the offending structs.
Problem pointed out by Arne Redlich <[email protected]>.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Sparse warns about casting to a __bitwise type. However, it's correct
to do when defining the enum for pci_bus_flags_t, so add a __force to
quiet the warnings. This will fix getting
include/linux/pci.h:100:26: warning: cast to restricted type
from sparse all over the build.
Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Fix the IPoIB build (which is broken in net-2.6.17 because of my
screw-up, which left out this chunk in ipoib_multicast.c).
The neighbour destructor is now in neigh_params, so we don't
need to clear it in the ops structure.
Signed-off-by: Roland Dreier <[email protected]>
Roland Dreier