1. 04 Oct, 2018 23 commits
  2. 29 Sep, 2018 17 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.130 · 46f9f7c3
      Greg Kroah-Hartman authored
      46f9f7c3
    • Steve Wise's avatar
      iw_cxgb4: only allow 1 flush on user qps · 616d5119
      Steve Wise authored
      commit 308aa2b8f7b7db3332a7d41099fd37851fb793b2 upstream.
      
      Once the qp has been flushed, it cannot be flushed again.  The user qp
      flush logic wasn't enforcing it however.  The bug can cause
      touch-after-free crashes like:
      
      Unable to handle kernel paging request for data at address 0x000001ec
      Faulting instruction address: 0xc008000016069100
      Oops: Kernel access of bad area, sig: 11 [#1]
      ...
      NIP [c008000016069100] flush_qp+0x80/0x480 [iw_cxgb4]
      LR [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4]
      Call Trace:
      [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4]
      [c00800001606e868] c4iw_ib_modify_qp+0x118/0x200 [iw_cxgb4]
      [c0080000119eae80] ib_security_modify_qp+0xd0/0x3d0 [ib_core]
      [c0080000119c4e24] ib_modify_qp+0xc4/0x2c0 [ib_core]
      [c008000011df0284] iwcm_modify_qp_err+0x44/0x70 [iw_cm]
      [c008000011df0fec] destroy_cm_id+0xcc/0x370 [iw_cm]
      [c008000011ed4358] rdma_destroy_id+0x3c8/0x520 [rdma_cm]
      [c0080000134b0540] ucma_close+0x90/0x1b0 [rdma_ucm]
      [c000000000444da4] __fput+0xe4/0x2f0
      
      So fix flush_qp() to only flush the wq once.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      616d5119
    • Nadav Amit's avatar
      vmw_balloon: include asm/io.h · 460f813b
      Nadav Amit authored
      commit a3b92ee6 upstream.
      
      Fix a build error due to missing virt_to_phys()
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Fixes: f0a1bf29 ("vmw_balloon: fix inflation with batching")
      Cc: stable@vger.kernel.org
      Cc: Xavier Deguillard <xdeguillard@vmware.com>
      Signed-off-by: default avatarNadav Amit <namit@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      460f813b
    • Zachary Zhang's avatar
      PCI: aardvark: Size bridges before resources allocation · 1879f9cb
      Zachary Zhang authored
      commit 91a2968e245d6ba616db37001fa1a043078b1a65 upstream.
      
      The PCIE I/O and MEM resource allocation mechanism is that root bus
      goes through the following steps:
      
      1. Check PCI bridges' range and computes I/O and Mem base/limits.
      
      2. Sort all subordinate devices I/O and MEM resource requirements and
         allocate the resources and writes/updates subordinate devices'
         requirements to PCI bridges I/O and Mem MEM/limits registers.
      
      Currently, PCI Aardvark driver only handles the second step and lacks
      the first step, so there is an I/O and MEM resource allocation failure
      when using a PCI switch. This commit fixes that by sizing bridges
      before doing the resource allocation.
      
      Fixes: 8c39d710 ("PCI: aardvark: Add Aardvark PCI host controller
      driver")
      Signed-off-by: default avatarZachary Zhang <zhangzg@marvell.com>
      [Thomas: edit commit log.]
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      1879f9cb
    • Roderick Colenbrander's avatar
      HID: sony: Support DS4 dongle · 72386b22
      Roderick Colenbrander authored
      commit de66a1a0 upstream.
      
      Add support for USB based DS4 dongle device, which allows connecting
      a DS4 through Bluetooth, but hides Bluetooth from the host system.
      Signed-off-by: default avatarRoderick Colenbrander <roderick.colenbrander@sony.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72386b22
    • Roderick Colenbrander's avatar
      HID: sony: Update device ids · f5ff43c8
      Roderick Colenbrander authored
      commit cf1015d6 upstream.
      
      Support additional DS4 model.
      Signed-off-by: default avatarRoderick Colenbrander <roderick.colenbrander@sony.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5ff43c8
    • Steve Muckle's avatar
      sched/fair: Fix vruntime_normalized() for remote non-migration wakeup · fa7a13e7
      Steve Muckle authored
      commit d0cdb3ce8834332d918fc9c8ff74f8a169ec9abe upstream.
      
      When a task which previously ran on a given CPU is remotely queued to
      wake up on that same CPU, there is a period where the task's state is
      TASK_WAKING and its vruntime is not normalized. This is not accounted
      for in vruntime_normalized() which will cause an error in the task's
      vruntime if it is switched from the fair class during this time.
      
      For example if it is boosted to RT priority via rt_mutex_setprio(),
      rq->min_vruntime will not be subtracted from the task's vruntime but
      it will be added again when the task returns to the fair class. The
      task's vruntime will have been erroneously doubled and the effective
      priority of the task will be reduced.
      
      Note this will also lead to inflation of all vruntimes since the doubled
      vruntime value will become the rq's min_vruntime when other tasks leave
      the rq. This leads to repeated doubling of the vruntime and priority
      penalty.
      
      Fix this by recognizing a WAKING task's vruntime as normalized only if
      sched_remote_wakeup is true. This indicates a migration, in which case
      the vruntime would have been normalized in migrate_task_rq_fair().
      
      Based on a similar patch from John Dias <joaodias@google.com>.
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Tested-by: default avatarDietmar Eggemann <dietmar.eggemann@arm.com>
      Signed-off-by: default avatarSteve Muckle <smuckle@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Chris Redpath <Chris.Redpath@arm.com>
      Cc: John Dias <joaodias@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Miguel de Dios <migueldedios@google.com>
      Cc: Morten Rasmussen <Morten.Rasmussen@arm.com>
      Cc: Patrick Bellasi <Patrick.Bellasi@arm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Quentin Perret <quentin.perret@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Todd Kjos <tkjos@google.com>
      Cc: kernel-team@android.com
      Fixes: b5179ac7 ("sched/fair: Prepare to fix fairness problems on migration")
      Link: http://lkml.kernel.org/r/20180831224217.169476-1-smuckle@google.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa7a13e7
    • Eric Biggers's avatar
      ext4: show test_dummy_encryption mount option in /proc/mounts · 797488ac
      Eric Biggers authored
      commit 338affb548c243d2af25b1ca628e67819350de6b upstream.
      
      When in effect, add "test_dummy_encryption" to _ext4_show_options() so
      that it is shown in /proc/mounts and other relevant procfs files.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      797488ac
    • Li Dongyang's avatar
      ext4: don't mark mmp buffer head dirty · b344b3a7
      Li Dongyang authored
      commit fe18d649891d813964d3aaeebad873f281627fbc upstream.
      
      Marking mmp bh dirty before writing it will make writeback
      pick up mmp block later and submit a write, we don't want the
      duplicate write as kmmpd thread should have full control of
      reading and writing the mmp block.
      Another reason is we will also have random I/O error on
      the writeback request when blk integrity is enabled, because
      kmmpd could modify the content of the mmp block(e.g. setting
      new seq and time) while the mmp block is under I/O requested
      by writeback.
      Signed-off-by: default avatarLi Dongyang <dongyangli@ddn.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b344b3a7
    • Theodore Ts'o's avatar
      ext4: fix online resizing for bigalloc file systems with a 1k block size · 4ba9e687
      Theodore Ts'o authored
      commit 5f8c10936fab2b69a487400f2872902e597dd320 upstream.
      
      An online resize of a file system with the bigalloc feature enabled
      and a 1k block size would be refused since ext4_resize_begin() did not
      understand s_first_data_block is 0 for all bigalloc file systems, even
      when the block size is 1k.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4ba9e687
    • Theodore Ts'o's avatar
      ext4: fix online resize's handling of a too-small final block group · 205dc0da
      Theodore Ts'o authored
      commit f0a459dec5495a3580f8d784555e6f8f3bf7f263 upstream.
      
      Avoid growing the file system to an extent so that the last block
      group is too small to hold all of the metadata that must be stored in
      the block group.
      
      This problem can be triggered with the following reproducer:
      
      umount /mnt
      mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \
      	-E resize=1073741824 /tmp/foo.img 128M
      mount /tmp/foo.img /mnt
      truncate --size 1708M /tmp/foo.img
      resize2fs /dev/loop0 295400
      umount /mnt
      e2fsck -fy /tmp/foo.img
      Reported-by: default avatarTorsten Hilbrich <torsten.hilbrich@secunet.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      205dc0da
    • Theodore Ts'o's avatar
      ext4: recalucate superblock checksum after updating free blocks/inodes · 67770b40
      Theodore Ts'o authored
      commit 4274f516d4bc50648a4d97e4f67ecbd7b65cde4a upstream.
      
      When mounting the superblock, ext4_fill_super() calculates the free
      blocks and free inodes and stores them in the superblock.  It's not
      strictly necessary, since we don't use them any more, but it's nice to
      keep them roughly aligned to reality.
      
      Since it's not critical for file system correctness, the code doesn't
      call ext4_commit_super().  The problem is that it's in
      ext4_commit_super() that we recalculate the superblock checksum.  So
      if we're not going to call ext4_commit_super(), we need to call
      ext4_superblock_csum_set() to make sure the superblock checksum is
      consistent.
      
      Most of the time, this doesn't matter, since we end up calling
      ext4_commit_super() very soon thereafter, and definitely by the time
      the file system is unmounted.  However, it doesn't work in this
      sequence:
      
      mke2fs -Fq -t ext4 /dev/vdc 128M
      mount /dev/vdc /vdc
      cp xfstests/git-versions /vdc
      godown /vdc
      umount /vdc
      mount /dev/vdc
      tune2fs -l /dev/vdc
      
      With this commit, the "tune2fs -l" no longer fails.
      Reported-by: default avatarChengguang Xu <cgxu519@gmx.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67770b40
    • Theodore Ts'o's avatar
      ext4: avoid divide by zero fault when deleting corrupted inline directories · acf32cf2
      Theodore Ts'o authored
      commit 4d982e25d0bdc83d8c64e66fdeca0b89240b3b85 upstream.
      
      A specially crafted file system can trick empty_inline_dir() into
      reading past the last valid entry in a inline directory, and then run
      into the end of xattr marker. This will trigger a divide by zero
      fault.  Fix this by using the size of the inline directory instead of
      dir->i_size.
      
      Also clean up error reporting in __ext4_check_dir_entry so that the
      message is clearer and more understandable --- and avoids the division
      by zero trap if the size passed in is zero.  (I'm not sure why we
      coded it that way in the first place; printing offset % size is
      actually more confusing and less useful.)
      
      https://bugzilla.kernel.org/show_bug.cgi?id=200933Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reported-by: default avatarWen Xu <wen.xu@gatech.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      acf32cf2
    • Theodore Ts'o's avatar
      ext4: check to make sure the rename(2)'s destination is not freed · 23f57cb1
      Theodore Ts'o authored
      commit b50282f3241acee880514212d88b6049fb5039c8 upstream.
      
      If the destination of the rename(2) system call exists, the inode's
      link count (i_nlinks) must be non-zero.  If it is, the inode can end
      up on the orphan list prematurely, leading to all sorts of hilarity,
      including a use-after-free.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=200931Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reported-by: default avatarWen Xu <wen.xu@gatech.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23f57cb1
    • Gustavo A. R. Silva's avatar
      tty: vt_ioctl: fix potential Spectre v1 · 0ec459ec
      Gustavo A. R. Silva authored
      commit e97267cb4d1ee01ca0929638ec0fcbb0904f903d upstream.
      
      vsa.console is indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue
      'vc_cons' [r]
      
      Fix this by sanitizing vsa.console before using it to index vc_cons
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Reviewed-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ec459ec
    • Boris Brezillon's avatar
      drm/vc4: Fix the "no scaling" case on multi-planar YUV formats · 90552762
      Boris Brezillon authored
      commit 658d8cbd07dae22ccecf49399e18c609c4e85c53 upstream.
      
      When there's no scaling requested ->is_unity should be true no matter
      the format.
      
      Also, when no scaling is requested and we have a multi-planar YUV
      format, we should leave ->y_scaling[0] to VC4_SCALING_NONE and only
      set ->x_scaling[0] to VC4_SCALING_PPF.
      
      Doing this fixes an hardly visible artifact (seen when using modetest
      and a rather big overlay plane in YUV420).
      
      Fixes: fc04023f ("drm/vc4: Add support for YUV planes.")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180725122907.13702-1-boris.brezillon@bootlin.comSigned-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90552762
    • Lyude Paul's avatar
      drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early · b1c150a6
      Lyude Paul authored
      commit 79e765ad665da4b8aa7e9c878bd2fef837f6fea5 upstream.
      
      On most systems with ACPI hotplugging support, it seems that we always
      receive a hotplug event once we re-enable EC interrupts even if the GPU
      hasn't even been resumed yet.
      
      This can cause problems since even though we schedule hpd_work to handle
      connector reprobing for us, hpd_work synchronizes on
      pm_runtime_get_sync() to wait until the device is ready to perform
      reprobing. Since runtime suspend/resume callbacks are disabled before
      the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during
      this period will grab a runtime PM ref and return immediately with
      -EACCES. Because we schedule hpd_work from our ACPI HPD handler, and
      hpd_work synchronizes on pm_runtime_get_sync(), this causes us to launch
      a connector reprobe immediately even if the GPU isn't actually resumed
      just yet. This causes various warnings in dmesg and occasionally, also
      prevents some displays connected to the dedicated GPU from coming back
      up after suspend. Example:
      
      usb 1-4: USB disconnect, device number 14
      usb 1-4.1: USB disconnect, device number 15
      WARNING: CPU: 0 PID: 838 at drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nouveau_dp_detect+0x17e/0x370 [nouveau]
      CPU: 0 PID: 838 Comm: kworker/0:6 Not tainted 4.17.14-201.Lyude.bz1477182.V3.fc28.x86_64 #1
      Hardware name: LENOVO 20EQS64N00/20EQS64N00, BIOS N1EET77W (1.50 ) 03/28/2018
      Workqueue: events nouveau_display_hpd_work [nouveau]
      RIP: 0010:nouveau_dp_detect+0x17e/0x370 [nouveau]
      RSP: 0018:ffffa15143933cf0 EFLAGS: 00010293
      RAX: 0000000000000000 RBX: ffff8cb4f656c400 RCX: 0000000000000000
      RDX: ffffa1514500e4e4 RSI: ffffa1514500e4e4 RDI: 0000000001009002
      RBP: ffff8cb4f4a8a800 R08: ffffa15143933cfd R09: ffffa15143933cfc
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff8cb4fb57a000
      R13: ffff8cb4fb57a000 R14: ffff8cb4f4a8f800 R15: ffff8cb4f656c418
      FS:  0000000000000000(0000) GS:ffff8cb51f400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f78ec938000 CR3: 000000073720a003 CR4: 00000000003606f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ? _cond_resched+0x15/0x30
       nouveau_connector_detect+0x2ce/0x520 [nouveau]
       ? _cond_resched+0x15/0x30
       ? ww_mutex_lock+0x12/0x40
       drm_helper_probe_detect_ctx+0x8b/0xe0 [drm_kms_helper]
       drm_helper_hpd_irq_event+0xa8/0x120 [drm_kms_helper]
       nouveau_display_hpd_work+0x2a/0x60 [nouveau]
       process_one_work+0x187/0x340
       worker_thread+0x2e/0x380
       ? pwq_unbound_release_workfn+0xd0/0xd0
       kthread+0x112/0x130
       ? kthread_create_worker_on_cpu+0x70/0x70
       ret_from_fork+0x35/0x40
      Code: 4c 8d 44 24 0d b9 00 05 00 00 48 89 ef ba 09 00 00 00 be 01 00 00 00 e8 e1 09 f8 ff 85 c0 0f 85 b2 01 00 00 80 7c 24 0c 03 74 02 <0f> 0b 48 89 ef e8 b8 07 f8 ff f6 05 51 1b c8 ff 02 0f 84 72 ff
      ---[ end trace 55d811b38fc8e71a ]---
      
      So, to fix this we attempt to grab a runtime PM reference in the ACPI
      handler itself asynchronously. If the GPU is already awake (it will have
      normal hotplugging at this point) or runtime PM callbacks are currently
      disabled on the device, we drop our reference without updating the
      autosuspend delay. We only schedule connector reprobes when we
      successfully managed to queue up a resume request with our asynchronous
      PM ref.
      
      This also has the added benefit of preventing redundant connector
      reprobes from ACPI while the GPU is runtime resumed!
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Cc: stable@vger.kernel.org
      Cc: Karol Herbst <kherbst@redhat.com>
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1477182#c41Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1c150a6