1. 16 Nov, 2019 1 commit
  2. 15 Nov, 2019 17 commits
  3. 14 Nov, 2019 15 commits
    • Xiaojie Yuan's avatar
      drm/amdgpu: fix null pointer deref in firmware header printing · a84fddb1
      Xiaojie Yuan authored
      v2: declare as (struct common_firmware_header *) type because
          struct xxx_firmware_header inherits from it
      
      When CE's ucode_id(8) is used to get sdma_hdr, we will be accessing an
      unallocated amdgpu_firmware_info instance.
      
      This issue appears on rhel7.7 with gcc 4.8.5. Newer compilers might have
      optimized out such 'defined but not referenced' variable.
      
      [ 1120.798564] BUG: unable to handle kernel NULL pointer dereference at 000000000000000a
      [ 1120.806703] IP: [<ffffffffc0e3c9b3>] psp_np_fw_load+0x1e3/0x390 [amdgpu]
      [ 1120.813693] PGD 80000002603ff067 PUD 271b8d067 PMD 0
      [ 1120.818931] Oops: 0000 [#1] SMP
      [ 1120.822245] Modules linked in: amdgpu(OE+) amdkcl(OE) amd_iommu_v2 amdttm(OE) amd_sched(OE) xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun bridge stp llc devlink ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat iptable_mangle iptable_security iptable_raw nf_conntrack libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc dm_mirror dm_region_hash dm_log dm_mod intel_pmc_core intel_powerclamp coretemp intel_rapl joydev kvm_intel eeepc_wmi asus_wmi kvm sparse_keymap iTCO_wdt irqbypass rfkill crc32_pclmul snd_hda_codec_realtek mxm_wmi ghash_clmulni_intel intel_wmi_thunderbolt iTCO_vendor_support snd_hda_codec_generic snd_hda_codec_hdmi aesni_intel lrw gf128mul glue_helper ablk_helper sg cryptd pcspkr snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd pinctrl_sunrisepoint pinctrl_intel soundcore acpi_pad mei_me wmi mei i2c_i801 pcc_cpufreq ip_tables ext4 mbcache jbd2 sd_mod crc_t10dif crct10dif_generic i915 i2c_algo_bit iosf_mbi drm_kms_helper e1000e syscopyarea sysfillrect sysimgblt fb_sys_fops ahci libahci drm ptp libata crct10dif_pclmul crct10dif_common crc32c_intel serio_raw pps_core drm_panel_orientation_quirks video i2c_hid
      [ 1120.954136] CPU: 4 PID: 2426 Comm: modprobe Tainted: G           OE  ------------   3.10.0-1062.el7.x86_64 #1
      [ 1120.964390] Hardware name: System manufacturer System Product Name/Z170-A, BIOS 1302 11/09/2015
      [ 1120.973321] task: ffff991ef1e3c1c0 ti: ffff991ee625c000 task.ti: ffff991ee625c000
      [ 1120.981020] RIP: 0010:[<ffffffffc0e3c9b3>]  [<ffffffffc0e3c9b3>] psp_np_fw_load+0x1e3/0x390 [amdgpu]
      [ 1120.990483] RSP: 0018:ffff991ee625f950  EFLAGS: 00010202
      [ 1120.995935] RAX: 0000000000000002 RBX: ffff991edf6b2d38 RCX: ffff991edf6a0000
      [ 1121.003391] RDX: 0000000000000000 RSI: ffff991f01d13898 RDI: ffffffffc110afb3
      [ 1121.010706] RBP: ffff991ee625f9b0 R08: 0000000000000000 R09: 0000000000000000
      [ 1121.018029] R10: 00000000000004c4 R11: ffff991ee625f64e R12: ffff991edf6b3220
      [ 1121.025353] R13: ffff991edf6a0000 R14: 0000000000000008 R15: ffff991edf6b2d30
      [ 1121.032666] FS:  00007f97b0c0b740(0000) GS:ffff991f01d00000(0000) knlGS:0000000000000000
      [ 1121.041000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1121.046880] CR2: 000000000000000a CR3: 000000025e604000 CR4: 00000000003607e0
      [ 1121.054239] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1121.061631] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 1121.068938] Call Trace:
      [ 1121.071494]  [<ffffffffc0e3dba8>] psp_hw_init+0x218/0x270 [amdgpu]
      [ 1121.077886]  [<ffffffffc0da3188>] amdgpu_device_fw_loading+0xe8/0x160 [amdgpu]
      [ 1121.085296]  [<ffffffffc0e3b34c>] ? vega10_ih_irq_init+0x4bc/0x730 [amdgpu]
      [ 1121.092534]  [<ffffffffc0da5c75>] amdgpu_device_init+0x1495/0x1c90 [amdgpu]
      [ 1121.099675]  [<ffffffffc0da9cab>] amdgpu_driver_load_kms+0x8b/0x2f0 [amdgpu]
      [ 1121.106888]  [<ffffffffc01b25cf>] drm_dev_register+0x12f/0x1d0 [drm]
      [ 1121.113419]  [<ffffffffa4dcdfd8>] ? pci_enable_device_flags+0xe8/0x140
      [ 1121.120183]  [<ffffffffc0da260a>] amdgpu_pci_probe+0xca/0x170 [amdgpu]
      [ 1121.126919]  [<ffffffffa4dcf97a>] local_pci_probe+0x4a/0xb0
      [ 1121.132622]  [<ffffffffa4dd10c9>] pci_device_probe+0x109/0x160
      [ 1121.138607]  [<ffffffffa4eb4205>] driver_probe_device+0xc5/0x3e0
      [ 1121.144766]  [<ffffffffa4eb4603>] __driver_attach+0x93/0xa0
      [ 1121.150507]  [<ffffffffa4eb4570>] ? __device_attach+0x50/0x50
      [ 1121.156422]  [<ffffffffa4eb1da5>] bus_for_each_dev+0x75/0xc0
      [ 1121.162213]  [<ffffffffa4eb3b7e>] driver_attach+0x1e/0x20
      [ 1121.167771]  [<ffffffffa4eb3620>] bus_add_driver+0x200/0x2d0
      [ 1121.173590]  [<ffffffffa4eb4c94>] driver_register+0x64/0xf0
      [ 1121.179345]  [<ffffffffa4dd0905>] __pci_register_driver+0xa5/0xc0
      [ 1121.185593]  [<ffffffffc099f000>] ? 0xffffffffc099efff
      [ 1121.190914]  [<ffffffffc099f0a4>] amdgpu_init+0xa4/0xb0 [amdgpu]
      [ 1121.197101]  [<ffffffffa4a0210a>] do_one_initcall+0xba/0x240
      [ 1121.202901]  [<ffffffffa4b1c90a>] load_module+0x271a/0x2bb0
      [ 1121.208598]  [<ffffffffa4dad740>] ? ddebug_proc_write+0x100/0x100
      [ 1121.214894]  [<ffffffffa4b1ce8f>] SyS_init_module+0xef/0x140
      [ 1121.220698]  [<ffffffffa518bede>] system_call_fastpath+0x25/0x2a
      [ 1121.226870] Code: b4 01 60 a2 00 00 31 c0 e8 83 60 33 e4 41 8b 47 08 48 8b 4d d0 48 c7 c7 b3 af 10 c1 48 69 c0 68 07 00 00 48 8b 84 01 60 a2 00 00 <48> 8b 70 08 31 c0 48 89 75 c8 e8 56 60 33 e4 48 8b 4d d0 48 c7
      [ 1121.247422] RIP  [<ffffffffc0e3c9b3>] psp_np_fw_load+0x1e3/0x390 [amdgpu]
      [ 1121.254432]  RSP <ffff991ee625f950>
      [ 1121.258017] CR2: 000000000000000a
      [ 1121.261427] ---[ end trace e98b35387ede75bd ]---
      Signed-off-by: default avatarXiaojie Yuan <xiaojie.yuan@amd.com>
      Fixes: c5fb9126 ("drm/amdgpu: add firmware header printing for psp fw loading (v2)")
      Reviewed-by: default avatarKevin Wang <kevin1.wang@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      a84fddb1
    • Chuhong Yuan's avatar
      rsxx: add missed destroy_workqueue calls in remove · dcb77e4b
      Chuhong Yuan authored
      The driver misses calling destroy_workqueue in remove like what is done
      when probe fails.
      Add the missed calls to fix it.
      Signed-off-by: default avatarChuhong Yuan <hslester96@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      dcb77e4b
    • Jiufei Xue's avatar
      iocost: check active_list of all the ancestors in iocg_activate() · 8b37bc27
      Jiufei Xue authored
      There is a bug that checking the same active_list over and over again
      in iocg_activate(). The intention of the code was checking whether all
      the ancestors and self have already been activated. So fix it.
      
      Fixes: 7caa4715 ("blkcg: implement blk-iocost")
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJiufei Xue <jiufei.xue@linux.alibaba.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      8b37bc27
    • Ilya Dryomov's avatar
      rbd: silence bogus uninitialized warning in rbd_object_map_update_finish() · 633739b2
      Ilya Dryomov authored
      Some versions of gcc (so far 6.3 and 7.4) throw a warning:
      
        drivers/block/rbd.c: In function 'rbd_object_map_callback':
        drivers/block/rbd.c:2124:21: warning: 'current_state' may be used uninitialized in this function [-Wmaybe-uninitialized]
              (current_state == OBJECT_EXISTS && state == OBJECT_EXISTS_CLEAN))
        drivers/block/rbd.c:2092:23: note: 'current_state' was declared here
          u8 state, new_state, current_state;
                                ^~~~~~~~~~~~~
      
      It's bogus because all current_state accesses are guarded by
      has_current_state.
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarDongsheng Yang <dongsheng.yang@easystack.cn>
      633739b2
    • Jeff Layton's avatar
      ceph: increment/decrement dio counter on async requests · 6a81749e
      Jeff Layton authored
      Ceph can in some cases issue an async DIO request, in which case we can
      end up calling ceph_end_io_direct before the I/O is actually complete.
      That may allow buffered operations to proceed while DIO requests are
      still in flight.
      
      Fix this by incrementing the i_dio_count when issuing an async DIO
      request, and decrement it when tearing down the aio_req.
      
      Fixes: 321fe13c ("ceph: add buffered/direct exclusionary locking for reads and writes")
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      6a81749e
    • Jeff Layton's avatar
      ceph: take the inode lock before acquiring cap refs · a81bc310
      Jeff Layton authored
      Most of the time, we (or the vfs layer) takes the inode_lock and then
      acquires caps, but ceph_read_iter does the opposite, and that can lead
      to a deadlock.
      
      When there are multiple clients treading over the same data, we can end
      up in a situation where a reader takes caps and then tries to acquire
      the inode_lock. Another task holds the inode_lock and issues a request
      to the MDS which needs to revoke the caps, but that can't happen until
      the inode_lock is unwedged.
      
      Fix this by having ceph_read_iter take the inode_lock earlier, before
      attempting to acquire caps.
      
      Fixes: 321fe13c ("ceph: add buffered/direct exclusionary locking for reads and writes")
      Link: https://tracker.ceph.com/issues/36348Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      a81bc310
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix incorrect size check for processing/extension units · 976a68f0
      Takashi Iwai authored
      The recently introduced unit descriptor validation had some bug for
      processing and extension units, it counts a bControlSize byte twice so
      it expected a bigger size than it should have been.  This seems
      resulting in a probe error on a few devices.
      
      Fix the calculation for proper checks of PU and EU.
      
      Fixes: 57f87706 ("ALSA: usb-audio: More validations of descriptor units")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191114165613.7422-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      976a68f0
    • Linus Torvalds's avatar
      Merge tag 'kbuild-fixes-v5.4-3' of... · 96b95eff
      Linus Torvalds authored
      Merge tag 'kbuild-fixes-v5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
      
      Pull Kbuild fixes from Masahiro Yamada:
      
       - fix build error when compiling SPARC VDSO with CONFIG_COMPAT=y
      
       - pass correct --arch option to Sparse
      
      * tag 'kbuild-fixes-v5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
        kbuild: tell sparse about the $ARCH
        sparc: vdso: fix build error of vdso32
      96b95eff
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma · 4e84608c
      Linus Torvalds authored
      Pull RDMA fixes from Jason Gunthorpe:
       "Bug fixes for old bugs in the hns and hfi1 drivers:
      
         - Calculate various values in hns properly to avoid over/underflows
           in some cases
      
         - Fix an oops, PCI negotiation on Gen4 systems, and bugs related to
           retries"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
        RDMA/hns: Correct the value of srq_desc_size
        RDMA/hns: Correct the value of HNS_ROCE_HEM_CHUNK_LEN
        IB/hfi1: TID RDMA WRITE should not return IB_WC_RNR_RETRY_EXC_ERR
        IB/hfi1: Calculate flow weight based on QP MTU for TID RDMA
        IB/hfi1: Ensure r_tid_ack is valid before building TID RDMA ACK packet
        IB/hfi1: Ensure full Gen3 speed in a Gen4 system
      4e84608c
    • Sean Christopherson's avatar
      KVM: x86/mmu: Take slots_lock when using kvm_mmu_zap_all_fast() · ed69a6cb
      Sean Christopherson authored
      Acquire the per-VM slots_lock when zapping all shadow pages as part of
      toggling nx_huge_pages.  The fast zap algorithm relies on exclusivity
      (via slots_lock) to identify obsolete vs. valid shadow pages, because it
      uses a single bit for its generation number. Holding slots_lock also
      obviates the need to acquire a read lock on the VM's srcu.
      
      Failing to take slots_lock when toggling nx_huge_pages allows multiple
      instances of kvm_mmu_zap_all_fast() to run concurrently, as the other
      user, KVM_SET_USER_MEMORY_REGION, does not take the global kvm_lock.
      (kvm_mmu_zap_all_fast() does take kvm->mmu_lock, but it can be
      temporarily dropped by kvm_zap_obsolete_pages(), so it is not enough
      to enforce exclusivity).
      
      Concurrent fast zap instances causes obsolete shadow pages to be
      incorrectly identified as valid due to the single bit generation number
      wrapping, which results in stale shadow pages being left in KVM's MMU
      and leads to all sorts of undesirable behavior.
      The bug is easily confirmed by running with CONFIG_PROVE_LOCKING and
      toggling nx_huge_pages via its module param.
      
      Note, until commit 4ae5acbc4936 ("KVM: x86/mmu: Take slots_lock when
      using kvm_mmu_zap_all_fast()", 2019-11-13) the fast zap algorithm used
      an ulong-sized generation instead of relying on exclusivity for
      correctness, but all callers except the recently added set_nx_huge_pages()
      needed to hold slots_lock anyways.  Therefore, this patch does not have
      to be backported to stable kernels.
      
      Given that toggling nx_huge_pages is by no means a fast path, force it
      to conform to the current approach instead of reintroducing the previous
      generation count.
      
      Fixes: b8e8c830 ("kvm: mmu: ITLB_MULTIHIT mitigation", but NOT FOR STABLE)
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      ed69a6cb
    • Luc Van Oostenryck's avatar
      kbuild: tell sparse about the $ARCH · 80591e61
      Luc Van Oostenryck authored
      Sparse uses the same executable for all archs and uses flags
      like -m64, -mbig-endian or -D__arm__ for arch-specific parameters.
      But Sparse also uses value from the host machine used to build
      Sparse as default value for the target machine.
      
      This works, of course, well for native build but can create
      problems when cross-compiling, like defining both '__i386__'
      and '__arm__' when cross-compiling for arm on a x86-64 machine.
      
      Fix this by explicitely telling sparse the target architecture.
      Reported-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      80591e61
    • Masahiro Yamada's avatar
      sparc: vdso: fix build error of vdso32 · 53472914
      Masahiro Yamada authored
      Since commit 54b8ae66 ("kbuild: change *FLAGS_<basetarget>.o to
      take the path relative to $(obj)"), sparc allmodconfig fails to build
      as follows:
      
        CC      arch/sparc/vdso/vdso32/vclock_gettime.o
      unrecognized e_machine 18 arch/sparc/vdso/vdso32/vclock_gettime.o
      arch/sparc/vdso/vdso32/vclock_gettime.o: failed
      
      The cause of the breakage is that -pg flag not being dropped.
      
      The vdso32 files are located in the vdso32/ subdirectory, but I missed
      to update the Makefile.
      
      I removed the meaningless CFLAGS_REMOVE_vdso-note.o since it is only
      effective for C file.
      
      vdso-note.o is compiled from assembly file:
      
        arch/sparc/vdso/vdso-note.S
        arch/sparc/vdso/vdso32/vdso-note.S
      
      Fixes: 54b8ae66 ("kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj)")
      Reported-by: default avatarAnatoly Pugachev <matorola@gmail.com>
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarAnatoly Pugachev <matorola@gmail.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      53472914
    • Paolo Valente's avatar
      block, bfq: deschedule empty bfq_queues not referred by any process · 478de338
      Paolo Valente authored
      Since commit 3726112e ("block, bfq: re-schedule empty queues if
      they deserve I/O plugging"), to prevent the service guarantees of a
      bfq_queue from being violated, the bfq_queue may be left busy, i.e.,
      scheduled for service, even if empty (see comments in
      __bfq_bfqq_expire() for details). But, if no process will send
      requests to the bfq_queue any longer, then there is no point in
      keeping the bfq_queue scheduled for service.
      
      In addition, keeping the bfq_queue scheduled for service, but with no
      process reference any longer, may cause the bfq_queue to be freed when
      descheduled from service. But this is assumed to never happen, and
      causes a UAF if it happens. This, in turn, caused crashes [1, 2].
      
      This commit fixes this issue by descheduling an empty bfq_queue when
      it remains with not process reference.
      
      [1] https://bugzilla.redhat.com/show_bug.cgi?id=1767539
      [2] https://bugzilla.kernel.org/show_bug.cgi?id=205447
      
      Fixes: 3726112e ("block, bfq: re-schedule empty queues if they deserve I/O plugging")
      Reported-by: default avatarChris Evich <cevich@redhat.com>
      Reported-by: default avatarPatrick Dung <patdung100@gmail.com>
      Reported-by: default avatarThorsten Schubert <tschubert@bafh.org>
      Tested-by: default avatarThorsten Schubert <tschubert@bafh.org>
      Tested-by: default avatarOleksandr Natalenko <oleksandr@natalenko.name>
      Signed-off-by: default avatarPaolo Valente <paolo.valente@linaro.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      478de338
    • Eugen Hristev's avatar
      mmc: sdhci-of-at91: fix quirk2 overwrite · fed23c58
      Eugen Hristev authored
      The quirks2 are parsed and set (e.g. from DT) before the quirk for broken
      HS200 is set in the driver.
      The driver needs to enable just this flag, not rewrite the whole quirk set.
      
      Fixes: 7871aa60 ("mmc: sdhci-of-at91: add quirk for broken HS200")
      Signed-off-by: default avatarEugen Hristev <eugen.hristev@microchip.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      fed23c58
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix incorrect NULL check in create_yamaha_midi_quirk() · cc9dbfa9
      Takashi Iwai authored
      The commit 60849562 ("ALSA: usb-audio: Fix possible NULL
      dereference at create_yamaha_midi_quirk()") added NULL checks in
      create_yamaha_midi_quirk(), but there was an overlook.  The code
      allows one of either injd or outjd is NULL, but the second if check
      made returning -ENODEV if any of them is NULL.  Fix it in a proper
      form.
      
      Fixes: 60849562 ("ALSA: usb-audio: Fix possible NULL dereference at create_yamaha_midi_quirk()")
      Reported-by: default avatarPavel Machek <pavel@denx.de>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191113111259.24123-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      cc9dbfa9
  4. 13 Nov, 2019 7 commits