Pull powerpc fixes from Benjamin Herrenschmidt:
 "So here are 3 fixes still for 3.10.  Fixes are simple, bugs are nasty
  (though not recent regressions, nasty enough) and all targeted at
  stable"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Fix missing/delayed calls to irq_work
  powerpc: Fix emulation of illegal instructions on PowerNV platform
  powerpc: Fix stack overflow crash in resume_kernel when ftracing

Thanks to commit f91eb62f ("init: scream bloody murder if interrupts
are enabled too early"), "bloody murder" is now being screamed.

With a MIPS OCTEON config, we use on_each_cpu() in our
irq_chip.irq_bus_sync_unlock() function.  This gets called in early as a
result of the time_init() call.  Because the !SMP version of
on_each_cpu() unconditionally enables irqs, we get:

    WARNING: at init/main.c:560 start_kernel+0x250/0x410()
    Interrupts were enabled early
    CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-rc5-Cavium-Octeon+ #801
    Call Trace:
      show_stack+0x68/0x80
      warn_slowpath_common+0x78/0xb0
      warn_slowpath_fmt+0x38/0x48
      start_kernel+0x250/0x410

Suggested fix: Do what we already do in the SMP version of
on_each_cpu(), and use local_irq_save/local_irq_restore.  Because we
need a flags variable, make it a static inline to avoid name space
issues.

[ Change from v1: Convert on_each_cpu to a static inline function, add
  #include <linux/irqflags.h> to avoid build breakage on some files.

  on_each_cpu_mask() and on_each_cpu_cond() suffer the same problem as
  on_each_cpu(), but they are not causing !SMP bugs for me, so I will
  defer changing them to a less urgent patch. ]
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull VFS fixes from Al Viro:
 "Several fixes + obvious cleanup (you've missed a couple of open-coded
  can_lookup() back then)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  snd_pcm_link(): fix a leak...
  use can_lookup() instead of direct checks of ->i_op->lookup
  move exit_task_namespaces() outside of exit_notify()
  fput: task_work_add() can fail if the caller has passed exit_task_work()
  ncpfs: fix rmdir returns Device or resource busy

Pull xfs fixes from Ben Myers:
 - Remove noisy warnings about experimental support which spams the logs
 - Add padding to align directory and attr structures correctly
 - Set block number on child buffer on a root btree split
 - Disable verifiers during log recovery for non-CRC filesystems

* tag 'for-linus-v3.10-rc6' of git://oss.sgi.com/xfs/xfs:
  xfs: don't shutdown log recovery on validation errors
  xfs: ensure btree root split sets blkno correctly
  xfs: fix implicit padding in directory and attr CRC formats
  xfs: don't emit v5 superblock warnings on write

Pull char / misc fixes from Greg Kroah-Hartman:
 "Here are some small mei driver fixes for 3.10-rc6 that fix some
  reported problems"

* tag 'char-misc-3.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  mei: me: clear interrupts on the resume path
  mei: nfc: fix nfc device freeing
  mei: init: Flush scheduled work before resetting the device

Pull USB fixes from Greg Kroah-Hartman:
 "Here are some small USB driver fixes that resolve some reported
  problems for 3.10-rc6

  Nothing major, just 3 USB serial driver fixes, and two chipidea fixes"

* tag 'usb-3.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  usb: chipidea: fix id change handling
  usb: chipidea: fix no transceiver case
  USB: pl2303: fix device initialisation at open
  USB: spcp8x5: fix device initialisation at open
  USB: f81232: fix device initialisation at open

When replaying interrupts (as a result of the interrupt occurring
while soft-disabled), in the case of the decrementer, we are exclusively
testing for a pending timer target. However we also use decrementer
interrupts to trigger the new "irq_work", which in this case would
be missed.

This change the logic to force a replay in both cases of a timer
boundary reached and a decrementer interrupt having actually occurred
while disabled. The former test is still useful to catch cases where
a CPU having been hard-disabled for a long time completely misses the
interrupt due to a decrementer rollover.

CC: <stable@vger.kernel.org> [v3.4+]
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: NSteven Rostedt <rostedt@goodmis.org>

Normally, the kernel emulates a few instructions that are unimplemented
on some processors (e.g. the old dcba instruction), or privileged (e.g.
mfpvr).  The emulation of unimplemented instructions is currently not
working on the PowerNV platform.  The reason is that on these machines,
unimplemented and illegal instructions cause a hypervisor emulation
assist interrupt, rather than a program interrupt as on older CPUs.
Our vector for the emulation assist interrupt just calls
program_check_exception() directly, without setting the bit in SRR1
that indicates an illegal instruction interrupt.  This fixes it by
making the emulation assist interrupt set that bit before calling
program_check_interrupt().  With this, old programs that use no-longer
implemented instructions such as dcba now work again.

CC: <stable@vger.kernel.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

It's possible for us to crash when running with ftrace enabled, eg:

  Bad kernel stack pointer bffffd12 at c00000000000a454
  cpu 0x3: Vector: 300 (Data Access) at [c00000000ffe3d40]
      pc: c00000000000a454: resume_kernel+0x34/0x60
      lr: c00000000000335c: performance_monitor_common+0x15c/0x180
      sp: bffffd12
     msr: 8000000000001032
     dar: bffffd12
   dsisr: 42000000

If we look at current's stack (paca->__current->stack) we see it is
equal to c0000002ecab0000. Our stack is 16K, and comparing to
paca->kstack (c0000002ecab3e30) we can see that we have overflowed our
kernel stack. This leads to us writing over our struct thread_info, and
in this case we have corrupted thread_info->flags and set
_TIF_EMULATE_STACK_STORE.

Dumping the stack we see:

  3:mon> t c0000002ecab0000
  [c0000002ecab0000] c00000000002131c .performance_monitor_exception+0x5c/0x70
  [c0000002ecab0080] c00000000000335c performance_monitor_common+0x15c/0x180
  --- Exception: f01 (Performance Monitor) at c0000000000fb2ec .trace_hardirqs_off+0x1c/0x30
  [c0000002ecab0370] c00000000016fdb0 .trace_graph_entry+0xb0/0x280 (unreliable)
  [c0000002ecab0410] c00000000003d038 .prepare_ftrace_return+0x98/0x130
  [c0000002ecab04b0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
  [c0000002ecab0520] c0000000000d6b58 .idle_cpu+0x18/0x90
  [c0000002ecab05a0] c00000000000a934 .return_to_handler+0x0/0x34
  [c0000002ecab0620] c00000000001e660 .timer_interrupt+0x160/0x300
  [c0000002ecab06d0] c0000000000025dc decrementer_common+0x15c/0x180
  --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0
  [c0000002ecab09c0] c0000000000fe044 .trace_hardirqs_on+0x14/0x30 (unreliable)
  [c0000002ecab0fb0] c00000000016fe3c .trace_graph_entry+0x13c/0x280
  [c0000002ecab1050] c00000000003d038 .prepare_ftrace_return+0x98/0x130
  [c0000002ecab10f0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
  [c0000002ecab1160] c0000000000161f0 .__ppc64_runlatch_on+0x10/0x40
  [c0000002ecab11d0] c00000000000a934 .return_to_handler+0x0/0x34
  --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0

  ... and so on

__ppc64_runlatch_on() is called from RUNLATCH_ON in the exception entry
path. At that point the irq state is not consistent, ie. interrupts are
hard disabled (by the exception entry), but the paca soft-enabled flag
may be out of sync.

This leads to the local_irq_restore() in trace_graph_entry() actually
enabling interrupts, which we do not want. Because we have not yet
reprogrammed the decrementer we immediately take another decrementer
exception, and recurse.

The fix is twofold. Firstly make sure we call DISABLE_INTS before
calling RUNLATCH_ON. The badly named DISABLE_INTS actually reconciles
the irq state in the paca with the hardware, making it safe again to
call local_irq_save/restore().

Although that should be sufficient to fix the bug, we also mark the
runlatch routines as notrace. They are called very early in the
exception entry and we are asking for trouble tracing them. They are
also fairly uninteresting and tracing them just adds unnecessary
overhead.

[ This regression was introduced by fe1952fc
  "powerpc: Rework runlatch code" by myself --BenH
]

CC: <stable@vger.kernel.org> [v3.4+]
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

in case when snd_pcm_stream_linked(substream) is true, we end up leaking
group.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

a couple of places got missed back when Linus has introduced that one...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

exit_notify() does exit_task_namespaces() after
forget_original_parent(). This was needed to ensure that ->nsproxy
can't be cleared prematurely, an exiting child we are going to
reparent can do do_notify_parent() and use the parent's (ours) pid_ns.

However, after 32084504 "pidns: use task_active_pid_ns in
do_notify_parent" ->nsproxy != NULL is no longer needed, we rely
on task_active_pid_ns().

Move exit_task_namespaces() from exit_notify() to do_exit(), after
exit_fs() and before exit_task_work().

This solves the problem reported by Andrey, free_ipc_ns()->shm_destroy()
does fput() which needs task_work_add().

Note: this particular problem can be fixed if we change fput(), and
that change makes sense anyway. But there is another reason to move
the callsite. The original reason for exit_task_namespaces() from
the middle of exit_notify() was subtle and it has already gone away,
now this looks confusing. And this allows us do simplify exit_notify(),
we can avoid unlock/lock(tasklist) and we can use ->exit_state instead
of PF_EXITING in forget_original_parent().
Reported-by: NAndrey Vagin <avagin@openvz.org>
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: NAndrey Vagin <avagin@openvz.org>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

fput() assumes that it can't be called after exit_task_work() but
this is not true, for example free_ipc_ns()->shm_destroy() can do
this. In this case fput() silently leaks the file.

Change it to fallback to delayed_fput_work if task_work_add() fails.
The patch looks complicated but it is not, it changes the code from

	if (PF_KTHREAD) {
		schedule_work(...);
		return;
	}
	task_work_add(...)

to
	if (!PF_KTHREAD) {
		if (!task_work_add(...))
			return;
		/* fallback */
	}
	schedule_work(...);

As for shm_destroy() in particular, we could make another fix but I
think this change makes sense anyway. There could be another similar
user, it is not safe to assume that task_work_add() can't fail.
Reported-by: NAndrey Vagin <avagin@openvz.org>
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Unfortunately, we cannot guarantee that items logged multiple times
and replayed by log recovery do not take objects back in time. When
they are taken back in time, the go into an intermediate state which
is corrupt, and hence verification that occurs on this intermediate
state causes log recovery to abort with a corruption shutdown.

Instead of causing a shutdown and unmountable filesystem, don't
verify post-recovery items before they are written to disk. This is
less than optimal, but there is no way to detect this issue for
non-CRC filesystems If log recovery successfully completes, this
will be undone and the object will be consistent by subsequent
transactions that are replayed, so in most cases we don't need to
take drastic action.

For CRC enabled filesystems, leave the verifiers in place - we need
to call them to recalculate the CRCs on the objects anyway. This
recovery problem can be solved for such filesystems - we have a LSN
stamped in all metadata at writeback time that we can to determine
whether the item should be replayed or not. This is a separate piece
of work, so is not addressed by this patch.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NBen Myers <bpm@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

(cherry picked from commit 9222a9cf)

For CRC enabled filesystems, the BMBT is rooted in an inode, so it
passes through a different code path on root splits than the
freespace and inode btrees. This is much less traversed by xfstests
than the other trees. When testing on a 1k block size filesystem,
I've been seeing ASSERT failures in generic/234 like:

XFS: Assertion failed: cur->bc_btnum != XFS_BTNUM_BMAP || cur->bc_private.b.allocated == 0, file: fs/xfs/xfs_btree.c, line: 317

which are generally preceded by a lblock check failure. I noticed
this in the bmbt stats:

$ pminfo -f xfs.btree.block_map

xfs.btree.block_map.lookup
    value 39135

xfs.btree.block_map.compare
    value 268432

xfs.btree.block_map.insrec
    value 15786

xfs.btree.block_map.delrec
    value 13884

xfs.btree.block_map.newroot
    value 2

xfs.btree.block_map.killroot
    value 0
.....

Very little coverage of root splits and merges. Indeed, on a 4k
filesystem, block_map.newroot and block_map.killroot are both zero.
i.e. the code is not exercised at all, and it's the only generic
btree infrastructure operation that is not exercised by a default run
of xfstests.

Turns out that on a 1k filesystem, generic/234 accounts for one of
those two root splits, and that is somewhat of a smoking gun. In
fact, it's the same problem we saw in the directory/attr code where
headers are memcpy()d from one block to another without updating the
self describing metadata.

Simple fix - when copying the header out of the root block, make
sure the block number is updated correctly.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NBen Myers <bpm@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

(cherry picked from commit ade1335a)

Michael L. Semon has been testing CRC patches on a 32 bit system and
been seeing assert failures in the directory code from xfs/080.
Thanks to Michael's heroic efforts with printk debugging, we found
that the problem was that the last free space being left in the
directory structure was too small to fit a unused tag structure and
it was being corrupted and attempting to log a region out of bounds.
Hence the assert failure looked something like:

.....
#5 calling xfs_dir2_data_log_unused() 36 32
#1 4092 4095 4096
#2 8182 8183 4096
XFS: Assertion failed: first <= last && last < BBTOB(bp->b_length), file: fs/xfs/xfs_trans_buf.c, line: 568

Where #1 showed the first region of the dup being logged (i.e. the
last 4 bytes of a directory buffer) and #2 shows the corrupt values
being calculated from the length of the dup entry which overflowed
the size of the buffer.

It turns out that the problem was not in the logging code, nor in
the freespace handling code. It is an initial condition bug that
only shows up on 32 bit systems. When a new buffer is initialised,
where's the freespace that is set up:

[  172.316249] calling xfs_dir2_leaf_addname() from xfs_dir_createname()
[  172.316346] #9 calling xfs_dir2_data_log_unused()
[  172.316351] #1 calling xfs_trans_log_buf() 60 63 4096
[  172.316353] #2 calling xfs_trans_log_buf() 4094 4095 4096

Note the offset of the first region being logged? It's 60 bytes into
the buffer. Once I saw that, I pretty much knew that the bug was
going to be caused by this.

Essentially, all direct entries are rounded to 8 bytes in length,
and all entries start with an 8 byte alignment. This means that we
can decode inplace as variables are naturally aligned. With the
directory data supposedly starting on a 8 byte boundary, and all
entries padded to 8 bytes, the minimum freespace in a directory
block is supposed to be 8 bytes, which is large enough to fit a
unused data entry structure (6 bytes in size). The fact we only have
4 bytes of free space indicates a directory data block alignment
problem.

And what do you know - there's an implicit hole in the directory
data block header for the CRC format, which means the header is 60
byte on 32 bit intel systems and 64 bytes on 64 bit systems. Needs
padding. And while looking at the structures, I found the same
problem in the attr leaf header. Fix them both.

Note that this only affects 32 bit systems with CRCs enabled.
Everything else is just fine. Note that CRC enabled filesystems created
before this fix on such systems will not be readable with this fix
applied.
Reported-by: NMichael L. Semon <mlsemon35@gmail.com>
Debugged-by: NMichael L. Semon <mlsemon35@gmail.com>
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NBen Myers <bpm@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

(cherry picked from commit 8a1fd295)

We write the superblock every 30s or so which results in the
verifier being called. Right now that results in this output
every 30s:

XFS (vda): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled!
Use of these features in this kernel is at your own risk!

And spamming the logs.

We don't need to check for whether we support v5 superblocks or
whether there are feature bits we don't support set as these are
only relevant when we first mount the filesytem. i.e. on superblock
read. Hence for the write verification we can just skip all the
checks (and hence verbose output) altogether.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NBrian Foster <bfoster@redhat.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

(cherry picked from commit 34510185)

Pull btrfs fixes from Chris Mason:
 "This is an assortment of crash fixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: stop all workers before cleaning up roots
  Btrfs: fix use-after-free bug during umount
  Btrfs: init relocate extent_io_tree with a mapping
  btrfs: Drop inode if inode root is NULL
  Btrfs: don't delete fs_roots until after we cleanup the transaction

We need to clear pending interrupts on the resume
path. This brings the device into defined state
before starting the reset flow

This should solve suspend/resume issues:

mei_me : wait hw ready failed. status = 0x0
mei_me : version message write failed
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The nfc_dev is a static variable and is not cleaned properly upon reset
mainly ndev->cl and ndev->cl_info are not set to NULL after freeing which

mei_stop:198: mei_me 0000:00:16.0: stopping the device.
[  404.253427] general protection fault: 0000 [#2] SMP
[  404.253437] Modules linked in: mei_me(-) binfmt_misc snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd af_packet cpufreq_conservative cpufreq_userspace cpufreq_powersave fuse loop dm_mod hid_generic usbhid hid coretemp acpi_cpufreq mperf kvm_intel kvm crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul snd_hda_codec_hdmi glue_helper aes_x86_64 e1000e snd_hda_intel snd_hda_codec ehci_pci iTCO_wdt iTCO_vendor_support ehci_hcd snd_hwdep xhci_hcd snd_pcm usbcore ptp mei sg microcode snd_timer pps_core i2c_i801 snd pcspkr battery rtc_cmos lpc_ich mfd_core soundcore usb_common snd_page_alloc ac ext3 jbd mbcache drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt i2c_core sd_mod crc_t10dif thermal fan video button processor thermal_sys hwmon ahci libahci libata scsi_mod [last unloaded: mei_me]
[  404.253591] CPU: 0 PID: 5551 Comm: modprobe Tainted: G      D W    3.10.0-rc3 #1
[  404.253611] task: ffff880143cd8300 ti: ffff880144a2a000 task.ti: ffff880144a2a000
[  404.253619] RIP: 0010:[<ffffffff81334e5d>]  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
[  404.253638] RSP: 0018:ffff880144a2bcf8  EFLAGS: 00010206
[  404.253645] RAX: 2020302e30202030 RBX: ffff880144fdb000 RCX: 0000000000000086
[  404.253652] RDX: 0000000000000001 RSI: 0000000000000086 RDI: ffff880144fdb000
[  404.253659] RBP: ffff880144a2bd18 R08: 0000000000000651 R09: 0000000000000006
[  404.253666] R10: 0000000000000651 R11: 0000000000000006 R12: ffff880144fdb000
[  404.253673] R13: ffff880149371098 R14: ffff880144482c00 R15: ffffffffa04710e0
[  404.253681] FS:  00007f251c59a700(0000) GS:ffff88014e200000(0000) knlGS:0000000000000000
[  404.253689] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  404.253696] CR2: ffffffffff600400 CR3: 0000000145319000 CR4: 00000000001407f0
[  404.253703] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  404.253710] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  404.253716] Stack:
[  404.253720]  ffff880144fdb000 ffff880143ffe000 ffff880149371098 ffffffffa0471000
[  404.253732]  ffff880144a2bd38 ffffffff8133502d ffff88014e20cf48 ffff880143ffe1d8
[  404.253744]  ffff880144a2bd48 ffffffffa02a4749 ffff880144a2bd58 ffffffffa02a4ba1
[  404.253755] Call Trace:
[  404.253766]  [<ffffffff8133502d>] device_unregister+0x1d/0x60
[  404.253787]  [<ffffffffa02a4749>] mei_cl_remove_device+0x9/0x10 [mei]
[  404.253804]  [<ffffffffa02a4ba1>] mei_nfc_host_exit+0x21/0x30 [mei]
[  404.253819]  [<ffffffffa029c2dd>] mei_stop+0x3d/0x90 [mei]
[  404.253830]  [<ffffffffa046e220>] mei_me_remove+0x60/0xe0 [mei_me]
[  404.253843]  [<ffffffff81278f37>] pci_device_remove+0x37/0xb0
[  404.253855]  [<ffffffff81337c68>] __device_release_driver+0x98/0x100
[  404.253865]  [<ffffffff81337d80>] driver_detach+0xb0/0xc0
[  404.253876]  [<ffffffff81336b4f>] bus_remove_driver+0x8f/0x120
[  404.253891]  [<ffffffff81075990>] ? try_to_wake_up+0x2b0/0x2b0
[  404.253903]  [<ffffffff81338a48>] driver_unregister+0x58/0x90
[  404.253913]  [<ffffffff8127906b>] pci_unregister_driver+0x2b/0xb0
[  404.253924]  [<ffffffffa046f244>] mei_me_driver_exit+0x10/0xdcc [mei_me]
[  404.253936]  [<ffffffff810a50d8>] SyS_delete_module+0x198/0x2b0
[  404.253949]  [<ffffffff814850d9>] ? do_page_fault+0x9/0x10
[  404.253961]  [<ffffffff81489692>] system_call_fastpath+0x16/0x1b
[  404.253967] Code: 41 5c 41 5d 41 5e 41 5f c9 c3 0f 1f 40 00 55 48 89 e5 41 56 41 55 41 54 49 89 fc 53 48 8b 87 88 00 00 00 4c 8b 37 48 85 c0 74 18 <48> 8b 78 78 4c 89 e2 be 02 00 00 00 48 81 c7 f8 00 00 00 e8 3b
[  404.254048] RIP  [<ffffffff81334e5d>] device_del+0x1d/0x1d0

Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Flushing pending work items before resetting the device makes more
sense than doing so afterwards. Some of them, like e.g. the NFC
initialization one, find themselves with client IDs changed after
the reset, eventually leading to trigger a client.c:mei_me_cl_by_id()
warning after a few modprobe/rmmod cycles.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull device tree bug fixes from Grant Likely:
 "This branch contains the following bug fixes:
   - Fix locking vs. interrupts. Bug caught by lockdep checks
   - Fix parsing of cpp #line directive output by dtc
   - Fix 'make clean' for dtc temporary files.

  There is also a commit that regenerates the dtc lexer and parser files
  with Bison 2.5.  The only purpose of this commit is to separate the
  functional change in the dtc bug fix from the code generation change
  caused by a different Bison version"

* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux:
  dtc: ensure #line directives don't consume data from the next line
  dtc: Update generated files to output from Bison 2.5
  of: Fix locking vs. interrupts
  kbuild: make sure we clean up DTB temporary files

Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line directive parsing. This
could cause syntax errors (i.e. #line parsing consuming the leading 0
from a hex literal 0x1234, leaving x1234 to be parsed as cell data,
which is a syntax error), or invalid compilation results (i.e. simply
consuming literal 1234 as part of the #line processing, thus removing it
from the cell data).

Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.

Convert all instances of {WS}, even though the other instances should be
irrelevant for any well-formed #line directive. This is done for
consistency and ultimate safety.

[Cherry picked from DTC commit a1ee6f068e1c8dbc62873645037a353d7852d5cc]
Reported-by: NIan Campbell <Ian.Campbell@citrix.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

This patch merely updates the generated dtc parser and lexer files to
the output generated by Bison 2.5. The previous versions were generated
from version 2.4.1. The only reason for this commit is to minimize the
diff on the next commit which fixes a bug in the DTC #line directive
parsing. Otherwise the Bison changes would be intermingled with the
functional changes.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The OF code uses irqsafe locks everywhere except in a handful of functions
for no obvious reasons. Since the conversion from the old rwlocks, this
now triggers lockdep warnings when used at interrupt time. At least one
driver (ibmvscsi) seems to be doing that from softirq context.

This converts the few non-irqsafe locks into irqsafe ones, making them
consistent with the rest of the code.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

Various temporary files used when building DTB files were not suffixed with
.tmp and therefore were not cleaned up by "make clean".
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

Pull ACPI fix from Rafael Wysocki:
 "This is an alternative fix for the regression introduced in 3.9 whose
  previous fix had to be reverted right before 3.10-rc5, because it
  broke one of the Tony's machines.

  In this one the check is confined to the ACPI video driver (which is
  the only one causing the problem to happen in the first place) and the
  Tony's box shouldn't even notice it.

   - ACPI fix for an issue causing ACPI video driver to attempt to bind
     to devices it shouldn't touch from Rafael J Wysocki."

* tag 'acpi-3.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / video: Do not bind to device objects with a scan handler

Pull x86 fixes from Peter Anvin:
 "Another set of fixes, the biggest bit of this is yet another tweak to
  the UEFI anti-bricking code; apparently we finally got some feedback
  from Samsung as to what makes at least their systems fail.  This set
  should actually fix the boot regressions that some other systems (e.g.
  SGI) have exhibited.

  Other than that, there is a patch to avoid a panic with particularly
  unhappy memory layouts and two minor protocol fixes which may or may
  not be manifest bugs"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86: Fix typo in kexec register clearing
  x86, relocs: Move __vvar_page from S_ABS to S_REL
  Modify UEFI anti-bricking code
  x86: Fix adjust_range_size_mask calling position

Pull RCU fixes from Paul McKenney:
 "I must confess that this past merge window was not RCU's best showing.
  This series contains three more fixes for RCU regressions:

   1.   A fix to __DECLARE_TRACE_RCU() that causes it to act as an
        interrupt from idle rather than as a task switch from idle.
        This change is needed due to the recent use of _rcuidle()
        tracepoints that can be invoked from interrupt handlers as well
        as from idle.  Without this fix, invoking _rcuidle() tracepoints
        from interrupt handlers results in splats and (more seriously)
        confusion on RCU's part as to whether a given CPU is idle or not.
        This confusion can in turn result in too-short grace periods and
        therefore random memory corruption.

   2.   A fix to a subtle deadlock that could result due to RCU doing
        a wakeup while holding one of its rcu_node structure's locks.
        Although the probability of occurrence is low, it really
        does happen.  The fix, courtesy of Steven Rostedt, uses
        irq_work_queue() to avoid the deadlock.

   3.   A fix to a silent deadlock (invisible to lockdep) due to the
        interaction of timeouts posted by RCU debug code enabled by
        CONFIG_PROVE_RCU_DELAY=y, grace-period initialization, and CPU
        hotplug operations.  This will not occur in production kernels,
        but really does occur in randconfig testing.  Diagnosis courtesy
        of Steven Rostedt"

* 'rcu/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
  rcu: Fix deadlock with CPU hotplug, RCU GP init, and timer migration
  rcu: Don't call wakeup() with rcu_node structure ->lock held
  trace: Allow idle-safe tracepoints to be called from irq

Pull s390 fixes from Martin Schwidefsky:
 "Three kvm related memory management fixes, a fix for show_trace, a fix
  for early console output and a patch from Ben to help prevent compile
  errors in regard to irq functions (or our lack thereof)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/pci: Implement IRQ functions if !PCI
  s390/sclp: fix new line detection
  s390/pgtable: make pgste lock an explicit barrier
  s390/pgtable: Save pgste during modify_prot_start/commit
  s390/dumpstack: fix address ranges for asynchronous and panic stack
  s390/pgtable: Fix guest overindication for change bit

Pull ASoC sound updates from Mark Brown:
 "Takashi is travelling at the minute and it'd be good to get the
  MAINTAINERS update in here merged so sending directly.

  As well as the usual driver specifics we've got a couple of core fixes
  here, one fixing capabilities for unidirectional streams and the other
  fixing suspend while audio streams are active.

  The suspend fix is a little involved but mostly as a result of
  removing some special casing that was doing the wrong thing."

* tag 'asoc-v3.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound:
  ASoC: tlv320aic3x: Remove deadlock from snd_soc_dapm_put_volsw_aic3x()
  ASoC: dapm: Treat DAI widgets like AIF widgets for power
  ASoC: arizona: Correct AEC loopback enable
  ASoC: pcm: Require both CODEC and CPU support when declaring stream caps
  MAINTAINERS: Remove myself from Wolfson maintainers
  ASoC: wm8994: Ensure microphone detection state is reset on removal
  ASoC: wm8994: Avoid leaking pm_runtime reference on removed jack race
  ASoC: cs42l52: fix hp_gain_enum shift value.
  ASoC: cs42l52: use correct PCM mixer TLV dB scale to match datasheet.

Pull md bugfixes from Neil Brown:
 "A few bugfixes for md

  Some tagged for -stable"

* tag 'md-3.10-fixes' of git://neil.brown.name/md:
  md/raid1,5,10: Disable WRITE SAME until a recovery strategy is in place
  md/raid1,raid10: use freeze_array in place of raise_barrier in various places.
  md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuilding drive completed it.
  md: md_stop_writes() should always freeze recovery.

On platforms with C8-C10 support, the additional C-states cause
turbostat to overrun its output buffer of 128 bytes per CPU.  Increase
this to 256 bytes per CPU.

[ As a bugfix, this should go into 3.10; however, since the C8-C10
  support didn't go in until after 3.9, this need not go into any stable
  kernel. ]
Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

 * More tweaking to the EFI variable anti-bricking algorithm. Quite a
   few users were reporting boot regressions in v3.9. This has now been
   fixed with a more accurate "minimum storage requirement to avoid
   bricking" value from Samsung (5K instead of 50%) and code to trigger
   garbage collection when we near our limit - Matthew Garrett.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

There are cases where the kernel will believe that the WRITE SAME
command is supported by a block device which does not, in fact,
support WRITE SAME.  This currently happens for SATA drivers behind a
SAS controller, but there are probably a hundred other ways that can
happen, including drive firmware bugs.

After receiving an error for WRITE SAME the block layer will retry the
request as a plain write of zeroes, but mdraid will consider the
failure as fatal and consider the drive failed.  This has the effect
that all the mirrors containing a specific set of data are each
offlined in very rapid succession resulting in data loss.

However, just bouncing the request back up to the block layer isn't
ideal either, because the whole initial request-retry sequence should
be inside the write bitmap fence, which probably means that md needs
to do its own conversion of WRITE SAME to write zero.

Until the failure scenario has been sorted out, disable WRITE SAME for
raid1, raid5, and raid10.

[neilb: added raid5]

This patch is appropriate for any -stable since 3.7 when write_same
support was added.

Cc: stable@vger.kernel.org
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

Various places in raid1 and raid10 are calling raise_barrier when they
really should call freeze_array.
The former is only intended to be called from "make_request".
The later has extra checks for 'nr_queued' and makes a call to
flush_pending_writes(), so it is safe to call it from within the
management thread.

Using raise_barrier will sometimes deadlock.  Using freeze_array
should not.

As 'freeze_array' currently expects one request to be pending (in
handle_read_error - the only previous caller), we need to pass
it the number of pending requests (extra) to ignore.

The deadlock was made particularly noticeable by commits
050b6615 (raid10) and 6b740b8d (raid1) which
appeared in 3.4, so the fix is appropriate for any -stable
kernel since then.

This patch probably won't apply directly to some early kernels and
will need to be applied by hand.

Cc: stable@vger.kernel.org
Reported-by: NAlexander Lyakas <alex.bolshoy@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuilding drive completed it.

Without that fix, the following scenario could happen:

- RAID1 with drives A and B; drive B was freshly-added and is rebuilding
- Drive A fails
- WRITE request arrives to the array. It is failed by drive A, so
r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B
succeeds in writing it, so the same r1_bio is marked as
R1BIO_Uptodate.
- r1_bio arrives to handle_write_finished, badblocks are disabled,
md_error()->error() does nothing because we don't fail the last drive
of raid1
- raid_end_bio_io()  calls call_bio_endio()
- As a result, in call_bio_endio():
        if (!test_bit(R1BIO_Uptodate, &r1_bio->state))
                clear_bit(BIO_UPTODATE, &bio->bi_flags);
this code doesn't clear the BIO_UPTODATE flag, and the whole master
WRITE succeeds, back to the upper layer.

So we returned success to the upper layer, even though we had written
the data onto the rebuilding drive only. But when we want to read the
data back, we would not read from the rebuilding drive, so this data
is lost.

[neilb - applied identical change to raid10 as well]

This bug can result in lost data, so it is suitable for any
-stable kernel.

Cc: stable@vger.kernel.org
Signed-off-by: NAlex Lyakas <alex@zadarastorage.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

__md_stop_writes() will currently sometimes freeze recovery.
So any caller must be ready for that to happen, and indeed they are.

However if __md_stop_writes() doesn't freeze_recovery, then
a recovery could start before mddev_suspend() is called, which
could be awkward.  This can particularly cause problems or dm-raid.

So change __md_stop_writes() to always freeze recovery.  This is safe
and more predicatable.
Reported-by: NBrassow Jonathan <jbrassow@redhat.com>
Tested-by: NBrassow Jonathan <jbrassow@redhat.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

Pull networking update from David Miller:

 1) Fix dump iterator in nfnl_acct_dump() and ctnl_timeout_dump() to
    dump all objects properly, from Pablo Neira Ayuso.

 2) xt_TCPMSS must use the default MSS of 536 when no MSS TCP option is
    present.  Fix from Phil Oester.

 3) qdisc_get_rtab() looks for an existing matching rate table and uses
    that instead of creating a new one.  However, it's key matching is
    incomplete, it fails to check to make sure the ->data[] array is
    identical too.  Fix from Eric Dumazet.

 4) ip_vs_dest_entry isn't fully initialized before copying back to
    userspace, fix from Dan Carpenter.

 5) Fix ubuf reference counting regression in vhost_net, from Jason
    Wang.

 6) When sock_diag dumps a socket filter back to userspace, we have to
    translate it out of the kernel's internal representation first.
    From Nicolas Dichtel.

 7) davinci_mdio holds a spinlock while calling pm_runtime, which
    sleeps.  Fix from Sebastian Siewior.

 8) Timeout check in sh_eth_check_reset is off by one, from Sergei
    Shtylyov.

 9) If sctp socket init fails, we can NULL deref during cleanup.  Fix
    from Daniel Borkmann.

10) netlink_mmap() does not propagate errors properly, from Patrick
    McHardy.

11) Disable powersave and use minstrel by default in ath9k.  From Sujith
    Manoharan.

12) Fix a regression in that SOCK_ZEROCOPY is not set on tuntap sockets
    which prevents vhost from being able to use zerocopy.  From Jason
    Wang.

13) Fix race between port lookup and TX path in team driver, from Jiri
    Pirko.

14) Missing length checks in bluetooth L2CAP packet parsing, from Johan
    Hedberg.

15) rtlwifi fails to connect to networking using any encryption method
    other than WPA2.  Fix from Larry Finger.

16) Fix iwlegacy build due to incorrect CONFIG_* ifdeffing for power
    management stuff.  From Yijing Wang.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (35 commits)
  b43: stop format string leaking into error msgs
  ath9k: Use minstrel rate control by default
  Revert "ath9k_hw: Update rx gain initval to improve rx sensitivity"
  ath9k: Disable PowerSave by default
  net: wireless: iwlegacy: fix build error for il_pm_ops
  rtlwifi: Fix a false leak indication for PCI devices
  wl12xx/wl18xx: scan all 5ghz channels
  wl12xx: increase minimum singlerole firmware version required
  wl12xx: fix minimum required firmware version for wl127x multirole
  rtlwifi: rtl8192cu: Fix problem in connecting to WEP or WPA(1) networks
  mwifiex: debugfs: Fix out of bounds array access
  Bluetooth: Fix mgmt handling of power on failures
  Bluetooth: Fix missing length checks for L2CAP signalling PDUs
  Bluetooth: btmrvl: support Marvell Bluetooth device SD8897
  Bluetooth: Fix checks for LE support on LE-only controllers
  team: fix checks in team_get_first_port_txable_rcu()
  team: move add to port list before port enablement
  team: check return value of team_get_port_by_index_rcu() for NULL
  tuntap: set SOCK_ZEROCOPY flag during open
  netlink: fix error propagation in netlink_mmap()
  ...

Pull input layer bugfix from Jiri Kosina:
 "Memory leak regression fix from Benjamin Tissoires"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
  HID: multitouch: prevent memleak with the allocated name