1. 30 Nov, 2015 40 commits
    • Lu, Han's avatar
      ALSA: hda/hdmi - apply Skylake fix-ups to Broxton display codec · d484194c
      Lu, Han authored
      commit e2656412 upstream.
      
      Broxton and Skylake have the same behavior on display audio. So this patch
      applys Skylake fix-ups to Broxton.
      Signed-off-by: default avatarLu, Han <han.lu@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ kamal: backport to 3.19-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d484194c
    • Eric Biggers's avatar
      fs/pipe.c: return error code rather than 0 in pipe_write() · 13ccbf75
      Eric Biggers authored
      commit 6ae08069 upstream.
      
      pipe_write() would return 0 if it failed to merge the beginning of the
      data to write with the last, partially filled pipe buffer.  It should
      return an error code instead.  Userspace programs could be confused by
      write() returning 0 when called with a nonzero 'count'.
      
      The EFAULT error case was a regression from f0d1bec9 ("new helper:
      copy_page_from_iter()"), while the ops->confirm() error case was a much
      older bug.
      
      Test program:
      
      	#include <assert.h>
      	#include <errno.h>
      	#include <unistd.h>
      
      	int main(void)
      	{
      		int fd[2];
      		char data[1] = {0};
      
      		assert(0 == pipe(fd));
      		assert(1 == write(fd[1], data, 1));
      
      		/* prior to this patch, write() returned 0 here  */
      		assert(-1 == write(fd[1], NULL, 1));
      		assert(errno == EFAULT);
      	}
      Signed-off-by: default avatarEric Biggers <ebiggers3@gmail.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      13ccbf75
    • Maciej W. Rozycki's avatar
      binfmt_elf: Don't clobber passed executable's file header · cb08503d
      Maciej W. Rozycki authored
      commit b582ef5c upstream.
      
      Do not clobber the buffer space passed from `search_binary_handler' and
      originally preloaded by `prepare_binprm' with the executable's file
      header by overwriting it with its interpreter's file header.  Instead
      keep the buffer space intact and directly use the data structure locally
      allocated for the interpreter's file header, fixing a bug introduced in
      2.1.14 with loadable module support (linux-mips.org commit beb11695
      [Import of Linux/MIPS 2.1.14], predating kernel.org repo's history).
      Adjust the amount of data read from the interpreter's file accordingly.
      
      This was not an issue before loadable module support, because back then
      `load_elf_binary' was executed only once for a given ELF executable,
      whether the function succeeded or failed.
      
      With loadable module support supported and enabled, upon a failure of
      `load_elf_binary' -- which may for example be caused by architecture
      code rejecting an executable due to a missing hardware feature requested
      in the file header -- a module load is attempted and then the function
      reexecuted by `search_binary_handler'.  With the executable's file
      header replaced with its interpreter's file header the executable can
      then be erroneously accepted in this subsequent attempt.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cb08503d
    • David Howells's avatar
      FS-Cache: Handle a write to the page immediately beyond the EOF marker · 101997da
      David Howells authored
      commit 102f4d90 upstream.
      
      Handle a write being requested to the page immediately beyond the EOF
      marker on a cache object.  Currently this gets an assertion failure in
      CacheFiles because the EOF marker is used there to encode information about
      a partial page at the EOF - which could lead to an unknown blank spot in
      the file if we extend the file over it.
      
      The problem is actually in fscache where we check the index of the page
      being written against store_limit.  store_limit is set to the number of
      pages that we're allowed to store by fscache_set_store_limit() - which
      means it's one more than the index of the last page we're allowed to store.
      The problem is that we permit writing to a page with an index _equal_ to
      the store limit - when we should reject that case.
      
      Whilst we're at it, change the triggered assertion in CacheFiles to just
      return -ENOBUFS instead.
      
      The assertion failure looks something like this:
      
      CacheFiles: Assertion failed
      1000 < 7b1 is false
      ------------[ cut here ]------------
      kernel BUG at fs/cachefiles/rdwr.c:962!
      ...
      RIP: 0010:[<ffffffffa02c9e83>]  [<ffffffffa02c9e83>] cachefiles_write_page+0x273/0x2d0 [cachefiles]
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      101997da
    • Kinglong Mee's avatar
      FS-Cache: Don't override netfs's primary_index if registering failed · ffd8882b
      Kinglong Mee authored
      commit b130ed59 upstream.
      
      Only override netfs->primary_index when registering success.
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ffd8882b
    • Kinglong Mee's avatar
      FS-Cache: Increase reference of parent after registering, netfs success · cac5addc
      Kinglong Mee authored
      commit 86108c2e upstream.
      
      If netfs exist, fscache should not increase the reference of parent's
      usage and n_children, otherwise, never be decreased.
      
      v2: thanks David's suggest,
       move increasing reference of parent if success
       use kmem_cache_free() freeing primary_index directly
      
      v3: don't move "netfs->primary_index->parent = &fscache_fsdef_index;"
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cac5addc
    • Egbert Eich's avatar
      drm/ast: Initialized data needed to map fbdev memory · f08c1028
      Egbert Eich authored
      commit 28fb4cb7 upstream.
      
      Due to a missing initialization there was no way to map fbdev memory.
      Thus for example using the Xserver with the fbdev driver failed.
      This fix adds initialization for fix.smem_start and fix.smem_len
      in the fb_info structure, which fixes this problem.
      Requested-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarEgbert Eich <eich@suse.de>
      [pulled from SuSE tree by me - airlied]
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f08c1028
    • Jason Liu's avatar
      drivers: of: of_reserved_mem: fixup the alignment with CMA setup · 0f5a1861
      Jason Liu authored
      commit 1cc8e345 upstream.
      
      There is an alignment mismatch issue between the of_reserved_mem and
      the CMA setup requirement. The of_reserved_mem will try to get the
      alignment value from the DTS and pass it to __memblock_alloc_base to
      do the memory block base allocation, but the alignment value specified
      in the DTS may not satisfy the CAM setup requirement since CMA setup
      required the alignment as the following in the code:
      
      align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
      
      The sanity check in the function of rmem_cma_setup will fail if the
      alignment does not setup correctly and thus CMA will fail to setup.
      
      This patch is to fixup the alignment to meet the CMA setup required.
      
      Mailing-list-thread: https://lkml.org/lkml/2015/11/9/138Signed-off-by: default avatarJason Liu <r64343@freescale.com>
      Acked-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0f5a1861
    • Paolo Bonzini's avatar
      KVM: svm: unconditionally intercept #DB · 76e4943d
      Paolo Bonzini authored
      commit cbdb967a upstream.
      
      This is needed to avoid the possibility that the guest triggers
      an infinite stream of #DB exceptions (CVE-2015-8104).
      
      VMX is not affected: because it does not save DR6 in the VMCS,
      it already intercepts #DB unconditionally.
      Reported-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      76e4943d
    • Eric Northup's avatar
      KVM: x86: work around infinite loop in microcode when #AC is delivered · cf492854
      Eric Northup authored
      commit 54a20552 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: default avatarEric Northup <digitaleric@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cf492854
    • K. Y. Srinivasan's avatar
      storvsc: Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag · 18517bcb
      K. Y. Srinivasan authored
      commit 8cf308e1 upstream.
      
      Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag since we are not specifying
      tags.  Without this, the qlogic driver doesn't work properly with storvsc.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      18517bcb
    • Hans de Goede's avatar
      ideapad-laptop: Add Lenovo Yoga 900 to no_hw_rfkill dmi list · 8fe13ac5
      Hans de Goede authored
      commit f71c882d upstream.
      
      Like some of the other Yoga models the Lenovo Yoga 900 does not have a
      hw rfkill switch, and trying to read the hw rfkill switch through the
      ideapad module causes it to always reported blocking breaking wifi.
      
      This commit adds the Lenovo Yoga 900 to the no_hw_rfkill dmi list, fixing
      the wifi breakage.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1275490Reported-and-tested-by: default avatarKevin Fenzi <kevin@scrye.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8fe13ac5
    • Filipe Manana's avatar
      Btrfs: fix race when listing an inode's xattrs · 02029355
      Filipe Manana authored
      commit f1cd1f0b upstream.
      
      When listing a inode's xattrs we have a time window where we race against
      a concurrent operation for adding a new hard link for our inode that makes
      us not return any xattr to user space. In order for this to happen, the
      first xattr of our inode needs to be at slot 0 of a leaf and the previous
      leaf must still have room for an inode ref (or extref) item, and this can
      happen because an inode's listxattrs callback does not lock the inode's
      i_mutex (nor does the VFS does it for us), but adding a hard link to an
      inode makes the VFS lock the inode's i_mutex before calling the inode's
      link callback.
      
      If we have the following leafs:
      
                     Leaf X (has N items)                    Leaf Y
      
       [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 XATTR_ITEM 12345), ... ]
                 slot N - 2         slot N - 1              slot 0
      
      The race illustrated by the following sequence diagram is possible:
      
             CPU 1                                               CPU 2
      
        btrfs_listxattr()
      
          searches for key (257 XATTR_ITEM 0)
      
          gets 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()
      
          btrfs_next_leaf()
            releases the path
      
                                                         adds key (257 INODE_REF 666)
                                                         to the end of leaf X (slot N),
                                                         and leaf X now has N + 1 items
      
            searches for the key (257 INODE_REF 256),
            with path->keep_locks == 1, because that
            is the last key it saw in leaf X before
            releasing the path
      
            ends up at leaf X again and it verifies
            that the key (257 INODE_REF 256) is no
            longer the last key in leaf X, so it
            returns with path->nodes[0] == leaf X
            and path->slots[0] == N, pointing to
            the new item with key (257 INODE_REF 666)
      
          btrfs_listxattr's loop iteration sees that
          the type of the key pointed by the path is
          different from the type BTRFS_XATTR_ITEM_KEY
          and so it breaks the loop and stops looking
          for more xattr items
            --> the application doesn't get any xattr
                listed for our inode
      
      So fix this by breaking the loop only if the key's type is greater than
      BTRFS_XATTR_ITEM_KEY and skip the current key if its type is smaller.
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      02029355
    • Peter Oberparleiter's avatar
      scsi_sysfs: Fix queue_ramp_up_period return code · 7a6ee9a0
      Peter Oberparleiter authored
      commit 863e02d0 upstream.
      
      Writing a number to /sys/bus/scsi/devices/<sdev>/queue_ramp_up_period
      returns the value of that number instead of the number of bytes written.
      This behavior can confuse programs expecting POSIX write() semantics.
      Fix this by returning the number of bytes written instead.
      Signed-off-by: default avatarPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7a6ee9a0
    • Peter Zijlstra's avatar
      perf: Fix inherited events vs. tracepoint filters · 3e78c36e
      Peter Zijlstra authored
      commit b71b437e 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: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/20151102095051.GN17308@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3e78c36e
    • Jurgen Kramer's avatar
      ALSA: usb: Add native DSD support for Aune X1S · 533f2386
      Jurgen Kramer authored
      commit 16771c7c upstream.
      
      This patch adds native DSD support for the Aune X1S 32BIT/384 DSD DAC
      Signed-off-by: default avatarJurgen Kramer <gtmkramer@xs4all.nl>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      533f2386
    • Filipe Manana's avatar
      Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow · 657299fc
      Filipe Manana authored
      commit 1d512cb7 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
      of type BTRFS_INODE_[REF|EXTREF]_KEY or of type BTRFS_XATTR_ITEM_KEY to a
      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
      
       run_dealloc_nocow()
         btrfs_lookup_file_extent()
           --> 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()
      
         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 {
             BUG_ON(1)
         }
      
      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
      BTRFS_EXTENT_DATA_KEY.
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      657299fc
    • Filipe Manana's avatar
      Btrfs: fix race leading to incorrect item deletion when dropping extents · 097ea2dc
      Filipe Manana authored
      commit aeafbf84 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;
        762
        763                  fi = btrfs_item_ptr(leaf, path->slots[0],
        764                                      struct btrfs_file_extent_item);
        765                  extent_type = btrfs_file_extent_type(leaf, fi);
        766
        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
      
        btrfs_finish_ordered_io()
          insert_reserved_file_extent()
            __btrfs_drop_extents()
               Searches for the key
                (257 EXTENT_DATA 4096) through
                btrfs_lookup_file_extent()
      
               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()
      
               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
               BTRFS_EXTENT_DATA_KEY
               (BTRFS_INODE_REF_KEY < BTRFS_EXTENT_DATA_KEY)
      
               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
      impossible).
      
      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: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      097ea2dc
    • Helge Deller's avatar
      parisc: Fixes and cleanups in kernel uapi header files · 7da5559a
      Helge Deller authored
      commit d0cf62fb upstream.
      
      This patch fixes some bugs and partly cleans up the parisc uapi header
      files to what glibc defined:
      - compat_semid64_ds was wrong and did not take the endianess into
        account
      - ipc64_perm exported userspace types which broke building userspace
        packages on debian (e.g. trinity)
      - ipc64_perm needs to use a 32bit mode_t on 64bit kernel
      - msqid64_ds and semid64_ds needs unsigned longs for various struct members
      - shmid64_ds exported size_t instead of __kernel_size_t
      
      And finally add some compile-time checks for the sizes of those structs
      to avoid future breakage.
      
      Runtime-tested with the Linux Test Project (LTP) testsuite.
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7da5559a
    • Borislav Petkov's avatar
      x86/cpu: Call verify_cpu() after having entered long mode too · 0cafa822
      Borislav Petkov authored
      commit 04633df0 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
      https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit
      only on the BSP:
      
        # rdmsr -a 0x1a0
        400850089
        850089
        850089
        850089
      
      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: default avatar"H. Peter Anvin" <hpa@zytor.com>
      Reported-and-tested-by: default avatarBastien Nocera <bugzilla@hadess.net>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@alien8.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0cafa822
    • Greg Thelen's avatar
      fs, seqfile: always allow oom killer · 6f3916c7
      Greg Thelen authored
      commit 0f930902 upstream.
      
      Since 5cec38ac ("fs, seq_file: fallback to vmalloc instead of oom kill
      processes") seq_buf_alloc() avoids calling the oom killer for PAGE_SIZE or
      smaller allocations; but larger allocations can use the oom killer via
      vmalloc().  Thus reads of small files can return ENOMEM, but larger files
      use the oom killer to avoid ENOMEM.
      
      The effect of this bug is that reads from /proc and other virtual
      filesystems can return ENOMEM instead of the preferred behavior - oom
      killing something (possibly the calling process).  I don't know of anyone
      except Google who has noticed the issue.
      
      I suspect the fix is more needed in smaller systems where there isn't any
      reclaimable memory.  But these seem like the kinds of systems which
      probably don't use the oom killer for production situations.
      
      Memory overcommit requires use of the oom killer to select a victim
      regardless of file size.
      
      Enable oom killer for small seq_buf_alloc() allocations.
      
      Fixes: 5cec38ac ("fs, seq_file: fallback to vmalloc instead of oom kill processes")
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      6f3916c7
    • Mathias Krause's avatar
      printk: prevent userland from spoofing kernel messages · 03bebbbe
      Mathias Krause authored
      commit 3824657c upstream.
      
      The following statement of ABI/testing/dev-kmsg is not quite right:
      
         It is not possible to inject messages from userspace with the
         facility number LOG_KERN (0), to make sure that the origin of the
         messages can always be reliably determined.
      
      Userland actually can inject messages with a facility of 0 by abusing the
      fact that the facility is stored in a u8 data type.  By using a facility
      which is a multiple of 256 the assignment of msg->facility in log_store()
      implicitly truncates it to 0, i.e.  LOG_KERN, allowing users of /dev/kmsg
      to spoof kernel messages as shown below:
      
      The following call...
         # printf '<%d>Kernel panic - not syncing: beer empty\n' 0 >/dev/kmsg
      ...leads to the following log entry (dmesg -x | tail -n 1):
         user  :emerg : [   66.137758] Kernel panic - not syncing: beer empty
      
      However, this call...
         # printf '<%d>Kernel panic - not syncing: beer empty\n' 0x800 >/dev/kmsg
      ...leads to the slightly different log entry (note the kernel facility):
         kern  :emerg : [   74.177343] Kernel panic - not syncing: beer empty
      
      Fix that by limiting the user provided facility to 8 bit right from the
      beginning and catch the truncation early.
      
      Fixes: 7ff9554b ("printk: convert byte-buffer to variable-length...")
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Alex Elder <elder@linaro.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      03bebbbe
    • Oleg Nesterov's avatar
      proc: actually make proc_fd_permission() thread-friendly · 1d6a67f1
      Oleg Nesterov authored
      commit 54708d28 upstream.
      
      The commit 96d0df79 ("proc: make proc_fd_permission() thread-friendly")
      fixed the access to /proc/self/fd from sub-threads, but introduced another
      problem: a sub-thread can't access /proc/<tid>/fd/ or /proc/thread-self/fd
      if generic_permission() fails.
      
      Change proc_fd_permission() to check same_thread_group(pid_task(), current).
      
      Fixes: 96d0df79 ("proc: make proc_fd_permission() thread-friendly")
      Reported-by: default avatar"Jin, Yihua" <yihua.jin@intel.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1d6a67f1
    • Takashi Iwai's avatar
      Input: elantech - add Fujitsu Lifebook U745 to force crc_enabled · c2bc43c2
      Takashi Iwai authored
      commit 60603950 upstream.
      
      Another Lifebook machine that needs the same quirk as other similar
      models to make the driver working.
      
      Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=883192Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c2bc43c2
    • Zi Shen Lim's avatar
      arm64: bpf: fix mod-by-zero case · 856b41c2
      Zi Shen Lim authored
      commit 14e589ff upstream.
      
      Turns out in the case of modulo by zero in a BPF program:
      	A = A % X;  (X == 0)
      the expected behavior is to terminate with return value 0.
      
      The bug in JIT is exposed by a new test case [1].
      
      [1] https://lkml.org/lkml/2015/11/4/499Signed-off-by: default avatarZi Shen Lim <zlim.lnx@gmail.com>
      Reported-by: default avatarYang Shi <yang.shi@linaro.org>
      Reported-by: default avatarXi Wang <xi.wang@gmail.com>
      CC: Alexei Starovoitov <ast@plumgrid.com>
      Fixes: e54bcde3 ("arm64: eBPF JIT compiler")
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      856b41c2
    • Zi Shen Lim's avatar
      arm64: bpf: fix div-by-zero case · eb0c40a4
      Zi Shen Lim authored
      commit 251599e1 upstream.
      
      In the case of division by zero in a BPF program:
      	A = A / X;  (X == 0)
      the expected behavior is to terminate with return value 0.
      
      This is confirmed by the test case introduced in commit 86bf1721
      ("test_bpf: add tests checking that JIT/interpreter sets A and X to 0.").
      Reported-by: default avatarYang Shi <yang.shi@linaro.org>
      Tested-by: default avatarYang Shi <yang.shi@linaro.org>
      CC: Xi Wang <xi.wang@gmail.com>
      CC: Alexei Starovoitov <ast@plumgrid.com>
      CC: linux-arm-kernel@lists.infradead.org
      CC: linux-kernel@vger.kernel.org
      Fixes: e54bcde3 ("arm64: eBPF JIT compiler")
      Signed-off-by: default avatarZi Shen Lim <zlim.lnx@gmail.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      eb0c40a4
    • Michal Hocko's avatar
      memcg: fix thresholds for 32b architectures. · 0079424f
      Michal Hocko authored
      commit c12176d3 upstream.
      
      Commit 424cdc14 ("memcg: convert threshold to bytes") has fixed a
      regression introduced by 3e32cb2e ("mm: memcontrol: lockless page
      counters") where thresholds were silently converted to use page units
      rather than bytes when interpreting the user input.
      
      The fix is not complete, though, as properly pointed out by Ben Hutchings
      during stable backport review.  The page count is converted to bytes but
      unsigned long is used to hold the value which would be obviously not
      sufficient for 32b systems with more than 4G thresholds.  The same applies
      to usage as taken from mem_cgroup_usage which might overflow.
      
      Let's remove this bytes vs.  pages internal tracking differences and
      handle thresholds in page units internally.  Chage mem_cgroup_usage() to
      return the value in page units and revert 424cdc14 because this should
      be sufficient for the consistent handling.  mem_cgroup_read_u64 as the
      only users of mem_cgroup_usage outside of the threshold handling code is
      converted to give the proper in bytes result.  It is doing that already
      for page_counter output so this is more consistent as well.
      
      The value presented to the userspace is still in bytes units.
      
      Fixes: 424cdc14 ("memcg: convert threshold to bytes")
      Fixes: 3e32cb2e ("mm: memcontrol: lockless page counters")
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Reviewed-by: default avatarVladimir Davydov <vdavydov@virtuozzo.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      From: Michal Hocko <mhocko@kernel.org>
      Subject: memcg-fix-thresholds-for-32b-architectures-fix
      
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Vladimir Davydov <vdavydov@virtuozzo.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      From: Andrew Morton <akpm@linux-foundation.org>
      Subject: memcg-fix-thresholds-for-32b-architectures-fix-fix
      
      don't attempt to inline mem_cgroup_usage()
      
      The compiler ignores the inline anwyay.  And __always_inlining it adds 600
      bytes of goop to the .o file.
      
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Vladimir Davydov <vdavydov@virtuozzo.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0079424f
    • Catalin Marinas's avatar
      mm: slab: only move management objects off-slab for sizes larger than KMALLOC_MIN_SIZE · e028ec21
      Catalin Marinas authored
      commit d4322d88 upstream.
      
      On systems with a KMALLOC_MIN_SIZE of 128 (arm64, some mips and powerpc
      configurations defining ARCH_DMA_MINALIGN to 128), the first
      kmalloc_caches[] entry to be initialised after slab_early_init = 0 is
      "kmalloc-128" with index 7.  Depending on the debug kernel configuration,
      sizeof(struct kmem_cache) can be larger than 128 resulting in an
      INDEX_NODE of 8.
      
      Commit 8fc9cf42 ("slab: make more slab management structure off the
      slab") enables off-slab management objects for sizes starting with
      PAGE_SIZE >> 5 (128 bytes for a 4KB page configuration) and the creation
      of the "kmalloc-128" cache would try to place the management objects
      off-slab.  However, since KMALLOC_MIN_SIZE is already 128 and
      freelist_size == 32 in __kmem_cache_create(), kmalloc_slab(freelist_size)
      returns NULL (kmalloc_caches[7] not populated yet).  This triggers the
      following bug on arm64:
      
        kernel BUG at /work/Linux/linux-2.6-aarch64/mm/slab.c:2283!
        Internal error: Oops - BUG: 0 [#1] SMP
        Modules linked in:
        CPU: 0 PID: 0 Comm: swapper Not tainted 4.3.0-rc4+ #540
        Hardware name: Juno (DT)
        PC is at __kmem_cache_create+0x21c/0x280
        LR is at __kmem_cache_create+0x210/0x280
        [...]
        Call trace:
          __kmem_cache_create+0x21c/0x280
          create_boot_cache+0x48/0x80
          create_kmalloc_cache+0x50/0x88
          create_kmalloc_caches+0x4c/0xf4
          kmem_cache_init+0x100/0x118
          start_kernel+0x214/0x33c
      
      This patch introduces an OFF_SLAB_MIN_SIZE definition to avoid off-slab
      management objects for sizes equal to or smaller than KMALLOC_MIN_SIZE.
      
      Fixes: 8fc9cf42 ("slab: make more slab management structure off the slab")
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e028ec21
    • Christoph Hellwig's avatar
      scsi: restart list search after unlock in scsi_remove_target · 2ba3333e
      Christoph Hellwig authored
      commit 40998193 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 bc3f02a7
      Author: Dan Williams <djbw@fb.com>
      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
      
      http://thread.gmane.org/gmane.linux.kernel/1348679
      
      However, we believe even with this revert of the original patch, the soft
      lockup problem has been fixed by
      
      commit f2495e22
      Author: James Bottomley <JBottomley@Parallels.com>
      Date:   Tue Jan 21 07:01:41 2014 -0800
      
          [SCSI] dual scan thread bug fix
      
      Thanks go to Dan Williams <dan.j.williams@intel.com> for tracking all this
      prior history down.
      Reported-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Tested-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Fixes: bc3f02a7Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2ba3333e
    • Stefan Richter's avatar
      firewire: ohci: fix JMicron JMB38x IT context discovery · 8926d851
      Stefan Richter authored
      commit 100ceb66 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
      access.
      
      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
          result.
        - 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: default avatarCraig Moore <craig.moore@qenos.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8926d851
    • Alexandra Yates's avatar
      ALSA: hda - Add Intel Lewisburg device IDs Audio · 1efbcb95
      Alexandra Yates authored
      commit 5cf92c8b upstream.
      
      Adding Intel codename Lewisburg platform device IDs for audio.
      
      [rearranged the position by tiwai]
      Signed-off-by: default avatarAlexandra Yates <alexandra.yates@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1efbcb95
    • Takashi Iwai's avatar
      ALSA: hda - Apply pin fixup for HP ProBook 6550b · 28e2272a
      Takashi Iwai authored
      commit c932b98c 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.
      
      Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=191971Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      28e2272a
    • Krzysztof Kozlowski's avatar
      thermal: exynos: Fix unbalanced regulator disable on probe failure · 402b7ecc
      Krzysztof Kozlowski authored
      commit 824ead03 upstream.
      
      During probe if the regulator could not be enabled, the error exit path
      would still disable it. This could lead to unbalanced counter of
      regulator enable/disable.
      
      The patch moves code for getting and enabling the regulator from
      exynos_map_dt_data() to probe function because it is really not a part
      of getting Device Tree properties.
      Acked-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Tested-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Reviewed-by: default avatarAlim Akhtar <alim.akhtar@samsung.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 5f09a5cb ("thermal: exynos: Disable the regulator on probe failure")
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      402b7ecc
    • Radim Krčmář's avatar
      KVM: VMX: fix SMEP and SMAP without EPT · 2d4290b7
      Radim Krčmář authored
      commit 656ec4a4 upstream.
      
      The comment in code had it mostly right, but we enable paging for
      emulated real mode regardless of EPT.
      
      Without EPT (which implies emulated real mode), secondary VCPUs won't
      start unless we disable SM[AE]P when the guest doesn't use paging.
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2d4290b7
    • Li Bin's avatar
      recordmcount: arm64: Replace the ignored mcount call into nop · 44a41198
      Li Bin authored
      commit 2ee8a74f upstream.
      
      By now, the recordmcount only records the function that in
      following sections:
      .text/.ref.text/.sched.text/.spinlock.text/.irqentry.text/
      .kprobes.text/.text.unlikely
      
      For the function that not in these sections, the call mcount
      will be in place and not be replaced when kernel boot up. And
      it will bring performance overhead, such as do_mem_abort (in
      .exception.text section). This patch make the call mcount to
      nop for this case in recordmcount.
      
      Link: http://lkml.kernel.org/r/1446019445-14421-1-git-send-email-huawei.libin@huawei.com
      Link: http://lkml.kernel.org/r/1446193864-24593-4-git-send-email-huawei.libin@huawei.com
      
      Cc: <lkp@intel.com>
      Cc: <catalin.marinas@arm.com>
      Cc: <takahiro.akashi@linaro.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarLi Bin <huawei.libin@huawei.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      44a41198
    • libin's avatar
      recordmcount: Fix endianness handling bug for nop_mcount · aa7dc98c
      libin authored
      commit c84da8b9 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.
      
      Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.comSigned-off-by: default avatarLi Bin <huawei.libin@huawei.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      aa7dc98c
    • Max Filippov's avatar
      xtensa: fix secondary core boot in SMP · ab5e118a
      Max Filippov authored
      commit ab45fb14 upstream.
      
      There are multiple factors adding to the issue in different
      configurations:
      
      - commit 17290231 ("xtensa: add fixup for double exception raised
        in window overflow") added function window_overflow_restore_a0_fixup to
        double exception vector overlapping reset vector location of secondary
        processor cores.
      - on MMUv2 cores RESET_VECTOR1_VADDR may point to uncached kernel memory
        making code overlapping depend on cache type and size, so that without
        cache or with WT cache reset vector code overwrites double exception
        code, making issue even harder to detect.
      - on MMUv3 cores RESET_VECTOR1_VADDR may point to unmapped area, as
        MMUv3 cores change virtual address map to match MMUv2 layout, but
        reset vector virtual address is given for the original MMUv3 mapping.
      - physical memory region of the secondary reset vector is not reserved
        in the physical memory map, and thus may be allocated and overwritten
        at arbitrary moment.
      
      Fix it as follows:
      
      - move window_overflow_restore_a0_fixup code to .text section.
      - define RESET_VECTOR1_VADDR so that it points to reset vector in the
        cacheable MMUv2 map for cores with MMU.
      - reserve reset vector region in the physical memory map. Drop separate
        literal section and build mxhead.S with text section literals.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ab5e118a
    • Arik Nemtsov's avatar
      mac80211: allow null chandef in tracing · c5be932d
      Arik Nemtsov authored
      commit 254d3dfe upstream.
      
      In TDLS channel-switch operations the chandef can sometimes be NULL.
      Avoid an oops in the trace code for these cases and just print a
      chandef full of zeros.
      
      Fixes: a7a6bdd0 ("mac80211: introduce TDLS channel switch ops")
      Signed-off-by: default avatarArik Nemtsov <arikx.nemtsov@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c5be932d
    • Ola Olsson's avatar
      nl80211: Fix potential memory leak from parse_acl_data · 2d359552
      Ola Olsson authored
      commit 4baf6bea upstream.
      
      If parse_acl_data succeeds but the subsequent parsing of smps
      attributes fails, there will be a memory leak due to early returns.
      Fix that by moving the ACL parsing later.
      
      Fixes: 18998c38 ("cfg80211: allow requesting SMPS mode on ap start")
      Signed-off-by: default avatarOla Olsson <ola.olsson@sonymobile.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2d359552
    • Janusz.Dziedzic@tieto.com's avatar
      mac80211: fix divide by zero when NOA update · 3d69b3f0
      Janusz.Dziedzic@tieto.com authored
      commit 519ee691 upstream.
      
      In case of one shot NOA the interval can be 0, catch that
      instead of potentially (depending on the driver) crashing
      like this:
      
      divide error: 0000 [#1] SMP
      [...]
      Call Trace:
      <IRQ>
      [<ffffffffc08e891c>] ieee80211_extend_absent_time+0x6c/0xb0 [mac80211]
      [<ffffffffc08e8a17>] ieee80211_update_p2p_noa+0xb7/0xe0 [mac80211]
      [<ffffffffc069cc30>] ath9k_p2p_ps_timer+0x170/0x190 [ath9k]
      [<ffffffffc070adf8>] ath_gen_timer_isr+0xc8/0xf0 [ath9k_hw]
      [<ffffffffc0691156>] ath9k_tasklet+0x296/0x2f0 [ath9k]
      [<ffffffff8107ad65>] tasklet_action+0xe5/0xf0
      [...]
      Signed-off-by: default avatarJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3d69b3f0