1. 17 May, 2017 40 commits
    • Szymon Janc's avatar
      Bluetooth: Fix user channel for 32bit userspace on 64bit kernel · 9575253a
      Szymon Janc authored
      [ Upstream commit ab89f0bd ]
      
      Running 32bit userspace on 64bit kernel results in MSG_CMSG_COMPAT being
      defined as 0x80000000. This results in sendmsg failure if used from 32bit
      userspace running on 64bit kernel. Fix this by accounting for MSG_CMSG_COMPAT
      in flags check in hci_sock_sendmsg.
      Signed-off-by: default avatarSzymon Janc <szymon.janc@codecoup.pl>
      Signed-off-by: default avatarMarko Kiiskila <marko@runtime.io>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9575253a
    • Eric Biggers's avatar
      ext4: evict inline data when writing to memory map · ca38d087
      Eric Biggers authored
      [ Upstream commit 7b4cc978 ]
      
      Currently the case of writing via mmap to a file with inline data is not
      handled.  This is maybe a rare case since it requires a writable memory
      map of a very small file, but it is trivial to trigger with on
      inline_data filesystem, and it causes the
      'BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));' in
      ext4_writepages() to be hit:
      
          mkfs.ext4 -O inline_data /dev/vdb
          mount /dev/vdb /mnt
          xfs_io -f /mnt/file \
      	-c 'pwrite 0 1' \
      	-c 'mmap -w 0 1m' \
      	-c 'mwrite 0 1' \
      	-c 'fsync'
      
      	kernel BUG at fs/ext4/inode.c:2723!
      	invalid opcode: 0000 [#1] SMP
      	CPU: 1 PID: 2532 Comm: xfs_io Not tainted 4.11.0-rc1-xfstests-00301-g071d9acf3d1f #633
      	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
      	task: ffff88003d3a8040 task.stack: ffffc90000300000
      	RIP: 0010:ext4_writepages+0xc89/0xf8a
      	RSP: 0018:ffffc90000303ca0 EFLAGS: 00010283
      	RAX: 0000028410000000 RBX: ffff8800383fa3b0 RCX: ffffffff812afcdc
      	RDX: 00000a9d00000246 RSI: ffffffff81e660e0 RDI: 0000000000000246
      	RBP: ffffc90000303dc0 R08: 0000000000000002 R09: 869618e8f99b4fa5
      	R10: 00000000852287a2 R11: 00000000a03b49f4 R12: ffff88003808e698
      	R13: 0000000000000000 R14: 7fffffffffffffff R15: 7fffffffffffffff
      	FS:  00007fd3e53094c0(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 00007fd3e4c51000 CR3: 000000003d554000 CR4: 00000000003406e0
      	Call Trace:
      	 ? _raw_spin_unlock+0x27/0x2a
      	 ? kvm_clock_read+0x1e/0x20
      	 do_writepages+0x23/0x2c
      	 ? do_writepages+0x23/0x2c
      	 __filemap_fdatawrite_range+0x80/0x87
      	 filemap_write_and_wait_range+0x67/0x8c
      	 ext4_sync_file+0x20e/0x472
      	 vfs_fsync_range+0x8e/0x9f
      	 ? syscall_trace_enter+0x25b/0x2d0
      	 vfs_fsync+0x1c/0x1e
      	 do_fsync+0x31/0x4a
      	 SyS_fsync+0x10/0x14
      	 do_syscall_64+0x69/0x131
      	 entry_SYSCALL64_slow_path+0x25/0x25
      
      We could try to be smart and keep the inline data in this case, or at
      least support delayed allocation when allocating the block, but these
      solutions would be more complicated and don't seem worthwhile given how
      rare this case seems to be.  So just fix the bug by calling
      ext4_convert_inline_data() when we're asked to make a page writable, so
      that any inline data gets evicted, with the block allocated immediately.
      Reported-by: default avatarNick Alcock <nick.alcock@oracle.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ca38d087
    • Takashi Iwai's avatar
      proc: Fix unbalanced hard link numbers · 3a9700b0
      Takashi Iwai authored
      [ Upstream commit d66bb160 ]
      
      proc_create_mount_point() forgot to increase the parent's nlink, and
      it resulted in unbalanced hard link numbers, e.g. /proc/fs shows one
      less than expected.
      
      Fixes: eb6d38d5 ("proc: Allow creating permanently empty directories...")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarTristan Ye <tristan.ye@suse.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3a9700b0
    • Adrian Salido's avatar
      dm ioctl: prevent stack leak in dm ioctl call · 2279c8b9
      Adrian Salido authored
      [ Upstream commit 4617f564 ]
      
      When calling a dm ioctl that doesn't process any data
      (IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct
      dm_ioctl are left initialized.  Current code is incorrectly extending
      the size of data copied back to user, causing the contents of kernel
      stack to be leaked to user.  Fix by only copying contents before data
      and allow the functions processing the ioctl to override.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAdrian Salido <salidoa@google.com>
      Reviewed-by: default avatarAlasdair G Kergon <agk@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2279c8b9
    • J. Bruce Fields's avatar
      nfsd: stricter decoding of write-like NFSv2/v3 ops · 5afff19d
      J. Bruce Fields authored
      [ Upstream commit 13bf9fbf ]
      
      The NFSv2/v3 code does not systematically check whether we decode past
      the end of the buffer.  This generally appears to be harmless, but there
      are a few places where we do arithmetic on the pointers involved and
      don't account for the possibility that a length could be negative.  Add
      checks to catch these.
      Reported-by: default avatarTuomas Haanpää <thaan@synopsys.com>
      Reported-by: default avatarAri Kauppi <ari@synopsys.com>
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5afff19d
    • J. Bruce Fields's avatar
      nfsd4: minor NFSv2/v3 write decoding cleanup · 24c3569d
      J. Bruce Fields authored
      [ Upstream commit db44bac4 ]
      
      Use a couple shortcuts that will simplify a following bugfix.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      24c3569d
    • J. Bruce Fields's avatar
      nfsd: check for oversized NFSv2/v3 arguments · c9bb9f02
      J. Bruce Fields authored
      [ Upstream commit e6838a29 ]
      
      A client can append random data to the end of an NFSv2 or NFSv3 RPC call
      without our complaining; we'll just stop parsing at the end of the
      expected data and ignore the rest.
      
      Encoded arguments and replies are stored together in an array of pages,
      and if a call is too large it could leave inadequate space for the
      reply.  This is normally OK because NFS RPC's typically have either
      short arguments and long replies (like READ) or long arguments and short
      replies (like WRITE).  But a client that sends an incorrectly long reply
      can violate those assumptions.  This was observed to cause crashes.
      
      Also, several operations increment rq_next_page in the decode routine
      before checking the argument size, which can leave rq_next_page pointing
      well past the end of the page array, causing trouble later in
      svc_free_pages.
      
      So, following a suggestion from Neil Brown, add a central check to
      enforce our expectation that no NFSv2/v3 call has both a large call and
      a large reply.
      
      As followup we may also want to rewrite the encoding routines to check
      more carefully that they aren't running off the end of the page array.
      
      We may also consider rejecting calls that have any extra garbage
      appended.  That would be safer, and within our rights by spec, but given
      the age of our server and the NFS protocol, and the fact that we've
      never enforced this before, we may need to balance that against the
      possibility of breaking some oddball client.
      Reported-by: default avatarTuomas Haanpää <thaan@synopsys.com>
      Reported-by: default avatarAri Kauppi <ari@synopsys.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c9bb9f02
    • Alexey Brodkin's avatar
      usb: Make sure usb/phy/of gets built-in · 6a5e6149
      Alexey Brodkin authored
      [ Upstream commit 3d615964 ]
      
      DWC3 driver uses of_usb_get_phy_mode() which is
      implemented in drivers/usb/phy/of.c and in bare minimal
      configuration it might not be pulled in kernel binary.
      
      In case of ARC or ARM this could be easily reproduced with
      "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m.
      
      On building all ends-up with:
      ---------------------->8------------------
        Kernel: arch/arm/boot/Image is ready
        Kernel: arch/arm/boot/zImage is ready
        Building modules, stage 2.
        MODPOST 5 modules
      ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined!
      make[1]: *** [__modpost] Error 1
      make: *** [modules] Error 2
      ---------------------->8------------------
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: linux-snps-arc@lists.infradead.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6a5e6149
    • Takashi Iwai's avatar
      ASoC: intel: Fix PM and non-atomic crash in bytcr drivers · 37232313
      Takashi Iwai authored
      [ Upstream commit 6e4cac23 ]
      
      The FE setups of Intel SST bytcr_rt5640 and bytcr_rt5651 drivers carry
      the ignore_suspend flag, and this prevents the suspend/resume working
      properly while the stream is running, since SST core code has the
      check of the running streams and returns -EBUSY.  Drop these
      superfluous flags for fixing the behavior.
      
      Also, the bytcr_rt5640 driver lacks of nonatomic flag in some FE
      definitions, which leads to the kernel Oops at suspend/resume like:
      
        BUG: scheduling while atomic: systemd-sleep/3144/0x00000003
        Call Trace:
         dump_stack+0x5c/0x7a
         __schedule_bug+0x55/0x70
         __schedule+0x63c/0x8c0
         schedule+0x3d/0x90
         schedule_timeout+0x16b/0x320
         ? del_timer_sync+0x50/0x50
         ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
         ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
         ? remove_wait_queue+0x60/0x60
         ? sst_prepare_and_post_msg+0x275/0x960 [snd_intel_sst_core]
         ? sst_pause_stream+0x9b/0x110 [snd_intel_sst_core]
         ....
      
      This patch addresses these appropriately, too.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: <stable@vger.kernel.org> # v4.1+
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      37232313
    • Dmitry Torokhov's avatar
      Input: i8042 - add Clevo P650RS to the i8042 reset list · b583cc93
      Dmitry Torokhov authored
      [ Upstream commit 7c5bb4ac ]
      
      Clevo P650RS and other similar devices require i8042 to be reset in order
      to detect Synaptics touchpad.
      Reported-by: default avatarPaweł Bylica <chfast@gmail.com>
      Tested-by: default avatarEd Bordin <edbordin@gmail.com>
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=190301Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b583cc93
    • Somasundaram Krishnasamy's avatar
      dm era: save spacemap metadata root after the pre-commit · 56e19170
      Somasundaram Krishnasamy authored
      [ Upstream commit 117aceb0 ]
      
      When committing era metadata to disk, it doesn't always save the latest
      spacemap metadata root in superblock. Due to this, metadata is getting
      corrupted sometimes when reopening the device. The correct order of update
      should be, pre-commit (shadows spacemap root), save the spacemap root
      (newly shadowed block) to in-core superblock and then the final commit.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSomasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      56e19170
    • Vinothkumar Raja's avatar
      dm btree: fix for dm_btree_find_lowest_key() · 6a887571
      Vinothkumar Raja authored
      [ Upstream commit 7d1fedb6 ]
      
      dm_btree_find_lowest_key() is giving incorrect results.  find_key()
      traverses the btree correctly for finding the highest key, but there is
      an error in the way it traverses the btree for retrieving the lowest
      key.  dm_btree_find_lowest_key() fetches the first key of the rightmost
      block of the btree instead of fetching the first key from the leftmost
      block.
      
      Fix this by conditionally passing the correct parameter to value64()
      based on the @find_highest flag.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarErez Zadok <ezk@fsl.cs.sunysb.edu>
      Signed-off-by: default avatarVinothkumar Raja <vinraja@cs.stonybrook.edu>
      Signed-off-by: default avatarNidhi Panpalia <npanpalia@cs.stonybrook.edu>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6a887571
    • Tyrel Datwyler's avatar
      powerpc/pseries: Fix of_node_put() underflow during DLPAR remove · 2ad7696b
      Tyrel Datwyler authored
      [ Upstream commit 68baf692 ]
      
      Historically struct device_node references were tracked using a kref embedded as
      a struct field. Commit 75b57ecf ("of: Make device nodes kobjects so they
      show up in sysfs") (Mar 2014) refactored device_nodes to be kobjects such that
      the device tree could by more simply exposed to userspace using sysfs.
      
      Commit 0829f6d1 ("of: device_node kobject lifecycle fixes") (Mar 2014)
      followed up these changes to better control the kobject lifecycle and in
      particular the referecne counting via of_node_get(), of_node_put(), and
      of_node_init().
      
      A result of this second commit was that it introduced an of_node_put() call when
      a dynamic node is detached, in of_node_remove(), that removes the initial kobj
      reference created by of_node_init().
      
      Traditionally as the original dynamic device node user the pseries code had
      assumed responsibilty for releasing this final reference in its platform
      specific DLPAR detach code.
      
      This patch fixes a refcount underflow introduced by commit 0829f6d1, and
      recently exposed by the upstreaming of the recount API.
      
      Messages like the following are no longer seen in the kernel log with this
      patch following DLPAR remove operations of cpus and pci devices.
      
        rpadlpar_io: slot PHB 72 removed
        refcount_t: underflow; use-after-free.
        ------------[ cut here ]------------
        WARNING: CPU: 5 PID: 3335 at lib/refcount.c:128 refcount_sub_and_test+0xf4/0x110
      
      Fixes: 0829f6d1 ("of: device_node kobject lifecycle fixes")
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      [mpe: Make change log commit references more verbose]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2ad7696b
    • Jack Morgenstein's avatar
      IB/mlx4: Fix ib device initialization error flow · e756dc9e
      Jack Morgenstein authored
      [ Upstream commit 99e68909 ]
      
      In mlx4_ib_add, procedure mlx4_ib_alloc_eqs is called to allocate EQs.
      
      However, in the mlx4_ib_add error flow, procedure mlx4_ib_free_eqs is not
      called to free the allocated EQs.
      
      Fixes: e605b743 ("IB/mlx4: Increase the number of vectors (EQs) available for ULPs")
      Cc: <stable@vger.kernel.org> # v3.4+
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e756dc9e
    • Ashish Kalra's avatar
      x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup · 50f63ac7
      Ashish Kalra authored
      [ Upstream commit d594aa02 ]
      
      The minimum size for a new stack (512 bytes) setup for arch/x86/boot components
      when the bootloader does not setup/provide a stack for the early boot components
      is not "enough".
      
      The setup code executing as part of early kernel startup code, uses the stack
      beyond 512 bytes and accidentally overwrites and corrupts part of the BSS
      section. This is exposed mostly in the early video setup code, where
      it was corrupting BSS variables like force_x, force_y, which in-turn affected
      kernel parameters such as screen_info (screen_info.orig_video_cols) and
      later caused an exception/panic in console_init().
      
      Most recent boot loaders setup the stack for early boot components, so this
      stack overwriting into BSS section issue has not been exposed.
      Signed-off-by: default avatarAshish Kalra <ashish@bluestacks.com>
      Cc: <stable@vger.kernel.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.localSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      50f63ac7
    • Steven Rostedt (VMware)'s avatar
      ring-buffer: Have ring_buffer_iter_empty() return true when empty · 51cad457
      Steven Rostedt (VMware) authored
      [ Upstream commit 78f7a45d ]
      
      I noticed that reading the snapshot file when it is empty no longer gives a
      status. It suppose to show the status of the snapshot buffer as well as how
      to allocate and use it. For example:
      
       ># cat snapshot
       # tracer: nop
       #
       #
       # * Snapshot is allocated *
       #
       # Snapshot commands:
       # echo 0 > snapshot : Clears and frees snapshot buffer
       # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
       #                      Takes a snapshot of the main buffer.
       # echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free)
       #                      (Doesn't have to be '2' works with any number that
       #                       is not a '0' or '1')
      
      But instead it just showed an empty buffer:
      
       ># cat snapshot
       # tracer: nop
       #
       # entries-in-buffer/entries-written: 0/0   #P:4
       #
       #                              _-----=> irqs-off
       #                             / _----=> need-resched
       #                            | / _---=> hardirq/softirq
       #                            || / _--=> preempt-depth
       #                            ||| /     delay
       #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
       #              | |       |   ||||       |         |
      
      What happened was that it was using the ring_buffer_iter_empty() function to
      see if it was empty, and if it was, it showed the status. But that function
      was returning false when it was empty. The reason was that the iter header
      page was on the reader page, and the reader page was empty, but so was the
      buffer itself. The check only tested to see if the iter was on the commit
      page, but the commit page was no longer pointing to the reader page, but as
      all pages were empty, the buffer is also.
      
      Cc: stable@vger.kernel.org
      Fixes: 651e22f2 ("ring-buffer: Always reset iterator to reader page")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      51cad457
    • Arnd Bergmann's avatar
      ACPI / power: Avoid maybe-uninitialized warning · 2933c0ba
      Arnd Bergmann authored
      [ Upstream commit fe8c470a ]
      
      gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state()
      is enterered at least once, so it assumes that cur_state might not get
      initialized:
      
      drivers/acpi/power.c: In function 'acpi_power_get_inferred_state':
      drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      This sets the variable to zero at the start of the loop, to ensure that
      there is well-defined behavior even for an empty list. This gets rid of
      the warning.
      
      The warning first showed up when the -Os flag got removed in a bug fix
      patch in linux-4.11-rc5.
      
      I would suggest merging this addon patch on top of that bug fix to avoid
      introducing a new warning in the stable kernels.
      
      Fixes: 61b79e16 (ACPI: Fix incompatibility with mcount-based function graph tracing)
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2933c0ba
    • Steven Rostedt (VMware)'s avatar
      tracing: Allocate the snapshot buffer before enabling probe · f7f44f58
      Steven Rostedt (VMware) authored
      [ Upstream commit df62db5b ]
      
      Currently the snapshot trigger enables the probe and then allocates the
      snapshot. If the probe triggers before the allocation, it could cause the
      snapshot to fail and turn tracing off. It's best to allocate the snapshot
      buffer first, and then enable the trigger. If something goes wrong in the
      enabling of the trigger, the snapshot buffer is still allocated, but it can
      also be freed by the user by writting zero into the snapshot buffer file.
      
      Also add a check of the return status of alloc_snapshot().
      
      Cc: stable@vger.kernel.org
      Fixes: 77fd5c15 ("tracing: Add snapshot trigger to function probes")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f7f44f58
    • Peter Chen's avatar
      usb: host: xhci: print correct command ring address · 73270592
      Peter Chen authored
      [ Upstream commit 6fc091fb ]
      
      Print correct command ring address using 'val_64'.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      73270592
    • Alyssa Milburn's avatar
      [media] ttusb2: limit messages to buffer size · 5ba52c08
      Alyssa Milburn authored
      [ Upstream commit a12b8ab8 ]
      
      Otherwise ttusb2_i2c_xfer can read or write beyond the end of static and
      heap buffers.
      Signed-off-by: default avatarAlyssa Milburn <amilburn@zall.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5ba52c08
    • Marek Vasut's avatar
      USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit · e1dfe98d
      Marek Vasut authored
      [ Upstream commit 31c5d192 ]
      
      This development kit has an FT4232 on it with a custom USB VID/PID.
      The FT4232 provides four UARTs, but only two are used. The UART 0
      is used by the FlashPro5 programmer and UART 2 is connected to the
      SmartFusion2 CortexM3 SoC UART port.
      
      Note that the USB VID is registered to Actel according to Linux USB
      VID database, but that was acquired by Microsemi.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e1dfe98d
    • Lukas Wunner's avatar
      PCI: Freeze PME scan before suspending devices · 00461b9f
      Lukas Wunner authored
      [ Upstream commit ea00353f ]
      
      Laurent Pinchart reported that the Renesas R-Car H2 Lager board (r8a7790)
      crashes during suspend tests.  Geert Uytterhoeven managed to reproduce the
      issue on an M2-W Koelsch board (r8a7791):
      
        It occurs when the PME scan runs, once per second.  During PME scan, the
        PCI host bridge (rcar-pci) registers are accessed while its module clock
        has already been disabled, leading to the crash.
      
      One reproducer is to configure s2ram to use "s2idle" instead of "deep"
      suspend:
      
        # echo 0 > /sys/module/printk/parameters/console_suspend
        # echo s2idle > /sys/power/mem_sleep
        # echo mem > /sys/power/state
      
      Another reproducer is to write either "platform" or "processors" to
      /sys/power/pm_test.  It does not (or is less likely) to happen during full
      system suspend ("core" or "none") because system suspend also disables
      timers, and thus the workqueue handling PME scans no longer runs.  Geert
      believes the issue may still happen in the small window between disabling
      module clocks and disabling timers:
      
        # echo 0 > /sys/module/printk/parameters/console_suspend
        # echo platform > /sys/power/pm_test    # Or "processors"
        # echo mem > /sys/power/state
      
      (Make sure CONFIG_PCI_RCAR_GEN2 and CONFIG_USB_OHCI_HCD_PCI are enabled.)
      
      Rafael Wysocki agrees that PME scans should be suspended before the host
      bridge registers become inaccessible.  To that end, queue the task on a
      workqueue that gets frozen before devices suspend.
      
      Rafael notes however that as a result, some wakeup events may be missed if
      they are delivered via PME from a device without working IRQ (which hence
      must be polled) and occur after the workqueue has been frozen.  If that
      turns out to be an issue in practice, it may be possible to solve it by
      calling pci_pme_list_scan() once directly from one of the host bridge's
      pm_ops callbacks.
      
      Stacktrace for posterity:
      
        PM: Syncing filesystems ... [   38.566237] done.
        PM: Preparing system for sleep (mem)
        Freezing user space processes ... [   38.579813] (elapsed 0.001 seconds) done.
        Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
        PM: Suspending system (mem)
        PM: suspend of devices complete after 152.456 msecs
        PM: late suspend of devices complete after 2.809 msecs
        PM: noirq suspend of devices complete after 29.863 msecs
        suspend debug: Waiting for 5 second(s).
        Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
        pgd = c0003000
        [00000000] *pgd=80000040004003, *pmd=00000000
        Internal error: : 1211 [#1] SMP ARM
        Modules linked in:
        CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted
        4.9.0-rc1-koelsch-00011-g68db9bc8 #3383
        Hardware name: Generic R8A7791 (Flattened Device Tree)
        Workqueue: events pci_pme_list_scan
        task: eb56e140 task.stack: eb58e000
        PC is at pci_generic_config_read+0x64/0x6c
        LR is at rcar_pci_cfg_base+0x64/0x84
        pc : [<c041d7b4>]    lr : [<c04309a0>]    psr: 600d0093
        sp : eb58fe98  ip : c041d750  fp : 00000008
        r10: c0e2283c  r9 : 00000000  r8 : 600d0013
        r7 : 00000008  r6 : eb58fed6  r5 : 00000002  r4 : eb58feb4
        r3 : 00000000  r2 : 00000044  r1 : 00000008  r0 : 00000000
        Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
        Control: 30c5387d  Table: 6a9f6c80  DAC: 55555555
        Process kworker/1:1 (pid: 20, stack limit = 0xeb58e210)
        Stack: (0xeb58fe98 to 0xeb590000)
        fe80:                                                       00000002 00000044
        fea0: eb6f5800 c041d9b0 eb58feb4 00000008 00000044 00000000 eb78a000 eb78a000
        fec0: 00000044 00000000 eb9aff00 c0424bf0 eb78a000 00000000 eb78a000 c0e22830
        fee0: ea8a6fc0 c0424c5c eaae79c0 c0424ce0 eb55f380 c0e22838 eb9a9800 c0235fbc
        ff00: eb55f380 c0e22838 eb55f380 eb9a9800 eb9a9800 eb58e000 eb9a9824 c0e02100
        ff20: eb55f398 c02366c4 eb56e140 eb5631c0 00000000 eb55f380 c023641c 00000000
        ff40: 00000000 00000000 00000000 c023a928 cd105598 00000000 40506a34 eb55f380
        ff60: 00000000 00000000 dead4ead ffffffff ffffffff eb58ff74 eb58ff74 00000000
        ff80: 00000000 dead4ead ffffffff ffffffff eb58ff90 eb58ff90 eb58ffac eb5631c0
        ffa0: c023a844 00000000 00000000 c0206d68 00000000 00000000 00000000 00000000
        ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 3a81336c 10ccd1dd
        [<c041d7b4>] (pci_generic_config_read) from [<c041d9b0>]
        (pci_bus_read_config_word+0x58/0x80)
        [<c041d9b0>] (pci_bus_read_config_word) from [<c0424bf0>]
        (pci_check_pme_status+0x34/0x78)
        [<c0424bf0>] (pci_check_pme_status) from [<c0424c5c>] (pci_pme_wakeup+0x28/0x54)
        [<c0424c5c>] (pci_pme_wakeup) from [<c0424ce0>] (pci_pme_list_scan+0x58/0xb4)
        [<c0424ce0>] (pci_pme_list_scan) from [<c0235fbc>]
        (process_one_work+0x1bc/0x308)
        [<c0235fbc>] (process_one_work) from [<c02366c4>] (worker_thread+0x2a8/0x3e0)
        [<c02366c4>] (worker_thread) from [<c023a928>] (kthread+0xe4/0xfc)
        [<c023a928>] (kthread) from [<c0206d68>] (ret_from_fork+0x14/0x2c)
        Code: ea000000 e5903000 f57ff04f e3a00000 (e5843000)
        ---[ end trace 667d43ba3aa9e589 ]---
      
      Fixes: df17e62e ("PCI: Add support for polling PME state on suspended legacy PCI devices")
      Reported-and-tested-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Reported-and-tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: stable@vger.kernel.org	# 2.6.37+
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Cc: Simon Horman <horms+renesas@verge.net.au>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      00461b9f
    • Richard Cochran's avatar
      regulator: tps65023: Fix inverted core enable logic. · 57b8e3a6
      Richard Cochran authored
      [ Upstream commit c90722b5 ]
      
      Commit 43530b69 ("regulator: Use
      regmap_read/write(), regmap_update_bits functions directly") intended
      to replace working inline helper functions with standard regmap
      calls.  However, it also inverted the set/clear logic of the "CORE ADJ
      Allowed" bit.  That patch was clearly never tested, since without that
      bit cleared, the core VDCDC1 voltage output does not react to I2C
      configuration changes.
      
      This patch fixes the issue by clearing the bit as in the original,
      correct implementation.  Note for stable back porting that, due to
      subsequent driver churn, this patch will not apply on every kernel
      version.
      
      Fixes: 43530b69 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly")
      Signed-off-by: default avatarRichard Cochran <rcochran@linutronix.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      57b8e3a6
    • Alyssa Milburn's avatar
      [media] zr364xx: enforce minimum size when reading header · 1ff62906
      Alyssa Milburn authored
      [ Upstream commit ee0fe833 ]
      
      This code copies actual_length-128 bytes from the header, which will
      underflow if the received buffer is too small.
      Signed-off-by: default avatarAlyssa Milburn <amilburn@zall.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1ff62906
    • Eric Biggers's avatar
      KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings · a0f82864
      Eric Biggers authored
      [ Upstream commit c9f838d1 ]
      
      This fixes CVE-2017-7472.
      
      Running the following program as an unprivileged user exhausts kernel
      memory by leaking thread keyrings:
      
      	#include <keyutils.h>
      
      	int main()
      	{
      		for (;;)
      			keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING);
      	}
      
      Fix it by only creating a new thread keyring if there wasn't one before.
      To make things more consistent, make install_thread_keyring_to_cred()
      and install_process_keyring_to_cred() both return 0 if the corresponding
      keyring is already present.
      
      Fixes: d84f4f99 ("CRED: Inaugurate COW credentials")
      Cc: stable@vger.kernel.org # 2.6.29+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a0f82864
    • David Howells's avatar
      KEYS: Change the name of the dead type to ".dead" to prevent user access · 86d961e2
      David Howells authored
      [ Upstream commit c1644fe0 ]
      
      This fixes CVE-2017-6951.
      
      Userspace should not be able to do things with the "dead" key type as it
      doesn't have some of the helper functions set upon it that the kernel
      needs.  Attempting to use it may cause the kernel to crash.
      
      Fix this by changing the name of the type to ".dead" so that it's rejected
      up front on userspace syscalls by key_get_type_from_user().
      
      Though this doesn't seem to affect recent kernels, it does affect older
      ones, certainly those prior to:
      
      	commit c06cfb08
      	Author: David Howells <dhowells@redhat.com>
      	Date:   Tue Sep 16 17:36:06 2014 +0100
      	KEYS: Remove key_type::match in favour of overriding default by match_preparse
      
      which went in before 3.18-rc1.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      86d961e2
    • David Howells's avatar
      KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings · 4ef48e49
      David Howells authored
      [ Upstream commit ee8f844e ]
      
      This fixes CVE-2016-9604.
      
      Keyrings whose name begin with a '.' are special internal keyrings and so
      userspace isn't allowed to create keyrings by this name to prevent
      shadowing.  However, the patch that added the guard didn't fix
      KEYCTL_JOIN_SESSION_KEYRING.  Not only can that create dot-named keyrings,
      it can also subscribe to them as a session keyring if they grant SEARCH
      permission to the user.
      
      This, for example, allows a root process to set .builtin_trusted_keys as
      its session keyring, at which point it has full access because now the
      possessor permissions are added.  This permits root to add extra public
      keys, thereby bypassing module verification.
      
      This also affects kexec and IMA.
      
      This can be tested by (as root):
      
      	keyctl session .builtin_trusted_keys
      	keyctl add user a a @s
      	keyctl list @s
      
      which on my test box gives me:
      
      	2 keys in keyring:
      	180010936: ---lswrv     0     0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05
      	801382539: --alswrv     0     0 user: a
      
      Fix this by rejecting names beginning with a '.' in the keyctl.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      cc: linux-ima-devel@lists.sourceforge.net
      cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      4ef48e49
    • Ravi Bangoria's avatar
      powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction · 369cd393
      Ravi Bangoria authored
      [ Upstream commit 9e1ba4f2 ]
      
      If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel
      OOPS:
      
        Bad kernel stack pointer cd93c840 at c000000000009868
        Oops: Bad kernel stack pointer, sig: 6 [#1]
        ...
        GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840
        ...
        NIP [c000000000009868] resume_kernel+0x2c/0x58
        LR [c000000000006208] program_check_common+0x108/0x180
      
      On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does
      not emulate actual store in emulate_step() because it may corrupt the exception
      frame. So the kernel does the actual store operation in exception return code
      i.e. resume_kernel().
      
      resume_kernel() loads the saved stack pointer from memory using lwz, which only
      loads the low 32-bits of the address, causing the kernel crash.
      
      Fix this by loading the 64-bit value instead.
      
      Fixes: be96f633 ("powerpc: Split out instruction analysis part of emulate_step()")
      Cc: stable@vger.kernel.org # v3.18+
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Reviewed-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Reviewed-by: default avatarAnanth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      [mpe: Change log massage, add stable tag]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      369cd393
    • Sachin Prabhu's avatar
      cifs: Do not send echoes before Negotiate is complete · 199ea04d
      Sachin Prabhu authored
      [ Upstream commit 62a6cfdd ]
      
      commit 4fcd1813 ("Fix reconnect to not defer smb3 session reconnect
      long after socket reconnect") added support for Negotiate requests to
      be initiated by echo calls.
      
      To avoid delays in calling echo after a reconnect, I added the patch
      introduced by the commit b8c60012 ("Call echo service immediately
      after socket reconnect").
      
      This has however caused a regression with cifs shares which do not have
      support for echo calls to trigger Negotiate requests. On connections
      which need to call Negotiation, the echo calls trigger an error which
      triggers a reconnect which in turn triggers another echo call. This
      results in a loop which is only broken when an operation is performed on
      the cifs share. For an idle share, it can DOS a server.
      
      The patch uses the smb_operation can_echo() for cifs so that it is
      called only if connection has been already been setup.
      
      kernel bz: 194531
      Signed-off-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Tested-by: default avatarJonathan Liu <net147@gmail.com>
      Acked-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      199ea04d
    • Al Viro's avatar
      p9_client_readdir() fix · b291f2ed
      Al Viro authored
      [ Upstream commit 71d6ad08 ]
      
      Don't assume that server is sane and won't return more data than
      asked for.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b291f2ed
    • Ludovic Desroches's avatar
      ARM: dts: at91: sama5d3_xplained: not all ADC channels are available · 98ae917f
      Ludovic Desroches authored
      [ Upstream commit d3df1ec0 ]
      
      Remove ADC channels that are not available by default on the sama5d3_xplained
      board (resistor not populated) in order to not create confusion.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Cc: <stable@vger.kernel.org> # 3.16+
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      98ae917f
    • Ludovic Desroches's avatar
      ARM: dts: at91: sama5d3_xplained: fix ADC vref · 42995731
      Ludovic Desroches authored
      [ Upstream commit 9cdd31e5 ]
      
      The voltage reference for the ADC is not 3V but 3.3V since it is connected to
      VDDANA.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Cc: <stable@vger.kernel.org> # 3.16+
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      42995731
    • Minchan Kim's avatar
      zram: do not use copy_page with non-page aligned address · c7f3669c
      Minchan Kim authored
      [ Upstream commit d72e9a7a ]
      
      The copy_page is optimized memcpy for page-alinged address.  If it is
      used with non-page aligned address, it can corrupt memory which means
      system corruption.  With zram, it can happen with
      
      1. 64K architecture
      2. partial IO
      3. slub debug
      
      Partial IO need to allocate a page and zram allocates it via kmalloc.
      With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned
      address.  And finally, copy_page(mem, cmem) corrupts memory.
      
      So, this patch changes it to memcpy.
      
      Actuaully, we don't need to change zram_bvec_write part because zsmalloc
      returns page-aligned address in case of PAGE_SIZE class but it's not
      good to rely on the internal of zsmalloc.
      
      Note:
       When this patch is merged to stable, clear_page should be fixed, too.
       Unfortunately, recent zram removes it by "same page merge" feature so
       it's hard to backport this patch to -stable tree.
      
      I will handle it when I receive the mail from stable tree maintainer to
      merge this patch to backport.
      
      Fixes: 42e99bd9 ("zram: optimize memory operations with clear_page()/copy_page()")
      Link: http://lkml.kernel.org/r/1492042622-12074-2-git-send-email-minchan@kernel.orgSigned-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: <stable@vger.kernel.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 avatarSasha Levin <alexander.levin@verizon.com>
      c7f3669c
    • Minchan Kim's avatar
      zram: fix operator precedence to get offset · ac87ea2f
      Minchan Kim authored
      [ Upstream commit 4ca82dab ]
      
      In zram_rw_page, the logic to get offset is wrong by operator precedence
      (i.e., "<<" is higher than "&").  With wrong offset, zram can corrupt
      the user's data.  This patch fixes it.
      
      Fixes: 8c7f0102 ("zram: implement rw_page operation of zram")
      Link: http://lkml.kernel.org/r/1492042622-12074-1-git-send-email-minchan@kernel.orgSigned-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: <stable@vger.kernel.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 avatarSasha Levin <alexander.levin@verizon.com>
      ac87ea2f
    • Takashi Iwai's avatar
      ALSA: seq: Don't break snd_use_lock_sync() loop by timeout · 7bee1c58
      Takashi Iwai authored
      [ Upstream commit 4e7655fd ]
      
      The snd_use_lock_sync() (thus its implementation
      snd_use_lock_sync_helper()) has the 5 seconds timeout to break out of
      the sync loop.  It was introduced from the beginning, just to be
      "safer", in terms of avoiding the stupid bugs.
      
      However, as Ben Hutchings suggested, this timeout rather introduces a
      potential leak or use-after-free that was apparently fixed by the
      commit 2d7d5400 ("ALSA: seq: Fix race during FIFO resize"):
      for example, snd_seq_fifo_event_in() -> snd_seq_event_dup() ->
      copy_from_user() could block for a long time, and snd_use_lock_sync()
      goes timeout and still leaves the cell at releasing the pool.
      
      For fixing such a problem, we remove the break by the timeout while
      still keeping the warning.
      Suggested-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7bee1c58
    • James Hogan's avatar
      MIPS: KGDB: Use kernel context for sleeping threads · 93dfafee
      James Hogan authored
      [ Upstream commit 162b270c ]
      
      KGDB is a kernel debug stub and it can't be used to debug userland as it
      can only safely access kernel memory.
      
      On MIPS however KGDB has always got the register state of sleeping
      processes from the userland register context at the beginning of the
      kernel stack. This is meaningless for kernel threads (which never enter
      userland), and for user threads it prevents the user seeing what it is
      doing while in the kernel:
      
      (gdb) info threads
        Id   Target Id         Frame
        ...
        3    Thread 2 (kthreadd) 0x0000000000000000 in ?? ()
        2    Thread 1 (init)   0x000000007705c4b4 in ?? ()
        1    Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201
      
      Get the register state instead from the (partial) kernel register
      context stored in the task's thread_struct for resume() to restore. All
      threads now correctly appear to be in context_switch():
      
      (gdb) info threads
        Id   Target Id         Frame
        ...
        3    Thread 2 (kthreadd) context_switch (rq=<optimized out>, cookie=..., next=<optimized out>, prev=0x0) at kernel/sched/core.c:2903
        2    Thread 1 (init)   context_switch (rq=<optimized out>, cookie=..., next=<optimized out>, prev=0x0) at kernel/sched/core.c:2903
        1    Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201
      
      Call clobbered registers which aren't saved and exception registers
      (BadVAddr & Cause) which can't be easily determined without stack
      unwinding are reported as 0. The PC is taken from the return address,
      such that the state presented matches that found immediately after
      returning from resume().
      
      Fixes: 88547001 ("[MIPS] kgdb: add arch support for the kernel's kgdb core")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/15829/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      93dfafee
    • David Woodhouse's avatar
      PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms · 22afb4fc
      David Woodhouse authored
      [ Upstream commit 6bccc7f4 ]
      
      In the PCI_MMAP_PROCFS case when the address being passed by the user is a
      'user visible' resource address based on the bus window, and not the actual
      contents of the resource, that's what we need to be checking it against.
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      22afb4fc
    • James Cowgill's avatar
      MIPS: Avoid BUG warning in arch_check_elf · 1ecc90c7
      James Cowgill authored
      [ Upstream commit c46f59e9 ]
      
      arch_check_elf contains a usage of current_cpu_data that will call
      smp_processor_id() with preemption enabled and therefore triggers a
      "BUG: using smp_processor_id() in preemptible" warning when an fpxx
      executable is loaded.
      
      As a follow-up to commit b244614a ("MIPS: Avoid a BUG warning during
      prctl(PR_SET_FP_MODE, ...)"), apply the same fix to arch_check_elf by
      using raw_current_cpu_data instead. The rationale quoted from the previous
      commit:
      
      "It is assumed throughout the kernel that if any CPU has an FPU, then
      all CPUs would have an FPU as well, so it is safe to perform the check
      with preemption enabled - change the code to use raw_ variant of the
      check to avoid the warning."
      
      Fixes: 46490b57 ("MIPS: kernel: elf: Improve the overall ABI and FPU mode checks")
      Signed-off-by: default avatarJames Cowgill <James.Cowgill@imgtec.com>
      CC: <stable@vger.kernel.org> # 4.0+
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/15951/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1ecc90c7
    • Christian Borntraeger's avatar
      s390/mm: fix CMMA vs KSM vs others · 396f0fe4
      Christian Borntraeger authored
      [ Upstream commit a8f60d1f ]
      
      On heavy paging with KSM I see guest data corruption. Turns out that
      KSM will add pages to its tree, where the mapping return true for
      pte_unused (or might become as such later).  KSM will unmap such pages
      and reinstantiate with different attributes (e.g. write protected or
      special, e.g. in replace_page or write_protect_page)). This uncovered
      a bug in our pagetable handling: We must remove the unused flag as
      soon as an entry becomes present again.
      
      Cc: stable@vger.kernel.org
      Signed-of-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      396f0fe4
    • Johan Hovold's avatar
      serial: omap: suspend device on probe errors · fab0b034
      Johan Hovold authored
      [ Upstream commit 77e6fe7f ]
      
      Make sure to actually suspend the device before returning after a failed
      (or deferred) probe.
      
      Note that autosuspend must be disabled before runtime pm is disabled in
      order to balance the usage count due to a negative autosuspend delay as
      well as to make the final put suspend the device synchronously.
      
      Fixes: 388bc262 ("omap-serial: Fix the error handling in the omap_serial probe")
      Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      fab0b034