git.openwrt.org Git - openwrt/staging/blogic.git/log

FS-Cache: Don't use spin_is_locked() in assertions

Under certain circumstances, spin_is_locked() is hardwired to 0 - even when the
code would normally be in a locked section where it should return 1. This
means it cannot be used for an assertion that checks that a spinlock is locked.

Remove such usages from FS-Cache.

The following oops might otherwise be observed:

FS-Cache: Assertion failed
BUG: failure at fs/fscache/operation.c:270/fscache_start_operations()!
Kernel panic - not syncing: BUG!
CPU: 0 PID: 10 Comm: kworker/u2:1 Not tainted 3.10.0-rc1-00133-ge7ebb75 #2
Workqueue: fscache_operation fscache_op_work_func [fscache]
7f091c48 603c8947 7f090000 7f9b1361 7f25f080 00000001 7f26d440 7f091c90
60299eb8 7f091d90 602951c5 7f26d440 3000000008 7f091da0 7f091cc0 7f091cd0
00000007 00000007 00000006 7f091ae0 00000010 0000010e 7f9af330 7f091ae0
Call Trace:
7f091c88: [<60299eb8>] dump_stack+0x17/0x19
7f091c98: [<602951c5>] panic+0xf4/0x1e9
7f091d38: [<6002b10e>] set_signals+0x1e/0x40
7f091d58: [<6005b89e>] __wake_up+0x4e/0x70
7f091d98: [<7f9aa003>] fscache_start_operations+0x43/0x50 [fscache]
7f091da8: [<7f9aa1e3>] fscache_op_complete+0x1d3/0x220 [fscache]
7f091db8: [<60082985>] unlock_page+0x55/0x60
7f091de8: [<7fb25bb0>] cachefiles_read_copier+0x250/0x330 [cachefiles]
7f091e58: [<7f9ab03c>] fscache_op_work_func+0xac/0x120 [fscache]
7f091e88: [<6004d5b0>] process_one_work+0x250/0x3a0
7f091ef8: [<6004edc7>] worker_thread+0x177/0x2a0
7f091f38: [<6004ec50>] worker_thread+0x0/0x2a0
7f091f58: [<60054418>] kthread+0xd8/0xe0
7f091f68: [<6005bb27>] finish_task_switch.isra.64+0x37/0xa0
7f091fd8: [<600185cf>] new_thread_handler+0x8f/0xb0

Reported-by: Milosz Tanski <milosz@adfin.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-and-tested-By: Milosz Tanski <milosz@adfin.com>

FS-Cache: The retrieval remaining-pages counter needs to be atomic_t

struct fscache_retrieval contains a count of the number of pages that still
need some processing (n_pages).  This is decremented as the pages are
processed.

However, this needs to be atomic as fscache_retrieval_complete() (I think) just
occasionally may be called from cachefiles_read_backing_file() and
cachefiles_read_copier() simultaneously.

This happens when an fscache_read_or_alloc_pages() request containing a lot of
pages (say a couple of hundred) is being processed.  The read on each backing
page is dispatched individually because we need to insert a monitor into the
waitqueue to catch when the read completes.  However, under low-memory
conditions, we might be forced to wait in the allocator - and this gives the
I/O on the backing page a chance to complete first.

When the I/O completes, fscache_enqueue_retrieval() chucks the retrieval onto
the workqueue without waiting for the operation to finish the initial I/O
dispatch (we want to release any pages we can as soon as we can), thus both can
end up running simultaneously and potentially attempting to partially complete
the retrieval simultaneously (ENOMEM may occur, backing pages may already be in
the page cache).

This was demonstrated by parallelling the non-atomic counter with an atomic
counter and printing both of them when the assertion fails.  At this point, the
atomic counter has reached zero, but the non-atomic counter has not.

To fix this, make the counter an atomic_t.

This results in the following bug appearing

FS-Cache: Assertion failed
3 == 5 is false
------------[ cut here ]------------
kernel BUG at fs/fscache/operation.c:421!

or

FS-Cache: Assertion failed
3 == 5 is false
------------[ cut here ]------------
kernel BUG at fs/fscache/operation.c:414!

With a backtrace like the following:

RIP: 0010:[<ffffffffa0211b1d>] fscache_put_operation+0x1ad/0x240 [fscache]
Call Trace:
[<ffffffffa0213185>] fscache_retrieval_work+0x55/0x270 [fscache]
[<ffffffffa0213130>] ? fscache_retrieval_work+0x0/0x270 [fscache]
[<ffffffff81090b10>] worker_thread+0x170/0x2a0
[<ffffffff81096d10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff810909a0>] ? worker_thread+0x0/0x2a0
[<ffffffff81096966>] kthread+0x96/0xa0
[<ffffffff8100c0ca>] child_rip+0xa/0x20
[<ffffffff810968d0>] ? kthread+0x0/0xa0
[<ffffffff8100c0c0>] ? child_rip+0x0/0x20

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-and-tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

cachefiles: remove unused macro list_to_page()

Signed-off-by: Haicheng Li <haicheng.li@linux.intel.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

FS-Cache: Simplify cookie retention for fscache_objects, fixing oops

Simplify the way fscache cache objects retain their cookie.  The way I
implemented the cookie storage handling made synchronisation a pain (ie. the
object state machine can't rely on the cookie actually still being there).

Instead of the the object being detached from the cookie and the cookie being
freed in __fscache_relinquish_cookie(), we defer both operations:

(*) The detachment of the object from the list in the cookie now takes place
     in fscache_drop_object() and is thus governed by the object state machine
     (fscache_detach_from_cookie() has been removed).

(*) The release of the cookie is now in fscache_object_destroy() - which is
     called by the cache backend just before it frees the object.

This means that the fscache_cookie struct is now available to the cache all the
way through from ->alloc_object() to ->drop_object() and ->put_object() -
meaning that it's no longer necessary to take object->lock to guarantee access.

However, __fscache_relinquish_cookie() doesn't wait for the object to go all
the way through to destruction before letting the netfs proceed.  That would
massively slow down the netfs.  Since __fscache_relinquish_cookie() leaves the
cookie around, in must therefore break all attachments to the netfs - which
includes ->def, ->netfs_data and any outstanding page read/writes.

To handle this, struct fscache_cookie now has an n_active counter:

(1) This starts off initialised to 1.

(2) Any time the cache needs to get at the netfs data, it calls
     fscache_use_cookie() to increment it - if it is not zero.  If it was zero,
     then access is not permitted.

(3) When the cache has finished with the data, it calls fscache_unuse_cookie()
     to decrement it.  This does a wake-up on it if it reaches 0.

(4) __fscache_relinquish_cookie() decrements n_active and then waits for it to
     reach 0.  The initialisation to 1 in step (1) ensures that we only get
     wake ups when we're trying to get rid of the cookie.

This leaves __fscache_relinquish_cookie() a lot simpler.

***
This fixes a problem in the current code whereby if fscache_invalidate() is
followed sufficiently quickly by fscache_relinquish_cookie() then it is
possible for __fscache_relinquish_cookie() to have detached the cookie from the
object and cleared the pointer before a thread is dispatched to process the
invalidation state in the object state machine.

Since the pending write clearance was deferred to the invalidation state to
make it asynchronous, we need to either wait in relinquishment for the stores
tree to be cleared in the invalidation state or we need to handle the clearance
in relinquishment.

Further, if the relinquishment code does clear the tree, then the invalidation
state need to make the clearance contingent on still having the cookie to hand
(since that's where the tree is rooted) and we have to prevent the cookie from
disappearing for the duration.

This can lead to an oops like the following:

BUG: unable to handle kernel NULL pointer dereference at 000000000000000c
...
RIP: 0010:[<ffffffff8151023e>] _spin_lock+0xe/0x30
...
CR2: 000000000000000c ...
...
Process kslowd002 (...)
....
Call Trace:
[<ffffffffa01c3278>] fscache_invalidate_writes+0x38/0xd0 [fscache]
[<ffffffff810096f0>] ? __switch_to+0xd0/0x320
[<ffffffff8105e759>] ? find_busiest_queue+0x69/0x150
[<ffffffff8110ddd4>] ? slow_work_enqueue+0x104/0x180
[<ffffffffa01c1303>] fscache_object_slow_work_execute+0x5e3/0x9d0 [fscache]
[<ffffffff81096b67>] ? bit_waitqueue+0x17/0xd0
[<ffffffff8110e233>] slow_work_execute+0x233/0x310
[<ffffffff8110e515>] slow_work_thread+0x205/0x360
[<ffffffff81096ca0>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8110e310>] ? slow_work_thread+0x0/0x360
[<ffffffff81096936>] kthread+0x96/0xa0
[<ffffffff8100c0ca>] child_rip+0xa/0x20
[<ffffffff810968a0>] ? kthread+0x0/0xa0
[<ffffffff8100c0c0>] ? child_rip+0x0/0x20

The parameter to fscache_invalidate_writes() was object->cookie which is NULL.

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

FS-Cache: Fix object state machine to have separate work and wait states

Fix object state machine to have separate work and wait states as that makes
it easier to envision.

There are now three kinds of state:

(1) Work state.  This is an execution state.  No event processing is performed
     by a work state.  The function attached to a work state returns a pointer
     indicating the next state to which the OSM should transition.  Returning
     NO_TRANSIT repeats the current state, but goes back to the scheduler
     first.

(2) Wait state.  This is an event processing state.  No execution is
     performed by a wait state.  Wait states are just tables of "if event X
     occurs, clear it and transition to state Y".  The dispatcher returns to
     the scheduler if none of the events in which the wait state has an
     interest are currently pending.

(3) Out-of-band state.  This is a special work state.  Transitions to normal
     states can be overridden when an unexpected event occurs (eg. I/O error).
     Instead the dispatcher disables and clears the OOB event and transits to
     the specified work state.  This then acts as an ordinary work state,
     though object->state points to the overridden destination.  Returning
     NO_TRANSIT resumes the overridden transition.

In addition, the states have names in their definitions, so there's no need for
tables of state names.  Further, the EV_REQUEUE event is no longer necessary as
that is automatic for work states.

Since the states are now separate structs rather than values in an enum, it's
not possible to use comparisons other than (non-)equality between them, so use
some object->flags to indicate what phase an object is in.

The EV_RELEASE, EV_RETIRE and EV_WITHDRAW events have been squished into one
(EV_KILL).  An object flag now carries the information about retirement.

Similarly, the RELEASING, RECYCLING and WITHDRAWING states have been merged
into an KILL_OBJECT state and additional states have been added for handling
waiting dependent objects (JUMPSTART_DEPS and KILL_DEPENDENTS).

A state has also been added for synchronising with parent object initialisation
(WAIT_FOR_PARENT) and another for initiating look up (PARENT_READY).

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

FS-Cache: Wrap checks on object state

Wrap checks on object state (mostly outside of fs/fscache/object.c) with
inline functions so that the mechanism can be replaced.

Some of the state checks within object.c are left as-is as they will be
replaced.

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

FS-Cache: Uninline fscache_object_init()

Uninline fscache_object_init() so as not to expose some of the FS-Cache
internals to the cache backend.

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

FS-Cache: Don't sleep in page release if __GFP_FS is not set

Don't sleep in __fscache_maybe_release_page() if __GFP_FS is not set.  This
goes some way towards mitigating fscache deadlocking against ext4 by way of
the allocator, eg:

INFO: task flush-8:0:24427 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
flush-8:0       D ffff88003e2b9fd8     0 24427      2 0x00000000
ffff88003e2b9138 0000000000000046 ffff880012e3a040 ffff88003e2b9fd8
0000000000011c80 ffff88003e2b9fd8 ffffffff81a10400 ffff880012e3a040
0000000000000002 ffff880012e3a040 ffff88003e2b9098 ffffffff8106dcf5
Call Trace:
[<ffffffff8106dcf5>] ? __lock_is_held+0x31/0x53
[<ffffffff81219b61>] ? radix_tree_lookup_element+0xf4/0x12a
[<ffffffff81454bed>] schedule+0x60/0x62
[<ffffffffa01d349c>] __fscache_wait_on_page_write+0x8b/0xa5 [fscache]
[<ffffffff810498a8>] ? __init_waitqueue_head+0x4d/0x4d
[<ffffffffa01d393a>] __fscache_maybe_release_page+0x30c/0x324 [fscache]
[<ffffffffa01d369a>] ? __fscache_maybe_release_page+0x6c/0x324 [fscache]
[<ffffffff81071b53>] ? trace_hardirqs_on_caller+0x114/0x170
[<ffffffffa01fd7b2>] nfs_fscache_release_page+0x68/0x94 [nfs]
[<ffffffffa01ef73e>] nfs_release_page+0x7e/0x86 [nfs]
[<ffffffff810aa553>] try_to_release_page+0x32/0x3b
[<ffffffff810b6c70>] shrink_page_list+0x535/0x71a
[<ffffffff81071b53>] ? trace_hardirqs_on_caller+0x114/0x170
[<ffffffff810b7352>] shrink_inactive_list+0x20a/0x2dd
[<ffffffff81071a13>] ? mark_held_locks+0xbe/0xea
[<ffffffff810b7a65>] shrink_lruvec+0x34c/0x3eb
[<ffffffff810b7bd3>] do_try_to_free_pages+0xcf/0x355
[<ffffffff810b7fc8>] try_to_free_pages+0x9a/0xa1
[<ffffffff810b08d2>] __alloc_pages_nodemask+0x494/0x6f7
[<ffffffff810d9a07>] kmem_getpages+0x58/0x155
[<ffffffff810dc002>] fallback_alloc+0x120/0x1f3
[<ffffffff8106db23>] ? trace_hardirqs_off+0xd/0xf
[<ffffffff810dbed3>] ____cache_alloc_node+0x177/0x186
[<ffffffff81162a6c>] ? ext4_init_io_end+0x1c/0x37
[<ffffffff810dc403>] kmem_cache_alloc+0xf1/0x176
[<ffffffff810b17ac>] ? test_set_page_writeback+0x101/0x113
[<ffffffff81162a6c>] ext4_init_io_end+0x1c/0x37
[<ffffffff81162ce4>] ext4_bio_write_page+0x20f/0x3af
[<ffffffff8115cc02>] mpage_da_submit_io+0x26e/0x2f6
[<ffffffff811088e5>] ? __find_get_block_slow+0x38/0x133
[<ffffffff81161348>] mpage_da_map_and_submit+0x3a7/0x3bd
[<ffffffff81161a60>] ext4_da_writepages+0x30d/0x426
[<ffffffff810b3359>] do_writepages+0x1c/0x2a
[<ffffffff81102f4d>] __writeback_single_inode+0x3e/0xe5
[<ffffffff81103995>] writeback_sb_inodes+0x1bd/0x2f4
[<ffffffff81103b3b>] __writeback_inodes_wb+0x6f/0xb4
[<ffffffff81103c81>] wb_writeback+0x101/0x195
[<ffffffff81071b53>] ? trace_hardirqs_on_caller+0x114/0x170
[<ffffffff811043aa>] ? wb_do_writeback+0xaa/0x173
[<ffffffff8110434a>] wb_do_writeback+0x4a/0x173
[<ffffffff81071bbc>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81038554>] ? del_timer+0x4b/0x5b
[<ffffffff811044e0>] bdi_writeback_thread+0x6d/0x147
[<ffffffff81104473>] ? wb_do_writeback+0x173/0x173
[<ffffffff81048fbc>] kthread+0xd0/0xd8
[<ffffffff81455eb2>] ? _raw_spin_unlock_irq+0x29/0x3e
[<ffffffff81048eec>] ? __init_kthread_worker+0x55/0x55
[<ffffffff81456aac>] ret_from_fork+0x7c/0xb0
[<ffffffff81048eec>] ? __init_kthread_worker+0x55/0x55
2 locks held by flush-8:0/24427:
#0:  (&type->s_umount_key#41){.+.+..}, at: [<ffffffff810e3b73>] grab_super_passive+0x4c/0x76
#1:  (jbd2_handle){+.+...}, at: [<ffffffff81190d81>] start_this_handle+0x475/0x4ea

The problem here is that another thread, which is attempting to write the
to-be-stored NFS page to the on-ext4 cache file is waiting for the journal
lock, eg:

INFO: task kworker/u:2:24437 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u:2     D ffff880039589768     0 24437      2 0x00000000
ffff8800395896d8 0000000000000046 ffff8800283bf040 ffff880039589fd8
0000000000011c80 ffff880039589fd8 ffff880039f0b040 ffff8800283bf040
0000000000000006 ffff8800283bf6b8 ffff880039589658 ffffffff81071a13
Call Trace:
[<ffffffff81071a13>] ? mark_held_locks+0xbe/0xea
[<ffffffff81455e73>] ? _raw_spin_unlock_irqrestore+0x3a/0x50
[<ffffffff81071b53>] ? trace_hardirqs_on_caller+0x114/0x170
[<ffffffff81071bbc>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81454bed>] schedule+0x60/0x62
[<ffffffff81190c23>] start_this_handle+0x317/0x4ea
[<ffffffff810498a8>] ? __init_waitqueue_head+0x4d/0x4d
[<ffffffff81190fcc>] jbd2__journal_start+0xb3/0x12e
[<ffffffff81176606>] __ext4_journal_start_sb+0xb2/0xc6
[<ffffffff8115f137>] ext4_da_write_begin+0x109/0x233
[<ffffffff810a964d>] generic_file_buffered_write+0x11a/0x264
[<ffffffff811032cf>] ? __mark_inode_dirty+0x2d/0x1ee
[<ffffffff810ab1ab>] __generic_file_aio_write+0x2a5/0x2d5
[<ffffffff810ab24a>] generic_file_aio_write+0x6f/0xd0
[<ffffffff81159a2c>] ext4_file_write+0x38c/0x3c4
[<ffffffff810e0915>] do_sync_write+0x91/0xd1
[<ffffffffa00a17f0>] cachefiles_write_page+0x26f/0x310 [cachefiles]
[<ffffffffa01d470b>] fscache_write_op+0x21e/0x37a [fscache]
[<ffffffff81455eb2>] ? _raw_spin_unlock_irq+0x29/0x3e
[<ffffffffa01d2479>] fscache_op_work_func+0x78/0xd7 [fscache]
[<ffffffff8104455a>] process_one_work+0x232/0x3a8
[<ffffffff810444ff>] ? process_one_work+0x1d7/0x3a8
[<ffffffff81044ee0>] worker_thread+0x214/0x303
[<ffffffff81044ccc>] ? manage_workers+0x245/0x245
[<ffffffff81048fbc>] kthread+0xd0/0xd8
[<ffffffff81455eb2>] ? _raw_spin_unlock_irq+0x29/0x3e
[<ffffffff81048eec>] ? __init_kthread_worker+0x55/0x55
[<ffffffff81456aac>] ret_from_fork+0x7c/0xb0
[<ffffffff81048eec>] ? __init_kthread_worker+0x55/0x55
4 locks held by kworker/u:2/24437:
#0:  (fscache_operation){.+.+.+}, at: [<ffffffff810444ff>] process_one_work+0x1d7/0x3a8
#1:  ((&op->work)){+.+.+.}, at: [<ffffffff810444ff>] process_one_work+0x1d7/0x3a8
#2:  (sb_writers#14){.+.+.+}, at: [<ffffffff810ab22c>] generic_file_aio_write+0x51/0xd0
#3:  (&sb->s_type->i_mutex_key#19){+.+.+.}, at: [<ffffffff810ab236>] generic_file_aio_write+0x5b/0x

fscache already tries to cancel pending stores, but it can't cancel a write
for which I/O is already in progress.

An alternative would be to accept writing garbage to the cache under extreme
circumstances and to kill the afflicted cache object if we have to do this.
However, we really need to know how strapped the allocator is before deciding
to do that.

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

CacheFiles: name i_mutex lock class explicitly

Just some cleanup.

(And note the caller of this function may, for example, call vfs_unlink
on a child, so the "1" (I_MUTEX_PARENT) really was what was intended
here.)

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

fs/fscache: remove spin_lock() from the condition in while()

The spinlock() within the condition in while() will cause a compile error
if it is not a function. This is not a problem on mainline but it does not
look pretty and there is no reason to do it that way.
That patch writes it a little differently and avoids the double condition.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

Add wait_on_atomic_t() and wake_up_atomic_t()

Add wait_on_atomic_t() and wake_up_atomic_t() to indicate became-zero events on
atomic_t types.  This uses the bit-wake waitqueue table.  The key is set to a
value outside of the number of bits in a long so that wait_on_bit() won't be
woken up accidentally.

What I'm using this for is: in a following patch I add a counter to struct
fscache_cookie to count the number of outstanding operations that need access
to netfs data.  The way this works is:

(1) When a cookie is allocated, the counter is initialised to 1.

(2) When an operation wants to access netfs data, it calls atomic_inc_unless()
     to increment the counter before it does so.  If it was 0, then the counter
     isn't incremented, the operation isn't permitted to access the netfs data
     (which might by this point no longer exist) and the operation aborts in
     some appropriate manner.

(3) When an operation finishes with the netfs data, it decrements the counter
     and if it reaches 0, calls wake_up_atomic_t() on it - the assumption being
     that it was the last blocker.

(4) When a cookie is released, the counter is decremented and the releaser
     uses wait_on_atomic_t() to wait for the counter to become 0 - which should
     indicate no one is using the netfs data any longer.  The netfs data can
     then be destroyed.

There are some alternatives that I have thought of and that have been suggested
by Tejun Heo:

(A) Using wait_on_bit() to wait on a bit in the counter.  This doesn't work
     because if that bit happens to be 0 then the wait won't happen - even if
     the counter is non-zero.

(B) Using wait_on_bit() to wait on a flag elsewhere which is cleared when the
     counter reaches 0.  Such a flag would be redundant and would add
     complexity.

(C) Adding a waitqueue to fscache_cookie - this would expand that struct by
     several words for an event that happens just once in each cookie's
     lifetime.  Further, cookies are generally per-file so there are likely to
     be a lot of them.

(D) Similar to (C), but add a pointer to a waitqueue in the cookie instead of
     a waitqueue.  This would add single word per cookie and so would be less
     of an expansion - but still an expansion.

(E) Adding a static waitqueue to the fscache module.  Generally this would be
     fine, but under certain circumstances many cookies will all get added at
     the same time (eg. NFS umount, cache withdrawal) thereby presenting
     scaling issues.  Note that the wait may be significant as disk I/O may be
     in progress.

So, I think reusing the wait_on_bit() waitqueue set is reasonable.  I don't
make much use of the waitqueue I need on a per-cookie basis, but sometimes I
have a huge flood of the cookies to deal with.

I also don't want to add a whole new set of global waitqueue tables
specifically for the dec-to-0 event if I can reuse the bit tables.

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-By: Milosz Tanski <milosz@adfin.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

Merge tag 'ext4_for_linus_stable' of git://git./linux/kernel/git/tytso/ext4

Pull ext4 update from Ted Ts'o:
"Fixed regressions (two stability regressions and a performance
  regression) introduced during the 3.10-rc1 merge window.

  Also included is a bug fix relating to allocating blocks after
  resizing an ext3 file system when using the ext4 file system driver"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  jbd,jbd2: fix oops in jbd2_journal_put_journal_head()
  ext4: revert "ext4: use io_end for multiple bios"
  ext4: limit group search loop for non-extent files
  ext4: fix fio regression

Merge branch 'for-3.10-fixes' of git://git./linux/kernel/git/tj/wq

Pull workqueue fix from Tejun Heo:
"A fix for a workqueue_congested() regression that broke fscache"

* 'for-3.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: workqueue_congested() shouldn't translate WORK_CPU_UNBOUND into node number

Merge branch 'merge' of git://git./linux/kernel/git/benh/powerpc

Pull powerpc fixes from Benjamin Herrenschmidt:
"This is mostly bug fixes (some of them regressions, some of them I
  deemed worth merging now) along with some patches from Li Zhong
  hooking up the new context tracking stuff (for the new full NO_HZ)"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (25 commits)
  powerpc: Set show_unhandled_signals to 1 by default
  powerpc/perf: Fix setting of "to" addresses for BHRB
  powerpc/pmu: Fix order of interpreting BHRB target entries
  powerpc/perf: Move BHRB code into CONFIG_PPC64 region
  powerpc: select HAVE_CONTEXT_TRACKING for pSeries
  powerpc: Use the new schedule_user API on userspace preemption
  powerpc: Exit user context on notify resume
  powerpc: Exception hooks for context tracking subsystem
  powerpc: Syscall hooks for context tracking subsystem
  powerpc/booke64: Fix kernel hangs at kernel_dbg_exc
  powerpc: Fix irq_set_affinity() return values
  powerpc: Provide __bswapdi2
  powerpc/powernv: Fix starting of secondary CPUs on OPALv2 and v3
  powerpc/powernv: Detect OPAL v3 API version
  powerpc: Fix MAX_STACK_TRACE_ENTRIES too low warning again
  powerpc: Make CONFIG_RTAS_PROC depend on CONFIG_PROC_FS
  powerpc: Bring all threads online prior to migration/hibernation
  powerpc/rtas_flash: Fix validate_flash buffer overflow issue
  powerpc/kexec: Fix kexec when using VMX optimised memcpy
  powerpc: Fix build errors STRICT_MM_TYPECHECKS
  ...

powerpc: Set show_unhandled_signals to 1 by default

Just like other architectures

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/perf: Fix setting of "to" addresses for BHRB

Currently we only set the "to" address in the branch stack when the CPU
explicitly gives us a value.  Unfortunately it only does this for XL form
branches (eg blr, bctr, bctar) and not I and B form branches (eg b, bc).

Fortunately if we read the instruction from memory we can extract the offset of
a branch and calculate the target address.

This adds a function power_pmu_bhrb_to() to calculate the target/to address of
the corresponding I and B form branches.  It handles branches in both user and
kernel spaces.  It also plumbs this into the perf brhb reading code.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/pmu: Fix order of interpreting BHRB target entries

The current Branch History Rolling Buffer (BHRB) code misinterprets the order
of entries in the hardware buffer. It assumes that a branch target address
will be read _after_ its corresponding branch. In reality the branch target
comes before (lower mfbhrb entry) it's corresponding branch.

This is a rewrite of the code to take this into account.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/perf: Move BHRB code into CONFIG_PPC64 region

The new Branch History Rolling buffer (BHRB) code is only useful on 64bit
processors, so move it into the #ifdef CONFIG_PPC64 region.

This avoids code bloat on 32bit systems.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: select HAVE_CONTEXT_TRACKING for pSeries

Start context tracking support from pSeries.

Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Use the new schedule_user API on userspace preemption

This patch corresponds to
[PATCH] x86: Use the new schedule_user API on userspace preemption
commit 0430499ce9d78691f3985962021b16bf8f8a8048

Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Exit user context on notify resume

This patch allows RCU usage in do_notify_resume, e.g. signal handling.
It corresponds to
[PATCH] x86: Exit RCU extended QS on notify resume
commit edf55fda35c7dc7f2d9241c3abaddaf759b457c6

Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Exception hooks for context tracking subsystem

This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.

This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
  commit 6ba3c97a38803883c2eee489505796cb0a727122

But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
  context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
  context_tracking: Restore correct previous context state on exception exit

it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.

Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Syscall hooks for context tracking subsystem

This is the syscall slow path hooks for context tracking subsystem,
corresponding to
[PATCH] x86: Syscall hooks for userspace RCU extended QS
commit bf5a3c13b939813d28ce26c01425054c740d6731

TIF_MEMDIE is moved to the second 16-bits (with value 17), as it seems there
is no asm code using it. TIF_NOHZ is added to _TIF_SYCALL_T_OR_A, so it is
better for it to be in the same 16 bits with others in the group, so in the
asm code, andi. with this group could work.

Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/booke64: Fix kernel hangs at kernel_dbg_exc

MSR_DE is not cleared on entry to the kernel, and we don't clear it
explicitly outside of debug code.  If we have MSR_DE set in
prime_debug_regs(), and the new thread has events enabled in DBCR0
(e.g.  ICMP is set in thread->dbsr0, even though it was cleared in the
real DBCR0 when the thread got scheduled out), we'll end up taking a
debug exception in the kernel when DBCR0 is loaded.  DSRR0 will not
point to an exception vector, and the kernel ends up hanging at
kernel_dbg_exc.  Fix this by always clearing MSR_DE when we load new
debug state.

Another observed source of kernel_dbg_exc hangs is with the branch
taken event.  If this event is active, but we take a non-debug trap
(e.g. a TLB miss or an asynchronous interrupt) before the next branch.
We end up taking a branch-taken debug exception on the initial branch
instruction of the exception vector, but because the debug exception is
DBSR_BT rather than DBSR_IC we branch to kernel_dbg_exc before even
checking the DSRR0 address.  Fix this by checking for DBSR_BT as well
as DBSR_IC, which is what 32-bit does and what the comments suggest was
intended in the 64-bit code as well.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Fix irq_set_affinity() return values

Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Provide __bswapdi2

Some versions of GCC apparently expect this to be provided by libgcc.

Updates from Mikey to fix 32 bit version and adding "r" to registers.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/powernv: Fix starting of secondary CPUs on OPALv2 and v3

The current code fails to handle kexec on OPALv2. This fixes it
and adds code to improve the situation on OPALv3 where we can
query the CPU status from the firmware and decide what to do
based on that.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/powernv: Detect OPAL v3 API version

Future firmwares will support that new version

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Fix MAX_STACK_TRACE_ENTRIES too low warning again

Saw this warning again, and this time from the ret_from_fork path.

It seems we could clear the back chain earlier in copy_thread(), which
could cover both path, and also fix potential lockdep usage in
schedule_tail(), or exception occurred before we clear the back chain.

Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Make CONFIG_RTAS_PROC depend on CONFIG_PROC_FS

We are getting build errors with CONFIG_PROC_FS=n:

arch/powerpc/kernel/rtas_flash.c
In function 'rtas_flash_init':
745:33: error: unused variable 'f' [-Werror=unused-variable]

But rtas_flash.c should not be built when CONFIG_PROC_FS=n, beacause all
it does is provide a /proc interface to the RTAS flash routines.

CONFIG_RTAS_FLASH already depends on CONFIG_RTAS_PROC, to indicate that
it depends on the RTAS proc support, but CONFIG_RTAS_PROC does not
depend on CONFIG_PROC_FS. So fix that.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Bring all threads online prior to migration/hibernation

This patch brings online all threads which are present but not online
prior to migration/hibernation. After migration/hibernation those
threads are taken back offline.

During migration/hibernation all online CPUs must call H_JOIN, this is
required by the hypervisor. Without this patch, threads that are offline
(H_CEDE'd) will not be woken to make the H_JOIN call and the OS will be
deadlocked (all threads either JOIN'd or CEDE'd).

Cc: <stable@kernel.org>
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/rtas_flash: Fix validate_flash buffer overflow issue

ibm,validate-flash-image RTAS call output buffer contains 150 - 200
bytes of data on latest system. Presently we have output
buffer size as 64 bytes and we use sprintf to copy data from
RTAS buffer to local buffer. This causes kernel oops (see below
call trace).

This patch increases local buffer size to 256 and also uses
snprintf instead of sprintf to copy data from RTAS buffer.

Kernel call trace :
-------------------
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: nfs fscache lockd auth_rpcgss nfs_acl sunrpc fuse loop dm_mod ipv6 ipv6_lib usb_storage ehea(X) sr_mod qlge ses cdrom enclosure st be2net sg ext3 jbd mbcache usbhid hid ohci_hcd ehci_hcd usbcore qla2xxx usb_common sd_mod crc_t10dif scsi_dh_hp_sw scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh lpfc scsi_transport_fc scsi_tgt ipr(X) libata scsi_mod
Supported: Yes
NIP: 4520323031333130 LR: 4520323031333130 CTR: 0000000000000000
REGS: c0000001b91779b0 TRAP: 0400 Tainted: G X (3.0.13-0.27-ppc64)
MSR: 8000000040009032 <EE,ME,IR,DR> CR: 44022488 XER: 20000018
TASK = c0000001bca1aba0[4736] 'cat' THREAD: c0000001b9174000 CPU: 36
GPR00: 4520323031333130 c0000001b9177c30 c000000000f87c98 000000000000009b
GPR04: c0000001b9177c4a 000000000000000b 3520323031333130 2032303133313031
GPR08: 3133313031350a4d 000000000000009b 0000000000000000 c0000000003664a4
GPR12: 0000000022022448 c000000003ee6c00 0000000000000002 00000000100e8a90
GPR16: 00000000100cb9d8 0000000010093370 000000001001d310 0000000000000000
GPR20: 0000000000008000 00000000100fae60 000000000000005e 0000000000000000
GPR24: 0000000010129350 46573738302e3030 2046573738302e30 300a4d4720323031
GPR28: 333130313520554e 4b4e4f574e0a4d47 2032303133313031 3520323031333130
NIP [4520323031333130] 0x4520323031333130
LR [4520323031333130] 0x4520323031333130
Call Trace:
[c0000001b9177c30] [4520323031333130] 0x4520323031333130 (unreliable)
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/kexec: Fix kexec when using VMX optimised memcpy

commit b3f271e86e5a (powerpc: POWER7 optimised memcpy using VMX and
enhanced prefetch) uses VMX when it is safe to do so (ie not in
interrupt). It also looks at the task struct to decide if we have to
save the current tasks' VMX state.

kexec calls memcpy() at a point where the task struct may have been
overwritten by the new kexec segments. If it has been overwritten
then when memcpy -> enable_altivec looks up current->thread.regs->msr
we get a cryptic oops or lockup.

I also notice we aren't initialising thread_info->cpu, which means
smp_processor_id is broken. Fix that too.

Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@vger.kernel.org> # 3.6+
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Fix build errors STRICT_MM_TYPECHECKS

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/mm: Use the correct mask value when looking at pgtable address

Our pgtable are 2*sizeof(pte_t)*PTRS_PER_PTE which is PTE_FRAG_SIZE.
Instead of depending on frag size, mask with PMD_MASKED_BITS.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Merge tag 'fixes-for-3.10-rc2-tag' of git://git./linux/kernel/git/sstabellini/xen

Pull Xen/arm fixes from Stefano Stabellini:
"This contains a couple of Xen on ARM initialization fixes and a patch
  to improve error handling"

* tag 'fixes-for-3.10-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen:
  xen/arm: rename xen_secondary_init and run it on every online cpu
  xen/arm: do not handle VCPUOP_register_vcpu_info failures
  xen/arm: initialize pm functions later

Merge branch 'parisc-for-3.10' of git://git./linux/kernel/git/deller/parisc-linux

Pull parisc update from Helge Deller:
"The second round of parisc updates for 3.10 includes build fixes and
  enhancements to utilize irq stacks, fixes SMP races when updating PTE
  and TLB entries by proper locking and makes the search for the correct
  cross compiler more robust on Debian and Gentoo."

* 'parisc-for-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: make default cross compiler search more robust (v3)
  parisc: fix SMP races when updating PTE and TLB entries in entry.S
  parisc: implement irq stacks - part 2 (v2)

Merge git://git./linux/kernel/git/davem/net

Pull networking fixes from David Miller:
"Several small bug fixes all over:

   1) be2net driver uses wrong payload length when submitting MAC list
      get requests to the chip.  From Sathya Perla.

   2) Fix mwifiex memory leak on driver unload, from Amitkumar Karwar.

   3) Prevent random memory access in batman-adv, from Marek Lindner.

   4) batman-adv doesn't check for pskb_trim_rcsum() errors, also from
      Marek Lindner.

   5) Fix fec crashes on rapid link up/down, from Frank Li.

   6) Fix inner protocol grovelling in GSO, from Pravin B Shelar.

   7) Link event validation fix in qlcnic from Rajesh Borundia.

   8) Not all FEC chips can support checksum offload, fix from Shawn
      Guo.

   9) EXPORT_SYMBOL + inline doesn't make any sense, from Denis Efremov.

  10) Fix race in passthru mode during device removal in macvlan, from
      Jiri Pirko.

  11) Fix RCU hash table lookup socket state race in ipv6, leading to
      NULL pointer derefs, from Eric Dumazet.

  12) Add several missing HAS_DMA kconfig dependencies, from Geert
      Uyttterhoeven.

  13) Fix bogus PCI resource management in 3c59x driver, from Sergei
      Shtylyov.

  14) Fix info leak in ipv6 GRE tunnel driver, from Amerigo Wang.

  15) Fix device leak in ipv6 IPSEC policy layer, from Cong Wang.

  16) DMA mapping leak fix in qlge from Thadeu Lima de Souza Cascardo.

  17) Missing iounmap on probe failure in bna driver, from Wei Yongjun."

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (40 commits)
  bna: add missing iounmap() on error in bnad_init()
  qlge: fix dma map leak when the last chunk is not allocated
  xfrm6: release dev before returning error
  ipv6,gre: do not leak info to user-space
  virtio_net: use default napi weight by default
  emac: Fix EMAC soft reset on 460EX/GT
  3c59x: fix PCI resource management
  caif: CAIF_VIRTIO should depend on HAS_DMA
  net/ethernet: MACB should depend on HAS_DMA
  net/ethernet: ARM_AT91_ETHER should depend on HAS_DMA
  net/wireless: ATH9K should depend on HAS_DMA
  net/ethernet: STMMAC_ETH should depend on HAS_DMA
  net/ethernet: NET_CALXEDA_XGMAC should depend on HAS_DMA
  ipv6: do not clear pinet6 field
  macvlan: fix passthru mode race between dev removal and rx path
  ipv4: ip_output: remove inline marking of EXPORT_SYMBOL functions
  net/mlx4: Strengthen VLAN tags/priorities enforcement in VST mode
  net/mlx4_core: Add missing report on VST and spoof-checking dev caps
  net: fec: enable hardware checksum only on imx6q-fec
  qlcnic: Fix validation of link event command.
  ...

parisc: make default cross compiler search more robust (v3)

People/distros vary how they prefix the toolchain name for 64bit builds.
Rather than enforce one convention over another, add a for loop which
does a search for all the general prefixes.

For 64bit builds, we now search for (in order):
hppa64-unknown-linux-gnu
hppa64-linux-gnu
hppa64-linux

For 32bit builds, we look for:
hppa-unknown-linux-gnu
hppa-linux-gnu
hppa-linux
hppa2.0-unknown-linux-gnu
hppa2.0-linux-gnu
hppa2.0-linux
hppa1.1-unknown-linux-gnu
hppa1.1-linux-gnu
hppa1.1-linux

This patch was initiated by Mike Frysinger, with feedback from Jeroen
Roovers, John David Anglin and Helge Deller.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Jeroen Roovers <jer@gentoo.org>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>

bna: add missing iounmap() on error in bnad_init()

Add the missing iounmap() before return from bnad_init()
in the error handling case.
Introduced by commit 01b54b1451853593739816a392485c4e2bee7dda
(bna: tx rx cleanup fix).

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: fix dma map leak when the last chunk is not allocated

qlge allocates chunks from a page that it maps and unmaps that page when
the last chunk is released. When the driver is unloaded or the card is
removed, all chunks are released and the page is unmapped for the last
chunk.

However, when the last chunk of a page is not allocated and the device
is removed, that page is not unmapped. In fact, its last reference is
not put and there's also a page leak. This bug prevents a device from
being properly hotplugged.

When the DMA API debug option is enabled, the following messages show
the pending DMA allocation after we remove the driver.

This patch fixes the bug by unmapping and putting the page from the ring
if its last chunk has not been allocated.

pci 0005:98:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=1]
One of leaked entries details: [device address=0x0000000060a80000] [size=65536 bytes] [mapped with DMA_FROM_DEVICE] [mapped as page]
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:746
Modules linked in: qlge(-) rpadlpar_io rpaphp pci_hotplug fuse [last unloaded: qlge]
NIP: c0000000003fc3ec LR: c0000000003fc3e8 CTR: c00000000054de60
REGS: c0000003ee9c74e0 TRAP: 0700 Tainted: G O (3.7.2)
MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28002424 XER: 00000001
SOFTE: 1
CFAR: c0000000007a39c8
TASK = c0000003ee8d5c90[8406] 'rmmod' THREAD: c0000003ee9c4000 CPU: 31
GPR00: c0000000003fc3e8 c0000003ee9c7760 c000000000c789f8 00000000000000ee
GPR04: 0000000000000000 00000000000000ef 0000000000004000 0000000000010000
GPR08: 00000000000000be c000000000b22088 c000000000c4c218 00000000007c0000
GPR12: 0000000028002422 c00000000ff26c80 0000000000000000 000001001b0f1b40
GPR16: 00000000100cb9d8 0000000010093088 c000000000cdf910 0000000000000001
GPR20: 0000000000000000 c000000000dbfc00 0000000000000000 c000000000dbfb80
GPR24: c0000003fafc9d80 0000000000000001 000000000001ff80 c0000003f38f7888
GPR28: c000000000ddfc00 0000000000000400 c000000000bd7790 c000000000ddfb80
NIP [c0000000003fc3ec] .dma_debug_device_change+0x22c/0x2b0
LR [c0000000003fc3e8] .dma_debug_device_change+0x228/0x2b0
Call Trace:
[c0000003ee9c7760] [c0000000003fc3e8] .dma_debug_device_change+0x228/0x2b0 (unreliable)
[c0000003ee9c7840] [c00000000079a098] .notifier_call_chain+0x78/0xf0
[c0000003ee9c78e0] [c0000000000acc20] .__blocking_notifier_call_chain+0x70/0xb0
[c0000003ee9c7990] [c0000000004a9580] .__device_release_driver+0x100/0x140
[c0000003ee9c7a20] [c0000000004a9708] .driver_detach+0x148/0x150
[c0000003ee9c7ac0] [c0000000004a8144] .bus_remove_driver+0xc4/0x150
[c0000003ee9c7b60] [c0000000004aa58c] .driver_unregister+0x8c/0xe0
[c0000003ee9c7bf0] [c0000000004090b4] .pci_unregister_driver+0x34/0xf0
[c0000003ee9c7ca0] [d000000002231194] .qlge_exit+0x1c/0x34 [qlge]
[c0000003ee9c7d20] [c0000000000e36d8] .SyS_delete_module+0x1e8/0x290
[c0000003ee9c7e30] [c0000000000098d4] syscall_exit+0x0/0x94
Instruction dump:
7f26cb78 e818003a e87e81a0 e8f80028 e9180030 796b1f24 78001f24 7d6a5a14
7d2a002a e94b0020 483a7595 60000000 <0fe00000> 2fb80000 40de0048 80120050
---[ end trace 4294f9abdb01031d ]---
Mapped at:
[<d000000002222f54>] .ql_update_lbq+0x384/0x580 [qlge]
[<d000000002227bd0>] .ql_clean_inbound_rx_ring+0x300/0xc60 [qlge]
[<d0000000022288cc>] .ql_napi_poll_msix+0x39c/0x5a0 [qlge]
[<c0000000006b3c50>] .net_rx_action+0x170/0x300
[<c000000000081840>] .__do_softirq+0x170/0x300

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Acked-by: Jitendra Kalsaria <Jitendra.kalsaria@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

xen/arm: rename xen_secondary_init and run it on every online cpu

Rename xen_secondary_init to xen_percpu_init.
Run xen_percpu_init on the each online cpu, reuse the current on_each_cpu call.
Merge xen_percpu_enable_events into xen_percpu_init.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

xen/arm: do not handle VCPUOP_register_vcpu_info failures

We expect VCPUOP_register_vcpu_info to succeed, do not try to handle
failures.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

xen/arm: initialize pm functions later

If we are running in dom0, we have to wait for the arch specific code to
complete the initialization in order for us to successfully reset the
power_off and pm_restart functions.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Merge tag 'spi-v3.10-rc1' of git://git./linux/kernel/git/broonie/spi

Pull spi updates from Mark Brown:
"A few driver specific fixes plus improved error handling in the
  generic DT GPIO chipselect handling - not exciting but useful."

* tag 'spi-v3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi/spi-atmel: BUG: fix doesn' support 16 bits transfers using PIO
  spi/davinci: fix module build error
  spi: Return error from of_spi_register_master on bad "cs-gpios" property
  spi: Initialize cs_gpio and cs_gpios with -ENOENT
  spi/atmel: fix speed_hz check in atmel_spi_transfer()

Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
"Just a few straggling fixes I hoovered up, and an intel fixes pull
  from Daniel which fixes some regressions, and some mgag200 fixes from
  Matrox."

* 'drm-next' of git://people.freedesktop.org/~airlied/linux:
  drm/mgag200: Fix framebuffer base address programming
  drm/mgag200: Convert counter delays to jiffies
  drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
  drm/mgag200: Don't change unrelated registers during modeset
  drm: Only print a debug message when the polled connector has changed
  drm: Make the HPD status updates debug logs more readable
  drm: Use names of ioctls in debug traces
  drm: Remove pointless '-' characters from drm_fb_helper documentation
  drm: Add kernel-doc for drm_fb_helper_funcs->initial_config
  drm: refactor call to request_module
  drm: Don't prune modes loudly when a connector is disconnected
  drm: Add missing break in the command line mode parsing code
  drm/i915: clear the stolen fb before resuming
  Revert "drm/i915: Calculate correct stolen size for GEN7+"
  drm/i915: hsw: fix link training for eDP on port-A
  Revert "drm/i915: revert eDP bpp clamping code changes"
  drm: don't check modeset locks in panic handler
  drm/i915: Fix pipe enabled mask for pipe C in WM calculations
  drm/mm: fix dump table BUG
  drm/i915: Always normalize return timeout for wait_timeout_ioctl

Merge tag 'fixes-for-linus' of git://git./linux/kernel/git/rusty/linux

Pull virtio/lguest fixes from Rusty Russell:
"Missing license tag and some fallout from the lguest pagetable rework"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
lguest: clear cached last cpu when guest_set_pgd() called.
Add missing module license tag to vring helpers.

Merge remote-tracking branch 'spi/fix/grant' into spi-linus

Merge remote-tracking branch 'spi/fix/atmel' into spi-linus

jbd,jbd2: fix oops in jbd2_journal_put_journal_head()

Commit ae4647fb (jbd2: reduce journal_head size) introduced a
regression where we occasionally hit panic in
jbd2_journal_put_journal_head() because of wrong b_jcount. The bug is
caused by gcc making 64-bit access to 32-bit bitfield and thus
clobbering b_jcount.

At least for now, those 8 bytes saved in struct journal_head are not
worth the trouble with gcc bitfield handling so revert that part of
the patch.

Reported-by: EUNBONG SONG <eunb.song@samsung.com>
Reported-by: Tony Luck <tony.luck@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

drm/mgag200: Fix framebuffer base address programming

Higher bits of the base address of framebuffers weren't being
programmed properly. This caused framebuffers that didn't happen to be
allocated at a low enough address to not be displayed properly.

Signed-off-by: Christopher Harvey <charvey@matrox.com>
Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/mgag200: Convert counter delays to jiffies

Signed-off-by: Christopher Harvey <charvey@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register

The original line,
WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp);
wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where
MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into
MGA1064_PIX_CLK_CTL. Change the line to write properly into
MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use
the same pattern (but work correctly), so this patch updates them all
to use this new (slightly more efficient) write pattern. The WREG_DAC
macro was causing the DAC_INDEX register to be set to the same value
twice. WREG8(DAC_DATA, foo) takes advantage of the fact that DAC_INDEX
is already at the value we want.

Signed-off-by: Christopher Harvey <charvey@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/mgag200: Don't change unrelated registers during modeset

Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.

Signed-off-by: Christopher Harvey <charvey@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Only print a debug message when the polled connector has changed

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Make the HPD status updates debug logs more readable

Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.

v2: Also patch output_poll_execute() (Daniel Vetter)
v3: Use drm_get_connector_status_name (Ville Syrjälä)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (for v1)
Signed-off-by: Dave Airlie <airlied@redhat.com>

xfrm6: release dev before returning error

We forget to call dev_put() on error path in xfrm6_fill_dst(),
its caller doesn't handle this.

Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6,gre: do not leak info to user-space

There is a hole in struct ip6_tnl_parm2, so we have to
zero the struct on stack before copying it to user-space.

Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

virtio_net: use default napi weight by default

Since commit 82dc3c63c692b1e1d5937 ("net: introduce NAPI_POLL_WEIGHT")
we warn drivers when they use napi weight higher than NAPI_POLL_WEIGHT,
but virtio_net still uses 128 by default. This patch makes its default
value to NAPI_POLL_WEIGHT.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

emac: Fix EMAC soft reset on 460EX/GT

Fix EMAC soft reset on 460EX/GT to select the right PHY clock source
before and after the soft reset.

EMAC with PHY should use the clock from PHY during soft reset.
EMAC without PHY should use the internal clock during soft reset.

PPC460EX/GT Embedded Processor Advanced User's Manual
section 28.10.1 Mode Register 0 (EMACx_MR0) states:
Note: The PHY must provide a TX Clk in order to perform a soft reset
of the EMAC. If none is present, select the internal clock
(SDR0_ETH_CFG[EMACx_PHY_CLK] = 1).
After a soft reset, select the external clock.

Without the fix, 460EX/GT-based boards with RGMII PHYs attached to
EMACs experience EMAC interrupt storm and system watchdog reset when
issuing "ifconfig eth0 down" + "ifconfig eth0 up" a few times.
The system enters endless loop of serving emac_irq() with EMACx_ISR
register stuck at value 0x10000000 (Rx parity error).

With the fix, the above issue is no longer observed.

Signed-off-by: Petri Gynther <pgynther@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

3c59x: fix PCI resource management

The driver wrongly claimed I/O ports at an address returned by pci_iomap() --
even if it was passed an MMIO address. Fix this by claiming/releasing all PCI
resources in the PCI driver's probe()/remove() methods instead and get rid of
'must_free_region' flag weirdness (why would Cardbus claim anything for us?).

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Linux 3.10-rc1

Merge tag 'trace-fixes-v3.10' of git://git./linux/kernel/git/rostedt/linux-trace

Pull tracing/kprobes update from Steven Rostedt:
"The majority of these changes are from Masami Hiramatsu bringing
  kprobes up to par with the latest changes to ftrace (multi buffering
  and the new function probes).

  He also discovered and fixed some bugs in doing so.  When pulling in
  his patches, I also found a few minor bugs as well and fixed them.

  This also includes a compile fix for some archs that select the ring
  buffer but not tracing.

  I based this off of the last patch you took from me that fixed the
  merge conflict error, as that was the commit that had all the changes
  I needed for this set of changes."

* tag 'trace-fixes-v3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing/kprobes: Support soft-mode disabling
  tracing/kprobes: Support ftrace_event_file base multibuffer
  tracing/kprobes: Pass trace_probe directly from dispatcher
  tracing/kprobes: Increment probe hit-count even if it is used by perf
  tracing/kprobes: Use bool for retprobe checker
  ftrace: Fix function probe when more than one probe is added
  ftrace: Fix the output of enabled_functions debug file
  ftrace: Fix locking in register_ftrace_function_probe()
  tracing: Add helper function trace_create_new_event() to remove duplicate code
  tracing: Modify soft-mode only if there's no other referrer
  tracing: Indicate enabled soft-mode in enable file
  tracing/kprobes: Fix to increment return event probe hit-count
  ftrace: Cleanup regex_lock and ftrace_lock around hash updating
  ftrace, kprobes: Fix a deadlock on ftrace_regex_lock
  ftrace: Have ftrace_regex_write() return either read or error
  tracing: Return error if register_ftrace_function_probe() fails for event_enable_func()
  tracing: Don't succeed if event_enable_func did not register anything
  ring-buffer: Select IRQ_WORK

caif: CAIF_VIRTIO should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `cfv_destroy_genpool':
drivers/net/caif/caif_virtio.c:364: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `cfv_create_genpool':
drivers/net/caif/caif_virtio.c:397: undefined reference to `dma_alloc_coherent'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>

net/ethernet: MACB should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `macb_free_consistent':
drivers/net/ethernet/cadence/macb.c:878: undefined reference to `dma_free_coherent'
drivers/net/ethernet/cadence/macb.c:883: undefined reference to `dma_free_coherent'
drivers/net/ethernet/cadence/macb.c:888: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `macb_alloc_consistent':
drivers/net/ethernet/cadence/macb.c:905: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `macb_tx_interrupt':
drivers/net/ethernet/cadence/macb.c:515: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `macb_tx_error_task':
drivers/net/ethernet/cadence/macb.c:457: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `macb_start_xmit':
drivers/net/ethernet/cadence/macb.c:838: undefined reference to `dma_map_single'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net/ethernet: ARM_AT91_ETHER should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `at91ether_start':
drivers/net/ethernet/cadence/at91_ether.c:49: undefined reference to `dma_alloc_coherent'
drivers/net/ethernet/cadence/at91_ether.c:60: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `at91ether_interrupt':
drivers/net/ethernet/cadence/at91_ether.c:250: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `at91ether_start_xmit':
drivers/net/ethernet/cadence/at91_ether.c:169: undefined reference to `dma_map_single'
drivers/built-in.o: In function `at91ether_close':
drivers/net/ethernet/cadence/at91_ether.c:145: undefined reference to `dma_free_coherent'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net/wireless: ATH9K should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `ath9k_beacon_generate':
drivers/net/wireless/ath/ath9k/beacon.c:146: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath9k/beacon.c:174: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/beacon.c:176: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath9k_beacon_remove_slot':
drivers/net/wireless/ath/ath9k/beacon.c:252: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_descdma_setup':
drivers/net/wireless/ath/ath9k/init.c:382: undefined reference to `dmam_alloc_coherent'
drivers/built-in.o: In function `ath_edma_get_buffers':
drivers/net/wireless/ath/ath9k/recv.c:616: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `ath_get_next_rx_buf':
drivers/net/wireless/ath/ath9k/recv.c:740: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `ath_rx_edma_cleanup':
drivers/net/wireless/ath/ath9k/recv.c:176: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_rx_cleanup':
drivers/net/wireless/ath/ath9k/recv.c:340: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_rx_edma_buf_link':
drivers/net/wireless/ath/ath9k/recv.c:122: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `ath_rx_tasklet':
drivers/net/wireless/ath/ath9k/recv.c:1275: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/recv.c:1277: undefined reference to `dma_mapping_error'
drivers/net/wireless/ath/ath9k/recv.c:1283: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_rx_edma_init':
drivers/net/wireless/ath/ath9k/recv.c:226: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/recv.c:229: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath_rx_init':
drivers/net/wireless/ath/ath9k/recv.c:303: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/recv.c:306: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath_tx_complete_buf':
drivers/net/wireless/ath/ath9k/xmit.c:2088: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_txstatus_setup':
drivers/net/wireless/ath/ath9k/xmit.c:2344: undefined reference to `dmam_alloc_coherent'
drivers/built-in.o: In function `ath_tx_set_retry':
drivers/net/wireless/ath/ath9k/xmit.c:307: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `ath_tx_setup_buffer':
drivers/net/wireless/ath/ath9k/xmit.c:1887: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/xmit.c:1889: undefined reference to `dma_mapping_error'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>

net/ethernet: STMMAC_ETH should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `dma_free_tx_skbufs':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1141: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `dma_free_rx_skbufs':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1120: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `free_dma_desc_resources':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1159: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `stmmac_init_rx_buffers':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:980: undefined reference to `dma_map_single'
drivers/built-in.o: In function `init_dma_desc_rings':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1015: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `stmmac_tx_clean':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1250: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `stmmac_rx':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2044: undefined reference to `dma_unmap_single'
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2082: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `stmmac_rx_refill':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1967: undefined reference to `dma_map_single'
drivers/built-in.o: In function `stmmac_xmit':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1845: undefined reference to `dma_map_single'
drivers/built-in.o: In function `skb_frag_dma_map':
include/linux/skbuff.h:2184: undefined reference to `dma_map_page'
drivers/built-in.o: In function `stmmac_jumbo_frm':
drivers/net/ethernet/stmicro/stmmac/ring_mode.c:40: undefined reference to `dma_map_single'
drivers/built-in.o: In function `stmmac_jumbo_frm':
drivers/net/ethernet/stmicro/stmmac/chain_mode.c:48: undefined reference to `dma_map_single'
drivers/net/ethernet/stmicro/stmmac/chain_mode.c:55: undefined reference to `dma_map_single'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>

net/ethernet: NET_CALXEDA_XGMAC should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `xgmac_xmit':
drivers/net/ethernet/calxeda/xgmac.c:1102: undefined reference to `dma_mapping_error'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: do not clear pinet6 field

We have seen multiple NULL dereferences in __inet6_lookup_established()

After analysis, I found that inet6_sk() could be NULL while the
check for sk_family == AF_INET6 was true.

Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP
and TCP stacks.

Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash
table, we no longer can clear pinet6 field.

This patch extends logic used in commit fcbdf09d9652c891
("net: fix nulls list corruptions in sk_prot_alloc")

TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method
to make sure we do not clear pinet6 field.

At socket clone phase, we do not really care, as cloning the parent (non
NULL) pinet6 is not adding a fatal race.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

macvlan: fix passthru mode race between dev removal and rx path

Currently, if macvlan in passthru mode is created and data are rxed and
you remove this device, following panic happens:

NULL pointer dereference at 0000000000000198
IP: [<ffffffffa0196058>] macvlan_handle_frame+0x153/0x1f7 [macvlan]

I'm using following script to trigger this:
<script>
while [ 1 ]
do
ip link add link e1 name macvtap0 type macvtap mode passthru
ip link set e1 up
ip link set macvtap0 up
IFINDEX=`ip link |grep macvtap0 | cut -f 1 -d ':'`
cat /dev/tap$IFINDEX >/dev/null &
ip link del dev macvtap0
done
</script>

I run this script while "ping -f" is running on another machine to send
packets to e1 rx.

Reason of the panic is that list_first_entry() is blindly called in
macvlan_handle_frame() even if the list was empty. vlan is set to
incorrect pointer which leads to the crash.

I'm fixing this by protecting port->vlans list by rcu and by preventing
from getting incorrect pointer in case the list is empty.

Introduced by: commit eb06acdc85585f2 "macvlan: Introduce 'passthru' mode to takeover the underlying device"

Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'batman-adv-fix-for-davem' of git://git.open-mesh.org/linux-merge

Included changes:
- fix parsing of user typed protocol string to avoid random memory access in
some cases
- check pskb_trim_rcsum() return value
- prevent DAT from sending ARP replies when not needed
- reorder the main clean up routine to prevent race conditions

Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'stable/for-linus-3.10-rc0-tag-two' of git://git./linux/kernel/git/konrad/xen

Pull Xen bug-fixes from Konrad Rzeszutek Wilk:
- More fixes in the vCPU PVHVM hotplug path.
- Add more documentation.
- Fix various ARM related issues in the Xen generic drivers.
- Updates in the xen-pciback driver per Bjorn's updates.
- Mask the x2APIC feature for PV guests.

* tag 'stable/for-linus-3.10-rc0-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen/pci: Used cached MSI-X capability offset
  xen/pci: Use PCI_MSIX_TABLE_BIR, not PCI_MSIX_FLAGS_BIRMASK
  xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
  xen: mask x2APIC feature in PV
  xen: SWIOTLB is only used on x86
  xen/spinlock: Fix check from greater than to be also be greater or equal to.
  xen/smp/pvhvm: Don't point per_cpu(xen_vpcu, 33 and larger) to shared_info
  xen/vcpu: Document the xen_vcpu_info and xen_vcpu
  xen/vcpu/pvhvm: Fix vcpu hotplugging hanging.

ipv4: ip_output: remove inline marking of EXPORT_SYMBOL functions

EXPORT_SYMBOL and inline directives are contradictory to each other.
The patch fixes this inconsistency.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net/mlx4: Strengthen VLAN tags/priorities enforcement in VST mode

Make sure that the following steps are taken:

- drop packets sent by the VF with vlan tag
- block packets with vlan tag which are steered to the VF
- drop/block tagged packets when the policy is priority-tagged
- make sure VLAN stripping for received packets is set
- make sure force UP bit for the VF QP is set

Use enum values for all the above instead of numerical bit offsets.

Signed-off-by: Rony Efraim <ronye@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net/mlx4_core: Add missing report on VST and spoof-checking dev caps

Commits e6b6a23 "net/mlx4: Add VF MAC spoof checking support" and
3f7fb021 "net/mlx4: Add set VF default vlan ID and priority support"
missed reporting in the device capabilities dump when these features
are actually supported. Also two too noisy debug messages which produce
message on every QP opened by a VF, were left in the code, fix that.

Signed-off-by: Rony Efraim <ronye@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: fec: enable hardware checksum only on imx6q-fec

Commit 4c09eed (net: fec: Enable imx6 enet checksum acceleration.)
enables hardware checksum acceleration unconditionally for all fec
variants.  This is inappropriate, because some variants like imx5 have
no such support on hardware.  Consequently, fec is broken on these
platforms.  Fix it by enabling hardware checksum only on imx6q-fec type
of controllers.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Jim Baxter <jim_baxter@mentor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ext4: revert "ext4: use io_end for multiple bios"

This reverts commit 4eec708d263f0ee10861d69251708a225b64cac7.

Multiple users have reported crashes which is apparently caused by
this commit. Thanks to Dmitry Monakhov for bisecting it.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: Jan Kara <jack@suse.cz>

Merge branch 'qlcnic'

Shahed Shaikh says:

====================
This patch series has following bug fixes:
* Fix a bug in unicast MAC address setting in adapter.
  Driver was not deleting older unicast MAC while adding new one.
* Fix an ethtool stats string array by adding missing string entry
  and fix a typo.
* Fix module paramter description. Bracket ')' was missing.
* Fix port status provided though 'ethtool <device>' for 83xx adapter.
* Fix reset recovery path in case of transmit timeout.
* Fix reset recovery during diagnostic tests by preserving
  current device status information.
* Fix mailbox response handling. Driver was not maintaining poll time properly.
* Fix validation of link event command.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix validation of link event command.

o VF driver that has enabled asynchronous link events
may not set BIT_8 in the request, if it does not require
link state in the response.

Signed-off-by: Pratik Pujar <pratik.pujar@qlogic.com>
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix mailbox response handling.

o Fix mailbox response poll time to maximum 5 seconds which
  includes mailbox response time as well as time required for
  processing AEN if any.
o Driver need to read firmware control mailbox register instead
  of host control mailbox register.

Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix bug in diagnostics test reset recovery path

o In order to perform reset recovery during diagnostics tests,
current device status information need to be preserved.
This patch makes the required changes in diagnostics routines

Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix reset recovery after transmit timeout

o When transmit timeout happens, recovery attempt should start with
  adapter soft reset. If soft reset fails to resume traffic, firmware
  dump will be collected and driver will perform a hard reset of the
  adapter. Reset recovery on 83xx was failing after a hard reset.
  This patch fixes that issue.

Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix ethtool supported port status for 83xx

o Fix display for interface while using 'ethtool <device>' for 83xx adapter

Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix missing bracket in module parameter.

Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix ethtool strings

o Add missing information in ethtool statistics information array.
o Fix the typo in the statistics information string.

Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix setting MAC address

o Delete previous unicast MAC which is already programmed
in adapter before setting new unicast MAC

Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'scsi-for-linus' of git://git./linux/kernel/git/jejb/scsi

Pull second SCSI update from James "Jaj B" Bottomley:
"This is the final round of SCSI patches for the merge window.  It
  consists mostly of driver updates (bnx2fc, ibmfc, fnic, lpfc,
  be2iscsi, pm80xx, qla4x and ipr).

  There's also the power management updates that complete the patches in
  Jens' tree, an iscsi refcounting problem fix from the last pull, some
  dif handling in scsi_debug fixes, a few nice code cleanups and an
  error handling busy bug fix."

* tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (92 commits)
  [SCSI] qla2xxx: Update firmware link in Kconfig file.
  [SCSI] iscsi class, qla4xxx: fix sess/conn refcounting when find fns are used
  [SCSI] sas: unify the pointlessly separated enums sas_dev_type and sas_device_type
  [SCSI] pm80xx: thermal, sas controller config and error handling update
  [SCSI] pm80xx: NCQ error handling changes
  [SCSI] pm80xx: WWN Modification for PM8081/88/89 controllers
  [SCSI] pm80xx: Changed module name and debug messages update
  [SCSI] pm80xx: Firmware flash memory free fix, with addition of new memory region for it
  [SCSI] pm80xx: SPC new firmware changes for device id 0x8081 alone
  [SCSI] pm80xx: Added SPCv/ve specific hardware functionalities and relevant changes in common files
  [SCSI] pm80xx: MSI-X implementation for using 64 interrupts
  [SCSI] pm80xx: Updated common functions common for SPC and SPCv/ve
  [SCSI] pm80xx: Multiple inbound/outbound queue configuration
  [SCSI] pm80xx: Added SPCv/ve specific ids, variables and modify for SPC
  [SCSI] lpfc: fix up Kconfig dependencies
  [SCSI] Handle MLQUEUE busy response in scsi_send_eh_cmnd
  [SCSI] sd: change to auto suspend mode
  [SCSI] sd: use REQ_PM in sd's runtime suspend operation
  [SCSI] qla4xxx: Fix iocb_cnt calculation in qla4xxx_send_mbox_iocb()
  [SCSI] ufs: Correct the expected data transfersize
  ...

Merge branch 'release' of git://git./linux/kernel/git/lenb/linux

Pull idle update from Len Brown:
"Add support for new Haswell-ULT CPU idle power states"

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
intel_idle: initial C8, C9, C10 support
tools/power turbostat: display C8, C9, C10 residency

Merge git://git.infradead.org/users/eparis/audit

Pull audit changes from Eric Paris:
"Al used to send pull requests every couple of years but he told me to
  just start pushing them to you directly.

  Our touching outside of core audit code is pretty straight forward.  A
  couple of interface changes which hit net/.  A simple argument bug
  calling audit functions in namei.c and the removal of some assembly
  branch prediction code on ppc"

* git://git.infradead.org/users/eparis/audit: (31 commits)
  audit: fix message spacing printing auid
  Revert "audit: move kaudit thread start from auditd registration to kaudit init"
  audit: vfs: fix audit_inode call in O_CREAT case of do_last
  audit: Make testing for a valid loginuid explicit.
  audit: fix event coverage of AUDIT_ANOM_LINK
  audit: use spin_lock in audit_receive_msg to process tty logging
  audit: do not needlessly take a lock in tty_audit_exit
  audit: do not needlessly take a spinlock in copy_signal
  audit: add an option to control logging of passwords with pam_tty_audit
  audit: use spin_lock_irqsave/restore in audit tty code
  helper for some session id stuff
  audit: use a consistent audit helper to log lsm information
  audit: push loginuid and sessionid processing down
  audit: stop pushing loginid, uid, sessionid as arguments
  audit: remove the old depricated kernel interface
  audit: make validity checking generic
  audit: allow checking the type of audit message in the user filter
  audit: fix build break when AUDIT_DEBUG == 2
  audit: remove duplicate export of audit_enabled
  Audit: do not print error when LSMs disabled
  ...

parisc: fix SMP races when updating PTE and TLB entries in entry.S

Currently, race conditions exist in the handling of TLB interruptions in
entry.S.  In particular, dirty bit updates can be lost if an accessed
interruption occurs just after the dirty bit interruption on a different
cpu.  Lost dirty bit updates result in user pages not being flushed and
general system instability.  This change adds lock and unlock macros to
synchronize all PTE and TLB updates done in entry.S.  As a result,
userspace stability is significantly improved.

Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>

parisc: implement irq stacks - part 2 (v2)

This patch fixes few build issues which were introduced with the last
irq stack patch, e.g. the combination of stack overflow check and irq
stack.

Furthermore we now do proper locking and change the irq bh handler
to use the irq stack as well.

In /proc/interrupts one now can monitor how huge the irq stack has grown
and how often it was preferred over the kernel stack.

IRQ stacks are now enabled by default just to make sure that we not
overflow the kernel stack by accident.

Signed-off-by: Helge Deller <deller@gmx.de>

workqueue: workqueue_congested() shouldn't translate WORK_CPU_UNBOUND into node number

df2d5ae499 ("workqueue: map an unbound workqueues to multiple per-node
pool_workqueues") made unbound workqueues to map to multiple per-node
pool_workqueues and accordingly updated workqueue_contested() so that,
for unbound workqueues, it maps the specified @cpu to the NUMA node
number to obtain the matching pool_workqueue to query the congested
state.

Before this change, workqueue_congested() ignored @cpu for unbound
workqueues as there was only one pool_workqueue and some users
(fscache) called it with WORK_CPU_UNBOUND.  After the commit, this
causes the following oops as WORK_CPU_UNBOUND gets translated to
garbage by cpu_to_node().

  BUG: unable to handle kernel paging request at ffff8803598d98b8
  IP: [<ffffffff81043b7e>] unbound_pwq_by_node+0xa1/0xfa
  PGD 2421067 PUD 0
  Oops: 0000 [#1] SMP
  CPU: 1 PID: 2689 Comm: cat Tainted: GF            3.9.0-fsdevel+ #4
  task: ffff88003d801040 ti: ffff880025806000 task.ti: ffff880025806000
  RIP: 0010:[<ffffffff81043b7e>]  [<ffffffff81043b7e>] unbound_pwq_by_node+0xa1/0xfa
  RSP: 0018:ffff880025807ad8  EFLAGS: 00010202
  RAX: 0000000000000001 RBX: ffff8800388a2400 RCX: 0000000000000003
  RDX: ffff880025807fd8 RSI: ffffffff81a31420 RDI: ffff88003d8016e0
  RBP: ffff880025807ae8 R08: ffff88003d801730 R09: ffffffffa00b4898
  R10: ffffffff81044217 R11: ffff88003d801040 R12: 0000000064206e97
  R13: ffff880036059d98 R14: ffff880038cc8080 R15: ffff880038cc82d0
  FS:  00007f21afd9c740(0000) GS:ffff88003d100000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: ffff8803598d98b8 CR3: 000000003df49000 CR4: 00000000000007e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Stack:
   ffff8800388a2400 0000000000000002 ffff880025807b18 ffffffff810442ce
   ffffffff81044217 ffff880000000002 ffff8800371b4080 ffff88003d112ec0
   ffff880025807b38 ffffffffa00810b0 ffff880036059d88 ffff880036059be8
  Call Trace:
   [<ffffffff810442ce>] workqueue_congested+0xb7/0x12c
   [<ffffffffa00810b0>] fscache_enqueue_object+0xb2/0xe8 [fscache]
   [<ffffffffa007facd>] __fscache_acquire_cookie+0x3b9/0x56c [fscache]
   [<ffffffffa00ad8fe>] nfs_fscache_set_inode_cookie+0xee/0x132 [nfs]
   [<ffffffffa009e112>] do_open+0x9/0xd [nfs]
   [<ffffffff810e804a>] do_dentry_open+0x175/0x24b
   [<ffffffff810e8298>] finish_open+0x41/0x51

Fix it by using smp_processor_id() if @cpu is WORK_CPU_UNBOUND.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: David Howells <dhowells@redhat.com>
Tested-and-Acked-by: David Howells <dhowells@redhat.com>

Merge branch 'wireless'

John W. Linville says:

====================
Here is a batch of fixes intended for the 3.10 stream.

Amitkumar Karwar provides an mwifiex fix to plug a memory leak when
the driver is unloaded.

Bing Zhao brings an mwifiex fix for some flag handling that leads to
log spam and an unusable interface.

Daniel Drake offers an mwifiex fix for multicast filter setup, to
correctly implement wakeup behaviour for multicast WOL.

Felix Fietkau fixes an ath9k problem that produces logspam and keycache
errors due to a bad return code.

Stanislaw Gruszka produces an fix for a WARNING from ath5k, and an
iwl4965 workaround to stop advertising a feature that doesn't work with
the current mac80211 implementation.

Sujith Manoharan gives us an ath9k fix to reprogram the HW beacon timers
after a TSF update, and an initvals fix for the AR9565 device.

Thommy Jakobsson fixes an rx descriptor underrun on b43.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'for-3.10' of git://linux-nfs.org/~bfields/linux

Pull nfsd fixes from Bruce Fields:
"Small fixes for two bugs and two warnings"

* 'for-3.10' of git://linux-nfs.org/~bfields/linux:
  nfsd: fix oops when legacy_recdir_name_error is passed a -ENOENT error
  SUNRPC: fix decoding of optional gss-proxy xdr fields
  SUNRPC: Refactor gssx_dec_option_array() to kill uninitialized warning
  nfsd4: don't allow owner override on 4.1 CLAIM_FH opens

Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86

Pull x86 platform drivers from Matthew Garrett:
"Small set of updates, mainly trivial bugfixes and some small updates
  to deal with newer hardware.

  There's also a new driver that allows qemu guests to notify the
  hypervisor that they've just paniced, which seems useful."

* 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86:
  Add support for fan button on Ideapad Z580
  pvpanic: pvpanic device driver
  asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75A
  drivers: platform: x86: Use PTR_RET function
  sony-laptop: SVS151290S kbd backlight and gfx switch support
  hp-wmi: add more definitions for new event_id's
  dell-laptop: Fix krealloc() misuse in parse_da_table()
  hp_accel: Ignore the error from lis3lv02d_poweron() at resume
  dell: add new dell WMI format for the AIO machines

Merge branch 'for-linus' of git://git./linux/kernel/git/viro/signal

Pull stray syscall bits from Al Viro:
"Several syscall-related commits that were missing from the original"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal:
  switch compat_sys_sysctl to COMPAT_SYSCALL_DEFINE
  unicore32: just use mmap_pgoff()...
  unify compat fanotify_mark(2), switch to COMPAT_SYSCALL_DEFINE
  x86, vm86: fix VM86 syscalls: use SYSCALL_DEFINEx(...)

Merge tag 'ecryptfs-3.10-rc1-ablkcipher' of git://git./linux/kernel/git/tyhicks/ecryptfs

Pull eCryptfs update from Tyler Hicks:
"Improve performance when AES-NI (and most likely other crypto
  accelerators) is available by moving to the ablkcipher crypto API.
  The improvement is more apparent on faster storage devices.

  There's no noticeable change when hardware crypto is not available"

* tag 'ecryptfs-3.10-rc1-ablkcipher' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
  eCryptfs: Use the ablkcipher crypto API

Merge tag 'for-linus-20130509' of git://git.infradead.org/~dwmw2/random-2.6

Pull misc fixes from David Woodhouse:
"This is some miscellaneous cleanups that don't really belong anywhere
  else (or were ignored), that have been sitting in linux-next for some
  time.  Two of them are fixes resulting from my audit of krealloc()
  usage that don't seem to have elicited any response when I posted
  them, and the other three are patches from Artem removing dead code."

* tag 'for-linus-20130509' of git://git.infradead.org/~dwmw2/random-2.6:
  pcmcia: remove RPX board stuff
  m68k: remove rpxlite stuff
  pcmcia: remove Motorola MBX860 support
  params: Fix potential memory leak in add_sysfs_param()
  dell-laptop: Fix krealloc() misuse in parse_da_table()

Merge tag 'kvm-3.10-2' of git://git./virt/kvm/kvm

Pull kvm fixes from Gleb Natapov:
"Most of the fixes are in the emulator since now we emulate more than
  we did before for correctness sake we see more bugs there, but there
  is also an OOPS fixed and corruption of xcr0 register."

* tag 'kvm-3.10-2' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: emulator: emulate SALC
  KVM: emulator: emulate XLAT
  KVM: emulator: emulate AAM
  KVM: VMX: fix halt emulation while emulating invalid guest sate
  KVM: Fix kvm_irqfd_init initialization
  KVM: x86: fix maintenance of guest/host xcr0 state