1. 28 Oct, 2016 10 commits
  2. 22 Oct, 2016 26 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.27 · 3afd8362
      Greg Kroah-Hartman authored
      3afd8362
    • Glauber Costa's avatar
      cfq: fix starvation of asynchronous writes · c7077fba
      Glauber Costa authored
      commit 3932a86b upstream.
      
      While debugging timeouts happening in my application workload (ScyllaDB), I have
      observed calls to open() taking a long time, ranging everywhere from 2 seconds -
      the first ones that are enough to time out my application - to more than 30
      seconds.
      
      The problem seems to happen because XFS may block on pending metadata updates
      under certain circumnstances, and that's confirmed with the following backtrace
      taken by the offcputime tool (iovisor/bcc):
      
          ffffffffb90c57b1 finish_task_switch
          ffffffffb97dffb5 schedule
          ffffffffb97e310c schedule_timeout
          ffffffffb97e1f12 __down
          ffffffffb90ea821 down
          ffffffffc046a9dc xfs_buf_lock
          ffffffffc046abfb _xfs_buf_find
          ffffffffc046ae4a xfs_buf_get_map
          ffffffffc046babd xfs_buf_read_map
          ffffffffc0499931 xfs_trans_read_buf_map
          ffffffffc044a561 xfs_da_read_buf
          ffffffffc0451390 xfs_dir3_leaf_read.constprop.16
          ffffffffc0452b90 xfs_dir2_leaf_lookup_int
          ffffffffc0452e0f xfs_dir2_leaf_lookup
          ffffffffc044d9d3 xfs_dir_lookup
          ffffffffc047d1d9 xfs_lookup
          ffffffffc0479e53 xfs_vn_lookup
          ffffffffb925347a path_openat
          ffffffffb9254a71 do_filp_open
          ffffffffb9242a94 do_sys_open
          ffffffffb9242b9e sys_open
          ffffffffb97e42b2 entry_SYSCALL_64_fastpath
          00007fb0698162ed [unknown]
      
      Inspecting my run with blktrace, I can see that the xfsaild kthread exhibit very
      high "Dispatch wait" times, on the dozens of seconds range and consistent with
      the open() times I have saw in that run.
      
      Still from the blktrace output, we can after searching a bit, identify the
      request that wasn't dispatched:
      
        8,0   11      152    81.092472813   804  A  WM 141698288 + 8 <- (8,1) 141696240
        8,0   11      153    81.092472889   804  Q  WM 141698288 + 8 [xfsaild/sda1]
        8,0   11      154    81.092473207   804  G  WM 141698288 + 8 [xfsaild/sda1]
        8,0   11      206    81.092496118   804  I  WM 141698288 + 8 (   22911) [xfsaild/sda1]
        <==== 'I' means Inserted (into the IO scheduler) ===================================>
        8,0    0   289372    96.718761435     0  D  WM 141698288 + 8 (15626265317) [swapper/0]
        <==== Only 15s later the CFQ scheduler dispatches the request ======================>
      
      As we can see above, in this particular example CFQ took 15 seconds to dispatch
      this request. Going back to the full trace, we can see that the xfsaild queue
      had plenty of opportunity to run, and it was selected as the active queue many
      times. It would just always be preempted by something else (example):
      
        8,0    1        0    81.117912979     0  m   N cfq1618SN / insert_request
        8,0    1        0    81.117913419     0  m   N cfq1618SN / add_to_rr
        8,0    1        0    81.117914044     0  m   N cfq1618SN / preempt
        8,0    1        0    81.117914398     0  m   N cfq767A  / slice expired t=1
        8,0    1        0    81.117914755     0  m   N cfq767A  / resid=40
        8,0    1        0    81.117915340     0  m   N / served: vt=1948520448 min_vt=1948520448
        8,0    1        0    81.117915858     0  m   N cfq767A  / sl_used=1 disp=0 charge=0 iops=1 sect=0
      
      where cfq767 is the xfsaild queue and cfq1618 corresponds to one of the ScyllaDB
      IO dispatchers.
      
      The requests preempting the xfsaild queue are synchronous requests. That's a
      characteristic of ScyllaDB workloads, as we only ever issue O_DIRECT requests.
      While it can be argued that preempting ASYNC requests in favor of SYNC is part
      of the CFQ logic, I don't believe that doing so for 15+ seconds is anyone's
      goal.
      
      Moreover, unless I am misunderstanding something, that breaks the expectation
      set by the "fifo_expire_async" tunable, which in my system is set to the
      default.
      
      Looking at the code, it seems to me that the issue is that after we make
      an async queue active, there is no guarantee that it will execute any request.
      
      When the queue itself tests if it cfq_may_dispatch() it can bail if it sees SYNC
      requests in flight. An incoming request from another queue can also preempt it
      in such situation before we have the chance to execute anything (as seen in the
      trace above).
      
      This patch sets the must_dispatch flag if we notice that we have requests
      that are already fifo_expired. This flag is always cleared after
      cfq_dispatch_request() returns from cfq_dispatch_requests(), so it won't pin
      the queue for subsequent requests (unless they are themselves expired)
      
      Care is taken during preempt to still allow rt requests to preempt us
      regardless.
      
      Testing my workload with this patch applied produces much better results.
      From the application side I see no timeouts, and the open() latency histogram
      generated by systemtap looks much better, with the worst outlier at 131ms:
      
      Latency histogram of xfs_buf_lock acquisition (microseconds):
       value |-------------------------------------------------- count
           0 |                                                     11
           1 |@@@@                                                161
           2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  1966
           4 |@                                                    54
           8 |                                                     36
          16 |                                                      7
          32 |                                                      0
          64 |                                                      0
             ~
        1024 |                                                      0
        2048 |                                                      0
        4096 |                                                      1
        8192 |                                                      1
       16384 |                                                      2
       32768 |                                                      0
       65536 |                                                      0
      131072 |                                                      1
      262144 |                                                      0
      524288 |                                                      0
      Signed-off-by: default avatarGlauber Costa <glauber@scylladb.com>
      CC: Jens Axboe <axboe@kernel.dk>
      CC: linux-block@vger.kernel.org
      CC: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarGlauber Costa <glauber@scylladb.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7077fba
    • Miklos Szeredi's avatar
      vfs: move permission checking into notify_change() for utimes(NULL) · b3b4283f
      Miklos Szeredi authored
      commit f2b20f6e upstream.
      
      This fixes a bug where the permission was not properly checked in
      overlayfs.  The testcase is ltp/utimensat01.
      
      It is also cleaner and safer to do the permission checking in the vfs
      helper instead of the caller.
      
      This patch introduces an additional ia_valid flag ATTR_TOUCH (since
      touch(1) is the most obvious user of utimes(NULL)) that is passed into
      notify_change whenever the conditions for this special permission checking
      mode are met.
      Reported-by: default avatarAihua Zhang <zhangaihua1@huawei.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Tested-by: default avatarAihua Zhang <zhangaihua1@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3b4283f
    • Marcelo Ricardo Leitner's avatar
      dlm: free workqueues after the connections · 1832397d
      Marcelo Ricardo Leitner authored
      commit 3a8db798 upstream.
      
      After backporting commit ee44b4bc ("dlm: use sctp 1-to-1 API")
      series to a kernel with an older workqueue which didn't use RCU yet, it
      was noticed that we are freeing the workqueues in dlm_lowcomms_stop()
      too early as free_conn() will try to access that memory for canceling
      the queued works if any.
      
      This issue was introduced by commit 0d737a8c as before it such
      attempt to cancel the queued works wasn't performed, so the issue was
      not present.
      
      This patch fixes it by simply inverting the free order.
      
      Fixes: 0d737a8c ("dlm: fix race while closing connections")
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1832397d
    • Marcelo Cerri's avatar
      crypto: vmx - Fix memory corruption caused by p8_ghash · 78e1355d
      Marcelo Cerri authored
      commit 80da44c2 upstream.
      
      This patch changes the p8_ghash driver to use ghash-generic as a fixed
      fallback implementation. This allows the correct value of descsize to be
      defined directly in its shash_alg structure and avoids problems with
      incorrect buffer sizes when its state is exported or imported.
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Fixes: cc333cd6 ("crypto: vmx - Adding GHASH routines for VMX module")
      Signed-off-by: default avatarMarcelo Cerri <marcelo.cerri@canonical.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      78e1355d
    • Marcelo Cerri's avatar
      crypto: ghash-generic - move common definitions to a new header file · 4f8c2ad3
      Marcelo Cerri authored
      commit a397ba82 upstream.
      
      Move common values and types used by ghash-generic to a new header file
      so drivers can directly use ghash-generic as a fallback implementation.
      
      Fixes: cc333cd6 ("crypto: vmx - Adding GHASH routines for VMX module")
      Signed-off-by: default avatarMarcelo Cerri <marcelo.cerri@canonical.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f8c2ad3
    • gmail's avatar
      ext4: release bh in make_indexed_dir · 847d63fc
      gmail authored
      commit e81d4477 upstream.
      
      The commit 6050d47a: "ext4: bail out from make_indexed_dir() on
      first error" could end up leaking bh2 in the error path.
      
      [ Also avoid renaming bh2 to bh, which just confuses things --tytso ]
      Signed-off-by: default avataryangsheng <yngsion@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      847d63fc
    • Ross Zwisler's avatar
      ext4: allow DAX writeback for hole punch · 2db2fd95
      Ross Zwisler authored
      commit cca32b7e upstream.
      
      Currently when doing a DAX hole punch with ext4 we fail to do a writeback.
      This is because the logic around filemap_write_and_wait_range() in
      ext4_punch_hole() only looks for dirty page cache pages in the radix tree,
      not for dirty DAX exceptional entries.
      Signed-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2db2fd95
    • Fabian Frederick's avatar
      ext4: fix memory leak in ext4_insert_range() · 6f6c12ce
      Fabian Frederick authored
      commit edf15aa1 upstream.
      
      Running xfstests generic/013 with kmemleak gives the following:
      
      unreferenced object 0xffff8801d3d27de0 (size 96):
        comm "fsstress", pid 4941, jiffies 4294860168 (age 53.485s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff818eaaf3>] kmemleak_alloc+0x23/0x40
          [<ffffffff81179805>] __kmalloc+0xf5/0x1d0
          [<ffffffff8122ef5c>] ext4_find_extent+0x1ec/0x2f0
          [<ffffffff8123530c>] ext4_insert_range+0x34c/0x4a0
          [<ffffffff81235942>] ext4_fallocate+0x4e2/0x8b0
          [<ffffffff81181334>] vfs_fallocate+0x134/0x210
          [<ffffffff8118203f>] SyS_fallocate+0x3f/0x60
          [<ffffffff818efa9b>] entry_SYSCALL_64_fastpath+0x13/0x8f
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      Problem seems mitigated by dropping refs and freeing path
      when there's no path[depth].p_ext
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f6c12ce
    • Daeho Jeong's avatar
      ext4: reinforce check of i_dtime when clearing high fields of uid and gid · d380cbb8
      Daeho Jeong authored
      commit 93e3b4e6 upstream.
      
      Now, ext4_do_update_inode() clears high 16-bit fields of uid/gid
      of deleted and evicted inode to fix up interoperability with old
      kernels. However, it checks only i_dtime of an inode to determine
      whether the inode was deleted and evicted, and this is very risky,
      because i_dtime can be used for the pointer maintaining orphan inode
      list, too. We need to further check whether the i_dtime is being
      used for the orphan inode list even if the i_dtime is not NULL.
      
      We found that high 16-bit fields of uid/gid of inode are unintentionally
      and permanently cleared when the inode truncation is just triggered,
      but not finished, and the inode metadata, whose high uid/gid bits are
      cleared, is written on disk, and the sudden power-off follows that
      in order.
      Signed-off-by: default avatarDaeho Jeong <daeho.jeong@samsung.com>
      Signed-off-by: default avatarHobin Woo <hobin.woo@samsung.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d380cbb8
    • Eric Whitney's avatar
      ext4: enforce online defrag restriction for encrypted files · 76a8f17e
      Eric Whitney authored
      commit 14fbd4aa upstream.
      
      Online defragging of encrypted files is not currently implemented.
      However, the move extent ioctl can still return successfully when
      called.  For example, this occurs when xfstest ext4/020 is run on an
      encrypted file system, resulting in a corrupted test file and a
      corresponding test failure.
      
      Until the proper functionality is implemented, fail the move extent
      ioctl if either the original or donor file is encrypted.
      Signed-off-by: default avatarEric Whitney <enwlinux@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76a8f17e
    • Brian King's avatar
      scsi: ibmvfc: Fix I/O hang when port is not mapped · 2ed1b50a
      Brian King authored
      commit 07d0e9a8 upstream.
      
      If a VFC port gets unmapped in the VIOS, it may not respond with a CRQ
      init complete following H_REG_CRQ. If this occurs, we can end up having
      called scsi_block_requests and not a resulting unblock until the init
      complete happens, which may never occur, and we end up hanging I/O
      requests.  This patch ensures the host action stay set to
      IBMVFC_HOST_ACTION_TGT_DEL so we move all rports into devloss state and
      unblock unless we receive an init complete.
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Acked-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ed1b50a
    • Borislav Petkov's avatar
      scsi: arcmsr: Simplify user_len checking · 161cbfec
      Borislav Petkov authored
      commit 4bd173c3 upstream.
      
      Do the user_len check first and then the ver_addr allocation so that we
      can save us the kfree() on the error path when user_len is >
      ARCMSR_API_DATA_BUFLEN.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Marco Grassi <marco.gra@gmail.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Tomas Henzl <thenzl@redhat.com>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      161cbfec
    • Dan Carpenter's avatar
      scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer() · 24040922
      Dan Carpenter authored
      commit 7bc2b55a upstream.
      
      We need to put an upper bound on "user_len" so the memcpy() doesn't
      overflow.
      Reported-by: default avatarMarco Grassi <marco.gra@gmail.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24040922
    • Justin Maggard's avatar
      async_pq_val: fix DMA memory leak · ffb3c7a9
      Justin Maggard authored
      commit c8475090 upstream.
      
      Add missing dmaengine_unmap_put(), so we don't OOM during RAID6 sync.
      
      Fixes: 1786b943 ("async_pq_val: convert to dmaengine_unmap_data")
      Signed-off-by: default avatarJustin Maggard <jmaggard@netgear.com>
      Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ffb3c7a9
    • Al Viro's avatar
      reiserfs: switch to generic_{get,set,remove}xattr() · be90a09b
      Al Viro authored
      commit 79a628d1 upstream.
      
      reiserfs_xattr_[sg]et() will fail with -EOPNOTSUPP for V1 inodes anyway,
      and all reiserfs instances of ->[sg]et() call it and so does ->set_acl().
      
      Checks for name length in the instances had been bogus; they should've
      been "bugger off if it's _exactly_ the prefix" (as generic would
      do on its own) and not "bugger off if it's shorter than the prefix" -
      that can't happen.
      
      xattr_full_name() is needed to adjust for the fact that generic instances
      will skip the prefix in the name passed to ->[gs]et(); reiserfs homegrown
      analogues didn't.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [jeffm: Backported to v4.4: adjust context]
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be90a09b
    • Mike Galbraith's avatar
      reiserfs: Unlock superblock before calling reiserfs_quota_on_mount() · 5c16520b
      Mike Galbraith authored
      commit 420902c9 upstream.
      
      If we hold the superblock lock while calling reiserfs_quota_on_mount(), we can
      deadlock our own worker - mount blocks kworker/3:2, sleeps forever more.
      
      crash> ps|grep UN
          715      2   3  ffff880220734d30  UN   0.0       0      0  [kworker/3:2]
         9369   9341   2  ffff88021ffb7560  UN   1.3  493404 123184  Xorg
         9665   9664   3  ffff880225b92ab0  UN   0.0   47368    812  udisks-daemon
        10635  10403   3  ffff880222f22c70  UN   0.0   14904    936  mount
      crash> bt ffff880220734d30
      PID: 715    TASK: ffff880220734d30  CPU: 3   COMMAND: "kworker/3:2"
       #0 [ffff8802244c3c20] schedule at ffffffff8144584b
       #1 [ffff8802244c3cc8] __rt_mutex_slowlock at ffffffff814472b3
       #2 [ffff8802244c3d28] rt_mutex_slowlock at ffffffff814473f5
       #3 [ffff8802244c3dc8] reiserfs_write_lock at ffffffffa05f28fd [reiserfs]
       #4 [ffff8802244c3de8] flush_async_commits at ffffffffa05ec91d [reiserfs]
       #5 [ffff8802244c3e08] process_one_work at ffffffff81073726
       #6 [ffff8802244c3e68] worker_thread at ffffffff81073eba
       #7 [ffff8802244c3ec8] kthread at ffffffff810782e0
       #8 [ffff8802244c3f48] kernel_thread_helper at ffffffff81450064
      crash> rd ffff8802244c3cc8 10
      ffff8802244c3cc8:  ffffffff814472b3 ffff880222f23250   .rD.....P2."....
      ffff8802244c3cd8:  0000000000000000 0000000000000286   ................
      ffff8802244c3ce8:  ffff8802244c3d30 ffff880220734d80   0=L$.....Ms ....
      ffff8802244c3cf8:  ffff880222e8f628 0000000000000000   (.."............
      ffff8802244c3d08:  0000000000000000 0000000000000002   ................
      crash> struct rt_mutex ffff880222e8f628
      struct rt_mutex {
        wait_lock = {
          raw_lock = {
            slock = 65537
          }
        },
        wait_list = {
          node_list = {
            next = 0xffff8802244c3d48,
            prev = 0xffff8802244c3d48
          }
        },
        owner = 0xffff880222f22c71,
        save_state = 0
      }
      crash> bt 0xffff880222f22c70
      PID: 10635  TASK: ffff880222f22c70  CPU: 3   COMMAND: "mount"
       #0 [ffff8802216a9868] schedule at ffffffff8144584b
       #1 [ffff8802216a9910] schedule_timeout at ffffffff81446865
       #2 [ffff8802216a99a0] wait_for_common at ffffffff81445f74
       #3 [ffff8802216a9a30] flush_work at ffffffff810712d3
       #4 [ffff8802216a9ab0] schedule_on_each_cpu at ffffffff81074463
       #5 [ffff8802216a9ae0] invalidate_bdev at ffffffff81178aba
       #6 [ffff8802216a9af0] vfs_load_quota_inode at ffffffff811a3632
       #7 [ffff8802216a9b50] dquot_quota_on_mount at ffffffff811a375c
       #8 [ffff8802216a9b80] finish_unfinished at ffffffffa05dd8b0 [reiserfs]
       #9 [ffff8802216a9cc0] reiserfs_fill_super at ffffffffa05de825 [reiserfs]
          RIP: 00007f7b9303997a  RSP: 00007ffff443c7a8  RFLAGS: 00010202
          RAX: 00000000000000a5  RBX: ffffffff8144ef12  RCX: 00007f7b932e9ee0
          RDX: 00007f7b93d9a400  RSI: 00007f7b93d9a3e0  RDI: 00007f7b93d9a3c0
          RBP: 00007f7b93d9a2c0   R8: 00007f7b93d9a550   R9: 0000000000000001
          R10: ffffffffc0ed040e  R11: 0000000000000202  R12: 000000000000040e
          R13: 0000000000000000  R14: 00000000c0ed040e  R15: 00007ffff443ca20
          ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b
      Signed-off-by: default avatarMike Galbraith <efault@gmx.de>
      Acked-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarMike Galbraith <mgalbraith@suse.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c16520b
    • Nicolas Iooss's avatar
      ASoC: Intel: Atom: add a missing star in a memcpy call · a3a9b33e
      Nicolas Iooss authored
      commit 61ab0d40 upstream.
      
      In sst_prepare_and_post_msg(), when a response is received in "block",
      the following code gets executed:
      
          *data = kzalloc(block->size, GFP_KERNEL);
          memcpy(data, (void *) block->data, block->size);
      
      The memcpy() call overwrites the content of the *data pointer instead of
      filling the newly-allocated memory (which pointer is hold by *data).
      Fix this by merging kzalloc+memcpy into a single kmemdup() call.
      
      Thanks Joe Perches for suggesting using kmemdup()
      
      Fixes: 60dc8dba ("ASoC: Intel: sst: Add some helper functions")
      Signed-off-by: default avatarNicolas Iooss <nicolas.iooss_linux@m4x.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3a9b33e
    • Rafał Miłecki's avatar
      brcmfmac: fix memory leak in brcmf_fill_bss_param · 85e27fe8
      Rafał Miłecki authored
      commit 23e9c128 upstream.
      
      This function is called from get_station callback which means that every
      time user space was getting/dumping station(s) we were leaking 2 KiB.
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      Fixes: 1f0dc59a ("brcmfmac: rework .get_station() callback")
      Acked-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      85e27fe8
    • Guilherme G Piccoli's avatar
      i40e: avoid NULL pointer dereference and recursive errors on early PCI error · 6281c088
      Guilherme G Piccoli authored
      commit edfc23ee upstream.
      
      Although rare, it's possible to hit PCI error early on device
      probe, meaning possibly some structs are not entirely initialized,
      and some might even be completely uninitialized, leading to NULL
      pointer dereference.
      
      The i40e driver currently presents a "bad" behavior if device hits
      such early PCI error: firstly, the struct i40e_pf might not be
      attached to pci_dev yet, leading to a NULL pointer dereference on
      access to pf->state.
      
      Even checking if the struct is NULL and avoiding the access in that
      case isn't enough, since the driver cannot recover from PCI error
      that early; in our experiments we saw multiple failures on kernel
      log, like:
      
        [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15
        [549.664] i40e: probe of 0007:01:00.1 failed with error -15
        [...]
        [871.644] i40e 0007:01:00.1: The driver for the device stopped because the
        device firmware failed to init. Try updating your NVM image.
        [871.644] i40e: probe of 0007:01:00.1 failed with error -32
        [...]
        [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored
      
      Between the first probe failure (error -15) and the second (error -32)
      another PCI error happened due to the first bad probe. Also, driver
      started to flood console with those ARQ event messages.
      
      This patch will prevent these issues by allowing error recovery
      mechanism to remove the failed device from the system instead of
      trying to recover from early PCI errors during device probe.
      Signed-off-by: default avatarGuilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
      Acked-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6281c088
    • Miklos Szeredi's avatar
      fuse: fix killing s[ug]id in setattr · 879d001c
      Miklos Szeredi authored
      commit a09f99ed upstream.
      
      Fuse allowed VFS to set mode in setattr in order to clear suid/sgid on
      chown and truncate, and (since writeback_cache) write.  The problem with
      this is that it'll potentially restore a stale mode.
      
      The poper fix would be to let the filesystems do the suid/sgid clearing on
      the relevant operations.  Possibly some are already doing it but there's no
      way we can detect this.
      
      So fix this by refreshing and recalculating the mode.  Do this only if
      ATTR_KILL_S[UG]ID is set to not destroy performance for writes.  This is
      still racy but the size of the window is reduced.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      879d001c
    • Miklos Szeredi's avatar
      fuse: invalidate dir dentry after chmod · 97a2eba1
      Miklos Szeredi authored
      commit 5e2b8828 upstream.
      
      Without "default_permissions" the userspace filesystem's lookup operation
      needs to perform the check for search permission on the directory.
      
      If directory does not allow search for everyone (this is quite rare) then
      userspace filesystem has to set entry timeout to zero to make sure
      permissions are always performed.
      
      Changing the mode bits of the directory should also invalidate the
      (previously cached) dentry to make sure the next lookup will have a chance
      of updating the timeout, if needed.
      Reported-by: default avatarJean-Pierre André <jean-pierre.andre@wanadoo.fr>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97a2eba1
    • Miklos Szeredi's avatar
      fuse: listxattr: verify xattr list · 80b742b8
      Miklos Szeredi authored
      commit cb3ae6d2 upstream.
      
      Make sure userspace filesystem is returning a well formed list of xattr
      names (zero or more nonzero length, null terminated strings).
      
      [Michael Theall: only verify in the nonzero size case]
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80b742b8
    • Peng Fan's avatar
      drivers: base: dma-mapping: page align the size when unmap_kernel_range · 1ccdc775
      Peng Fan authored
      commit 85714108 upstream.
      
      When dma_common_free_remap, the input parameter 'size' may not
      be page aligned. And, met kernel warning when doing iommu dma
      for usb on i.MX8 platform:
      "
      WARNING: CPU: 0 PID: 869 at mm/vmalloc.c:70 vunmap_page_range+0x1cc/0x1d0()
      Modules linked in:
      CPU: 0 PID: 869 Comm: kworker/u8:2 Not tainted 4.1.12-00444-gc5f9d1d-dirty #147
      Hardware name: Freescale i.MX8DV Sabreauto (DT)
      Workqueue: ci_otg ci_otg_work
      Call trace:
      [<ffffffc000089920>] dump_backtrace+0x0/0x124
      [<ffffffc000089a54>] show_stack+0x10/0x1c
      [<ffffffc0006d1e6c>] dump_stack+0x84/0xc8
      [<ffffffc0000b4568>] warn_slowpath_common+0x98/0xd0
      [<ffffffc0000b4664>] warn_slowpath_null+0x14/0x20
      [<ffffffc000170348>] vunmap_page_range+0x1c8/0x1d0
      [<ffffffc000170388>] unmap_kernel_range+0x20/0x88
      [<ffffffc000460ad0>] dma_common_free_remap+0x74/0x84
      [<ffffffc0000940d8>] __iommu_free_attrs+0x9c/0x178
      [<ffffffc0005032bc>] ehci_mem_cleanup+0x140/0x194
      [<ffffffc000503548>] ehci_stop+0x8c/0xdc
      [<ffffffc0004e8258>] usb_remove_hcd+0xf0/0x1cc
      [<ffffffc000516bc0>] host_stop+0x1c/0x58
      [<ffffffc000514240>] ci_otg_work+0xdc/0x120
      [<ffffffc0000c9c34>] process_one_work+0x134/0x33c
      [<ffffffc0000c9f78>] worker_thread+0x13c/0x47c
      [<ffffffc0000cf43c>] kthread+0xd8/0xf0
      "
      
      For dma_common_pages_remap:
      dma_common_pages_remap
         |->get_vm_area_caller
              |->__get_vm_area_node
                  |->size = PAGE_ALIGN(size);   Round up to page aligned
      
      So, in dma_common_free_remap, we also need a page aligned size,
      pass 'PAGE_ALIGN(size)' to unmap_kernel_range.
      Signed-off-by: default avatarPeng Fan <van.freenix@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ccdc775
    • Junjie Mao's avatar
      btrfs: assign error values to the correct bio structs · bea46981
      Junjie Mao authored
      commit 14155caf upstream.
      
      Fixes: 4246a0b6 ("block: add a bi_error field to struct bio")
      Signed-off-by: default avatarJunjie Mao <junjie.mao@enight.me>
      Acked-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bea46981
    • Kefeng Wang's avatar
      serial: 8250_dw: Check the data->pclk when get apb_pclk · 42c94790
      Kefeng Wang authored
      commit e16b46f1 upstream.
      
      It should check the data->pclk, not data->clk when get apb_pclk.
      
      Fixes: c8ed99d4("serial: 8250_dw: Add support for deferred probing")
      Signed-off-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Tested-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42c94790
  3. 20 Oct, 2016 3 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.26 · 4ad45491
      Greg Kroah-Hartman authored
      4ad45491
    • Linus Torvalds's avatar
      mm: remove gup_flags FOLL_WRITE games from __get_user_pages() · 1294d355
      Linus Torvalds authored
      commit 19be0eaf upstream.
      
      This is an ancient bug that was actually attempted to be fixed once
      (badly) by me eleven years ago in commit 4ceb5db9 ("Fix
      get_user_pages() race for write access") but that was then undone due to
      problems on s390 by commit f33ea7f4 ("fix get_user_pages bug").
      
      In the meantime, the s390 situation has long been fixed, and we can now
      fix it by checking the pte_dirty() bit properly (and do it better).  The
      s390 dirty bit was implemented in abf09bed ("s390/mm: implement
      software dirty bits") which made it into v3.9.  Earlier kernels will
      have to look at the page state itself.
      
      Also, the VM has become more scalable, and what used a purely
      theoretical race back then has become easier to trigger.
      
      To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
      we already did a COW" rather than play racy games with FOLL_WRITE that
      is very fundamental, and then use the pte dirty flag to validate that
      the FOLL_COW flag is still valid.
      Reported-and-tested-by: default avatarPhil "not Paul" Oester <kernel@linuxace.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Nick Piggin <npiggin@gmail.com>
      Cc: Greg Thelen <gthelen@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1294d355
    • H.J. Lu's avatar
      x86/build: Build compressed x86 kernels as PIE · 74a2862d
      H.J. Lu authored
      commit 6d92bc9d upstream.
      
      The 32-bit x86 assembler in binutils 2.26 will generate R_386_GOT32X
      relocation to get the symbol address in PIC.  When the compressed x86
      kernel isn't built as PIC, the linker optimizes R_386_GOT32X relocations
      to their fixed symbol addresses.  However, when the compressed x86
      kernel is loaded at a different address, it leads to the following
      load failure:
      
        Failed to allocate space for phdrs
      
      during the decompression stage.
      
      If the compressed x86 kernel is relocatable at run-time, it should be
      compiled with -fPIE, instead of -fPIC, if possible and should be built as
      Position Independent Executable (PIE) so that linker won't optimize
      R_386_GOT32X relocation to its fixed symbol address.
      
      Older linkers generate R_386_32 relocations against locally defined
      symbols, _bss, _ebss, _got and _egot, in PIE.  It isn't wrong, just less
      optimal than R_386_RELATIVE.  But the x86 kernel fails to properly handle
      R_386_32 relocations when relocating the kernel.  To generate
      R_386_RELATIVE relocations, we mark _bss, _ebss, _got and _egot as
      hidden in both 32-bit and 64-bit x86 kernels.
      
      To build a 64-bit compressed x86 kernel as PIE, we need to disable the
      relocation overflow check to avoid relocation overflow errors. We do
      this with a new linker command-line option, -z noreloc-overflow, which
      got added recently:
      
       commit 4c10bbaa0912742322f10d9d5bb630ba4e15dfa7
       Author: H.J. Lu <hjl.tools@gmail.com>
       Date:   Tue Mar 15 11:07:06 2016 -0700
      
          Add -z noreloc-overflow option to x86-64 ld
      
          Add -z noreloc-overflow command-line option to the x86-64 ELF linker to
          disable relocation overflow check.  This can be used to avoid relocation
          overflow check if there will be no dynamic relocation overflow at
          run-time.
      
      The 64-bit compressed x86 kernel is built as PIE only if the linker supports
      -z noreloc-overflow.  So far 64-bit relocatable compressed x86 kernel
      boots fine even when it is built as a normal executable.
      Signed-off-by: default avatarH.J. Lu <hjl.tools@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      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: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      [ Edited the changelog and comments. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Paul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      74a2862d
  4. 16 Oct, 2016 1 commit