6 years agoperf: Fix inherited events vs. tracepoint filters
Peter Zijlstra [Mon, 2 Nov 2015 09:50:51 +0000 (10:50 +0100)]
perf: Fix inherited events vs. tracepoint filters

commit b71b437eedaed985062492565d9d421d975ae845 upstream.

Arnaldo reported that tracepoint filters seem to misbehave (ie. not
apply) on inherited events.

The fix is obvious; filters are only set on the actual (parent)
event, use the normal pattern of using this parent event for filters.
This is safe because each child event has a reference to it.

Reported-by: Arnaldo Carvalho de Melo <>
Tested-by: Arnaldo Carvalho de Melo <>
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Adrian Hunter <>
Cc: Arnaldo Carvalho de Melo <>
Cc: David Ahern <>
Cc: Frédéric Weisbecker <>
Cc: Jiri Olsa <>
Cc: Jiri Olsa <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Steven Rostedt <>
Cc: Thomas Gleixner <>
Cc: Wang Nan <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: fix race leading to BUG_ON when running delalloc for nodatacow
Filipe Manana [Mon, 9 Nov 2015 00:33:58 +0000 (00:33 +0000)]
Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow

commit 1d512cb77bdbda80f0dd0620a3b260d697fd581d upstream.

If we are using the NO_HOLES feature, we have a tiny time window when
running delalloc for a nodatacow inode where we can race with a concurrent
link or xattr add operation leading to a BUG_ON.

This happens because at run_delalloc_nocow() we end up casting a leaf item
file extent item (struct btrfs_file_extent_item) and then analyse its
extent type field, which won't match any of the expected extent types
(values BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]) and therefore trigger an
explicit BUG_ON(1).

The following sequence diagram shows how the race happens when running a
no-cow dellaloc range [4K, 8K[ for inode 257 and we have the following
neighbour leafs:

             Leaf X (has N items)                    Leaf Y

 [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 EXTENT_DATA 8192), ... ]
              slot N - 2         slot N - 1              slot 0

 (Note the implicit hole for inode 257 regarding the [0, 8K[ range)

       CPU 1                                         CPU 2

     --> searches for a key with value
         (257 EXTENT_DATA 4096) in the
         fs/subvol tree
     --> returns us a path with
         path->nodes[0] == leaf X and
         path->slots[0] == N

   because path->slots[0] is >=
   btrfs_header_nritems(leaf X), it
   calls btrfs_next_leaf()

     --> releases the path

                                              hard link added to our inode,
                                              with key (257 INODE_REF 500)
                                              added to the end of leaf X,
                                              so leaf X now has N + 1 keys

     --> searches for the key
         (257 INODE_REF 256), because
         it was the last key in leaf X
         before it released the path,
         with path->keep_locks set to 1

     --> ends up at leaf X again and
         it verifies that the key
         (257 INODE_REF 256) is no longer
         the last key in the leaf, so it
         returns with path->nodes[0] ==
         leaf X and path->slots[0] == N,
         pointing to the new item with
         key (257 INODE_REF 500)

   the loop iteration of run_dealloc_nocow()
   does not break out the loop and continues
   because the key referenced in the path
   at path->nodes[0] and path->slots[0] is
   for inode 257, its type is < BTRFS_EXTENT_DATA_KEY
   and its offset (500) is less then our delalloc
   range's end (8192)

   the item pointed by the path, an inode reference item,
   is (incorrectly) interpreted as a file extent item and
   we get an invalid extent type, leading to the BUG_ON(1):

   if (extent_type == BTRFS_FILE_EXTENT_REG ||
      extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
   } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
   } else {

The same can happen if a xattr is added concurrently and ends up having
a key with an offset smaller then the delalloc's range end.

So fix this by skipping keys with a type smaller than

Signed-off-by: Filipe Manana <>
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: fix race leading to incorrect item deletion when dropping extents
Filipe Manana [Fri, 6 Nov 2015 13:33:33 +0000 (13:33 +0000)]
Btrfs: fix race leading to incorrect item deletion when dropping extents

commit aeafbf8486c9e2bd53f5cc3c10c0b7fd7149d69c upstream.

While running a stress test I got the following warning triggered:

  [191627.672810] ------------[ cut here ]------------
  [191627.673949] WARNING: CPU: 8 PID: 8447 at fs/btrfs/file.c:779 __btrfs_drop_extents+0x391/0xa50 [btrfs]()
  [191627.701485] Call Trace:
  [191627.702037]  [<ffffffff8145f077>] dump_stack+0x4f/0x7b
  [191627.702992]  [<ffffffff81095de5>] ? console_unlock+0x356/0x3a2
  [191627.704091]  [<ffffffff8104b3b0>] warn_slowpath_common+0xa1/0xbb
  [191627.705380]  [<ffffffffa0664499>] ? __btrfs_drop_extents+0x391/0xa50 [btrfs]
  [191627.706637]  [<ffffffff8104b46d>] warn_slowpath_null+0x1a/0x1c
  [191627.707789]  [<ffffffffa0664499>] __btrfs_drop_extents+0x391/0xa50 [btrfs]
  [191627.709155]  [<ffffffff8115663c>] ? cache_alloc_debugcheck_after.isra.32+0x171/0x1d0
  [191627.712444]  [<ffffffff81155007>] ? kmemleak_alloc_recursive.constprop.40+0x16/0x18
  [191627.714162]  [<ffffffffa06570c9>] insert_reserved_file_extent.constprop.40+0x83/0x24e [btrfs]
  [191627.715887]  [<ffffffffa065422b>] ? start_transaction+0x3bb/0x610 [btrfs]
  [191627.717287]  [<ffffffffa065b604>] btrfs_finish_ordered_io+0x273/0x4e2 [btrfs]
  [191627.728865]  [<ffffffffa065b888>] finish_ordered_fn+0x15/0x17 [btrfs]
  [191627.730045]  [<ffffffffa067d688>] normal_work_helper+0x14c/0x32c [btrfs]
  [191627.731256]  [<ffffffffa067d96a>] btrfs_endio_write_helper+0x12/0x14 [btrfs]
  [191627.732661]  [<ffffffff81061119>] process_one_work+0x24c/0x4ae
  [191627.733822]  [<ffffffff810615b0>] worker_thread+0x206/0x2c2
  [191627.734857]  [<ffffffff810613aa>] ? process_scheduled_works+0x2f/0x2f
  [191627.736052]  [<ffffffff810613aa>] ? process_scheduled_works+0x2f/0x2f
  [191627.737349]  [<ffffffff810669a6>] kthread+0xef/0xf7
  [191627.738267]  [<ffffffff810f3b3a>] ? time_hardirqs_on+0x15/0x28
  [191627.739330]  [<ffffffff810668b7>] ? __kthread_parkme+0xad/0xad
  [191627.741976]  [<ffffffff81465592>] ret_from_fork+0x42/0x70
  [191627.743080]  [<ffffffff810668b7>] ? __kthread_parkme+0xad/0xad
  [191627.744206] ---[ end trace bbfddacb7aaada8d ]---

  $ cat -n fs/btrfs/file.c
  691  int __btrfs_drop_extents(struct btrfs_trans_handle *trans,
  758                  btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);
  759                  if (key.objectid > ino ||
  760                      key.type > BTRFS_EXTENT_DATA_KEY || key.offset >= end)
  761                          break;
  763                  fi = btrfs_item_ptr(leaf, path->slots[0],
  764                                      struct btrfs_file_extent_item);
  765                  extent_type = btrfs_file_extent_type(leaf, fi);
  767                  if (extent_type == BTRFS_FILE_EXTENT_REG ||
  768                      extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
  774                  } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
  778                  } else {
  779                          WARN_ON(1);
  780                          extent_end = search_start;
  781                  }

This happened because the item we were processing did not match a file
extent item (its key type != BTRFS_EXTENT_DATA_KEY), and even on this
case we cast the item to a struct btrfs_file_extent_item pointer and
then find a type field value that does not match any of the expected
values (BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]). This scenario happens
due to a tiny time window where a race can happen as exemplified below.
For example, consider the following scenario where we're using the
NO_HOLES feature and we have the following two neighbour leafs:

               Leaf X (has N items)                    Leaf Y

[ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 EXTENT_DATA 8192), ... ]
          slot N - 2         slot N - 1              slot 0

Our inode 257 has an implicit hole in the range [0, 8K[ (implicit rather
than explicit because NO_HOLES is enabled). Now if our inode has an
ordered extent for the range [4K, 8K[ that is finishing, the following
can happen:

          CPU 1                                       CPU 2

         Searches for the key
          (257 EXTENT_DATA 4096) through

         Key not found and we get a path where
         path->nodes[0] == leaf X and
         path->slots[0] == N

         Because path->slots[0] is >=
         btrfs_header_nritems(leaf X), we call

         btrfs_next_leaf() releases the path

                                                  inserts key
                                                  (257 INODE_REF 4096)
                                                  at the end of leaf X,
                                                  leaf X now has N + 1 keys,
                                                  and the new key is at
                                                  slot N

         btrfs_next_leaf() searches for
         key (257 INODE_REF 256), with
         path->keep_locks set to 1,
         because it was the last key it
         saw in leaf X

           finds it in leaf X again and
           notices it's no longer the last
           key of the leaf, so it returns 0
           with path->nodes[0] == leaf X and
           path->slots[0] == N (which is now
           < btrfs_header_nritems(leaf X)),
           pointing to the new key
           (257 INODE_REF 4096)

         __btrfs_drop_extents() casts the
         item at path->nodes[0], slot
         path->slots[0], to a struct
         btrfs_file_extent_item - it does
         not skip keys for the target
         inode with a type less than

         sees a bogus value for the type
         field triggering the WARN_ON in
         the trace shown above, and sets
         extent_end = search_start (4096)

         does the if-then-else logic to
         fixup 0 length extent items created
         by a past bug from hole punching:

           if (extent_end == key.offset &&
               extent_end >= search_start)
               goto delete_extent_item;

         that evaluates to true and it ends
         up deleting the key pointed to by
         path->slots[0], (257 INODE_REF 4096),
         from leaf X

The same could happen for example for a xattr that ends up having a key
with an offset value that matches search_start (very unlikely but not

So fix this by ensuring that keys smaller than BTRFS_EXTENT_DATA_KEY are
skipped, never casted to struct btrfs_file_extent_item and never deleted
by accident. Also protect against the unexpected case of getting a key
for a lower inode number by skipping that key and issuing a warning.

Signed-off-by: Filipe Manana <>
[bwh: Backported to 3.2: drop use of ASSERT()]
Signed-off-by: Ben Hutchings <>
6 years agox86/cpu: Call verify_cpu() after having entered long mode too
Borislav Petkov [Thu, 5 Nov 2015 15:57:56 +0000 (16:57 +0100)]
x86/cpu: Call verify_cpu() after having entered long mode too

commit 04633df0c43d710e5f696b06539c100898678235 upstream.

When we get loaded by a 64-bit bootloader, kernel entry point is
startup_64 in head_64.S. We don't trust any and all bootloaders because
some will fiddle with CPU configuration so we go ahead and massage each
CPU into sanity again.

For example, some dell BIOSes have this XD disable feature which set
IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround
for other OSes but Linux sure doesn't need it.

A similar thing is present in the Surface 3 firmware - see - which sets this bit
only on the BSP:

  # rdmsr -a 0x1a0

I know, right?!

There's not even an off switch in there.

So fix all those cases by sanitizing the 64-bit entry point too. For
that, make verify_cpu() callable in 64-bit mode also.

Requested-and-debugged-by: "H. Peter Anvin" <>
Reported-and-tested-by: Bastien Nocera <>
Signed-off-by: Borislav Petkov <>
Cc: Matt Fleming <>
Cc: Peter Zijlstra <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoscsi: restart list search after unlock in scsi_remove_target
Christoph Hellwig [Mon, 19 Oct 2015 14:35:46 +0000 (16:35 +0200)]
scsi: restart list search after unlock in scsi_remove_target

commit 40998193560dab6c3ce8d25f4fa58a23e252ef38 upstream.

When dropping a lock while iterating a list we must restart the search
as other threads could have manipulated the list under us.  Without this
we can get stuck in an endless loop.  This bug was introduced by

commit bc3f02a795d3b4faa99d37390174be2a75d091bd
Author: Dan Williams <>
Date:   Tue Aug 28 22:12:10 2012 -0700

    [SCSI] scsi_remove_target: fix softlockup regression on hot remove

Which was itself trying to fix a reported soft lockup issue

However, we believe even with this revert of the original patch, the soft
lockup problem has been fixed by

commit f2495e228fce9f9cec84367547813cbb0d6db15a
Author: James Bottomley <>
Date:   Tue Jan 21 07:01:41 2014 -0800

    [SCSI] dual scan thread bug fix

Thanks go to Dan Williams <> for tracking all this
prior history down.

Reported-by: Johannes Thumshirn <>
Signed-off-by: Christoph Hellwig <>
Tested-by: Johannes Thumshirn <>
Reviewed-by: Johannes Thumshirn <>
Fixes: bc3f02a795d3b4faa99d37390174be2a75d091bd
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
6 years agofirewire: ohci: fix JMicron JMB38x IT context discovery
Stefan Richter [Tue, 3 Nov 2015 00:46:21 +0000 (01:46 +0100)]
firewire: ohci: fix JMicron JMB38x IT context discovery

commit 100ceb66d5c40cc0c7018e06a9474302470be73c upstream.

Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo
controllers:  Often or even most of the time, the controller is
initialized with the message "added OHCI v1.10 device as card 0, 4 IR +
0 IT contexts, quirks 0x10".  With 0 isochronous transmit DMA contexts
(IT contexts), applications like audio output are impossible.

However, OHCI-1394 demands that at least 4 IT contexts are implemented
by the link layer controller, and indeed JMicron JMB38x do implement
four of them.  Only their IsoXmitIntMask register is unreliable at early

With my own JMB381 single function controller I found:
  - I can reproduce the problem with a lower probability than Craig's.
  - If I put a loop around the section which clears and reads
    IsoXmitIntMask, then either the first or the second attempt will
    return the correct initial mask of 0x0000000f.  I never encountered
    a case of needing more than a second attempt.
  - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)
    before the first write, the subsequent read will return the correct
  - If I merely ignore a wrong read result and force the known real
    result, later isochronous transmit DMA usage works just fine.

So let's just fix this chip bug up by the latter method.  Tested with
JMB381 on kernel 3.13 and 4.3.

Since OHCI-1394 generally requires 4 IT contexts at a minium, this
workaround is simply applied whenever the initial read of IsoXmitIntMask
returns 0, regardless whether it's a JMicron chip or not.  I never heard
of this issue together with any other chip though.

I am not 100% sure that this fix works on the OHCI-1394 part of JMB380
and JMB388 combo controllers exactly the same as on the JMB381 single-
function controller, but so far I haven't had a chance to let an owner
of a combo chip run a patched kernel.

Strangely enough, IsoRecvIntMask is always reported correctly, even
though it is probed right before IsoXmitIntMask.

Reported-by: Clifford Dunn
Reported-by: Craig Moore <>
Signed-off-by: Stefan Richter <>
[bwh: Backported to 3.2: log with fw_notify() instead of ohci_notice()]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: hda - Apply pin fixup for HP ProBook 6550b
Takashi Iwai [Wed, 4 Nov 2015 21:39:16 +0000 (22:39 +0100)]
ALSA: hda - Apply pin fixup for HP ProBook 6550b

commit c932b98c1e47312822d911c1bb76e81ef50e389c upstream.

HP ProBook 6550b needs the same pin fixup applied to other HP B-series
laptops with docks for making its headphone and dock headphone jacks
working properly.  We just need to add the codec SSID to the list.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoipv6: fix tunnel error handling
Michal Kubeček [Tue, 3 Nov 2015 07:51:07 +0000 (08:51 +0100)]
ipv6: fix tunnel error handling

commit ebac62fe3d24c0ce22dd83afa7b07d1a2aaef44d upstream.

Both tunnel6_protocol and tunnel46_protocol share the same error
handler, tunnel6_err(), which traverses through tunnel6_handlers list.
For ipip6 tunnels, we need to traverse tunnel46_handlers as we do e.g.
in tunnel46_rcv(). Current code can generate an ICMPv6 error message
with an IPv4 packet embedded in it.

Fixes: 73d605d1abbd ("[IPSEC]: changing API of xfrm6_tunnel_register")
Signed-off-by: Michal Kubecek <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agorecordmcount: Fix endianness handling bug for nop_mcount
libin [Tue, 3 Nov 2015 00:58:47 +0000 (08:58 +0800)]
recordmcount: Fix endianness handling bug for nop_mcount

commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream.

In nop_mcount, shdr->sh_offset and welp->r_offset should handle
endianness properly, otherwise it will trigger Segmentation fault
if the recordmcount main and file.o have different endianness.

Signed-off-by: Li Bin <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
6 years agomegaraid_sas : SMAP restriction--do not access user memory from IOCTL code [Thu, 15 Oct 2015 08:10:54 +0000 (13:40 +0530)]
megaraid_sas : SMAP restriction--do not access user memory from IOCTL code

commit 323c4a02c631d00851d8edc4213c4d184ef83647 upstream.

This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit
OS. Do not access user memory from kernel code. The SMAP bit restricts
accessing user memory from kernel code.

Signed-off-by: Sumit Saxena <>
Signed-off-by: Kashyap Desai <>
Reviewed-by: Tomas Henzl <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
6 years agocrypto: algif_hash - Only export and import on sockets with data
Herbert Xu [Sun, 1 Nov 2015 09:11:19 +0000 (17:11 +0800)]
crypto: algif_hash - Only export and import on sockets with data

commit 4afa5f9617927453ac04b24b584f6c718dfb4f45 upstream.

The hash_accept call fails to work on sockets that have not received
any data.  For some algorithm implementations it may cause crashes.

This patch fixes this by ensuring that we only export and import on
sockets that have received data.

Reported-by: Harsh Jain <>
Signed-off-by: Herbert Xu <>
Tested-by: Stephan Mueller <>
Signed-off-by: Ben Hutchings <>
6 years agomtd: blkdevs: fix potential deadlock + lockdep warnings
Brian Norris [Mon, 26 Oct 2015 17:20:23 +0000 (10:20 -0700)]
mtd: blkdevs: fix potential deadlock + lockdep warnings

commit f3c63795e90f0c6238306883b6c72f14d5355721 upstream.

Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.

The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.

 -> blktrans_open()
    ->  mutex_lock(&dev->lock);
    ->  mutex_lock(&mtd_table_mutex);

 -> del_mtd_device()
    ->  mutex_lock(&mtd_table_mutex);
    ->  blktrans_notify_remove() -> del_mtd_blktrans_dev()
       ->  mutex_lock(&dev->lock);

This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired &dev->lock:

        if (mutex_trylock(&mtd_table_mutex)) {

So, reverse the ordering of acquisition of &dev->lock and &mtd_table_mutex so
we always acquire mtd_table_mutex first.

Snippets of the lockdep output follow:

  # modprobe -r m25p80
  [   53.419251]
  [   53.420838] ======================================================
  [   53.427300] [ INFO: possible circular locking dependency detected ]
  [   53.433865] 4.3.0-rc6 #96 Not tainted
  [   53.437686] -------------------------------------------------------
  [   53.444220] modprobe/372 is trying to acquire lock:
  [   53.449320]  (&new->lock){+.+...}, at: [<c043fe4c>] del_mtd_blktrans_dev+0x80/0xdc
  [   53.457271]
  [   53.457271] but task is already holding lock:
  [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [<c0439994>] del_mtd_device+0x18/0x100
  [   53.471321]
  [   53.471321] which lock already depends on the new lock.
  [   53.471321]
  [   53.479856]
  [   53.479856] the existing dependency chain (in reverse order) is:
  [   53.487660]
  -> #1 (mtd_table_mutex){+.+.+.}:
  [   53.492331]        [<c043fc5c>] blktrans_open+0x34/0x1a4
  [   53.497879]        [<c01afce0>] __blkdev_get+0xc4/0x3b0
  [   53.503364]        [<c01b0bb8>] blkdev_get+0x108/0x320
  [   53.508743]        [<c01713c0>] do_dentry_open+0x218/0x314
  [   53.514496]        [<c0180454>] path_openat+0x4c0/0xf9c
  [   53.519959]        [<c0182044>] do_filp_open+0x5c/0xc0
  [   53.525336]        [<c0172758>] do_sys_open+0xfc/0x1cc
  [   53.530716]        [<c000f740>] ret_fast_syscall+0x0/0x1c
  [   53.536375]
  -> #0 (&new->lock){+.+...}:
  [   53.540587]        [<c063f124>] mutex_lock_nested+0x38/0x3cc
  [   53.546504]        [<c043fe4c>] del_mtd_blktrans_dev+0x80/0xdc
  [   53.552606]        [<c043f164>] blktrans_notify_remove+0x7c/0x84
  [   53.558891]        [<c04399f0>] del_mtd_device+0x74/0x100
  [   53.564544]        [<c043c670>] del_mtd_partitions+0x80/0xc8
  [   53.570451]        [<c0439aa0>] mtd_device_unregister+0x24/0x48
  [   53.576637]        [<c046ce6c>] spi_drv_remove+0x1c/0x34
  [   53.582207]        [<c03de0f0>] __device_release_driver+0x88/0x114
  [   53.588663]        [<c03de19c>] device_release_driver+0x20/0x2c
  [   53.594843]        [<c03dd9e8>] bus_remove_device+0xd8/0x108
  [   53.600748]        [<c03dacc0>] device_del+0x10c/0x210
  [   53.606127]        [<c03dadd0>] device_unregister+0xc/0x20
  [   53.611849]        [<c046d878>] __unregister+0x10/0x20
  [   53.617211]        [<c03da868>] device_for_each_child+0x50/0x7c
  [   53.623387]        [<c046eae8>] spi_unregister_master+0x58/0x8c
  [   53.629578]        [<c03e12f0>] release_nodes+0x15c/0x1c8
  [   53.635223]        [<c03de0f8>] __device_release_driver+0x90/0x114
  [   53.641689]        [<c03de900>] driver_detach+0xb4/0xb8
  [   53.647147]        [<c03ddc78>] bus_remove_driver+0x4c/0xa0
  [   53.652970]        [<c00cab50>] SyS_delete_module+0x11c/0x1e4
  [   53.658976]        [<c000f740>] ret_fast_syscall+0x0/0x1c
  [   53.664621]
  [   53.664621] other info that might help us debug this:
  [   53.664621]
  [   53.672979]  Possible unsafe locking scenario:
  [   53.672979]
  [   53.679169]        CPU0                    CPU1
  [   53.683900]        ----                    ----
  [   53.688633]   lock(mtd_table_mutex);
  [   53.692383]                                lock(&new->lock);
  [   53.698306]                                lock(mtd_table_mutex);
  [   53.704658]   lock(&new->lock);
  [   53.707946]
  [   53.707946]  *** DEADLOCK ***

Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing mtd->usecount")
Reported-by: Felipe Balbi <>
Tested-by: Felipe Balbi <>
Signed-off-by: Brian Norris <>
Signed-off-by: Ben Hutchings <>
6 years agocan: Use correct type in sizeof() in nla_put()
Marek Vasut [Fri, 30 Oct 2015 12:48:19 +0000 (13:48 +0100)]
can: Use correct type in sizeof() in nla_put()

commit 562b103a21974c2f9cd67514d110f918bb3e1796 upstream.

The sizeof() is invoked on an incorrect variable, likely due to some
copy-paste error, and this might result in memory corruption. Fix this.

Signed-off-by: Marek Vasut <>
Cc: Wolfgang Grandegger <>
Signed-off-by: Marc Kleine-Budde <>
[bwh: Backported to 3.2:
 - Keep using the old NLA_PUT macro
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomegaraid_sas: Do not use PAGE_SIZE for max_sectors [Thu, 15 Oct 2015 08:10:04 +0000 (13:40 +0530)]
megaraid_sas: Do not use PAGE_SIZE for max_sectors

commit 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758 upstream.

Do not use PAGE_SIZE marco to calculate max_sectors per I/O
request. Driver code assumes PAGE_SIZE will be always 4096 which can
lead to wrongly calculated value if PAGE_SIZE is not 4096. This issue
was reported in Ubuntu Bugzilla Bug #1475166.

Signed-off-by: Sumit Saxena <>
Signed-off-by: Kashyap Desai <>
Reviewed-by: Tomas Henzl <>
Reviewed-by: Martin K. Petersen <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: hda - Disable 64bit address for Creative HDA controllers
Takashi Iwai [Tue, 27 Oct 2015 13:21:51 +0000 (14:21 +0100)]
ALSA: hda - Disable 64bit address for Creative HDA controllers

commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.

We've had many reports that some Creative sound cards with CA0132
don't work well.  Some reported that it starts working after reloading
the module, while some reported it starts working when a 32bit kernel
is used.  All these facts seem implying that the chip fails to
communicate when the buffer is located in 64bit address.

This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
flag to the corresponding PCI entries.  I casually had a chance to
test an SB Recon3D board, and indeed this seems helping.

Although this hasn't been tested on all Creative devices, it's safer
to assume that this restriction applies to the rest of them, too.  So
the flag is applied to all Creative entries.

Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: drop the change to AZX_DCAPS_PRESET_CTHDA]
Signed-off-by: Ben Hutchings <>
6 years agoMIPS: atomic: Fix comment describing atomic64_add_unless's return value.
Ralf Baechle [Fri, 16 Oct 2015 21:09:57 +0000 (23:09 +0200)]
MIPS: atomic: Fix comment describing atomic64_add_unless's return value.

commit f25319d2cb439249a6859f53ad42ffa332b0acba upstream.

Signed-off-by: Ralf Baechle <>
Fixes: f24219b4e90cf70ec4a211b17fbabc725a0ddf3c
(cherry picked from commit f0a232cde7be18a207fd057dd79bbac8a0a45dec)
Signed-off-by: Ben Hutchings <>
6 years agoACPI: Use correct IRQ when uninstalling ACPI interrupt handler
Chen Yu [Sat, 24 Oct 2015 17:02:19 +0000 (01:02 +0800)]
ACPI: Use correct IRQ when uninstalling ACPI interrupt handler

commit 49e4b84333f338d4f183f28f1f3c1131b9fb2b5a upstream.

Currently when the system is trying to uninstall the ACPI interrupt
handler, it uses acpi_gbl_FADT.sci_interrupt as the IRQ number.
However, the IRQ number that the ACPI interrupt handled is installed
for comes from acpi_gsi_to_irq() and that is the number that should
be used for the handler removal.

Fix this problem by using the mapped IRQ returned from acpi_gsi_to_irq()
as appropriate.

Acked-by: Lv Zheng <>
Signed-off-by: Chen Yu <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agostaging: rtl8712: Add device ID for Sitecom WLA2100
Larry Finger [Mon, 19 Oct 2015 03:14:48 +0000 (22:14 -0500)]
staging: rtl8712: Add device ID for Sitecom WLA2100

commit 1e6e63283691a2a9048a35d9c6c59cf0abd342e4 upstream.

This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file
was checked to verify that the addition is correct.

Reported-by: Frans van de Wiel <>
Signed-off-by: Larry Finger <>
Cc: Frans van de Wiel <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoBluetooth: ath3k: Add support of AR3012 0cf3:817b device
Dmitry Tunin [Fri, 16 Oct 2015 08:45:26 +0000 (11:45 +0300)]
Bluetooth: ath3k: Add support of AR3012 0cf3:817b device

commit 18e0afab8ce3f1230ce3fef52b2e73374fd9c0e7 upstream.

T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=817b Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
6 years agoBluetooth: ath3k: Add new AR3012 0930:021c id
Dmitry Tunin [Mon, 5 Oct 2015 16:29:33 +0000 (19:29 +0300)]
Bluetooth: ath3k: Add new AR3012 0930:021c id

commit cd355ff071cd37e7197eccf9216770b2b29369f7 upstream.

This adapter works with the existing linux-firmware.

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0930 ProdID=021c Rev=00.01
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
6 years agoext4, jbd2: ensure entering into panic after recording an error in superblock
Daeho Jeong [Sun, 18 Oct 2015 21:02:56 +0000 (17:02 -0400)]
ext4, jbd2: ensure entering into panic after recording an error in superblock

commit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream.

If a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the
journaling will be aborted first and the error number will be recorded
into JBD2 superblock and, finally, the system will enter into the
panic state in "errors=panic" option.  But, in the rare case, this
sequence is little twisted like the below figure and it will happen
that the system enters into panic state, which means the system reset
in mobile environment, before completion of recording an error in the
journal superblock. In this case, e2fsck cannot recognize that the
filesystem failure occurred in the previous run and the corruption
wouldn't be fixed.

Task A                        Task B
-> jbd2_journal_abort()
  -> __journal_abort_soft()
    -> __jbd2_journal_abort_hard()
    | -> journal->j_flags |= JBD2_ABORT;
    |                         __ext4_abort()
    |                         -> jbd2_journal_abort()
    |                         | -> __journal_abort_soft()
    |                         |   -> if (journal->j_flags & JBD2_ABORT)
    |                         |           return;
    |                         -> panic()
    -> jbd2_journal_update_sb_errno()

Tested-by: Hobin Woo <>
Signed-off-by: Daeho Jeong <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: fix truncation of compressed and inlined extents
Filipe Manana [Fri, 16 Oct 2015 11:34:25 +0000 (12:34 +0100)]
Btrfs: fix truncation of compressed and inlined extents

commit 0305cd5f7fca85dae392b9ba85b116896eb7c1c7 upstream.

When truncating a file to a smaller size which consists of an inline
extent that is compressed, we did not discard (or made unusable) the
data between the new file size and the old file size, wasting metadata
space and allowing for the truncated data to be leaked and the data
corruption/loss mentioned below.
We were also not correctly decrementing the number of bytes used by the
inode, we were setting it to zero, giving a wrong report for callers of
the stat(2) syscall. The fsck tool also reported an error about a mismatch
between the nbytes of the file versus the real space used by the file.

Now because we weren't discarding the truncated region of the file, it
was possible for a caller of the clone ioctl to actually read the data
that was truncated, allowing for a security breach without requiring root
access to the system, using only standard filesystem operations. The
scenario is the following:

   1) User A creates a file which consists of an inline and compressed
      extent with a size of 2000 bytes - the file is not accessible to
      any other users (no read, write or execution permission for anyone

   2) The user truncates the file to a size of 1000 bytes;

   3) User A makes the file world readable;

   4) User B creates a file consisting of an inline extent of 2000 bytes;

   5) User B issues a clone operation from user A's file into its own
      file (using a length argument of 0, clone the whole range);

   6) User B now gets to see the 1000 bytes that user A truncated from
      its file before it made its file world readbale. User B also lost
      the bytes in the range [1000, 2000[ bytes from its own file, but
      that might be ok if his/her intention was reading stale data from
      user A that was never supposed to be public.

Note that this contrasts with the case where we truncate a file from 2000
bytes to 1000 bytes and then truncate it back from 1000 to 2000 bytes. In
this case reading any byte from the range [1000, 2000[ will return a value
of 0x00, instead of the original data.

This problem exists since the clone ioctl was added and happens both with
and without my recent data loss and file corruption fixes for the clone
ioctl (patch "Btrfs: fix file corruption and data loss after cloning
inline extents").

So fix this by truncating the compressed inline extents as we do for the
non-compressed case, which involves decompressing, if the data isn't already
in the page cache, compressing the truncated version of the extent, writing
the compressed content into the inline extent and then truncate it.

The following test case for fstests reproduces the problem. In order for
the test to pass both this fix and my previous fix for the clone ioctl
that forbids cloning a smaller inline extent into a larger one,
which is titled "Btrfs: fix file corruption and data loss after cloning
inline extents", are needed. Without that other fix the test fails in a
different way that does not leak the truncated data, instead part of
destination file gets replaced with zeroes (because the destination file
has a larger inline extent than the source).

  seq=`basename $0`
  echo "QA output created by $seq"
  status=1 # failure is the default!
  trap "_cleanup; exit \$status" 0 1 2 3 15

      rm -f $tmp.*

  # get standard environment, filters and checks
  . ./common/rc
  . ./common/filter

  # real QA test starts here
  _supported_fs btrfs
  _supported_os Linux

  rm -f $seqres.full

  _scratch_mkfs >>$seqres.full 2>&1
  _scratch_mount "-o compress"

  # Create our test files. File foo is going to be the source of a clone operation
  # and consists of a single inline extent with an uncompressed size of 512 bytes,
  # while file bar consists of a single inline extent with an uncompressed size of
  # 256 bytes. For our test's purpose, it's important that file bar has an inline
  # extent with a size smaller than foo's inline extent.
  $XFS_IO_PROG -f -c "pwrite -S 0xa1 0 128"   \
          -c "pwrite -S 0x2a 128 384" \
          $SCRATCH_MNT/foo | _filter_xfs_io
  $XFS_IO_PROG -f -c "pwrite -S 0xbb 0 256" $SCRATCH_MNT/bar | _filter_xfs_io

  # Now durably persist all metadata and data. We do this to make sure that we get
  # on disk an inline extent with a size of 512 bytes for file foo.

  # Now truncate our file foo to a smaller size. Because it consists of a
  # compressed and inline extent, btrfs did not shrink the inline extent to the
  # new size (if the extent was not compressed, btrfs would shrink it to 128
  # bytes), it only updates the inode's i_size to 128 bytes.
  $XFS_IO_PROG -c "truncate 128" $SCRATCH_MNT/foo

  # Now clone foo's inline extent into bar.
  # This clone operation should fail with errno EOPNOTSUPP because the source
  # file consists only of an inline extent and the file's size is smaller than
  # the inline extent of the destination (128 bytes < 256 bytes). However the
  # clone ioctl was not prepared to deal with a file that has a size smaller
  # than the size of its inline extent (something that happens only for compressed
  # inline extents), resulting in copying the full inline extent from the source
  # file into the destination file.
  # Note that btrfs' clone operation for inline extents consists of removing the
  # inline extent from the destination inode and copy the inline extent from the
  # source inode into the destination inode, meaning that if the destination
  # inode's inline extent is larger (N bytes) than the source inode's inline
  # extent (M bytes), some bytes (N - M bytes) will be lost from the destination
  # file. Btrfs could copy the source inline extent's data into the destination's
  # inline extent so that we would not lose any data, but that's currently not
  # done due to the complexity that would be needed to deal with such cases
  # (specially when one or both extents are compressed), returning EOPNOTSUPP, as
  # it's normally not a very common case to clone very small files (only case
  # where we get inline extents) and copying inline extents does not save any
  # space (unlike for normal, non-inlined extents).
  $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar

  # Now because the above clone operation used to succeed, and due to foo's inline
  # extent not being shinked by the truncate operation, our file bar got the whole
  # inline extent copied from foo, making us lose the last 128 bytes from bar
  # which got replaced by the bytes in range [128, 256[ from foo before foo was
  # truncated - in other words, data loss from bar and being able to read old and
  # stale data from foo that should not be possible to read anymore through normal
  # filesystem operations. Contrast with the case where we truncate a file from a
  # size N to a smaller size M, truncate it back to size N and then read the range
  # [M, N[, we should always get the value 0x00 for all the bytes in that range.

  # We expected the clone operation to fail with errno EOPNOTSUPP and therefore
  # not modify our file's bar data/metadata. So its content should be 256 bytes
  # long with all bytes having the value 0xbb.
  # Without the btrfs bug fix, the clone operation succeeded and resulted in
  # leaking truncated data from foo, the bytes that belonged to its range
  # [128, 256[, and losing data from bar in that same range. So reading the
  # file gave us the following content:
  # 0000000 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1
  # *
  # 0000200 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a
  # *
  # 0000400
  echo "File bar's content after the clone operation:"
  od -t x1 $SCRATCH_MNT/bar

  # Also because the foo's inline extent was not shrunk by the truncate
  # operation, btrfs' fsck, which is run by the fstests framework everytime a
  # test completes, failed reporting the following error:
  #  root 5 inode 257 errors 400, nbytes wrong


Signed-off-by: Filipe Manana <>
[bwh: Backported to 3.2:
 - Adjust parameters to btrfs_truncate_page() and btrfs_truncate_item()
 - Pass transaction pointer into truncate_inline_extent()
 - Add prototype of btrfs_truncate_page()
 - s/test_bit(BTRFS_ROOT_REF_COWS, &root->state)/root->ref_cows/
 - Keep using BUG_ON() for other error cases, as there is no
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: don't use ram_bytes for uncompressed inline items
Chris Mason [Sat, 4 Jan 2014 05:07:00 +0000 (21:07 -0800)]
Btrfs: don't use ram_bytes for uncompressed inline items

commit 514ac8ad8793a097c0c9d89202c642479d6dfa34 upstream.

If we truncate an uncompressed inline item, ram_bytes isn't updated to reflect
the new size.  The fixe uses the size directly from the item header when
reading uncompressed inlines, and also fixes truncate to update the
size as it goes.

Reported-by: Jens Axboe <>
Signed-off-by: Chris Mason <>
[bwh: Backported to 3.2:
 - Don't use btrfs_map_token API
 - There are fewer callers of btrfs_file_extent_inline_len() to change
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmode
Arnd Bergmann [Mon, 12 Oct 2015 13:46:08 +0000 (15:46 +0200)]
ARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmode

commit 54c09889bff6d99c8733eed4a26c9391b177c88b upstream.

The z2 machine calls pxa27x_set_pwrmode() in order to power off
the machine, but this function gets discarded early at boot because
it is marked __init, as pointed out by kbuild:

WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the function z2_power_off() to the function .init.text:pxa27x_set_pwrmode()
The function z2_power_off() references
the function __init pxa27x_set_pwrmode().
This is often because z2_power_off lacks a __init
annotation or the annotation of pxa27x_set_pwrmode is wrong.

This removes the __init section modifier to fix rebooting and the
build error.

Signed-off-by: Arnd Bergmann <>
Fixes: ba4a90a6d86a ("ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available")
Signed-off-by: Robert Jarzmik <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoiommu/vt-d: Fix ATSR handling for Root-Complex integrated endpoints
David Woodhouse [Thu, 15 Oct 2015 08:28:06 +0000 (09:28 +0100)]
iommu/vt-d: Fix ATSR handling for Root-Complex integrated endpoints

commit d14053b3c714178525f22660e6aaf41263d00056 upstream.

The VT-d specification says that "Software must enable ATS on endpoint
devices behind a Root Port only if the Root Port is reported as
supporting ATS transactions."

We walk up the tree to find a Root Port, but for integrated devices we
don't find one — we get to the host bridge. In that case we *should*
allow ATS. Currently we don't, which means that we are incorrectly
failing to use ATS for the integrated graphics. Fix that.

We should never break out of this loop "naturally" with bus==NULL,
since we'll always find bridge==NULL in that case (and now return 1).

So remove the check for (!bridge) after the loop, since it can never
happen. If it did, it would be worthy of a BUG_ON(!bridge). But since
it'll oops anyway in that case, that'll do just as well.

Signed-off-by: David Woodhouse <>
[bwh: Backported to 3.2:
 - Adjust context
 - There's no (!bridge) check to remove]
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: fix file corruption and data loss after cloning inline extents
Filipe Manana [Tue, 13 Oct 2015 14:15:00 +0000 (15:15 +0100)]
Btrfs: fix file corruption and data loss after cloning inline extents

commit 8039d87d9e473aeb740d4fdbd59b9d2f89b2ced9 upstream.

Currently the clone ioctl allows to clone an inline extent from one file
to another that already has other (non-inlined) extents. This is a problem
because btrfs is not designed to deal with files having inline and regular
extents, if a file has an inline extent then it must be the only extent
in the file and must start at file offset 0. Having a file with an inline
extent followed by regular extents results in EIO errors when doing reads
or writes against the first 4K of the file.

Also, the clone ioctl allows one to lose data if the source file consists
of a single inline extent, with a size of N bytes, and the destination
file consists of a single inline extent with a size of M bytes, where we
have M > N. In this case the clone operation removes the inline extent
from the destination file and then copies the inline extent from the
source file into the destination file - we lose the M - N bytes from the
destination file, a read operation will get the value 0x00 for any bytes
in the the range [N, M] (the destination inode's i_size remained as M,
that's why we can read past N bytes).

So fix this by not allowing such destructive operations to happen and
return errno EOPNOTSUPP to user space.

Currently the fstest btrfs/035 tests the data loss case but it totally
ignores this - i.e. expects the operation to succeed and does not check
the we got data loss.

The following test case for fstests exercises all these cases that result
in file corruption and data loss:

  seq=`basename $0`
  echo "QA output created by $seq"
  status=1 # failure is the default!
  trap "_cleanup; exit \$status" 0 1 2 3 15

      rm -f $tmp.*

  # get standard environment, filters and checks
  . ./common/rc
  . ./common/filter

  # real QA test starts here
  _supported_fs btrfs
  _supported_os Linux
  _require_btrfs_fs_feature "no_holes"
  _require_btrfs_mkfs_feature "no-holes"

  rm -f $seqres.full

      local mkfs_opts=$1
      local mount_opts=$2

      _scratch_mkfs $mkfs_opts >>$seqres.full 2>&1
      _scratch_mount $mount_opts

      # File bar, the source for all the following clone operations, consists
      # of a single inline extent (50 bytes).
      $XFS_IO_PROG -f -c "pwrite -S 0xbb 0 50" $SCRATCH_MNT/bar \
          | _filter_xfs_io

      # Test cloning into a file with an extent (non-inlined) where the
      # destination offset overlaps that extent. It should not be possible to
      # clone the inline extent from file bar into this file.
      $XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 16K" $SCRATCH_MNT/foo \
          | _filter_xfs_io
      $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo

      # Doing IO against any range in the first 4K of the file should work.
      # Due to a past clone ioctl bug which allowed cloning the inline extent,
      # these operations resulted in EIO errors.
      echo "File foo data after clone operation:"
      # All bytes should have the value 0xaa (clone operation failed and did
      # not modify our file).
      od -t x1 $SCRATCH_MNT/foo
      $XFS_IO_PROG -c "pwrite -S 0xcc 0 100" $SCRATCH_MNT/foo | _filter_xfs_io

      # Test cloning the inline extent against a file which has a hole in its
      # first 4K followed by a non-inlined extent. It should not be possible
      # as well to clone the inline extent from file bar into this file.
      $XFS_IO_PROG -f -c "pwrite -S 0xdd 4K 12K" $SCRATCH_MNT/foo2 \
          | _filter_xfs_io
      $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo2

      # Doing IO against any range in the first 4K of the file should work.
      # Due to a past clone ioctl bug which allowed cloning the inline extent,
      # these operations resulted in EIO errors.
      echo "File foo2 data after clone operation:"
      # All bytes should have the value 0x00 (clone operation failed and did
      # not modify our file).
      od -t x1 $SCRATCH_MNT/foo2
      $XFS_IO_PROG -c "pwrite -S 0xee 0 90" $SCRATCH_MNT/foo2 | _filter_xfs_io

      # Test cloning the inline extent against a file which has a size of zero
      # but has a prealloc extent. It should not be possible as well to clone
      # the inline extent from file bar into this file.
      $XFS_IO_PROG -f -c "falloc -k 0 1M" $SCRATCH_MNT/foo3 | _filter_xfs_io
      $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo3

      # Doing IO against any range in the first 4K of the file should work.
      # Due to a past clone ioctl bug which allowed cloning the inline extent,
      # these operations resulted in EIO errors.
      echo "First 50 bytes of foo3 after clone operation:"
      # Should not be able to read any bytes, file has 0 bytes i_size (the
      # clone operation failed and did not modify our file).
      od -t x1 $SCRATCH_MNT/foo3
      $XFS_IO_PROG -c "pwrite -S 0xff 0 90" $SCRATCH_MNT/foo3 | _filter_xfs_io

      # Test cloning the inline extent against a file which consists of a
      # single inline extent that has a size not greater than the size of
      # bar's inline extent (40 < 50).
      # It should be possible to do the extent cloning from bar to this file.
      $XFS_IO_PROG -f -c "pwrite -S 0x01 0 40" $SCRATCH_MNT/foo4 \
          | _filter_xfs_io
      $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo4

      # Doing IO against any range in the first 4K of the file should work.
      echo "File foo4 data after clone operation:"
      # Must match file bar's content.
      od -t x1 $SCRATCH_MNT/foo4
      $XFS_IO_PROG -c "pwrite -S 0x02 0 90" $SCRATCH_MNT/foo4 | _filter_xfs_io

      # Test cloning the inline extent against a file which consists of a
      # single inline extent that has a size greater than the size of bar's
      # inline extent (60 > 50).
      # It should not be possible to clone the inline extent from file bar
      # into this file.
      $XFS_IO_PROG -f -c "pwrite -S 0x03 0 60" $SCRATCH_MNT/foo5 \
          | _filter_xfs_io
      $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo5

      # Reading the file should not fail.
      echo "File foo5 data after clone operation:"
      # Must have a size of 60 bytes, with all bytes having a value of 0x03
      # (the clone operation failed and did not modify our file).
      od -t x1 $SCRATCH_MNT/foo5

      # Test cloning the inline extent against a file which has no extents but
      # has a size greater than bar's inline extent (16K > 50).
      # It should not be possible to clone the inline extent from file bar
      # into this file.
      $XFS_IO_PROG -f -c "truncate 16K" $SCRATCH_MNT/foo6 | _filter_xfs_io
      $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo6

      # Reading the file should not fail.
      echo "File foo6 data after clone operation:"
      # Must have a size of 16K, with all bytes having a value of 0x00 (the
      # clone operation failed and did not modify our file).
      od -t x1 $SCRATCH_MNT/foo6

      # Test cloning the inline extent against a file which has no extents but
      # has a size not greater than bar's inline extent (30 < 50).
      # It should be possible to clone the inline extent from file bar into
      # this file.
      $XFS_IO_PROG -f -c "truncate 30" $SCRATCH_MNT/foo7 | _filter_xfs_io
      $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo7

      # Reading the file should not fail.
      echo "File foo7 data after clone operation:"
      # Must have a size of 50 bytes, with all bytes having a value of 0xbb.
      od -t x1 $SCRATCH_MNT/foo7

      # Test cloning the inline extent against a file which has a size not
      # greater than the size of bar's inline extent (20 < 50) but has
      # a prealloc extent that goes beyond the file's size. It should not be
      # possible to clone the inline extent from bar into this file.
      $XFS_IO_PROG -f -c "falloc -k 0 1M" \
                      -c "pwrite -S 0x88 0 20" \
                      $SCRATCH_MNT/foo8 | _filter_xfs_io
      $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo8

      echo "File foo8 data after clone operation:"
      # Must have a size of 20 bytes, with all bytes having a value of 0x88
      # (the clone operation did not modify our file).
      od -t x1 $SCRATCH_MNT/foo8


  echo -e "\nTesting without compression and without the no-holes feature...\n"

  echo -e "\nTesting with compression and without the no-holes feature...\n"
  test_cloning_inline_extents "" "-o compress"

  echo -e "\nTesting without compression and with the no-holes feature...\n"
  test_cloning_inline_extents "-O no-holes" ""

  echo -e "\nTesting with compression and with the no-holes feature...\n"
  test_cloning_inline_extents "-O no-holes" "-o compress"


Signed-off-by: Filipe Manana <>
[bwh: Backported to 3.2:
 - Adjust parameters to btrfs_drop_extents()
 - Drop use of ASSERT()
 - Keep using BUG_ON() for other error cases, as there is no
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: added helper btrfs_next_item()
Jan Schmidt [Tue, 22 Nov 2011 14:14:33 +0000 (15:14 +0100)]
Btrfs: added helper btrfs_next_item()

commit c7d22a3c3cdb73d8a0151e2ccc8cf4a48c48310b upstream.

btrfs_next_item() makes the btrfs path point to the next item, crossing leaf
boundaries if needed.

Signed-off-by: Arne Jansen <>
Signed-off-by: Jan Schmidt <>
[bwh: Dependency of the following fix]
Signed-off-by: Ben Hutchings <>
6 years agopacket: fix match_fanout_group()
Eric Dumazet [Fri, 9 Oct 2015 18:29:32 +0000 (11:29 -0700)]
packet: fix match_fanout_group()

commit 161642e24fee40fba2c5bc2ceacc00d118a22d65 upstream.

Recent TCP listener patches exposed a prior af_packet bug :
match_fanout_group() blindly assumes it is always safe
to cast sk to a packet socket to compare fanout with af_packet_priv

But SYNACK packets can be sent while attached to request_sock, which
are smaller than a "struct sock".

We can read non existent memory and crash.

Fixes: c0de08d04215 ("af_packet: don't emit packet on orig fanout group")
Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener")
Signed-off-by: Eric Dumazet <>
Cc: Willem de Bruijn <>
Cc: Eric Leblond <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agodevres: fix a for loop bounds check
Dan Carpenter [Mon, 21 Sep 2015 16:21:51 +0000 (19:21 +0300)]
devres: fix a for loop bounds check

commit 1f35d04a02a652f14566f875aef3a6f2af4cb77b upstream.

The iomap[] array has PCIM_IOMAP_MAX (6) elements and not
DEVICE_COUNT_RESOURCE (16).  This bug was found using a static checker.
It may be that the "if (!(mask & (1 << i)))" check means we never
actually go past the end of the array in real life.

Fixes: ec04b075843d ('iomap: implement pcim_iounmap_regions()')
Signed-off-by: Dan Carpenter <>
Acked-by: Tejun Heo <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agomtd: mtdpart: fix add_mtd_partitions error path
Boris BREZILLON [Thu, 30 Jul 2015 10:18:03 +0000 (12:18 +0200)]
mtd: mtdpart: fix add_mtd_partitions error path

commit e5bae86797141e4a95e42d825f737cb36d7b8c37 upstream.

If we fail to allocate a partition structure in the middle of the partition
creation process, the already allocated partitions are never removed, which
means they are still present in the partition list and their resources are
never freed.

Signed-off-by: Boris Brezillon <>
Signed-off-by: Brian Norris <>
Signed-off-by: Ben Hutchings <>
6 years agomwifiex: fix mwifiex_rdeeprom_read()
Dan Carpenter [Mon, 21 Sep 2015 16:19:53 +0000 (19:19 +0300)]
mwifiex: fix mwifiex_rdeeprom_read()

commit 1f9c6e1bc1ba5f8a10fcd6e99d170954d7c6d382 upstream.

There were several bugs here.

1)  The done label was in the wrong place so we didn't copy any
    information out when there was no command given.

2)  We were using PAGE_SIZE as the size of the buffer instead of
    "PAGE_SIZE - pos".

3)  snprintf() returns the number of characters that would have been
    printed if there were enough space.  If there was not enough space
    (and we had fixed the memory corruption bug #2) then it would result
    in an information leak when we do simple_read_from_buffer().  I've
    changed it to use scnprintf() instead.

I also removed the initialization at the start of the function, because
I thought it made the code a little more clear.

Fixes: 5e6e3a92b9a4 ('wireless: mwifiex: initial commit for Marvell mwifiex driver')
Signed-off-by: Dan Carpenter <>
Acked-by: Amitkumar Karwar <>
Signed-off-by: Kalle Valo <>
Signed-off-by: Ben Hutchings <>
6 years agowm831x_power: Use IRQF_ONESHOT to request threaded IRQs
Valentin Rothberg [Tue, 22 Sep 2015 17:00:40 +0000 (19:00 +0200)]
wm831x_power: Use IRQF_ONESHOT to request threaded IRQs

commit 90adf98d9530054b8e665ba5a928de4307231d84 upstream.

Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail.

scripts/coccinelle/misc/irqf_oneshot.cocci detected this issue.

Fixes: b5874f33bbaf ("wm831x_power: Use genirq")
Signed-off-by: Valentin Rothberg <>
Signed-off-by: Sebastian Reichel <>
Signed-off-by: Ben Hutchings <>
6 years agoHID: core: Avoid uninitialized buffer access
Richard Purdie [Fri, 18 Sep 2015 23:31:33 +0000 (16:31 -0700)]
HID: core: Avoid uninitialized buffer access

commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.

hid_connect adds various strings to the buffer but they're all
conditional. You can find circumstances where nothing would be written
to it but the kernel will still print the supposedly empty buffer with
printk. This leads to corruption on the console/in the logs.

Ensure buf is initialized to an empty string.

Signed-off-by: Richard Purdie <>
[dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
Cc: Jiri Kosina <>
Signed-off-by: Darren Hart <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Ben Hutchings <>
6 years agomac80211: fix driver RSSI event calculations
Johannes Berg [Fri, 28 Aug 2015 08:52:53 +0000 (10:52 +0200)]
mac80211: fix driver RSSI event calculations

commit 8ec6d97871f37e4743678ea4a455bd59580aa0f4 upstream.

The ifmgd->ave_beacon_signal value cannot be taken as is for
comparisons, it must be divided by since it's represented
like that for better accuracy of the EWMA calculations. This
would lead to invalid driver RSSI events. Fix the used value.

Fixes: 615f7b9bb1f8 ("mac80211: add driver RSSI threshold events")
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
6 years agoPCI: Use function 0 VPD for identical functions, regular VPD for others
Alex Williamson [Wed, 16 Sep 2015 04:24:46 +0000 (22:24 -0600)]
PCI: Use function 0 VPD for identical functions, regular VPD for others

commit da2d03ea27f6ed9d2005a67b20dd021ddacf1e4d upstream.

932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0")
added PCI_DEV_FLAGS_VPD_REF_F0.  Previously, we set the flag on every
non-zero function of quirked devices.  If a function turned out to be
different from function 0, i.e., it had a different class, vendor ID, or
device ID, the flag remained set but we didn't make VPD accessible at all.

Flip this around so we only set PCI_DEV_FLAGS_VPD_REF_F0 for functions that
are identical to function 0, and allow regular VPD access for any other

[bhelgaas: changelog, stable tag]
Fixes: 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0")
Signed-off-by: Alex Williamson <>
Signed-off-by: Bjorn Helgaas <>
Acked-by: Myron Stowe <>
Acked-by: Mark Rustad <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoPCI: Fix devfn for VPD access through function 0
Alex Williamson [Tue, 15 Sep 2015 17:17:21 +0000 (11:17 -0600)]
PCI: Fix devfn for VPD access through function 0

commit 9d9240756e63dd87d6cbf5da8b98ceb8f8192b55 upstream.

Commit 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function
0") passes PCI_SLOT(devfn) for the devfn parameter of pci_get_slot().
Generally this works because we're fairly well guaranteed that a PCIe
device is at slot address 0, but for the general case, including
conventional PCI, it's incorrect.  We need to get the slot and then convert
it back into a devfn.

Fixes: 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0")
Signed-off-by: Alex Williamson <>
Signed-off-by: Bjorn Helgaas <>
Acked-by: Myron Stowe <>
Acked-by: Mark Rustad <>
Signed-off-by: Ben Hutchings <>
6 years agoLinux 3.2.73 v3.2.73
Ben Hutchings [Tue, 17 Nov 2015 15:54:47 +0000 (15:54 +0000)]
Linux 3.2.73

6 years agoKEYS: Fix crash when attempt to garbage collect an uninstantiated keyring
David Howells [Thu, 15 Oct 2015 16:21:37 +0000 (17:21 +0100)]
KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring

commit f05819df10d7b09f6d1eb6f8534a8f68e5a4fe61 upstream.

The following sequence of commands:

    i=`keyctl add user a a @s`
    keyctl request2 keyring foo bar @t
    keyctl unlink $i @s

tries to invoke an upcall to instantiate a keyring if one doesn't already
exist by that name within the user's keyring set.  However, if the upcall
fails, the code sets keyring->type_data.reject_error to -ENOKEY or some
other error code.  When the key is garbage collected, the key destroy
function is called unconditionally and keyring_destroy() uses list_empty()
on keyring-> - which is in a union with reject_error.
Subsequently, the kernel tries to unlink the keyring from the keyring names
list - which oopses like this:

BUG: unable to handle kernel paging request at 00000000ffffff8a
IP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88
Workqueue: events key_garbage_collector
RIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88
RSP: 0018:ffff88003e2f3d30  EFLAGS: 00010203
RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40
RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000
R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900
R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000
CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0
Call Trace:
 [<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f
 [<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351
 [<ffffffff8105ec9b>] process_one_work+0x28e/0x547
 [<ffffffff8105fd17>] worker_thread+0x26e/0x361
 [<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8
 [<ffffffff810648ad>] kthread+0xf3/0xfb
 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
 [<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70
 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2

Note the value in RAX.  This is a 32-bit representation of -ENOKEY.

The solution is to only call ->destroy() if the key was successfully

Reported-by: Dmitry Vyukov <>
Signed-off-by: David Howells <>
Tested-by: Dmitry Vyukov <>
[carnil: Backported for 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoKEYS: Fix race between key destruction and finding a keyring by name
David Howells [Fri, 25 Sep 2015 15:30:08 +0000 (16:30 +0100)]
KEYS: Fix race between key destruction and finding a keyring by name

commit 94c4554ba07adbdde396748ee7ae01e86cf2d8d7 upstream.

There appears to be a race between:

 (1) key_gc_unused_keys() which frees key->security and then calls
     keyring_destroy() to unlink the name from the name list

 (2) find_keyring_by_name() which calls key_permission(), thus accessing
     key->security, on a key before checking to see whether the key usage is 0
     (ie. the key is dead and might be cleaned up).

Fix this by calling ->destroy() before cleaning up the core key data -
including key->security.

Reported-by: Petr Matousek <>
Signed-off-by: David Howells <>
[carnil: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoKVM: x86: work around infinite loop in microcode when #AC is delivered
Eric Northup [Tue, 3 Nov 2015 17:03:53 +0000 (18:03 +0100)]
KVM: x86: work around infinite loop in microcode when #AC is delivered

commit 54a20552e1eae07aa240fa370a0293e006b5faed upstream.

It was found that a guest can DoS a host by triggering an infinite
stream of "alignment check" (#AC) exceptions.  This causes the
microcode to enter an infinite loop where the core never receives
another interrupt.  The host kernel panics pretty quickly due to the
effects (CVE-2015-5307).

Signed-off-by: Eric Northup <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2:
 - Add definition of AC_VECTOR
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
6 years agoFailing to send a CLOSE if file is opened WRONLY and server reboots on a 4.x mount
Olga Kornievskaia [Mon, 14 Sep 2015 23:54:36 +0000 (19:54 -0400)]
Failing to send a CLOSE if file is opened WRONLY and server reboots on a 4.x mount

commit a41cbe86df3afbc82311a1640e20858c0cd7e065 upstream.

A test case is as the description says:
open(foobar, O_WRONLY);
sleep()  --> reboot the server

The bug is because in nfs4state.c in nfs4_reclaim_open_state() a few
line before going to restart, there is
clear_bit(NFS4CLNT_RECLAIM_NOGRACE, &state->flags).

NFS4CLNT_RECLAIM_NOGRACE is a flag for the client states not open
owner states. Value of NFS4CLNT_RECLAIM_NOGRACE is 4 which is the
value of NFS_O_WRONLY_STATE in nfs4_state->flags. So clearing it wipes
out state and when we go to close it, “call_close” doesn’t get set as
state flag is not set and CLOSE doesn’t go on the wire.

Signed-off-by: Olga Kornievskaia <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Ben Hutchings <>
6 years agoasix: Do full reset during ax88772_bind
Charles Keepax [Thu, 6 Nov 2014 15:49:41 +0000 (15:49 +0000)]
asix: Do full reset during ax88772_bind

[ Upstream commit 436c2a5036b6ffe813310df2cf327d3b69be0734 ]

commit 3cc81d85ee01 ("asix: Don't reset PHY on if_up for ASIX 88772")
causes the ethernet on Arndale to no longer function. This appears to
be because the Arndale ethernet requires a full reset before it will
function correctly, however simply reverting the above patch causes
problems with ethtool settings getting reset.

It seems the problem is that the ethernet is not properly reset during
bind, and indeed the code in ax88772_bind that resets the device is a
very small subset of the actual ax88772_reset function. This patch uses
ax88772_reset in place of the existing reset code in ax88772_bind which
removes some code duplication and fixes the ethernet on Arndale.

It is still possible that the original patch causes some issues with
suspend and resume but that seems like a separate issue and I haven't
had a chance to test that yet.

Signed-off-by: Charles Keepax <>
Tested-by: Riku Voipio <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoasix: Don't reset PHY on if_up for ASIX 88772
Michel Stam [Thu, 2 Oct 2014 08:22:02 +0000 (10:22 +0200)]
asix: Don't reset PHY on if_up for ASIX 88772

[ Upstream commit 3cc81d85ee01e5a0b7ea2f4190e2ed1165f53c31 ]

I've noticed every time the interface is set to 'up,', the kernel
reports that the link speed is set to 100 Mbps/Full Duplex, even
when ethtool is used to set autonegotiation to 'off', half
duplex, 10 Mbps.
It can be tested by:
 ifconfig eth0 down
 ethtool -s eth0 autoneg off speed 10 duplex half
 ifconfig eth0 up

Then checking 'dmesg' for the link speed.

Signed-off-by: Michel Stam <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoethtool: Use kcalloc instead of kmalloc for ethtool_get_strings
Joe Perches [Wed, 14 Oct 2015 08:09:40 +0000 (01:09 -0700)]
ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings

[ Upstream commit 077cb37fcf6f00a45f375161200b5ee0cd4e937b ]

It seems that kernel memory can leak into userspace by a
kmalloc, ethtool_get_strings, then copy_to_user sequence.

Avoid this by using kcalloc to zero fill the copied buffer.

Signed-off-by: Joe Perches <>
Acked-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoskbuff: Fix skb checksum partial check.
Pravin B Shelar [Tue, 29 Sep 2015 00:24:25 +0000 (17:24 -0700)]
skbuff: Fix skb checksum partial check.

[ Upstream commit 31b33dfb0a144469dd805514c9e63f4993729a48 ]

Earlier patch 6ae459bda tried to detect void ckecksum partial
skb by comparing pull length to checksum offset. But it does
not work for all cases since checksum-offset depends on
updates to skb->data.

Following patch fixes it by validating checksum start offset
after skb-data pointer is updated. Negative value of checksum
offset start means there is no need to checksum.

Fixes: 6ae459bda ("skbuff: Fix skb checksum flag on skb pull")
Reported-by: Andrew Vagin <>
Signed-off-by: Pravin B Shelar <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoskbuff: Fix skb checksum flag on skb pull
Pravin B Shelar [Tue, 22 Sep 2015 19:57:53 +0000 (12:57 -0700)]
skbuff: Fix skb checksum flag on skb pull

[ Upstream commit 6ae459bdaaeebc632b16e54dcbabb490c6931d61 ]

VXLAN device can receive skb with checksum partial. But the checksum
offset could be in outer header which is pulled on receive. This results
in negative checksum offset for the skb. Such skb can cause the assert
failure in skb_checksum_help(). Following patch fixes the bug by setting
checksum-none while pulling outer header.

Following is the kernel panic msg from old kernel hitting the bug.

------------[ cut here ]------------
kernel BUG at net/core/dev.c:1906!
RIP: 0010:[<ffffffff81518034>] skb_checksum_help+0x144/0x150
Call Trace:
[<ffffffffa0164c28>] queue_userspace_packet+0x408/0x470 [openvswitch]
[<ffffffffa016614d>] ovs_dp_upcall+0x5d/0x60 [openvswitch]
[<ffffffffa0166236>] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch]
[<ffffffffa016629b>] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch]
[<ffffffffa016c51a>] ovs_vport_receive+0x2a/0x30 [openvswitch]
[<ffffffffa0171383>] vxlan_rcv+0x53/0x60 [openvswitch]
[<ffffffffa01734cb>] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
[<ffffffff8157addc>] udp_queue_rcv_skb+0x2dc/0x3b0
[<ffffffff8157b56f>] __udp4_lib_rcv+0x1cf/0x6c0
[<ffffffff8157ba7a>] udp_rcv+0x1a/0x20
[<ffffffff8154fdbd>] ip_local_deliver_finish+0xdd/0x280
[<ffffffff81550128>] ip_local_deliver+0x88/0x90
[<ffffffff8154fa7d>] ip_rcv_finish+0x10d/0x370
[<ffffffff81550365>] ip_rcv+0x235/0x300
[<ffffffff8151ba1d>] __netif_receive_skb+0x55d/0x620
[<ffffffff8151c360>] netif_receive_skb+0x80/0x90
[<ffffffff81459935>] virtnet_poll+0x555/0x6f0
[<ffffffff8151cd04>] net_rx_action+0x134/0x290
[<ffffffff810683d8>] __do_softirq+0xa8/0x210
[<ffffffff8162fe6c>] call_softirq+0x1c/0x30
[<ffffffff810161a5>] do_softirq+0x65/0xa0
[<ffffffff810687be>] irq_exit+0x8e/0xb0
[<ffffffff81630733>] do_IRQ+0x63/0xe0
[<ffffffff81625f2e>] common_interrupt+0x6e/0x6e

Reported-by: Anupam Chanda <>
Signed-off-by: Pravin B Shelar <>
Acked-by: Tom Herbert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agonet: add length argument to skb_copy_and_csum_datagram_iovec
Sabrina Dubroca [Thu, 15 Oct 2015 12:25:03 +0000 (14:25 +0200)]
net: add length argument to skb_copy_and_csum_datagram_iovec

Without this length argument, we can read past the end of the iovec in
memcpy_toiovec because we have no way of knowing the total length of the
iovec's buffers.

This is needed for stable kernels where 89c22d8c3b27 ("net: Fix skb
csum races when peeking") has been backported but that don't have the
ioviter conversion, which is almost all the stable trees <= 3.18.

This also fixes a kernel crash for NFS servers when the client uses
 -onfsvers=3,proto=udp to mount the export.

Signed-off-by: Sabrina Dubroca <>
Reviewed-by: Hannes Frederic Sowa <>
[bwh: Backported to 3.2: adjust context in include/linux/skbuff.h]
Signed-off-by: Ben Hutchings <>
6 years agosched: declare pid_alive as inline
Richard Guy Briggs [Sun, 16 Mar 2014 18:00:19 +0000 (14:00 -0400)]
sched: declare pid_alive as inline

commit 80e0b6e8a001361316a2d62b748fe677ec46b860 upstream.

We accidentally declared pid_alive without any extern/inline connotation.
Some platforms were fine with this, some like ia64 and mips were very angry.
If the function is inline, the prototype should be inline!

on ia64:
include/linux/sched.h:1718: warning: 'pid_alive' declared inline after
being called

Signed-off-by: Richard Guy Briggs <>
Signed-off-by: Eric Paris <>
Signed-off-by: Ben Hutchings <>
Cc: Neal Gompa <>
6 years agomvsas: Fix NULL pointer dereference in mvs_slot_task_free
Dāvis Mosāns [Fri, 21 Aug 2015 04:29:22 +0000 (07:29 +0300)]
mvsas: Fix NULL pointer dereference in mvs_slot_task_free

commit 2280521719e81919283b82902ac24058f87dfc1b upstream.

When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays
NULL but it's later used in mvs_abort_task as slot which is passed
to mvs_slot_task_free causing NULL pointer dereference.

Just return from mvs_slot_task_free when passed with NULL slot.

Signed-off-by: Dāvis Mosāns <>
Reviewed-by: Tomas Henzl <>
Reviewed-by: Johannes Thumshirn <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
6 years agomd/raid10: don't clear bitmap bit when bad-block-list write fails.
NeilBrown [Sat, 24 Oct 2015 05:23:48 +0000 (16:23 +1100)]
md/raid10: don't clear bitmap bit when bad-block-list write fails.

commit c340702ca26a628832fade4f133d8160a55c29cc upstream.

When a write fails and a bad-block-list is present, we can
update the bad-block-list instead of writing the data.  If
this succeeds then it is OK clear the relevant bitmap-bit as
no further 'sync' of the block is needed.

However if writing the bad-block-list fails then we need to
treat the write as failed and particularly must not clear
the bitmap bit.  Otherwise the device can be re-added (after
any hardware connection issues are resolved) and because the
relevant bit in the bitmap is clear, that block will not be
resynced.  This leads to data corruption.

We already delay the final bio_endio() on the write until
the bad-block-list is written so that when the write
returns: either that data is safe, the bad-block record is
safe, or the fact that the device is faulty is safe.
However we *don't* delay the clearing of the bitmap, so the
bitmap bit can be recorded as cleared before we know if the
bad-block-list was written safely.

So: delay that until the write really is safe.
i.e. move the call to close_write() until just before
calling bio_endio(), and recheck the 'is array degraded'
status before making that call.

This bug goes back to v3.1 when bad-block-lists were
introduced, though it only affects arrays created with
mdadm-3.3 or later as only those have bad-block lists.

Backports will require at least
Commit: 95af587e95aa ("md/raid10: ensure device failure recorded before write request returns.")
as well.  I'll send that to 'stable' separately.

Note that of the two tests of R10BIO_WriteError that this
patch adds, the first is certain to fail and the second is
certain to succeed.  However doing it this way makes the
patch more obviously correct.  I will tidy the code up in a
future merge window.

Reported-by: Nate Dailey <>
Fixes: bd870a16c594 ("md/raid10:  Handle write errors by updating badblock log.")
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
6 years agomd/raid10: ensure device failure recorded before write request returns.
NeilBrown [Fri, 14 Aug 2015 01:26:17 +0000 (11:26 +1000)]
md/raid10: ensure device failure recorded before write request returns.

commit 95af587e95aacb9cfda4a9641069a5244a540dc8 upstream.

When a write to one of the legs of a RAID10 fails, the failure is
recorded in the metadata of the other legs so that after a restart
the data on the failed drive wont be trusted even if that drive seems
to be working again (maybe a cable was unplugged).

Currently there is no interlock between the write request completing
and the metadata update.  So it is possible that the write will
complete, the app will confirm success in some way, and then the
machine will crash before the metadata update completes.

This is an extremely small hole for a racy to fit in, but it is
theoretically possible and so should be closed.

 - set MD_CHANGE_PENDING when requesting a metadata update for a
   failed device, so we can know with certainty when it completes
 - queue requests that experienced an error on a new queue which
   is only processed after the metadata update completes
 - call raid_end_bio_io() on bios in that queue when the time comes.

Signed-off-by: NeilBrown <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomd/raid1: don't clear bitmap bit when bad-block-list write fails.
NeilBrown [Sat, 24 Oct 2015 05:02:16 +0000 (16:02 +1100)]
md/raid1: don't clear bitmap bit when bad-block-list write fails.

commit bd8688a199b864944bf62eebed0ca13b46249453 upstream.

When a write fails and a bad-block-list is present, we can
update the bad-block-list instead of writing the data.  If
this succeeds then it is OK clear the relevant bitmap-bit as
no further 'sync' of the block is needed.

However if writing the bad-block-list fails then we need to
treat the write as failed and particularly must not clear
the bitmap bit.  Otherwise the device can be re-added (after
any hardware connection issues are resolved) and because the
relevant bit in the bitmap is clear, that block will not be
resynced.  This leads to data corruption.

We already delay the final bio_endio() on the write until
the bad-block-list is written so that when the write
returns: either that data is safe, the bad-block record is
safe, or the fact that the device is faulty is safe.
However we *don't* delay the clearing of the bitmap, so the
bitmap bit can be recorded as cleared before we know if the
bad-block-list was written safely.

So: delay that until the write really is safe.
i.e. move the call to close_write() until just before
calling bio_endio(), and recheck the 'is array degraded'
status before making that call.

This bug goes back to v3.1 when bad-block-lists were
introduced, though it only affects arrays created with
mdadm-3.3 or later as only those have bad-block lists.

Backports will require at least
Commit: 55ce74d4bfe1 ("md/raid1: ensure device failure recorded before write request returns.")
as well.  I'll send that to 'stable' separately.

Note that of the two tests of R1BIO_WriteError that this
patch adds, the first is certain to fail and the second is
certain to succeed.  However doing it this way makes the
patch more obviously correct.  I will tidy the code up in a
future merge window.

Reported-and-tested-by: Nate Dailey <>
Cc: Jes Sorensen <>
Fixes: cd5ff9a16f08 ("md/raid1:  Handle write errors by updating badblock log.")
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
6 years agomd/raid1: ensure device failure recorded before write request returns.
NeilBrown [Fri, 14 Aug 2015 01:11:10 +0000 (11:11 +1000)]
md/raid1: ensure device failure recorded before write request returns.

commit 55ce74d4bfe1b9444436264c637f39a152d1e5ac upstream.

When a write to one of the legs of a RAID1 fails, the failure is
recorded in the metadata of the other leg(s) so that after a restart
the data on the failed drive wont be trusted even if that drive seems
to be working again  (maybe a cable was unplugged).

Similarly when we record a bad-block in response to a write failure,
we must not let the write complete until the bad-block update is safe.

Currently there is no interlock between the write request completing
and the metadata update.  So it is possible that the write will
complete, the app will confirm success in some way, and then the
machine will crash before the metadata update completes.

This is an extremely small hole for a racy to fit in, but it is
theoretically possible and so should be closed.

 - set MD_CHANGE_PENDING when requesting a metadata update for a
   failed device, so we can know with certainty when it completes
 - queue requests that experienced an error on a new queue which
   is only processed after the metadata update completes
 - call raid_end_bio_io() on bios in that queue when the time comes.

Signed-off-by: NeilBrown <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agodm btree: fix leak of bufio-backed block in btree_split_beneath error path
Mike Snitzer [Thu, 22 Oct 2015 14:56:40 +0000 (10:56 -0400)]
dm btree: fix leak of bufio-backed block in btree_split_beneath error path

commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be upstream.

btree_split_beneath()'s error path had an outstanding FIXME that speaks
directly to the potential for _not_ cleaning up a previously allocated
bufio-backed block.

Fix this by releasing the previously allocated bufio block using

Reported-by: Mikulas Patocka <>
Signed-off-by: Mike Snitzer <>
Acked-by: Joe Thornber <>
Signed-off-by: Ben Hutchings <>
6 years agodm btree remove: fix a bug when rebalancing nodes after removal
Joe Thornber [Wed, 21 Oct 2015 17:36:49 +0000 (18:36 +0100)]
dm btree remove: fix a bug when rebalancing nodes after removal

commit 2871c69e025e8bc507651d5a9cf81a8a7da9d24b upstream.

Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't
a complete fix for redistribute3().

The redistribute3 function takes 3 btree nodes and shares out the entries
evenly between them.  If the three nodes in total contained
(MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting
rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in
the center.

Fix this issue by being more careful about calculating the target number
of entries for the left and right nodes.

Unit tested in userspace using this program:

Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
6 years agoppp: fix pppoe_dev deletion condition in pppoe_release()
Guillaume Nault [Thu, 22 Oct 2015 14:57:10 +0000 (16:57 +0200)]
ppp: fix pppoe_dev deletion condition in pppoe_release()

commit 1acea4f6ce1b1c0941438aca75dd2e5c6b09db60 upstream.

We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev.
PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is
NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies
(po->pppoe_dev != NULL).
Since we're releasing a PPPoE socket, we want to release the pppoe_dev
if it exists and reset sk_state to PPPOX_DEAD, no matter the previous
value of sk_state. So we can just check for po->pppoe_dev and avoid any
assumption on sk->sk_state.

Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agomm: make sendfile(2) killable
Jan Kara [Thu, 22 Oct 2015 20:32:21 +0000 (13:32 -0700)]
mm: make sendfile(2) killable

commit 296291cdd1629c308114504b850dc343eabc2782 upstream.

Currently a simple program below issues a sendfile(2) system call which
takes about 62 days to complete in my test KVM instance.

        int fd;
        off_t off = 0;

        fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644);
        ftruncate(fd, 2);
        lseek(fd, 0, SEEK_END);
        sendfile(fd, fd, &off, 0xfffffff);

Now you should not ask kernel to do a stupid stuff like copying 256MB in
2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin
should have a way to stop you.

We actually do have a check for fatal_signal_pending() in
generic_perform_write() which triggers in this path however because we
always succeed in writing something before the check is done, we return
value > 0 from generic_perform_write() and thus the information about
signal gets lost.

Fix the problem by doing the signal check before writing anything.  That
way generic_perform_write() returns -EINTR, the error gets propagated up
and the sendfile loop terminates early.

Signed-off-by: Jan Kara <>
Reported-by: Dmitry Vyukov <>
Cc: Al Viro <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agopowerpc/rtas: Validate rtas.entry before calling enter_rtas()
Vasant Hegde [Fri, 16 Oct 2015 10:23:29 +0000 (15:53 +0530)]
powerpc/rtas: Validate rtas.entry before calling enter_rtas()

commit 8832317f662c06f5c06e638f57bfe89a71c9b266 upstream.

Currently we do not validate rtas.entry before calling enter_rtas(). This
leads to a kernel oops when user space calls rtas system call on a powernv
platform (see below). This patch adds code to validate rtas.entry before
making enter_rtas() call.

  Oops: Exception in kernel mode, sig: 4 [#1]
  task: c000000004294b80 ti: c0000007e1a78000 task.ti: c0000007e1a78000
  NIP: 0000000000000000 LR: 0000000000009c14 CTR: c000000000423140
  REGS: c0000007e1a7b920 TRAP: 0e40   Not tainted  (3.18.17-340.el7_1.pkvm3_1_0.2400.1.ppc64le)
  MSR: 1000000000081000 <HV,ME>  CR: 00000000  XER: 00000000
  CFAR: c000000000009c0c SOFTE: 0
  NIP [0000000000000000]           (null)
  LR [0000000000009c14] 0x9c14
  Call Trace:
  [c0000007e1a7bba0] [c00000000041a7f4] avc_has_perm_noaudit+0x54/0x110 (unreliable)
  [c0000007e1a7bd80] [c00000000002ddc0] ppc_rtas+0x150/0x2d0
  [c0000007e1a7be30] [c000000000009358] syscall_exit+0x0/0x98

Fixes: 55190f88789a ("powerpc: Add skeleton PowerNV platform")
Reported-by: NAGESWARA R. SASTRY <>
Signed-off-by: Vasant Hegde <>
[mpe: Reword change log, trim oops, and add stable + fixes]
Signed-off-by: Michael Ellerman <>
Signed-off-by: Ben Hutchings <>
6 years agodrm/nouveau/gem: return only valid domain when there's only one
Ilia Mirkin [Tue, 20 Oct 2015 05:15:39 +0000 (01:15 -0400)]
drm/nouveau/gem: return only valid domain when there's only one

commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 upstream.

On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.

This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.

Signed-off-by: Ilia Mirkin <>
Signed-off-by: Ben Skeggs <>
Signed-off-by: Ben Hutchings <>
6 years agoIB/cm: Fix rb-tree duplicate free and use-after-free
Doron Tsur [Sun, 11 Oct 2015 12:58:17 +0000 (15:58 +0300)]
IB/cm: Fix rb-tree duplicate free and use-after-free

commit 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4 upstream.

ib_send_cm_sidr_rep could sometimes erase the node from the sidr
(depending on errors in the process). Since ib_send_cm_sidr_rep is
called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv
could be either erased from the rb_tree twice or not erased at all.
Fixing that by making sure it's erased only once before freeing

Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation')
Signed-off-by: Doron Tsur <>
Signed-off-by: Matan Barak <>
Signed-off-by: Doug Ledford <>
Signed-off-by: Ben Hutchings <>
6 years agoASoC: wm8904: Correct number of EQ registers
Charles Keepax [Tue, 20 Oct 2015 09:25:58 +0000 (10:25 +0100)]
ASoC: wm8904: Correct number of EQ registers

commit 97aff2c03a1e4d343266adadb52313613efb027f upstream.

There are 24 EQ registers not 25, I suspect this bug came about because
the registers start at EQ1 not zero. The bug is relatively harmless as
the extra register written is an unused one.

Signed-off-by: Charles Keepax <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agocrypto: api - Only abort operations on fatal signal
Herbert Xu [Mon, 19 Oct 2015 10:23:57 +0000 (18:23 +0800)]
crypto: api - Only abort operations on fatal signal

commit 3fc89adb9fa4beff31374a4bf50b3d099d88ae83 upstream.

Currently a number of Crypto API operations may fail when a signal
occurs.  This causes nasty problems as the caller of those operations
are often not in a good position to restart the operation.

In fact there is currently no need for those operations to be
interrupted by user signals at all.  All we need is for them to
be killable.

This patch replaces the relevant calls of signal_pending with
fatal_signal_pending, and wait_for_completion_interruptible with
wait_for_completion_killable, respectively.

Signed-off-by: Herbert Xu <>
[bwh: Backported to 3.2: drop change to crypto_user_skcipher_alg(), which
 we don't have]
Signed-off-by: Ben Hutchings <>
6 years agoxhci: Add spurious wakeup quirk for LynxPoint-LP controllers
Laura Abbott [Mon, 12 Oct 2015 08:30:13 +0000 (11:30 +0300)]
xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

commit fd7cd061adcf5f7503515ba52b6a724642a839c8 upstream.

We received several reports of systems rebooting and powering on
after an attempted shutdown. Testing showed that setting
quirk allowed the system to shutdown as expected for LynxPoint-LP
xHCI controllers. Set the quirk back.

Note that the quirk was originally introduced for LynxPoint and
LynxPoint-LP just for this same reason. See:

commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")

It was later limited to only concern HP machines as it caused
regression on some machines, see both bug and commit:

commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")

Later it was discovered that the powering on after shutdown
was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
machine suffered from spontaneous resume from S3 (which should
not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
to fix this then removed the SPURIOUS_WAKEUP flag usage completely.

commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")

Current understanding is that LynxPoint-LP (Haswell ULT) machines
need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
plain Lynxpoint (Haswell) machines may _not_ have the quirk
set otherwise they again will restart.

Signed-off-by: Laura Abbott <>
Cc: Takashi Iwai <>
Cc: Oliver Neukum <>
[Added more history to commit message -Mathias]
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoxhci: Switch Intel Lynx Point LP ports to EHCI on shutdown.
Denis Turischev [Fri, 25 Apr 2014 16:20:14 +0000 (19:20 +0300)]
xhci: Switch Intel Lynx Point LP ports to EHCI on shutdown.

commits c09ec25d3684cad74d851c0f028a495999591279 and
0a939993bff117d3657108ca13b011fc0378aedb upstream.

The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.

The bug can be avoided if the USB ports are switched back to EHCI on

This patch should be backported to stable kernels as old as 3.12,
that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
"xhci: Fix spurious wakeups after S5 on Haswell"

Signed-off-by: Denis Turischev <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Patch "xhci: Switch Intel Lynx Point ports to EHCI on shutdown."
commit c09ec25d3684cad74d851c0f028a495999591279 is not fully correct

It switches both Lynx Point and Lynx Point-LP ports to EHCI on shutdown.
On some Lynx Point machines it causes spurious interrupt,
which wake the system:

On Lynx Point-LP on the contrary switching ports to EHCI seems to be
necessary to fix these spurious interrupts.

Signed-off-by: Denis Turischev <>
Reported-by: Wulf Richartz <>
Cc: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Combined the above commits and backported to 3.2: adjust context to
 apply after "xhci: Limit the spurious wakeup fix only to HP machines" and
 "xhci: no switching back on non-ULT Haswell"]
Signed-off-by: Ben Hutchings <>
6 years agoxhci: handle no ping response error properly
Mathias Nyman [Mon, 12 Oct 2015 08:30:12 +0000 (11:30 +0300)]
xhci: handle no ping response error properly

commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 upstream.

If a host fails to wake up a isochronous SuperSpeed device from U1/U2
in time for a isoch transfer it will generate a "No ping response error"
Host will then move to the next transfer descriptor.

Handle this case in the same way as missed service errors, tag the
current TD as skipped and handle it on the next transfer event.

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoxhci: don't finish a TD if we get a short transfer event mid TD
Mathias Nyman [Mon, 12 Oct 2015 08:30:11 +0000 (11:30 +0300)]
xhci: don't finish a TD if we get a short transfer event mid TD

commit e210c422b6fdd2dc123bedc588f399aefd8bf9de upstream.

If the difference is big enough between the bytes asked and received
in a bulk transfer we can get a short transfer event pointing to a TRB in
the middle of the TD. We don't want to handle the TD yet as we will anyway
receive a new event for the last TRB in the TD.

Hold off from finishing the TD and removing it from the list until we
receive an event for the last TRB in the TD

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoiommu/vt-d: fix range computation when making room for large pages
Christian Zander [Wed, 10 Jun 2015 16:41:45 +0000 (09:41 -0700)]
iommu/vt-d: fix range computation when making room for large pages

commit ba2374fd2bf379f933773811fdb06cb6a5445f41 upstream.

In preparation for the installation of a large page, any small page
tables that may still exist in the target IOV address range are
removed.  However, if a scatter/gather list entry is large enough to
fit more than one large page, the address space for any subsequent
large pages is not cleared of conflicting small page tables.

This can cause legitimate mapping requests to fail with errors of the
form below, potentially followed by a series of IOMMU faults:

ERROR: DMA PTE for vPFN 0xfde00 already set (to 7f83a4003 not 7e9e00083)

In this example, a 4MiB scatter/gather list entry resulted in the
successful installation of a large page @ vPFN 0xfdc00, followed by
a failed attempt to install another large page @ vPFN 0xfde00, due to
the presence of a pointer to a small page table @ 0x7f83a4000.

To address this problem, compute the number of large pages that fit
into a given scatter/gather list entry, and use it to derive the
last vPFN covered by the large page(s).

Signed-off-by: Christian Zander <>
Signed-off-by: David Woodhouse <>
[bwh: Backported to 3.2:
 - Add the lvl_pages variable, added by an earlier commit upstream
 - Also change arguments to dma_pte_clear_range(), which is called by
   dma_pte_free_pagetable() upstream]
Signed-off-by: Ben Hutchings <>
6 years agocrypto: ahash - ensure statesize is non-zero
Russell King [Fri, 9 Oct 2015 19:43:33 +0000 (20:43 +0100)]
crypto: ahash - ensure statesize is non-zero

commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a upstream.

Unlike shash algorithms, ahash drivers must implement export
and import as their descriptors may contain hardware state and
cannot be exported as is.  Unfortunately some ahash drivers did
not provide them and end up causing crashes with algif_hash.

This patch adds a check to prevent these drivers from registering
ahash algorithms until they are fixed.

Signed-off-by: Russell King <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: hda - Fix inverted internal mic on Lenovo G50-80
David Henningsson [Tue, 13 Oct 2015 08:10:18 +0000 (10:10 +0200)]
ALSA: hda - Fix inverted internal mic on Lenovo G50-80

commit e8d65a8d985271a102f07c7456da5b86c19ffe16 upstream.

Add the appropriate quirk to indicate the Lenovo G50-80 has a stereo
mic input where one channel has reverse polarity.

Alsa-info available at:

Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoxen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)
Cathy Avery [Fri, 2 Oct 2015 13:35:01 +0000 (09:35 -0400)]
xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

commit a54c8f0f2d7df525ff997e2afe71866a1a013064 upstream.

xen-blkfront will crash if the check to talk_to_blkback()
in blkback_changed()(XenbusStateInitWait) returns an error.
The driver data is freed and info is set to NULL. Later during
the close process via talk_to_blkback's call to xenbus_dev_fatal()
the null pointer is passed to and dereference in blkfront_closing.

Signed-off-by: Cathy Avery <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
6 years ago3w-9xxx: don't unmap bounce buffered commands
Christoph Hellwig [Sat, 3 Oct 2015 17:16:07 +0000 (19:16 +0200)]
3w-9xxx: don't unmap bounce buffered commands

commit 15e3d5a285ab9283136dba34bbf72886d9146706 upstream.

3w controller don't dma map small single SGL entry commands but instead
bounce buffer them.  Add a helper to identify these commands and don't
call scsi_dma_unmap for them.

Based on an earlier patch from James Bottomley.

Fixes: 118c85 ("3w-9xxx: fix command completion race")
Reported-by: Tóth Attila <>
Tested-by: Tóth Attila <>
Signed-off-by: Christoph Hellwig <>
Acked-by: Adam Radford <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
6 years agosched/core: Fix TASK_DEAD race in finish_task_switch()
Peter Zijlstra [Tue, 29 Sep 2015 12:45:09 +0000 (14:45 +0200)]
sched/core: Fix TASK_DEAD race in finish_task_switch()

commit 95913d97914f44db2b81271c2e2ebd4d2ac2df83 upstream.

So the problem this patch is trying to address is as follows:

        CPU0                            CPU1

        context_switch(A, B)
                                          LOCK A->pi_lock
                                          A->on_cpu == 0
          prev_state = A->state  <-.
          WMB                      |
          A->on_cpu = 0;           |
          UNLOCK rq0->lock         |
                                   |    context_switch(C, A)
                                   `--  A->state = TASK_DEAD
          prev_state == TASK_DEAD
                                        context_switch(A, C)
                                          A->state == TASK_DEAD

The argument being that the WMB will allow the load of A->state on CPU0
to cross over and observe CPU1's store of A->state, which will then
result in a double-drop and use-after-free.

Now the comment states (and this was true once upon a long time ago)
that we need to observe A->state while holding rq->lock because that
will order us against the wakeup; however the wakeup will not in fact
acquire (that) rq->lock; it takes A->pi_lock these days.

We can obviously fix this by upgrading the WMB to an MB, but that is
expensive, so we'd rather avoid that.

The alternative this patch takes is: smp_store_release(&A->on_cpu, 0),
which avoids the MB on some archs, but not important ones like ARM.

Reported-by: Oleg Nesterov <>
Signed-off-by: Peter Zijlstra (Intel) <>
Acked-by: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Fixes: e4a52bcb9a18 ("sched: Remove rq->lock from the first half of ttwu()")
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - Adjust filename
 - As smp_store_release() is not defined, use smp_mb()]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: synth: Fix conflicting OSS device registration on AWE32
Takashi Iwai [Mon, 5 Oct 2015 14:55:09 +0000 (16:55 +0200)]
ALSA: synth: Fix conflicting OSS device registration on AWE32

commit 225db5762dc1a35b26850477ffa06e5cd0097243 upstream.

When OSS emulation is loaded on ISA SB AWE32 chip, we get now kernel
warnings like:
  WARNING: CPU: 0 PID: 2791 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x51/0x80()
  sysfs: cannot create duplicate filename '/devices/isa/sbawe.0/sound/card0/seq-oss-0-0'

It's because both emux synth and opl3 drivers try to register their
OSS device object with the same static index number 0.  This hasn't
been a big problem until the recent rewrite of device management code
(that exposes sysfs at the same time), but it's been an obvious bug.

This patch works around it just by using a different index number of
emux synth object.  There can be a more elegant way to fix, but it's
enough for now, as this code won't be touched so often, in anyway.

Reported-and-tested-by: Michael Shell <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoiwlwifi: dvm: fix D3 firmware PN programming
Johannes Berg [Tue, 15 Sep 2015 12:36:09 +0000 (14:36 +0200)]
iwlwifi: dvm: fix D3 firmware PN programming

commit 5bd166872d8f99f156fac191299d24f828bb2348 upstream.

The code to send the RX PN data (for each TID) to the firmware
has a devastating bug: it overwrites the data for TID 0 with
all the TID data, leaving the remaining TIDs zeroed. This will
allow replays to actually be accepted by the firmware, which
could allow waking up the system.

Signed-off-by: Johannes Berg <>
Signed-off-by: Luca Coelho <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoppp: don't override sk->sk_state in pppoe_flush_dev()
Guillaume Nault [Wed, 30 Sep 2015 09:45:33 +0000 (11:45 +0200)]
ppp: don't override sk->sk_state in pppoe_flush_dev()

commit e6740165b8f7f06d8caee0fceab3fb9d790a6fed upstream.

Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the
PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to
PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the
following oops:

[  570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0
[  570.142931] IP: [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
[  570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0
[  570.144601] Oops: 0000 [#1] SMP
[  570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio
[  570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1
[  570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[  570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000
[  570.144601] RIP: 0010:[<ffffffffa018c701>]  [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
[  570.144601] RSP: 0018:ffff880036b63e08  EFLAGS: 00010202
[  570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206
[  570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20
[  570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000
[  570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780
[  570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0
[  570.144601] FS:  00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000
[  570.144601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0
[  570.144601] Stack:
[  570.144601]  ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0
[  570.144601]  ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008
[  570.144601]  ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5
[  570.144601] Call Trace:
[  570.144601]  [<ffffffff812caabe>] sock_release+0x1a/0x75
[  570.144601]  [<ffffffff812cabad>] sock_close+0xd/0x11
[  570.144601]  [<ffffffff811347f5>] __fput+0xff/0x1a5
[  570.144601]  [<ffffffff811348cb>] ____fput+0x9/0xb
[  570.144601]  [<ffffffff81056682>] task_work_run+0x66/0x90
[  570.144601]  [<ffffffff8100189e>] prepare_exit_to_usermode+0x8c/0xa7
[  570.144601]  [<ffffffff81001a26>] syscall_return_slowpath+0x16d/0x19b
[  570.144601]  [<ffffffff813babb1>] int_ret_from_sys_call+0x25/0x9f
[  570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00
[  570.144601] RIP  [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
[  570.144601]  RSP <ffff880036b63e08>
[  570.144601] CR2: 00000000000004e0
[  570.200518] ---[ end trace 46956baf17349563 ]---

pppoe_flush_dev() has no reason to override sk->sk_state with
PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to
PPPOX_DEAD, which is the correct state given that sk is unbound and
po->pppoe_dev is NULL.

Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
Tested-by: Oleksii Berezhniak <>
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agodrivers/tty: require read access for controlling terminal
Jann Horn [Sun, 4 Oct 2015 17:29:12 +0000 (19:29 +0200)]
drivers/tty: require read access for controlling terminal

commit 0c55627167870255158db1cde0d28366f91c8872 upstream.

This is mostly a hardening fix, given that write-only access to other
users' ttys is usually only given through setgid tty executables.

Signed-off-by: Jann Horn <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - __proc_set_tty() also takes a task_struct pointer]
Signed-off-by: Ben Hutchings <>
6 years agotty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c
Kosuke Tatsukawa [Fri, 2 Oct 2015 08:27:05 +0000 (08:27 +0000)]
tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c

commit e81107d4c6bd098878af9796b24edc8d4a9524fd upstream.

My colleague ran into a program stall on a x86_64 server, where
n_tty_read() was waiting for data even if there was data in the buffer
in the pty.  kernel stack for the stuck process looks like below.
 #0 [ffff88303d107b58] __schedule at ffffffff815c4b20
 #1 [ffff88303d107bd0] schedule at ffffffff815c513e
 #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
 #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
 #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
 #5 [ffff88303d107dd0] tty_read at ffffffff81368013
 #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
 #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
 #8 [ffff88303d107f00] sys_read at ffffffff811a4306
 #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7

There seems to be two problems causing this issue.

First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
updates ldata->commit_head using smp_store_release() and then checks
the wait queue using waitqueue_active().  However, since there is no
memory barrier, __receive_buf() could return without calling
wake_up_interactive_poll(), and at the same time, n_tty_read() could
start to wait in wait_woken() as in the following chart.

        __receive_buf()                         n_tty_read()
if (waitqueue_active(&tty->read_wait))
/* Memory operations issued after the
   RELEASE may be completed before the
   RELEASE operation has completed */
                                        add_wait_queue(&tty->read_wait, &wait);
                                        if (!input_available_p(tty, 0)) {
                                        timeout = wait_woken(&wait,
                                          TASK_INTERRUPTIBLE, timeout);

The second problem is that n_tty_read() also lacks a memory barrier
call and could also cause __receive_buf() to return without calling
wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
as in the chart below.

        __receive_buf()                         n_tty_read()
                                        spin_lock_irqsave(&q->lock, flags);
                                        /* from add_wait_queue() */
                                        if (!input_available_p(tty, 0)) {
                                        /* Memory operations issued after the
                                           RELEASE may be completed before the
                                           RELEASE operation has completed */
if (waitqueue_active(&tty->read_wait))
                                        __add_wait_queue(q, wait);
                                        /* from add_wait_queue() */
                                        timeout = wait_woken(&wait,
                                          TASK_INTERRUPTIBLE, timeout);

There are also other places in drivers/tty/n_tty.c which have similar
calls to waitqueue_active(), so instead of adding many memory barrier
calls, this patch simply removes the call to waitqueue_active(),
leaving just wake_up*() behind.

This fixes both problems because, even though the memory access before
or after the spinlocks in both wake_up*() and add_wait_queue() can
sneak into the critical section, it cannot go past it and the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation).  Moreover, the resulting code is much simpler.

Latency measurement using a ping-pong test over a pty doesn't show any
visible performance drop.

Signed-off-by: Kosuke Tatsukawa <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Use wake_up_interruptible(), not wake_up_interruptible_poll()
 - There are only two spurious uses of waitqueue_active() to remove]
Signed-off-by: Ben Hutchings <>
6 years agousb: Add device quirk for Logitech PTZ cameras
Vincent Palatin [Thu, 1 Oct 2015 21:10:22 +0000 (14:10 -0700)]
usb: Add device quirk for Logitech PTZ cameras

commit 72194739f54607bbf8cfded159627a2015381557 upstream.

Add a device quirk for the Logitech PTZ Pro Camera and its sibling the
ConferenceCam CC3000e Camera.
This fixes the failed camera enumeration on some boot, particularly on
machines with fast CPU.

Tested by connecting a Logitech PTZ Pro Camera to a machine with a
Haswell Core i7-4600U CPU @ 2.10GHz, and doing thousands of reboot cycles
while recording the kernel logs and taking camera picture after each boot.
Before the patch, more than 7% of the boots show some enumeration transfer
failures and in a few of them, the kernel is giving up before actually
enumerating the webcam. After the patch, the enumeration has been correct
on every reboot.

Signed-off-by: Vincent Palatin <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: Add reset-resume quirk for two Plantronics usb headphones.
Yao-Wen Mao [Mon, 31 Aug 2015 06:24:09 +0000 (14:24 +0800)]
USB: Add reset-resume quirk for two Plantronics usb headphones.

commit 8484bf2981b3d006426ac052a3642c9ce1d8d980 upstream.

These two headphones need a reset-resume quirk to properly resume to
original volume level.

Signed-off-by: Yao-Wen Mao <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoiio: accel: sca3000: memory corruption in sca3000_read_first_n_hw_rb()
Dan Carpenter [Sat, 8 Aug 2015 19:16:42 +0000 (22:16 +0300)]
iio: accel: sca3000: memory corruption in sca3000_read_first_n_hw_rb()

commit eda7d0f38aaf50dbb2a2de15e8db386c4f6f65fc upstream.

"num_read" is in byte units but we are write u16s so we end up write
twice as much as intended.

Signed-off-by: Dan Carpenter <>
Signed-off-by: Jonathan Cameron <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoclocksource: Fix abs() usage w/ 64bit values
John Stultz [Tue, 15 Sep 2015 01:05:20 +0000 (18:05 -0700)]
clocksource: Fix abs() usage w/ 64bit values

commit 67dfae0cd72fec5cd158b6e5fb1647b7dbe0834c upstream.

This patch fixes one cases where abs() was being used with 64-bit
nanosecond values, where the result may be capped at 32-bits.

This potentially could cause watchdog false negatives on 32-bit
systems, so this patch addresses the issue by using abs64().

Signed-off-by: John Stultz <>
Cc: Prarit Bhargava <>
Cc: Richard Cochran <>
Cc: Ingo Molnar <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomd/raid0: apply base queue limits *before* disk_stack_limits
NeilBrown [Thu, 24 Sep 2015 05:47:47 +0000 (15:47 +1000)]
md/raid0: apply base queue limits *before* disk_stack_limits

commit 66eefe5de11db1e0d8f2edc3880d50e7c36a9d43 upstream.

Calling e.g. blk_queue_max_hw_sectors() after calls to
disk_stack_limits() discards the settings determined by
So we need to make those calls first.

Fixes: 199dc6ed5179 ("md/raid0: update queue parameter in a safer location.")
Reported-by: Jes Sorensen <>
Signed-off-by: NeilBrown <>
[bwh: Backported to 3.2: the code being moved looks a little different]
Signed-off-by: Ben Hutchings <>
6 years agomd/raid0: update queue parameter in a safer location.
NeilBrown [Mon, 3 Aug 2015 03:11:47 +0000 (13:11 +1000)]
md/raid0: update queue parameter in a safer location.

commit 199dc6ed5179251fa6158a461499c24bdd99c836 upstream.

When a (e.g.) RAID5 array is reshaped to RAID0, the updating
of queue parameters (e.g. max number of sectors per bio) is
done in the wrong place.
It should be part of ->run, but it is actually part of ->takeover.
This means it happens before level_store() calls:


and so it ineffective.  This can lead to errors from underlying

So move all the relevant settings out of create_stripe_zones()
and into raid0_run().

As this can lead to a bug-on it is suitable for any -stable
kernel which supports reshape to RAID0.  So 2.6.35 or later.
As the bug has been present for five years there is no urgency,
so no need to rush into -stable.

Fixes: 9af204cf720c ("md: Add support for Raid5->Raid0 and Raid10->Raid0 takeover")
Reported-by: Yi Zhang <>
Signed-off-by: NeilBrown <>
[bwh: Backported to 3.2:
 - md has no discard or write-same support
 - md is not used by dm-raid so mddev->queue is never null
 - Open-code rdev_for_each()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoDo not fall back to SMBWriteX in set_file_size error cases
Steve French [Mon, 28 Sep 2015 22:21:07 +0000 (17:21 -0500)]
Do not fall back to SMBWriteX in set_file_size error cases

commit 646200a041203f440fb6fcf9cacd9efeda9de74c upstream.

The error paths in set_file_size for cifs and smb3 are incorrect.

In the unlikely event that a server did not support set file info
of the file size, the code incorrectly falls back to trying SMBWriteX
(note that only the original core SMB Write, used for example by DOS,
can set the file size this way - this actually  does not work for the more
recent SMBWriteX).  The idea was since the old DOS SMB Write could set
the file size if you write zero bytes at that offset then use that if
server rejects the normal set file info call.

Fortunately the SMBWriteX will never be sent on the wire (except when
file size is zero) since the length and offset fields were reversed
in the two places in this function that call SMBWriteX causing
the fall back path to return an error. It is also important to never call
an SMB request from an SMB2/sMB3 session (which theoretically would
be possible, and can cause a brief session drop, although the client
recovers) so this should be fixed.  In practice this path does not happen
with modern servers but the error fall back to SMBWriteX is clearly wrong.

Removing the calls to SMBWriteX in the error paths in cifs_set_file_size

Pointed out by PaX/grsecurity team

Signed-off-by: Steve French <>
Reported-by: PaX Team <>
CC: Emese Revfy <>
CC: Brad Spengler <>
[bwh: Backported to 3.2: deleted code looks slightly different]
Signed-off-by: Ben Hutchings <>
6 years agomm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault
Mel Gorman [Thu, 1 Oct 2015 22:36:57 +0000 (15:36 -0700)]
mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault

commit 2f84a8990ebbe235c59716896e017c6b2ca1200f upstream.

SunDong reported the following on

I think I find a linux bug, I have the test cases is constructed. I
can stable recurring problems in fedora22(4.0.4) kernel version,
arch for x86_64.  I construct transparent huge page, when the parent
and child process with MAP_SHARE, MAP_PRIVATE way to access the same
huge page area, it has the opportunity to lead to huge page copy on
write failure, and then it will munmap the child corresponding mmap
area, but then the child mmap area with VM_MAYSHARE attributes, child
process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
functions (vma - > vm_flags & VM_MAYSHARE).

There were a number of problems with the report (e.g.  it's hugetlbfs that
triggers this, not transparent huge pages) but it was fundamentally
correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that
looks like this

 vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
 prot 8000000000000027 anon_vma           (null) vm_ops ffffffff8182a7a0
 pgoff 0 file ffff88106bdb9800 private_data           (null)
 flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
 kernel BUG at mm/hugetlb.c:462!
 Modules linked in: xt_pkttype xt_LOG xt_limit [..]
 CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012

The VM_BUG_ON is correct because private and shared mappings have
different reservation accounting but the warning clearly shows that the
VMA is shared.

When a private COW fails to allocate a new page then only the process
that created the VMA gets the page -- all the children unmap the page.
If the children access that data in the future then they get killed.

The problem is that the same file is mapped shared and private.  During
the COW, the allocation fails, the VMAs are traversed to unmap the other
private pages but a shared VMA is found and the bug is triggered.  This
patch identifies such VMAs and skips them.

Signed-off-by: Mel Gorman <>
Reported-by: SunDong <>
Reviewed-by: Michal Hocko <>
Cc: Andrea Arcangeli <>
Cc: Hugh Dickins <>
Cc: Naoya Horiguchi <>
Cc: David Rientjes <>
Reviewed-by: Naoya Horiguchi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agogenirq: Fix race in register_irq_proc()
Ben Hutchings [Sat, 26 Sep 2015 11:23:56 +0000 (12:23 +0100)]
genirq: Fix race in register_irq_proc()

commit 95c2b17534654829db428f11bcf4297c059a2a7e upstream.

Per-IRQ directories in procfs are created only when a handler is first
added to the irqdesc, not when the irqdesc is created.  In the case of
a shared IRQ, multiple tasks can race to create a directory.  This
race condition seems to have been present forever, but is easier to
hit with async probing.

Signed-off-by: Ben Hutchings <>
Signed-off-by: Thomas Gleixner <>
6 years agox86/process: Add proper bound checks in 64bit get_wchan()
Thomas Gleixner [Wed, 30 Sep 2015 08:38:22 +0000 (08:38 +0000)]
x86/process: Add proper bound checks in 64bit get_wchan()

commit eddd3826a1a0190e5235703d1e666affa4d13b96 upstream.

Dmitry Vyukov reported the following using trinity and the memory
error detector AddressSanitizer

[ 124.575597] ERROR: AddressSanitizer: heap-buffer-overflow on
address ffff88002e280000
[ 124.576801] ffff88002e280000 is located 131938492886538 bytes to
the left of 28857600-byte region [ffffffff81282e0affffffff82e0830a)
[ 124.578633] Accessed by thread T10915:
[ 124.579295] inlined in describe_heap_address
[ 124.579295] #0 ffffffff810dd277 in asan_report_error
[ 124.580137] #1 ffffffff810dc6a0 in asan_check_region
[ 124.581050] #2 ffffffff810dd423 in __tsan_read8 ??:0
[ 124.581893] #3 ffffffff8107c093 in get_wchan

The address checks in the 64bit implementation of get_wchan() are
wrong in several ways:

 - The lower bound of the stack is not the start of the stack
   page. It's the start of the stack page plus sizeof (struct

 - The upper bound must be:

       top_of_stack - TOP_OF_KERNEL_STACK_PADDING - 2 * sizeof(unsigned long).

   The 2 * sizeof(unsigned long) is required because the stack pointer
   points at the frame pointer. The layout on the stack is: ... IP FP
   ... IP FP. So we need to make sure that both IP and FP are in the

Fix the bound checks and get rid of the mix of numeric constants, u64
and unsigned long. Making all unsigned long allows us to use the same
function for 32bit as well.

Use READ_ONCE() when accessing the stack. This does not prevent a
concurrent wakeup of the task and the stack changing, but at least it
avoids TOCTOU.

Also check task state at the end of the loop. Again that does not
prevent concurrent changes, but it avoids walking for nothing.

Add proper comments while at it.

Reported-by: Dmitry Vyukov <>
Reported-by: Sasha Levin <>
Based-on-patch-from: Wolfram Gloger <>
Signed-off-by: Thomas Gleixner <>
Reviewed-by: Borislav Petkov <>
Reviewed-by: Dmitry Vyukov <>
Cc: Andrey Ryabinin <>
Cc: Andy Lutomirski <>
Cc: Andrey Konovalov <>
Cc: Kostya Serebryany <>
Cc: Alexander Potapenko <>
Cc: kasan-dev <>
Cc: Denys Vlasenko <>
Cc: Andi Kleen <>
Cc: Wolfram Gloger <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2:
 - Remove use of TOP_OF_KERNEL_STACK_PADDING, not defined here and would
   be defined as 0]
Signed-off-by: Ben Hutchings <>
6 years agoMIPS: dma-default: Fix 32-bit fall back to GFP_DMA
James Hogan [Fri, 27 Mar 2015 08:33:43 +0000 (08:33 +0000)]
MIPS: dma-default: Fix 32-bit fall back to GFP_DMA

commit 53960059d56ecef67d4ddd546731623641a3d2d1 upstream.

If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32
zone, as is the case for some 32-bit kernels, then massage_gfp_flags()
will cause DMA memory allocated for devices with a 32..63-bit
coherent_dma_mask to fall back to using __GFP_DMA, even though there may
only be 32-bits of physical address available anyway.

Correct that case to compare against a mask the size of phys_addr_t
instead of always using a 64-bit mask.

Signed-off-by: James Hogan <>
Fixes: a2e715a86c6d ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.")
Cc: Ralf Baechle <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
6 years agoUBI: return ENOSPC if no enough space available
shengyong [Mon, 28 Sep 2015 17:57:19 +0000 (17:57 +0000)]
UBI: return ENOSPC if no enough space available

commit 7c7feb2ebfc9c0552c51f0c050db1d1a004faac5 upstream.

UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI error: init_volumes: not enough PEBs, required 706, available 686
UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1)
UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM
UBI error: ubi_init: cannot attach mtd1

If available PEBs are not enough when initializing volumes, return -ENOSPC
directly. If available PEBs are not enough when initializing WL, return
-ENOSPC instead of -ENOMEM.

Signed-off-by: Sheng Yong <>
Signed-off-by: Richard Weinberger <>
Reviewed-by: David Gstir <>
Signed-off-by: Ben Hutchings <>
6 years agoUBI: Validate data_size
Richard Weinberger [Tue, 22 Sep 2015 21:58:07 +0000 (23:58 +0200)]
UBI: Validate data_size

commit 281fda27673f833a01d516658a64d22a32c8e072 upstream.

Make sure that data_size is less than LEB size.
Otherwise a handcrafted UBI image is able to trigger
an out of bounds memory access in ubi_compare_lebs().

Signed-off-by: Richard Weinberger <>
Reviewed-by: David Gstir <>
[bwh: Backported to 3.2: drop first argument to ubi_err()]
Signed-off-by: Ben Hutchings <>
6 years agox86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing map
Malcolm Crossley [Mon, 28 Sep 2015 10:36:52 +0000 (11:36 +0100)]
x86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing map

commit 64c98e7f49100b637cd20a6c63508caed6bbba7a upstream.

Sanitizing the e820 map may produce extra E820 entries which would result in
the topmost E820 entries being removed. The removed entries would typically
include the top E820 usable RAM region and thus result in the domain having
signicantly less RAM available to it.

Fix by allowing sanitize_e820_map to use the full size of the allocated E820

Signed-off-by: Malcolm Crossley <>
Reviewed-by: Boris Ostrovsky <>
Signed-off-by: David Vrabel <>
[bwh: Backported to 3.2:
 s/xen_e820_map_entries/memmap.nr_entries/; s/xen_e820_map/map/g]
Signed-off-by: Ben Hutchings <>
6 years agom68k: Define asmlinkage_protect
Andreas Schwab [Wed, 23 Sep 2015 21:12:09 +0000 (23:12 +0200)]
m68k: Define asmlinkage_protect

commit 8474ba74193d302e8340dddd1e16c85cc4b98caf upstream.

Make sure the compiler does not modify arguments of syscall functions.
This can happen if the compiler generates a tailcall to another
function.  For example, without asmlinkage_protect sys_openat is compiled
into this function:

clr.l %d0
move.w 18(%sp),%d0
move.l %d0,16(%sp)
jbra do_sys_open

Note how the fourth argument is modified in place, modifying the register
%d4 that gets restored from this stack slot when the function returns to
user-space.  The caller may expect the register to be unmodified across
system calls.

Signed-off-by: Andreas Schwab <>
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Ben Hutchings <>
6 years agoath9k: declare required extra tx headroom
Felix Fietkau [Thu, 24 Sep 2015 14:59:46 +0000 (16:59 +0200)]
ath9k: declare required extra tx headroom

commit 029cd0370241641eb70235d205aa0b90c84dce44 upstream.

ath9k inserts padding between the 802.11 header and the data area (to
align it). Since it didn't declare this extra required headroom, this
led to some nasty issues like randomly dropped packets in some setups.

Signed-off-by: Felix Fietkau <>
Signed-off-by: Kalle Valo <>
Signed-off-by: Ben Hutchings <>
6 years agoregmap: debugfs: Don't bother actually printing when calculating max length
Mark Brown [Sat, 19 Sep 2015 14:12:34 +0000 (07:12 -0700)]
regmap: debugfs: Don't bother actually printing when calculating max length

commit 176fc2d5770a0990eebff903ba680d2edd32e718 upstream.

The in kernel snprintf() will conveniently return the actual length of
the printed string even if not given an output beffer at all so just do
that rather than relying on the user to pass in a suitable buffer,
ensuring that we don't need to worry if the buffer was truncated due to
the size of the buffer passed in.

Reported-by: Rasmus Villemoes <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agoregmap: debugfs: Ensure we don't underflow when printing access masks
Mark Brown [Sat, 19 Sep 2015 14:00:18 +0000 (07:00 -0700)]
regmap: debugfs: Ensure we don't underflow when printing access masks

commit b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 upstream.

If a read is attempted which is smaller than the line length then we may
underflow the subtraction we're doing with the unsigned size_t type so
move some of the calculation to be additions on the right hand side
instead in order to avoid this.

Reported-by: Rasmus Villemoes <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agomodule: Fix locking in symbol_put_addr()
Peter Zijlstra [Thu, 20 Aug 2015 01:04:59 +0000 (10:34 +0930)]
module: Fix locking in symbol_put_addr()

commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 upstream.

Poma (on the way to another bug) reported an assertion triggering:

  [<ffffffff81150529>] module_assert_mutex_or_preempt+0x49/0x90
  [<ffffffff81150822>] __module_address+0x32/0x150
  [<ffffffff81150956>] __module_text_address+0x16/0x70
  [<ffffffff81150f19>] symbol_put_addr+0x29/0x40
  [<ffffffffa04b77ad>] dvb_frontend_detach+0x7d/0x90 [dvb_core]

Laura Abbott <> produced a patch which lead us to
inspect symbol_put_addr(). This function has a comment claiming it
doesn't need to disable preemption around the module lookup
because it holds a reference to the module it wants to find, which
therefore cannot go away.

This is wrong (and a false optimization too, preempt_disable() is really
rather cheap, and I doubt any of this is on uber critical paths,
otherwise it would've retained a pointer to the actual module anyway and
avoided the second lookup).

While its true that the module cannot go away while we hold a reference
on it, the data structure we do the lookup in very much _CAN_ change
while we do the lookup. Therefore fix the comment and add the
required preempt_disable().

Reported-by: poma <>
Signed-off-by: Peter Zijlstra (Intel) <>
Signed-off-by: Rusty Russell <>
Fixes: a6e6abd575fc ("module: remove module_text_address()")
Signed-off-by: Ben Hutchings <>
6 years agoRevert "KVM: MMU: fix validation of mmio page fault"
Ben Hutchings [Thu, 15 Oct 2015 00:20:29 +0000 (01:20 +0100)]
Revert "KVM: MMU: fix validation of mmio page fault"

This reverts commit 41e3025eacd6daafc40c3e7850fbcabc8b847805, which
was commit 6f691251c0350ac52a007c54bf3ef62e9d8cdc5e upstream.

The fix is only needed after commit f8f559422b6c ("KVM: MMU: fast
invalidate all mmio sptes"), included in Linux 3.11.

Signed-off-by: Ben Hutchings <>
6 years agoLinux 3.2.72 v3.2.72
Ben Hutchings [Tue, 13 Oct 2015 02:46:14 +0000 (03:46 +0100)]
Linux 3.2.72

6 years agoRevert "sctp: Fix race between OOTB responce and route removal"
Ben Hutchings [Thu, 8 Oct 2015 22:44:23 +0000 (23:44 +0100)]
Revert "sctp: Fix race between OOTB responce and route removal"

This reverts commit 117b8a10fe0c434d9043267efd51f3ba3f3d359a, which
was commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 upstream.  The bug
it fixes upstream clearly doesn't exist in 3.2.

Signed-off-by: Ben Hutchings <>
6 years agojbd2: avoid infinite loop when destroying aborted journal
Jan Kara [Tue, 28 Jul 2015 18:57:14 +0000 (14:57 -0400)]
jbd2: avoid infinite loop when destroying aborted journal

commit 841df7df196237ea63233f0f9eaa41db53afd70f upstream.

Commit 6f6a6fda2945 "jbd2: fix ocfs2 corrupt when updating journal
superblock fails" changed jbd2_cleanup_journal_tail() to return EIO
when the journal is aborted. That makes logic in
jbd2_log_do_checkpoint() bail out which is fine, except that
jbd2_journal_destroy() expects jbd2_log_do_checkpoint() to always make
a progress in cleaning the journal. Without it jbd2_journal_destroy()
just loops in an infinite loop.

Fix jbd2_journal_destroy() to cleanup journal checkpoint lists of
jbd2_log_do_checkpoint() fails with error.

Reported-by: Eryu Guan <>
Tested-by: Eryu Guan <>
Fixes: 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a
Signed-off-by: Jan Kara <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
Cc: Roland Dreier <>