1. 13 Dec, 2018 40 commits
    • Peter Shih's avatar
      tty: serial: 8250_mtk: always resume the device in probe. · 4f50d3a0
      Peter Shih authored
      commit 100bc3e2 upstream.
      
      serial8250_register_8250_port calls uart_config_port, which calls
      config_port on the port before it tries to power on the port. So we need
      the port to be on before calling serial8250_register_8250_port. Change
      the code to always do a runtime resume in probe before registering port,
      and always do a runtime suspend in remove.
      
      This basically reverts the change in commit 68e5fc4a ("tty: serial:
      8250_mtk: use pm_runtime callbacks for enabling"), but still use
      pm_runtime callbacks.
      
      Fixes: 68e5fc4a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling")
      Signed-off-by: default avatarPeter Shih <pihsun@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f50d3a0
    • Dexuan Cui's avatar
      Drivers: hv: vmbus: Offload the handling of channels to two workqueues · c1063941
      Dexuan Cui authored
      commit 37c2578c upstream.
      
      vmbus_process_offer() mustn't call channel->sc_creation_callback()
      directly for sub-channels, because sc_creation_callback() ->
      vmbus_open() may never get the host's response to the
      OPEN_CHANNEL message (the host may rescind a channel at any time,
      e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
      may not wake up the vmbus_open() as it's blocked due to a non-zero
      vmbus_connection.offer_in_progress, and finally we have a deadlock.
      
      The above is also true for primary channels, if the related device
      drivers use sync probing mode by default.
      
      And, usually the handling of primary channels and sub-channels can
      depend on each other, so we should offload them to different
      workqueues to avoid possible deadlock, e.g. in sync-probing mode,
      NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
      rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
      and waits for all the sub-channels to appear, but the latter
      can't get the rtnl_lock and this blocks the handling of sub-channels.
      
      The patch can fix the multiple-NIC deadlock described above for
      v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
      of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
      but don't enable async-probing for Hyper-V drivers (yet).
      
      The patch can also fix the hang issue in sub-channel's handling described
      above for all versions of kernels, including v4.19 and v4.20-rc4.
      
      So actually the patch should be applied to all the existing kernels,
      not only the kernels that have 8195b139.
      
      Fixes: 8195b139 ("hv_netvsc: fix deadlock on hotplug")
      Cc: stable@vger.kernel.org
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c1063941
    • Alex Deucher's avatar
      drm/amdgpu/gmc8: update MC firmware for polaris · eff5e74f
      Alex Deucher authored
      commit a81a7c9c upstream.
      
      Some variants require different MC firmware images.
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarJunwei Zhang <Jerry.Zhang@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eff5e74f
    • Junwei Zhang's avatar
      drm/amdgpu: update mc firmware image for polaris12 variants · 99e6900d
      Junwei Zhang authored
      commit d7fd6765 upstream.
      
      Some new variants require updated firmware.
      Signed-off-by: default avatarJunwei Zhang <Jerry.Zhang@amd.com>
      Reviewed-by: default avatarEvan Quan <evan.quan@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99e6900d
    • Young Xiao's avatar
      Revert commit ef9209b6 "staging: rtl8723bs: Fix indenting errors and an... · c33e7a5a
      Young Xiao authored
      Revert commit ef9209b6 "staging: rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c"
      
      commit 87e4a540 upstream.
      
      pstapriv->max_num_sta is always <= NUM_STA, since max_num_sta is either
      set in _rtw_init_sta_priv() or rtw_set_beacon().
      
      Fixes: ef9209b6 ("staging: rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c")
      Signed-off-by: default avatarYoung Xiao <YangX92@hotmail.com>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      c33e7a5a
    • Young Xiao's avatar
      staging: rtl8712: Fix possible buffer overrun · 948ef680
      Young Xiao authored
      commit 300cd664 upstream.
      
      In commit 8b7a13c3 ("staging: r8712u: Fix possible buffer
      overrun") we fix a potential off by one by making the limit smaller.
      The better fix is to make the buffer larger.  This makes it match up
      with the similar code in other drivers.
      
      Fixes: 8b7a13c3 ("staging: r8712u: Fix possible buffer overrun")
      Signed-off-by: default avatarYoung Xiao <YangX92@hotmail.com>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      948ef680
    • Paulo Alcantara's avatar
      cifs: Fix separator when building path from dentry · b505b9b0
      Paulo Alcantara authored
      commit c988de29 upstream.
      
      Make sure to use the CIFS_DIR_SEP(cifs_sb) as path separator for
      prefixpath too. Fixes a bug with smb1 UNIX extensions.
      
      Fixes: a6b5058f ("fs/cifs: make share unaccessible at root level mountable")
      Signed-off-by: default avatarPaulo Alcantara <palcantara@suse.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b505b9b0
    • Greg Kroah-Hartman's avatar
      staging: atomisp: remove "fun" strncpy warning · a604686c
      Greg Kroah-Hartman authored
      [for older kernels only, atomisp has been removed from upstream]
      
      gcc-8 rightfully warns that this instance of strncpy is just copying
      from the source, to the same source, for a few bytes.  Meaning this call
      does nothing.  As the author of the code obviously meant it to do
      something, but this code must be working properly, just replace the call
      to the kernel internal strscpy() which gcc doesn't know about, so the
      warning goes away.
      
      As this driver was deleted from newer kernel versions, none of this
      really matters but now at least we do not have to worry about a build
      warning in the stable trees.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a604686c
    • Greg Kroah-Hartman's avatar
      Staging: lustre: remove two build warnings · b4e4b857
      Greg Kroah-Hartman authored
      [for older kernels only, lustre has been removed from upstream]
      
      When someone writes:
      	strncpy(dest, source, sizeof(source));
      they really are just doing the same thing as:
      	strcpy(dest, source);
      but somehow they feel better because they are now using the "safe"
      version of the string functions.  Cargo-cult programming at its
      finest...
      
      gcc-8 rightfully warns you about doing foolish things like this.  Now
      that the stable kernels are all starting to be built using gcc-8, let's
      get rid of this warning so that we do not have to gaze at this horror.
      
      To dropt the warning, just convert the code to using strcpy() so that if
      someone really wants to audit this code and find all of the obvious
      problems, it will be easier to do so.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4e4b857
    • Kees Cook's avatar
      swiotlb: clean up reporting · f2a4f762
      Kees Cook authored
      commit 7d63fb3a upstream.
      
      This removes needless use of '%p', and refactors the printk calls to
      use pr_*() helpers instead.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      [bwh: Backported to 4.14:
       - Adjust filename
       - Remove "swiotlb: " prefix from an additional log message]
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f2a4f762
    • Chao Yu's avatar
      f2fs: fix to do sanity check with block address in main area v2 · 38fce19d
      Chao Yu authored
      commit 91291e99 upstream.
      
      This patch adds f2fs_is_valid_blkaddr() in below functions to do sanity
      check with block address to avoid pentential panic:
      - f2fs_grab_read_bio()
      - __written_first_block()
      
      https://bugzilla.kernel.org/show_bug.cgi?id=200465
      
      - Reproduce
      
      - POC (poc.c)
          #define _GNU_SOURCE
          #include <sys/types.h>
          #include <sys/mount.h>
          #include <sys/mman.h>
          #include <sys/stat.h>
          #include <sys/xattr.h>
      
          #include <dirent.h>
          #include <errno.h>
          #include <error.h>
          #include <fcntl.h>
          #include <stdio.h>
          #include <stdlib.h>
          #include <string.h>
          #include <unistd.h>
      
          #include <linux/falloc.h>
          #include <linux/loop.h>
      
          static void activity(char *mpoint) {
      
            char *xattr;
            int err;
      
            err = asprintf(&xattr, "%s/foo/bar/xattr", mpoint);
      
            char buf2[113];
            memset(buf2, 0, sizeof(buf2));
            listxattr(xattr, buf2, sizeof(buf2));
      
          }
      
          int main(int argc, char *argv[]) {
            activity(argv[1]);
            return 0;
          }
      
      - kernel message
      [  844.718738] F2FS-fs (loop0): Mounted with checkpoint version = 2
      [  846.430929] F2FS-fs (loop0): access invalid blkaddr:1024
      [  846.431058] WARNING: CPU: 1 PID: 1249 at fs/f2fs/checkpoint.c:154 f2fs_is_valid_blkaddr+0x10f/0x160
      [  846.431059] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd input_leds joydev soundcore serio_raw i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear qxl ttm crct10dif_pclmul crc32_pclmul drm_kms_helper ghash_clmulni_intel syscopyarea sysfillrect sysimgblt fb_sys_fops pcbc drm 8139too aesni_intel 8139cp floppy psmouse mii aes_x86_64 crypto_simd pata_acpi cryptd glue_helper
      [  846.431310] CPU: 1 PID: 1249 Comm: a.out Not tainted 4.18.0-rc3+ #1
      [  846.431312] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [  846.431315] RIP: 0010:f2fs_is_valid_blkaddr+0x10f/0x160
      [  846.431316] Code: 00 eb ed 31 c0 83 fa 05 75 ae 48 83 ec 08 48 8b 3f 89 f1 48 c7 c2 fc 0b 0f 8b 48 c7 c6 8b d7 09 8b 88 44 24 07 e8 61 8b ff ff <0f> 0b 0f b6 44 24 07 48 83 c4 08 eb 81 4c 8b 47 10 8b 8f 38 04 00
      [  846.431347] RSP: 0018:ffff961c414a7bc0 EFLAGS: 00010282
      [  846.431349] RAX: 0000000000000000 RBX: ffffc5f787b8ea80 RCX: 0000000000000000
      [  846.431350] RDX: 0000000000000000 RSI: ffff89dfffd165d8 RDI: ffff89dfffd165d8
      [  846.431351] RBP: ffff961c414a7c20 R08: 0000000000000001 R09: 0000000000000248
      [  846.431353] R10: 0000000000000000 R11: 0000000000000248 R12: 0000000000000007
      [  846.431369] R13: ffff89dff5492800 R14: ffff89dfae3aa000 R15: ffff89dff4ff88d0
      [  846.431372] FS:  00007f882e2fb700(0000) GS:ffff89dfffd00000(0000) knlGS:0000000000000000
      [  846.431373] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  846.431374] CR2: 0000000001a88008 CR3: 00000001eb572000 CR4: 00000000000006e0
      [  846.431384] Call Trace:
      [  846.431426]  f2fs_iget+0x6f4/0xe70
      [  846.431430]  ? f2fs_find_entry+0x71/0x90
      [  846.431432]  f2fs_lookup+0x1aa/0x390
      [  846.431452]  __lookup_slow+0x97/0x150
      [  846.431459]  lookup_slow+0x35/0x50
      [  846.431462]  walk_component+0x1c6/0x470
      [  846.431479]  ? memcg_kmem_charge_memcg+0x70/0x90
      [  846.431488]  ? page_add_file_rmap+0x13/0x200
      [  846.431491]  path_lookupat+0x76/0x230
      [  846.431501]  ? __alloc_pages_nodemask+0xfc/0x280
      [  846.431504]  filename_lookup+0xb8/0x1a0
      [  846.431534]  ? _cond_resched+0x16/0x40
      [  846.431541]  ? kmem_cache_alloc+0x160/0x1d0
      [  846.431549]  ? path_listxattr+0x41/0xa0
      [  846.431551]  path_listxattr+0x41/0xa0
      [  846.431570]  do_syscall_64+0x55/0x100
      [  846.431583]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  846.431607] RIP: 0033:0x7f882de1c0d7
      [  846.431607] Code: f0 ff ff 73 01 c3 48 8b 0d be dd 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 c2 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 dd 2b 00 f7 d8 64 89 01 48
      [  846.431639] RSP: 002b:00007ffe8e66c238 EFLAGS: 00000202 ORIG_RAX: 00000000000000c2
      [  846.431641] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f882de1c0d7
      [  846.431642] RDX: 0000000000000071 RSI: 00007ffe8e66c280 RDI: 0000000001a880c0
      [  846.431643] RBP: 00007ffe8e66c300 R08: 0000000001a88010 R09: 0000000000000000
      [  846.431645] R10: 00000000000001ab R11: 0000000000000202 R12: 0000000000400550
      [  846.431646] R13: 00007ffe8e66c400 R14: 0000000000000000 R15: 0000000000000000
      [  846.431648] ---[ end trace abca54df39d14f5c ]---
      [  846.431651] F2FS-fs (loop0): invalid blkaddr: 1024, type: 5, run fsck to fix.
      [  846.431762] WARNING: CPU: 1 PID: 1249 at fs/f2fs/f2fs.h:2697 f2fs_iget+0xd17/0xe70
      [  846.431763] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd input_leds joydev soundcore serio_raw i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear qxl ttm crct10dif_pclmul crc32_pclmul drm_kms_helper ghash_clmulni_intel syscopyarea sysfillrect sysimgblt fb_sys_fops pcbc drm 8139too aesni_intel 8139cp floppy psmouse mii aes_x86_64 crypto_simd pata_acpi cryptd glue_helper
      [  846.431797] CPU: 1 PID: 1249 Comm: a.out Tainted: G        W         4.18.0-rc3+ #1
      [  846.431798] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [  846.431800] RIP: 0010:f2fs_iget+0xd17/0xe70
      [  846.431801] Code: ff ff 48 63 d8 e9 e1 f6 ff ff 48 8b 45 c8 41 b8 05 00 00 00 48 c7 c2 d8 e8 0e 8b 48 c7 c6 1d b0 0a 8b 48 8b 38 e8 f9 b4 00 00 <0f> 0b 48 8b 45 c8 f0 80 48 48 04 e9 d8 f9 ff ff 0f 0b 48 8b 43 18
      [  846.431832] RSP: 0018:ffff961c414a7bd0 EFLAGS: 00010282
      [  846.431834] RAX: 0000000000000000 RBX: ffffc5f787b8ea80 RCX: 0000000000000006
      [  846.431835] RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffff89dfffd165d0
      [  846.431836] RBP: ffff961c414a7c20 R08: 0000000000000000 R09: 0000000000000273
      [  846.431837] R10: 0000000000000000 R11: ffff89dfad50ca60 R12: 0000000000000007
      [  846.431838] R13: ffff89dff5492800 R14: ffff89dfae3aa000 R15: ffff89dff4ff88d0
      [  846.431840] FS:  00007f882e2fb700(0000) GS:ffff89dfffd00000(0000) knlGS:0000000000000000
      [  846.431841] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  846.431842] CR2: 0000000001a88008 CR3: 00000001eb572000 CR4: 00000000000006e0
      [  846.431846] Call Trace:
      [  846.431850]  ? f2fs_find_entry+0x71/0x90
      [  846.431853]  f2fs_lookup+0x1aa/0x390
      [  846.431856]  __lookup_slow+0x97/0x150
      [  846.431858]  lookup_slow+0x35/0x50
      [  846.431874]  walk_component+0x1c6/0x470
      [  846.431878]  ? memcg_kmem_charge_memcg+0x70/0x90
      [  846.431880]  ? page_add_file_rmap+0x13/0x200
      [  846.431882]  path_lookupat+0x76/0x230
      [  846.431884]  ? __alloc_pages_nodemask+0xfc/0x280
      [  846.431886]  filename_lookup+0xb8/0x1a0
      [  846.431890]  ? _cond_resched+0x16/0x40
      [  846.431891]  ? kmem_cache_alloc+0x160/0x1d0
      [  846.431894]  ? path_listxattr+0x41/0xa0
      [  846.431896]  path_listxattr+0x41/0xa0
      [  846.431898]  do_syscall_64+0x55/0x100
      [  846.431901]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  846.431902] RIP: 0033:0x7f882de1c0d7
      [  846.431903] Code: f0 ff ff 73 01 c3 48 8b 0d be dd 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 c2 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 dd 2b 00 f7 d8 64 89 01 48
      [  846.431934] RSP: 002b:00007ffe8e66c238 EFLAGS: 00000202 ORIG_RAX: 00000000000000c2
      [  846.431936] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f882de1c0d7
      [  846.431937] RDX: 0000000000000071 RSI: 00007ffe8e66c280 RDI: 0000000001a880c0
      [  846.431939] RBP: 00007ffe8e66c300 R08: 0000000001a88010 R09: 0000000000000000
      [  846.431940] R10: 00000000000001ab R11: 0000000000000202 R12: 0000000000400550
      [  846.431941] R13: 00007ffe8e66c400 R14: 0000000000000000 R15: 0000000000000000
      [  846.431943] ---[ end trace abca54df39d14f5d ]---
      [  846.432033] F2FS-fs (loop0): access invalid blkaddr:1024
      [  846.432051] WARNING: CPU: 1 PID: 1249 at fs/f2fs/checkpoint.c:154 f2fs_is_valid_blkaddr+0x10f/0x160
      [  846.432051] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd input_leds joydev soundcore serio_raw i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear qxl ttm crct10dif_pclmul crc32_pclmul drm_kms_helper ghash_clmulni_intel syscopyarea sysfillrect sysimgblt fb_sys_fops pcbc drm 8139too aesni_intel 8139cp floppy psmouse mii aes_x86_64 crypto_simd pata_acpi cryptd glue_helper
      [  846.432085] CPU: 1 PID: 1249 Comm: a.out Tainted: G        W         4.18.0-rc3+ #1
      [  846.432086] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [  846.432089] RIP: 0010:f2fs_is_valid_blkaddr+0x10f/0x160
      [  846.432089] Code: 00 eb ed 31 c0 83 fa 05 75 ae 48 83 ec 08 48 8b 3f 89 f1 48 c7 c2 fc 0b 0f 8b 48 c7 c6 8b d7 09 8b 88 44 24 07 e8 61 8b ff ff <0f> 0b 0f b6 44 24 07 48 83 c4 08 eb 81 4c 8b 47 10 8b 8f 38 04 00
      [  846.432120] RSP: 0018:ffff961c414a7900 EFLAGS: 00010286
      [  846.432122] RAX: 0000000000000000 RBX: 0000000000000400 RCX: 0000000000000006
      [  846.432123] RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffff89dfffd165d0
      [  846.432124] RBP: ffff89dff5492800 R08: 0000000000000001 R09: 000000000000029d
      [  846.432125] R10: ffff961c414a7820 R11: 000000000000029d R12: 0000000000000400
      [  846.432126] R13: 0000000000000000 R14: ffff89dff4ff88d0 R15: 0000000000000000
      [  846.432128] FS:  00007f882e2fb700(0000) GS:ffff89dfffd00000(0000) knlGS:0000000000000000
      [  846.432130] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  846.432131] CR2: 0000000001a88008 CR3: 00000001eb572000 CR4: 00000000000006e0
      [  846.432135] Call Trace:
      [  846.432151]  f2fs_wait_on_block_writeback+0x20/0x110
      [  846.432158]  f2fs_grab_read_bio+0xbc/0xe0
      [  846.432161]  f2fs_submit_page_read+0x21/0x280
      [  846.432163]  f2fs_get_read_data_page+0xb7/0x3c0
      [  846.432165]  f2fs_get_lock_data_page+0x29/0x1e0
      [  846.432167]  f2fs_get_new_data_page+0x148/0x550
      [  846.432170]  f2fs_add_regular_entry+0x1d2/0x550
      [  846.432178]  ? __switch_to+0x12f/0x460
      [  846.432181]  f2fs_add_dentry+0x6a/0xd0
      [  846.432184]  f2fs_do_add_link+0xe9/0x140
      [  846.432186]  __recover_dot_dentries+0x260/0x280
      [  846.432189]  f2fs_lookup+0x343/0x390
      [  846.432193]  __lookup_slow+0x97/0x150
      [  846.432195]  lookup_slow+0x35/0x50
      [  846.432208]  walk_component+0x1c6/0x470
      [  846.432212]  ? memcg_kmem_charge_memcg+0x70/0x90
      [  846.432215]  ? page_add_file_rmap+0x13/0x200
      [  846.432217]  path_lookupat+0x76/0x230
      [  846.432219]  ? __alloc_pages_nodemask+0xfc/0x280
      [  846.432221]  filename_lookup+0xb8/0x1a0
      [  846.432224]  ? _cond_resched+0x16/0x40
      [  846.432226]  ? kmem_cache_alloc+0x160/0x1d0
      [  846.432228]  ? path_listxattr+0x41/0xa0
      [  846.432230]  path_listxattr+0x41/0xa0
      [  846.432233]  do_syscall_64+0x55/0x100
      [  846.432235]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  846.432237] RIP: 0033:0x7f882de1c0d7
      [  846.432237] Code: f0 ff ff 73 01 c3 48 8b 0d be dd 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 c2 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 dd 2b 00 f7 d8 64 89 01 48
      [  846.432269] RSP: 002b:00007ffe8e66c238 EFLAGS: 00000202 ORIG_RAX: 00000000000000c2
      [  846.432271] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f882de1c0d7
      [  846.432272] RDX: 0000000000000071 RSI: 00007ffe8e66c280 RDI: 0000000001a880c0
      [  846.432273] RBP: 00007ffe8e66c300 R08: 0000000001a88010 R09: 0000000000000000
      [  846.432274] R10: 00000000000001ab R11: 0000000000000202 R12: 0000000000400550
      [  846.432275] R13: 00007ffe8e66c400 R14: 0000000000000000 R15: 0000000000000000
      [  846.432277] ---[ end trace abca54df39d14f5e ]---
      [  846.432279] F2FS-fs (loop0): invalid blkaddr: 1024, type: 5, run fsck to fix.
      [  846.432376] WARNING: CPU: 1 PID: 1249 at fs/f2fs/f2fs.h:2697 f2fs_wait_on_block_writeback+0xb1/0x110
      [  846.432376] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd input_leds joydev soundcore serio_raw i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear qxl ttm crct10dif_pclmul crc32_pclmul drm_kms_helper ghash_clmulni_intel syscopyarea sysfillrect sysimgblt fb_sys_fops pcbc drm 8139too aesni_intel 8139cp floppy psmouse mii aes_x86_64 crypto_simd pata_acpi cryptd glue_helper
      [  846.432410] CPU: 1 PID: 1249 Comm: a.out Tainted: G        W         4.18.0-rc3+ #1
      [  846.432411] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [  846.432413] RIP: 0010:f2fs_wait_on_block_writeback+0xb1/0x110
      [  846.432414] Code: 66 90 f0 ff 4b 34 74 59 5b 5d c3 48 8b 7d 00 41 b8 05 00 00 00 89 d9 48 c7 c2 d8 e8 0e 8b 48 c7 c6 1d b0 0a 8b e8 df bc fd ff <0f> 0b f0 80 4d 48 04 e9 67 ff ff ff 48 8b 03 48 c1 e8 37 83 e0 07
      [  846.432445] RSP: 0018:ffff961c414a7910 EFLAGS: 00010286
      [  846.432447] RAX: 0000000000000000 RBX: 0000000000000400 RCX: 0000000000000006
      [  846.432448] RDX: 0000000000000000 RSI: 0000000000000092 RDI: ffff89dfffd165d0
      [  846.432449] RBP: ffff89dff5492800 R08: 0000000000000000 R09: 00000000000002d1
      [  846.432450] R10: ffff961c414a7820 R11: ffff89dfad50cf80 R12: 0000000000000400
      [  846.432451] R13: 0000000000000000 R14: ffff89dff4ff88d0 R15: 0000000000000000
      [  846.432453] FS:  00007f882e2fb700(0000) GS:ffff89dfffd00000(0000) knlGS:0000000000000000
      [  846.432454] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  846.432455] CR2: 0000000001a88008 CR3: 00000001eb572000 CR4: 00000000000006e0
      [  846.432459] Call Trace:
      [  846.432463]  f2fs_grab_read_bio+0xbc/0xe0
      [  846.432464]  f2fs_submit_page_read+0x21/0x280
      [  846.432466]  f2fs_get_read_data_page+0xb7/0x3c0
      [  846.432468]  f2fs_get_lock_data_page+0x29/0x1e0
      [  846.432470]  f2fs_get_new_data_page+0x148/0x550
      [  846.432473]  f2fs_add_regular_entry+0x1d2/0x550
      [  846.432475]  ? __switch_to+0x12f/0x460
      [  846.432477]  f2fs_add_dentry+0x6a/0xd0
      [  846.432480]  f2fs_do_add_link+0xe9/0x140
      [  846.432483]  __recover_dot_dentries+0x260/0x280
      [  846.432485]  f2fs_lookup+0x343/0x390
      [  846.432488]  __lookup_slow+0x97/0x150
      [  846.432490]  lookup_slow+0x35/0x50
      [  846.432505]  walk_component+0x1c6/0x470
      [  846.432509]  ? memcg_kmem_charge_memcg+0x70/0x90
      [  846.432511]  ? page_add_file_rmap+0x13/0x200
      [  846.432513]  path_lookupat+0x76/0x230
      [  846.432515]  ? __alloc_pages_nodemask+0xfc/0x280
      [  846.432517]  filename_lookup+0xb8/0x1a0
      [  846.432520]  ? _cond_resched+0x16/0x40
      [  846.432522]  ? kmem_cache_alloc+0x160/0x1d0
      [  846.432525]  ? path_listxattr+0x41/0xa0
      [  846.432526]  path_listxattr+0x41/0xa0
      [  846.432529]  do_syscall_64+0x55/0x100
      [  846.432531]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  846.432533] RIP: 0033:0x7f882de1c0d7
      [  846.432533] Code: f0 ff ff 73 01 c3 48 8b 0d be dd 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 c2 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 dd 2b 00 f7 d8 64 89 01 48
      [  846.432565] RSP: 002b:00007ffe8e66c238 EFLAGS: 00000202 ORIG_RAX: 00000000000000c2
      [  846.432567] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f882de1c0d7
      [  846.432568] RDX: 0000000000000071 RSI: 00007ffe8e66c280 RDI: 0000000001a880c0
      [  846.432569] RBP: 00007ffe8e66c300 R08: 0000000001a88010 R09: 0000000000000000
      [  846.432570] R10: 00000000000001ab R11: 0000000000000202 R12: 0000000000400550
      [  846.432571] R13: 00007ffe8e66c400 R14: 0000000000000000 R15: 0000000000000000
      [  846.432573] ---[ end trace abca54df39d14f5f ]---
      [  846.434280] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      [  846.434424] PGD 80000001ebd3a067 P4D 80000001ebd3a067 PUD 1eb1ae067 PMD 0
      [  846.434551] Oops: 0000 [#1] SMP PTI
      [  846.434697] CPU: 0 PID: 44 Comm: kworker/u5:0 Tainted: G        W         4.18.0-rc3+ #1
      [  846.434805] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [  846.435000] Workqueue: fscrypt_read_queue decrypt_work
      [  846.435174] RIP: 0010:fscrypt_do_page_crypto+0x6e/0x2d0
      [  846.435351] Code: 00 65 48 8b 04 25 28 00 00 00 48 89 84 24 88 00 00 00 31 c0 e8 43 c2 e0 ff 49 8b 86 48 02 00 00 85 ed c7 44 24 70 00 00 00 00 <48> 8b 58 08 0f 84 14 02 00 00 48 8b 78 10 48 8b 0c 24 48 c7 84 24
      [  846.435696] RSP: 0018:ffff961c40f9bd60 EFLAGS: 00010206
      [  846.435870] RAX: 0000000000000000 RBX: ffffc5f787719b80 RCX: ffffc5f787719b80
      [  846.436051] RDX: ffffffff8b9f4b88 RSI: ffffffff8b0ae622 RDI: ffff961c40f9bdb8
      [  846.436261] RBP: 0000000000001000 R08: ffffc5f787719b80 R09: 0000000000001000
      [  846.436433] R10: 0000000000000018 R11: fefefefefefefeff R12: ffffc5f787719b80
      [  846.436562] R13: ffffc5f787719b80 R14: ffff89dff4ff88d0 R15: 0ffff89dfaddee60
      [  846.436658] FS:  0000000000000000(0000) GS:ffff89dfffc00000(0000) knlGS:0000000000000000
      [  846.436758] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  846.436898] CR2: 0000000000000008 CR3: 00000001eddd0000 CR4: 00000000000006f0
      [  846.437001] Call Trace:
      [  846.437181]  ? check_preempt_wakeup+0xf2/0x230
      [  846.437276]  ? check_preempt_curr+0x7c/0x90
      [  846.437370]  fscrypt_decrypt_page+0x48/0x4d
      [  846.437466]  __fscrypt_decrypt_bio+0x5b/0x90
      [  846.437542]  decrypt_work+0x12/0x20
      [  846.437651]  process_one_work+0x15e/0x3d0
      [  846.437740]  worker_thread+0x4c/0x440
      [  846.437848]  kthread+0xf8/0x130
      [  846.437938]  ? rescuer_thread+0x350/0x350
      [  846.438022]  ? kthread_associate_blkcg+0x90/0x90
      [  846.438117]  ret_from_fork+0x35/0x40
      [  846.438201] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd input_leds joydev soundcore serio_raw i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear qxl ttm crct10dif_pclmul crc32_pclmul drm_kms_helper ghash_clmulni_intel syscopyarea sysfillrect sysimgblt fb_sys_fops pcbc drm 8139too aesni_intel 8139cp floppy psmouse mii aes_x86_64 crypto_simd pata_acpi cryptd glue_helper
      [  846.438653] CR2: 0000000000000008
      [  846.438713] ---[ end trace abca54df39d14f60 ]---
      [  846.438796] RIP: 0010:fscrypt_do_page_crypto+0x6e/0x2d0
      [  846.438844] Code: 00 65 48 8b 04 25 28 00 00 00 48 89 84 24 88 00 00 00 31 c0 e8 43 c2 e0 ff 49 8b 86 48 02 00 00 85 ed c7 44 24 70 00 00 00 00 <48> 8b 58 08 0f 84 14 02 00 00 48 8b 78 10 48 8b 0c 24 48 c7 84 24
      [  846.439084] RSP: 0018:ffff961c40f9bd60 EFLAGS: 00010206
      [  846.439176] RAX: 0000000000000000 RBX: ffffc5f787719b80 RCX: ffffc5f787719b80
      [  846.440927] RDX: ffffffff8b9f4b88 RSI: ffffffff8b0ae622 RDI: ffff961c40f9bdb8
      [  846.442083] RBP: 0000000000001000 R08: ffffc5f787719b80 R09: 0000000000001000
      [  846.443284] R10: 0000000000000018 R11: fefefefefefefeff R12: ffffc5f787719b80
      [  846.444448] R13: ffffc5f787719b80 R14: ffff89dff4ff88d0 R15: 0ffff89dfaddee60
      [  846.445558] FS:  0000000000000000(0000) GS:ffff89dfffc00000(0000) knlGS:0000000000000000
      [  846.446687] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  846.447796] CR2: 0000000000000008 CR3: 00000001eddd0000 CR4: 00000000000006f0
      
      - Location
      https://elixir.bootlin.com/linux/v4.18-rc4/source/fs/crypto/crypto.c#L149
      	struct crypto_skcipher *tfm = ci->ci_ctfm;
      Here ci can be NULL
      
      Note that this issue maybe require CONFIG_F2FS_FS_ENCRYPTION=y to reproduce.
      
      Reported-by Wen Xu <wen.xu@gatech.edu>
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      [bwh: Backported to 4.14: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      38fce19d
    • Mathias Nyman's avatar
      xhci: Prevent U1/U2 link pm states if exit latency is too long · cacfa255
      Mathias Nyman authored
      commit 0472bf06 upstream.
      
      Don't allow USB3 U1 or U2 if the latency to wake up from the U-state
      reaches the service interval for a periodic endpoint.
      
      This is according to xhci 1.1 specification section 4.23.5.2 extra note:
      
      "Software shall ensure that a device is prevented from entering a U-state
       where its worst case exit latency approaches the ESIT."
      
      Allowing too long exit latencies for periodic endpoint confuses xHC
      internal scheduling, and new devices may fail to enumerate with a
      "Not enough bandwidth for new device state" error from the host.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cacfa255
    • Sandeep Singh's avatar
      xhci: workaround CSS timeout on AMD SNPS 3.0 xHC · 3ff01312
      Sandeep Singh authored
      commit a7d57abc upstream.
      
      Occasionally AMD SNPS 3.0 xHC does not respond to
      CSS when set, also it does not flag anything on SRE and HCE
      to point the internal xHC errors on USBSTS register. This stalls
      the entire system wide suspend and there is no point in stalling
      just because of xHC CSS is not responding.
      
      To work around this problem, if the xHC does not flag
      anything on SRE and HCE, we can skip the CSS
      timeout and allow the system to continue the suspend. Once the
      system resume happens we can internally reset the controller
      using XHCI_RESET_ON_RESUME quirk
      Signed-off-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      Signed-off-by: default avatarSandeep Singh <Sandeep.Singh@amd.com>
      cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ff01312
    • Kees Cook's avatar
      ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE · f9e0bc71
      Kees Cook authored
      commit e46daee5 upstream.
      
      The arm compiler internally interprets an inline assembly label
      as an unsigned long value, not a pointer. As a result, under
      CONFIG_FORTIFY_SOURCE, the address of a label has a size of 4 bytes,
      which was tripping the runtime checks. Instead, we can just cast the label
      (as done with the size calculations earlier).
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1639397Reported-by: default avatarWilliam Cohen <wcohen@redhat.com>
      Fixes: 6974f0c4 ("include/linux/string.h: add the option of fortified string.h functions")
      Cc: stable@vger.kernel.org
      Acked-by: default avatarLaura Abbott <labbott@redhat.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Tested-by: default avatarWilliam Cohen <wcohen@redhat.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9e0bc71
    • Bin Liu's avatar
      dmaengine: cppi41: delete channel from pending list when stop channel · e47a6e68
      Bin Liu authored
      commit 59861547 upstream.
      
      The driver defines three states for a cppi channel.
      - idle: .chan_busy == 0 && not in .pending list
      - pending: .chan_busy == 0 && in .pending list
      - busy: .chan_busy == 1 && not in .pending list
      
      There are cases in which the cppi channel could be in the pending state
      when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
      is called.
      
      cppi41_stop_chan() has a bug for these cases to set channels to idle state.
      It only checks the .chan_busy flag, but not the .pending list, then later
      when cppi41_runtime_resume() is called the channels in .pending list will
      be transitioned to busy state.
      
      Removing channels from the .pending list solves the problem.
      
      Fixes: 975faaeb ("dma: cppi41: start tear down only if channel is busy")
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Reviewed-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e47a6e68
    • Andy Shevchenko's avatar
      dmaengine: dw: Fix FIFO size for Intel Merrifield · bc3d506a
      Andy Shevchenko authored
      commit ffe843b1 upstream.
      
      Intel Merrifield has a reduced size of FIFO used in iDMA 32-bit controller,
      i.e. 512 bytes instead of 1024.
      
      Fix this by partitioning it as 64 bytes per channel.
      
      Note, in the future we might switch to 'fifo-size' property instead of
      hard coded value.
      
      Fixes: 199244d6 ("dmaengine: dw: add support of iDMA 32-bit hardware")
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc3d506a
    • Chuck Lever's avatar
      SUNRPC: Fix leak of krb5p encode pages · e3dccb52
      Chuck Lever authored
      commit 8dae5398 upstream.
      
      call_encode can be invoked more than once per RPC call. Ensure that
      each call to gss_wrap_req_priv does not overwrite pointers to
      previously allocated memory.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3dccb52
    • Stefan Hajnoczi's avatar
      vhost/vsock: fix use-after-free in network stack callers · f15c072d
      Stefan Hajnoczi authored
      commit 834e772c upstream.
      
      If the network stack calls .send_pkt()/.cancel_pkt() during .release(),
      a struct vhost_vsock use-after-free is possible.  This occurs because
      .release() does not wait for other CPUs to stop using struct
      vhost_vsock.
      
      Switch to an RCU-enabled hashtable (indexed by guest CID) so that
      .release() can wait for other CPUs by calling synchronize_rcu().  This
      also eliminates vhost_vsock_lock acquisition in the data path so it
      could have a positive effect on performance.
      
      This is CVE-2018-14625 "kernel: use-after-free Read in vhost_transport_send_pkt".
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: syzbot+bd391451452fb0b93039@syzkaller.appspotmail.com
      Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
      Reported-by: syzbot+d5a0a170c5069658b141@syzkaller.appspotmail.com
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f15c072d
    • Halil Pasic's avatar
      virtio/s390: fix race in ccw_io_helper() · 52b993b4
      Halil Pasic authored
      commit 78b1a52e upstream.
      
      While ccw_io_helper() seems like intended to be exclusive in a sense that
      it is supposed to facilitate I/O for at most one thread at any given
      time, there is actually nothing ensuring that threads won't pile up at
      vcdev->wait_q. If they do, all threads get woken up and see the status
      that belongs to some other request than their own. This can lead to bugs.
      For an example see:
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432
      
      This race normally does not cause any problems. The operations provided
      by struct virtio_config_ops are usually invoked in a well defined
      sequence, normally don't fail, and are normally used quite infrequent
      too.
      
      Yet, if some of the these operations are directly triggered via sysfs
      attributes, like in the case described by the referenced bug, userspace
      is given an opportunity to force races by increasing the frequency of the
      given operations.
      
      Let us fix the problem by ensuring, that for each device, we finish
      processing the previous request before starting with a new one.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Cc: stable@vger.kernel.org
      Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52b993b4
    • Halil Pasic's avatar
      virtio/s390: avoid race on vcdev->config · 73f6d525
      Halil Pasic authored
      commit 2448a299 upstream.
      
      Currently we have a race on vcdev->config in virtio_ccw_get_config() and
      in virtio_ccw_set_config().
      
      This normally does not cause problems, as these are usually infrequent
      operations. However, for some devices writing to/reading from the config
      space can be triggered through sysfs attributes. For these, userspace can
      force the race by increasing the frequency.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Cc: stable@vger.kernel.org
      Message-Id: <20180925121309.58524-2-pasic@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73f6d525
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570 · 01a02e66
      Takashi Iwai authored
      commit 54947cd6 upstream.
      
      We've got a regression report for some Thinkpad models (at least
      T570s) which shows the too low speaker output volume.  The bisection
      leaded to the commit 61fcf8ec ("ALSA: hda/realtek - Enable Thinkpad
      Dock device for ALC298 platform"), and it's basically adding the two
      pin configurations for the dock, and looks harmless.
      
      The real culprit seems, though, that the DAC assignment for the
      speaker pin is implicitly assumed on these devices, i.e. pin NID 0x14
      to be coupled with DAC NID 0x03.  When more pins are configured by the
      commit above, the auto-parser changes the DAC assignment, and this
      resulted in the regression.
      
      As a workaround, just provide the fixed pin / DAC mapping table for
      this Thinkpad fixup function.  It's no generic solution, but the
      problem itself is pretty much device-specific, so must be good
      enough.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1554304
      Fixes: 61fcf8ec ("ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform")
      Cc: <stable@vger.kernel.org>
      Reported-and-tested-by: default avatarJeremy Cline <jcline@redhat.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01a02e66
    • Takashi Iwai's avatar
      ALSA: pcm: Fix interval evaluation with openmin/max · 7852f54f
      Takashi Iwai authored
      commit 5363857b upstream.
      
      As addressed in alsa-lib (commit b420056604f0), we need to fix the
      case where the evaluation of PCM interval "(x x+1]" leading to
      -EINVAL.  After applying rules, such an interval may be translated as
      "(x x+1)".
      
      Fixes: ff2d6acd ("ALSA: pcm: Fix snd_interval_refine first/last with open min/max")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7852f54f
    • Takashi Iwai's avatar
      ALSA: pcm: Call snd_pcm_unlink() conditionally at closing · cabb9539
      Takashi Iwai authored
      commit b51abed8 upstream.
      
      Currently the PCM core calls snd_pcm_unlink() always unconditionally
      at closing a stream.  However, since snd_pcm_unlink() invokes the
      global rwsem down, the lock can be easily contended.  More badly, when
      a thread runs in a high priority RT-FIFO, it may stall at spinning.
      
      Basically the call of snd_pcm_unlink() is required only for the linked
      streams that are already rare occasion.  For normal use cases, this
      code path is fairly superfluous.
      
      As an optimization (and also as a workaround for the RT problem
      above in normal situations without linked streams), this patch adds a
      check before calling snd_pcm_unlink() and calls it only when needed.
      Reported-by: default avatarChanho Min <chanho.min@lge.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cabb9539
    • Chanho Min's avatar
      ALSA: pcm: Fix starvation on down_write_nonblock() · 108ab9ea
      Chanho Min authored
      commit b888a5f7 upstream.
      
      Commit 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM
      stream") fixes deadlock for non-atomic PCM stream. But, This patch
      causes antother stuck.
      If writer is RT thread and reader is a normal thread, the reader
      thread will be difficult to get scheduled. It may not give chance to
      release readlocks and writer gets stuck for a long time if they are
      pinned to single cpu.
      
      The deadlock described in the previous commit is because the linux
      rwsem queues like a FIFO. So, we might need non-FIFO writelock, not
      non-block one.
      
      My suggestion is that the writer gives reader a chance to be scheduled
      by using the minimum msleep() instaed of spinning without blocking by
      writer. Also, The *_nonblock may be changed to *_nonfifo appropriately
      to this concept.
      In terms of performance, when trylock is failed, this minimum periodic
      msleep will have the same performance as the tick-based
      schedule()/wake_up_q().
      
      [ Although this has a fairly high performance penalty, the relevant
        code path became already rare due to the previous commit ("ALSA:
        pcm: Call snd_pcm_unlink() conditionally at closing").  That is, now
        this unconditional msleep appears only when using linked streams,
        and this must be a rare case.  So we accept this as a quick
        workaround until finding a more suitable one -- tiwai ]
      
      Fixes: 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream")
      Suggested-by: default avatarWonmin Jung <wonmin.jung@lge.com>
      Signed-off-by: default avatarChanho Min <chanho.min@lge.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      108ab9ea
    • Kai-Heng Feng's avatar
      ALSA: hda: Add support for AMD Stoney Ridge · 0618c71c
      Kai-Heng Feng authored
      commit 3deef52c upstream.
      
      It's similar to other AMD audio devices, it also supports D3, which can
      save some power drain.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0618c71c
    • Hui Peng's avatar
      ALSA: usb-audio: Fix UAF decrement if card has no live interfaces in card.c · 19f74e45
      Hui Peng authored
      commit 5f8cf712 upstream.
      
      If a USB sound card reports 0 interfaces, an error condition is triggered
      and the function usb_audio_probe errors out. In the error path, there was a
      use-after-free vulnerability where the memory object of the card was first
      freed, followed by a decrement of the number of active chips. Moving the
      decrement above the atomic_dec fixes the UAF.
      
      [ The original problem was introduced in 3.1 kernel, while it was
        developed in a different form.  The Fixes tag below indicates the
        original commit but it doesn't mean that the patch is applicable
        cleanly. -- tiwai ]
      
      Fixes: 362e4e49 ("ALSA: usb-audio - clear chip->probing on error exit")
      Reported-by: default avatarHui Peng <benquike@gmail.com>
      Reported-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Signed-off-by: default avatarHui Peng <benquike@gmail.com>
      Signed-off-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19f74e45
    • Mathias Payer's avatar
      USB: check usb_get_extra_descriptor for proper size · 7b6e85da
      Mathias Payer authored
      commit 704620af upstream.
      
      When reading an extra descriptor, we need to properly check the minimum
      and maximum size allowed, to prevent from invalid data being sent by a
      device.
      Reported-by: default avatarHui Peng <benquike@gmail.com>
      Reported-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Co-developed-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarHui Peng <benquike@gmail.com>
      Signed-off-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: stable <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b6e85da
    • Alexander Theissen's avatar
      usb: appledisplay: Add 27" Apple Cinema Display · 810487aa
      Alexander Theissen authored
      commit d7859905 upstream.
      
      Add another Apple Cinema Display to the list of supported displays.
      Signed-off-by: default avatarAlexander Theissen <alex.theissen@me.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      810487aa
    • Harry Pan's avatar
      usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device · d2afd22a
      Harry Pan authored
      commit 2f2dde6b upstream.
      
      Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is
      in 0781:5591, will aggressively request LPM of U1/U2 during runtime,
      when using this thumb drive as the OS installation key we found the
      device will generate failure during U1 exit path making it dropped
      from the USB bus, this causes a corrupted installation in system at
      the end.
      
      i.e.,
      [  166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004
      [  166.918327] usb usb2-port2: link state change
      [  166.918337] usb usb2-port2: do warm reset
      [  166.970039] usb usb2-port2: not warm reset yet, waiting 50ms
      [  167.022040] usb usb2-port2: not warm reset yet, waiting 200ms
      [  167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s
      [  167.276050] usb 2-2: USB disconnect, device number 2
      [  167.276058] usb 2-2: unregistering device
      [  167.276060] usb 2-2: unregistering interface 2-2:1.0
      [  167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk
      [  167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
      [  167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00
      ...
      
      Analyzed the USB trace in the link layer we realized it is because
      of the 6-ms timer of tRecoveryConfigurationTimeout which documented
      on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from
      Recovery.Configuration"; device initiates U1 exit -> Recovery.Active
      -> Recovery.Configuration, then the host timer timeout makes the link
      transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset.
      
      Interestingly, the other higher volume of SanDisk Ultra Flair sharing
      the same VID:PID, such as 64GB, would not request LPM during runtime,
      it sticks at U0 always, thus disabling LPM does not affect those thumb
      drives at all.
      
      The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583.
      Signed-off-by: default avatarHarry Pan <harry.pan@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2afd22a
    • Tetsuo Handa's avatar
      mm: don't warn about allocations which stall for too long · 4515bbc4
      Tetsuo Handa authored
      [ Upstream commit 400e2249 ]
      
      Commit 63f53dea ("mm: warn about allocations which stall for too
      long") was a great step for reducing possibility of silent hang up
      problem caused by memory allocation stalls.  But this commit reverts it,
      for it is possible to trigger OOM lockup and/or soft lockups when many
      threads concurrently called warn_alloc() (in order to warn about memory
      allocation stalls) due to current implementation of printk(), and it is
      difficult to obtain useful information due to limitation of synchronous
      warning approach.
      
      Current printk() implementation flushes all pending logs using the
      context of a thread which called console_unlock().  printk() should be
      able to flush all pending logs eventually unless somebody continues
      appending to printk() buffer.
      
      Since warn_alloc() started appending to printk() buffer while waiting
      for oom_kill_process() to make forward progress when oom_kill_process()
      is processing pending logs, it became possible for warn_alloc() to force
      oom_kill_process() loop inside printk().  As a result, warn_alloc()
      significantly increased possibility of preventing oom_kill_process()
      from making forward progress.
      
      ---------- Pseudo code start ----------
      Before warn_alloc() was introduced:
      
        retry:
          if (mutex_trylock(&oom_lock)) {
            while (atomic_read(&printk_pending_logs) > 0) {
              atomic_dec(&printk_pending_logs);
              print_one_log();
            }
            // Send SIGKILL here.
            mutex_unlock(&oom_lock)
          }
          goto retry;
      
      After warn_alloc() was introduced:
      
        retry:
          if (mutex_trylock(&oom_lock)) {
            while (atomic_read(&printk_pending_logs) > 0) {
              atomic_dec(&printk_pending_logs);
              print_one_log();
            }
            // Send SIGKILL here.
            mutex_unlock(&oom_lock)
          } else if (waited_for_10seconds()) {
            atomic_inc(&printk_pending_logs);
          }
          goto retry;
      ---------- Pseudo code end ----------
      
      Although waited_for_10seconds() becomes true once per 10 seconds,
      unbounded number of threads can call waited_for_10seconds() at the same
      time.  Also, since threads doing waited_for_10seconds() keep doing
      almost busy loop, the thread doing print_one_log() can use little CPU
      resource.  Therefore, this situation can be simplified like
      
      ---------- Pseudo code start ----------
        retry:
          if (mutex_trylock(&oom_lock)) {
            while (atomic_read(&printk_pending_logs) > 0) {
              atomic_dec(&printk_pending_logs);
              print_one_log();
            }
            // Send SIGKILL here.
            mutex_unlock(&oom_lock)
          } else {
            atomic_inc(&printk_pending_logs);
          }
          goto retry;
      ---------- Pseudo code end ----------
      
      when printk() is called faster than print_one_log() can process a log.
      
      One of possible mitigation would be to introduce a new lock in order to
      make sure that no other series of printk() (either oom_kill_process() or
      warn_alloc()) can append to printk() buffer when one series of printk()
      (either oom_kill_process() or warn_alloc()) is already in progress.
      
      Such serialization will also help obtaining kernel messages in readable
      form.
      
      ---------- Pseudo code start ----------
        retry:
          if (mutex_trylock(&oom_lock)) {
            mutex_lock(&oom_printk_lock);
            while (atomic_read(&printk_pending_logs) > 0) {
              atomic_dec(&printk_pending_logs);
              print_one_log();
            }
            // Send SIGKILL here.
            mutex_unlock(&oom_printk_lock);
            mutex_unlock(&oom_lock)
          } else {
            if (mutex_trylock(&oom_printk_lock)) {
              atomic_inc(&printk_pending_logs);
              mutex_unlock(&oom_printk_lock);
            }
          }
          goto retry;
      ---------- Pseudo code end ----------
      
      But this commit does not go that direction, for we don't want to
      introduce a new lock dependency, and we unlikely be able to obtain
      useful information even if we serialized oom_kill_process() and
      warn_alloc().
      
      Synchronous approach is prone to unexpected results (e.g.  too late [1],
      too frequent [2], overlooked [3]).  As far as I know, warn_alloc() never
      helped with providing information other than "something is going wrong".
      I want to consider asynchronous approach which can obtain information
      during stalls with possibly relevant threads (e.g.  the owner of
      oom_lock and kswapd-like threads) and serve as a trigger for actions
      (e.g.  turn on/off tracepoints, ask libvirt daemon to take a memory dump
      of stalling KVM guest for diagnostic purpose).
      
      This commit temporarily loses ability to report e.g.  OOM lockup due to
      unable to invoke the OOM killer due to !__GFP_FS allocation request.
      But asynchronous approach will be able to detect such situation and emit
      warning.  Thus, let's remove warn_alloc().
      
      [1] https://bugzilla.kernel.org/show_bug.cgi?id=192981
      [2] http://lkml.kernel.org/r/CAM_iQpWuPVGc2ky8M-9yukECtS+zKjiDasNymX7rMcBjBFyM_A@mail.gmail.com
      [3] commit db73ee0d ("mm, vmscan: do not loop on too_many_isolated for ever"))
      
      Link: http://lkml.kernel.org/r/1509017339-4802-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jpSigned-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reported-by: default avataryuwang.yuwang <yuwang.yuwang@alibaba-inc.com>
      Reported-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Steven Rostedt <rostedt@goodmis.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 <sashal@kernel.org>
      4515bbc4
    • Yangtao Li's avatar
      net: amd: add missing of_node_put() · ccbffb5d
      Yangtao Li authored
      [ Upstream commit c44c749d ]
      
      of_find_node_by_path() acquires a reference to the node
      returned by it and that reference needs to be dropped by its caller.
      This place doesn't do that, so fix it.
      Signed-off-by: default avatarYangtao Li <tiny.windzz@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ccbffb5d
    • Hangbin Liu's avatar
      team: no need to do team_notify_peers or team_mcast_rejoin when disabling port · 63e307e8
      Hangbin Liu authored
      [ Upstream commit 5ed9dc99 ]
      
      team_notify_peers() will send ARP and NA to notify peers. team_mcast_rejoin()
      will send multicast join group message to notify peers. We should do this when
      enabling/changed to a new port. But it doesn't make sense to do it when a port
      is disabled.
      
      On the other hand, when we set mcast_rejoin_count to 2, and do a failover,
      team_port_disable() will increase mcast_rejoin.count_pending to 2 and then
      team_port_enable() will increase mcast_rejoin.count_pending to 4. We will send
      4 mcast rejoin messages at latest, which will make user confused. The same
      with notify_peers.count.
      
      Fix it by deleting team_notify_peers() and team_mcast_rejoin() in
      team_port_disable().
      Reported-by: default avatarLiang Li <liali@redhat.com>
      Fixes: fc423ff0 ("team: add peer notification")
      Fixes: 492b200e ("team: add support for sending multicast rejoins")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      63e307e8
    • Thomas Falcon's avatar
      ibmvnic: Fix RX queue buffer cleanup · 1c1fbd4d
      Thomas Falcon authored
      [ Upstream commit b7cdec3d ]
      
      The wrong index is used when cleaning up RX buffer objects during release
      of RX queues. Update to use the correct index counter.
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1c1fbd4d
    • Tigran Mkrtchyan's avatar
      flexfiles: use per-mirror specified stateid for IO · dab45f4d
      Tigran Mkrtchyan authored
      [ Upstream commit bb21ce0a ]
      
      rfc8435 says:
      
        For tight coupling, ffds_stateid provides the stateid to be used by
        the client to access the file.
      
      However current implementation replaces per-mirror provided stateid with
      by open or lock stateid.
      
      Ensure that per-mirror stateid is used by ff_layout_write_prepare_v4 and
      nfs4_ff_layout_prepare_ds.
      Signed-off-by: default avatarTigran Mkrtchyan <tigran.mkrtchyan@desy.de>
      Signed-off-by: default avatarRick Macklem <rmacklem@uoguelph.ca>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dab45f4d
    • Pan Bian's avatar
      iommu/vt-d: Use memunmap to free memremap · 84f49bb0
      Pan Bian authored
      [ Upstream commit 829383e1 ]
      
      memunmap() should be used to free the return of memremap(), not
      iounmap().
      
      Fixes: dfddb969 ('iommu/vt-d: Switch from ioremap_cache to memremap')
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      84f49bb0
    • Vincent Chen's avatar
      net: faraday: ftmac100: remove netif_running(netdev) check before disabling interrupts · d0decb8d
      Vincent Chen authored
      [ Upstream commit 426a593e ]
      
      In the original ftmac100_interrupt(), the interrupts are only disabled when
      the condition "netif_running(netdev)" is true. However, this condition
      causes kerenl hang in the following case. When the user requests to
      disable the network device, kernel will clear the bit __LINK_STATE_START
      from the dev->state and then call the driver's ndo_stop function. Network
      device interrupts are not blocked during this process. If an interrupt
      occurs between clearing __LINK_STATE_START and stopping network device,
      kernel cannot disable the interrupts due to the condition
      "netif_running(netdev)" in the ISR. Hence, kernel will hang due to the
      continuous interruption of the network device.
      
      In order to solve the above problem, the interrupts of the network device
      should always be disabled in the ISR without being restricted by the
      condition "netif_running(netdev)".
      
      [V2]
      Remove unnecessary curly braces.
      Signed-off-by: default avatarVincent Chen <vincentc@andestech.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d0decb8d
    • Denis Bolotin's avatar
      qed: Fix QM getters to always return a valid pq · f7a6fd08
      Denis Bolotin authored
      [ Upstream commit eb62cca9 ]
      
      The getter callers doesn't know the valid Physical Queues (PQ) values.
      This patch makes sure that a valid PQ will always be returned.
      
      The patch consists of 3 fixes:
      
       - When qed_init_qm_get_idx_from_flags() receives a disabled flag, it
         returned PQ 0, which can potentially be another function's pq. Verify
         that flag is enabled, otherwise return default start_pq.
      
       - When qed_init_qm_get_idx_from_flags() receives an unknown flag, it
         returned NULL and could lead to a segmentation fault. Return default
         start_pq instead.
      
       - A modulo operation was added to MCOS/VFS PQ getters to make sure the
         PQ returned is in range of the required flag.
      
      Fixes: b5a9ee7c ("qed: Revise QM cofiguration")
      Signed-off-by: default avatarDenis Bolotin <denis.bolotin@cavium.com>
      Signed-off-by: default avatarMichal Kalderon <michal.kalderon@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f7a6fd08
    • Denis Bolotin's avatar
      qed: Fix bitmap_weight() check · 9dded0ff
      Denis Bolotin authored
      [ Upstream commit 276d43f0 ]
      
      Fix the condition which verifies that only one flag is set. The API
      bitmap_weight() should receive size in bits instead of bytes.
      
      Fixes: b5a9ee7c ("qed: Revise QM cofiguration")
      Signed-off-by: default avatarDenis Bolotin <denis.bolotin@cavium.com>
      Signed-off-by: default avatarMichal Kalderon <michal.kalderon@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9dded0ff
    • Thor Thayer's avatar
      mtd: spi-nor: Fix Cadence QSPI page fault kernel panic · 4b4c6714
      Thor Thayer authored
      [ Upstream commit a6a66f80 ]
      
      The current Cadence QSPI driver caused a kernel panic sporadically
      when writing to QSPI. The problem was caused by writing more bytes
      than needed because the QSPI operated on 4 bytes at a time.
      <snip>
      [   11.202044] Unable to handle kernel paging request at virtual address bffd3000
      [   11.209254] pgd = e463054d
      [   11.211948] [bffd3000] *pgd=2fffb811, *pte=00000000, *ppte=00000000
      [   11.218202] Internal error: Oops: 7 [#1] SMP ARM
      [   11.222797] Modules linked in:
      [   11.225844] CPU: 1 PID: 1317 Comm: systemd-hwdb Not tainted 4.17.7-d0c45cd44a8f
      [   11.235796] Hardware name: Altera SOCFPGA Arria10
      [   11.240487] PC is at __raw_writesl+0x70/0xd4
      [   11.244741] LR is at cqspi_write+0x1a0/0x2cc
      </snip>
      On a page boundary limit the number of bytes copied from the tx buffer
      to remain within the page.
      
      This patch uses a temporary buffer to hold the 4 bytes to write and then
      copies only the bytes required from the tx buffer.
      Reported-by: default avatarAdrian Amborzewicz <adrian.ambrozewicz@intel.com>
      Signed-off-by: default avatarThor Thayer <thor.thayer@linux.intel.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4b4c6714
    • Kai-Heng Feng's avatar
      HID: multitouch: Add pointstick support for Cirque Touchpad · 16f2433e
      Kai-Heng Feng authored
      [ Upstream commit 12d43aac ]
      
      Cirque Touchpad/Pointstick combo is similar to Alps devices, it requires
      MT_CLS_WIN_8_DUAL to expose its pointstick as a mouse.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      16f2433e