1. 31 Jul, 2020 22 commits
    • Hans de Goede's avatar
      HID: apple: Disable Fn-key key-re-mapping on clone keyboards · d1893610
      Hans de Goede authored
      [ Upstream commit a5d81646 ]
      
      The Maxxter KB-BT-001 Bluetooth keyboard, which looks somewhat like the
      Apple Wireless Keyboard, is using the vendor and product IDs (05AC:0239)
      of the Apple Wireless Keyboard (2009 ANSI version) <sigh>.
      
      But its F1 - F10 keys are marked as sending F1 - F10, not the special
      functions hid-apple.c maps them too; and since its descriptors do not
      contain the HID_UP_CUSTOM | 0x0003 usage apple-hid looks for for the
      Fn-key, apple_setup_input() never gets called, so F1 - F6 are mapped
      to key-codes which have not been set in the keybit array causing them
      to not send any events at all.
      
      The lack of a usage code matching the Fn key in the clone is actually
      useful as this allows solving this problem in a generic way.
      
      This commits adds a fn_found flag and it adds a input_configured
      callback which checks if this flag is set once all usages have been
      mapped. If it is not set, then assume this is a clone and clear the
      quirks bitmap so that the hid-apple code does not add any special
      handling to this keyboard.
      
      This fixes F1 - F6 not sending anything at all and F7 - F12 sending
      the wrong codes on the Maxxter KB-BT-001 Bluetooth keyboard and on
      similar clones.
      
      Cc: Joao Moreno <mail@joaomoreno.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d1893610
    • Federico Ricchiuto's avatar
      HID: i2c-hid: add Mediacom FlexBook edge13 to descriptor override · 95c0fa1e
      Federico Ricchiuto authored
      [ Upstream commit 43e666ac ]
      
      The Mediacom FlexBook edge13 uses the SIPODEV SP1064 touchpad, which does not
      supply descriptors, so it has to be added to the override list.
      Signed-off-by: default avatarFederico Ricchiuto <fed.ricchiuto@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      95c0fa1e
    • Pi-Hsun Shih's avatar
      scripts/decode_stacktrace: strip basepath from all paths · 5e085f2f
      Pi-Hsun Shih authored
      [ Upstream commit d178770d ]
      
      Currently the basepath is removed only from the beginning of the string.
      When the symbol is inlined and there's multiple line outputs of
      addr2line, only the first line would have basepath removed.
      
      Change to remove the basepath prefix from all lines.
      
      Fixes: 31013836 ("scripts/decode_stacktrace: match basepath using shell prefix operator, not regex")
      Co-developed-by: default avatarShik Chen <shik@chromium.org>
      Signed-off-by: default avatarPi-Hsun Shih <pihsun@chromium.org>
      Signed-off-by: default avatarShik Chen <shik@chromium.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: default avatarStephen Boyd <swboyd@chromium.org>
      Cc: Sasha Levin <sashal@kernel.org>
      Cc: Nicolas Boichat <drinkcat@chromium.org>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Link: http://lkml.kernel.org/r/20200720082709.252805-1-pihsun@chromium.orgSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5e085f2f
    • Wang Hai's avatar
      net: smc91x: Fix possible memory leak in smc_drv_probe() · 49c4d850
      Wang Hai authored
      [ Upstream commit bca9749b ]
      
      If try_toggle_control_gpio() failed in smc_drv_probe(), free_netdev(ndev)
      should be called to free the ndev created earlier. Otherwise, a memleak
      will occur.
      
      Fixes: 7d2911c4 ("net: smc91x: Fix gpios for device tree based booting")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarWang Hai <wanghai38@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      49c4d850
    • Sergey Organov's avatar
      net: dp83640: fix SIOCSHWTSTAMP to update the struct with actual configuration · 059e2392
      Sergey Organov authored
      [ Upstream commit 473309fb ]
      
      From Documentation/networking/timestamping.txt:
      
        A driver which supports hardware time stamping shall update the
        struct with the actual, possibly more permissive configuration.
      
      Do update the struct passed when we upscale the requested time
      stamping mode.
      
      Fixes: cb646e2b ("ptp: Added a clock driver for the National Semiconductor PHYTER.")
      Signed-off-by: default avatarSergey Organov <sorganov@gmail.com>
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      059e2392
    • George Kennedy's avatar
      ax88172a: fix ax88172a_unbind() failures · 041aff4a
      George Kennedy authored
      [ Upstream commit c28d9a28 ]
      
      If ax88172a_unbind() fails, make sure that the return code is
      less than zero so that cleanup is done properly and avoid UAF.
      
      Fixes: a9a51bd7 ("ax88172a: fix information leak on short answers")
      Signed-off-by: default avatarGeorge Kennedy <george.kennedy@oracle.com>
      Reported-by: syzbot+4cd84f527bf4a10fc9c1@syzkaller.appspotmail.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      041aff4a
    • Christophe JAILLET's avatar
      hippi: Fix a size used in a 'pci_free_consistent()' in an error handling path · 7a1d03de
      Christophe JAILLET authored
      [ Upstream commit 3195c470 ]
      
      The size used when calling 'pci_alloc_consistent()' and
      'pci_free_consistent()' should match.
      
      Fix it and have it consistent with the corresponding call in 'rr_close()'.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7a1d03de
    • Vasundhara Volam's avatar
      bnxt_en: Fix race when modifying pause settings. · 1ff463b6
      Vasundhara Volam authored
      [ Upstream commit 163e9ef6 ]
      
      The driver was modified to not rely on rtnl lock to protect link
      settings about 2 years ago.  The pause setting was missed when
      making that change.  Fix it by acquiring link_lock mutex before
      calling bnxt_hwrm_set_pause().
      
      Fixes: e2dc9b6e ("bnxt_en: Don't use rtnl lock to protect link change logic in workqueue.")
      Signed-off-by: default avatarVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Reviewed-by: default avatarEdwin Peer <edwin.peer@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1ff463b6
    • Boris Burkov's avatar
      btrfs: fix mount failure caused by race with umount · 59b6d221
      Boris Burkov authored
      [ Upstream commit 48cfa61b ]
      
      It is possible to cause a btrfs mount to fail by racing it with a slow
      umount. The crux of the sequence is generic_shutdown_super not yet
      calling sop->put_super before btrfs_mount_root calls btrfs_open_devices.
      If that occurs, btrfs_open_devices will decide the opened counter is
      non-zero, increment it, and skip resetting fs_devices->total_rw_bytes to
      0. From here, mount will call sget which will result in grab_super
      trying to take the super block umount semaphore. That semaphore will be
      held by the slow umount, so mount will block. Before up-ing the
      semaphore, umount will delete the super block, resulting in mount's sget
      reliably allocating a new one, which causes the mount path to dutifully
      fill it out, and increment total_rw_bytes a second time, which causes
      the mount to fail, as we see double the expected bytes.
      
      Here is the sequence laid out in greater detail:
      
      CPU0                                                    CPU1
      down_write sb->s_umount
      btrfs_kill_super
        kill_anon_super(sb)
          generic_shutdown_super(sb);
            shrink_dcache_for_umount(sb);
            sync_filesystem(sb);
            evict_inodes(sb); // SLOW
      
                                                    btrfs_mount_root
                                                      btrfs_scan_one_device
                                                      fs_devices = device->fs_devices
                                                      fs_info->fs_devices = fs_devices
                                                      // fs_devices-opened makes this a no-op
                                                      btrfs_open_devices(fs_devices, mode, fs_type)
                                                      s = sget(fs_type, test, set, flags, fs_info);
                                                        find sb in s_instances
                                                        grab_super(sb);
                                                          down_write(&s->s_umount); // blocks
      
            sop->put_super(sb)
              // sb->fs_devices->opened == 2; no-op
            spin_lock(&sb_lock);
            hlist_del_init(&sb->s_instances);
            spin_unlock(&sb_lock);
            up_write(&sb->s_umount);
                                                          return 0;
                                                        retry lookup
                                                        don't find sb in s_instances (deleted by CPU0)
                                                        s = alloc_super
                                                        return s;
                                                      btrfs_fill_super(s, fs_devices, data)
                                                        open_ctree // fs_devices total_rw_bytes improperly set!
                                                          btrfs_read_chunk_tree
                                                            read_one_dev // increment total_rw_bytes again!!
                                                            super_total_bytes < fs_devices->total_rw_bytes // ERROR!!!
      
      To fix this, we clear total_rw_bytes from within btrfs_read_chunk_tree
      before the calls to read_one_dev, while holding the sb umount semaphore
      and the uuid mutex.
      
      To reproduce, it is sufficient to dirty a decent number of inodes, then
      quickly umount and mount.
      
        for i in $(seq 0 500)
        do
          dd if=/dev/zero of="/mnt/foo/$i" bs=1M count=1
        done
        umount /mnt/foo&
        mount /mnt/foo
      
      does the trick for me.
      
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarBoris Burkov <boris@bur.io>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      59b6d221
    • Filipe Manana's avatar
      btrfs: fix double free on ulist after backref resolution failure · c6ff26b1
      Filipe Manana authored
      commit 580c079b upstream.
      
      At btrfs_find_all_roots_safe() we allocate a ulist and set the **roots
      argument to point to it. However if later we fail due to an error returned
      by find_parent_nodes(), we free that ulist but leave a dangling pointer in
      the **roots argument. Upon receiving the error, a caller of this function
      can attempt to free the same ulist again, resulting in an invalid memory
      access.
      
      One such scenario is during qgroup accounting:
      
      btrfs_qgroup_account_extents()
      
       --> calls btrfs_find_all_roots() passes &new_roots (a stack allocated
           pointer) to btrfs_find_all_roots()
      
         --> btrfs_find_all_roots() just calls btrfs_find_all_roots_safe()
             passing &new_roots to it
      
           --> allocates ulist and assigns its address to **roots (which
               points to new_roots from btrfs_qgroup_account_extents())
      
           --> find_parent_nodes() returns an error, so we free the ulist
               and leave **roots pointing to it after returning
      
       --> btrfs_qgroup_account_extents() sees btrfs_find_all_roots() returned
           an error and jumps to the label 'cleanup', which just tries to
           free again the same ulist
      
      Stack trace example:
      
       ------------[ cut here ]------------
       BTRFS: tree first key check failed
       WARNING: CPU: 1 PID: 1763215 at fs/btrfs/disk-io.c:422 btrfs_verify_level_key+0xe0/0x180 [btrfs]
       Modules linked in: dm_snapshot dm_thin_pool (...)
       CPU: 1 PID: 1763215 Comm: fsstress Tainted: G        W         5.8.0-rc3-btrfs-next-64 #1
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
       RIP: 0010:btrfs_verify_level_key+0xe0/0x180 [btrfs]
       Code: 28 5b 5d (...)
       RSP: 0018:ffffb89b473779a0 EFLAGS: 00010286
       RAX: 0000000000000000 RBX: ffff90397759bf08 RCX: 0000000000000000
       RDX: 0000000000000001 RSI: 0000000000000027 RDI: 00000000ffffffff
       RBP: ffff9039a419c000 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: ffffb89b43301000 R12: 000000000000005e
       R13: ffffb89b47377a2e R14: ffffb89b473779af R15: 0000000000000000
       FS:  00007fc47e1e1000(0000) GS:ffff9039ac200000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007fc47e1df000 CR3: 00000003d9e4e001 CR4: 00000000003606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        read_block_for_search+0xf6/0x350 [btrfs]
        btrfs_next_old_leaf+0x242/0x650 [btrfs]
        resolve_indirect_refs+0x7cf/0x9e0 [btrfs]
        find_parent_nodes+0x4ea/0x12c0 [btrfs]
        btrfs_find_all_roots_safe+0xbf/0x130 [btrfs]
        btrfs_qgroup_account_extents+0x9d/0x390 [btrfs]
        btrfs_commit_transaction+0x4f7/0xb20 [btrfs]
        btrfs_sync_file+0x3d4/0x4d0 [btrfs]
        do_fsync+0x38/0x70
        __x64_sys_fdatasync+0x13/0x20
        do_syscall_64+0x5c/0xe0
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7fc47e2d72e3
       Code: Bad RIP value.
       RSP: 002b:00007fffa32098c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004b
       RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc47e2d72e3
       RDX: 00007fffa3209830 RSI: 00007fffa3209830 RDI: 0000000000000003
       RBP: 000000000000072e R08: 0000000000000001 R09: 0000000000000003
       R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000003e8
       R13: 0000000051eb851f R14: 00007fffa3209970 R15: 00005607c4ac8b50
       irq event stamp: 0
       hardirqs last  enabled at (0): [<0000000000000000>] 0x0
       hardirqs last disabled at (0): [<ffffffffb8eb5e85>] copy_process+0x755/0x1eb0
       softirqs last  enabled at (0): [<ffffffffb8eb5e85>] copy_process+0x755/0x1eb0
       softirqs last disabled at (0): [<0000000000000000>] 0x0
       ---[ end trace 8639237550317b48 ]---
       BTRFS error (device sdc): tree first key mismatch detected, bytenr=62324736 parent_transid=94 key expected=(262,108,1351680) has=(259,108,1921024)
       general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
       CPU: 2 PID: 1763215 Comm: fsstress Tainted: G        W         5.8.0-rc3-btrfs-next-64 #1
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
       RIP: 0010:ulist_release+0x14/0x60 [btrfs]
       Code: c7 07 00 (...)
       RSP: 0018:ffffb89b47377d60 EFLAGS: 00010282
       RAX: 6b6b6b6b6b6b6b6b RBX: ffff903959b56b90 RCX: 0000000000000000
       RDX: 0000000000000001 RSI: 0000000000270024 RDI: ffff9036e2adc840
       RBP: ffff9036e2adc848 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000000 R12: ffff9036e2adc840
       R13: 0000000000000015 R14: ffff9039a419ccf8 R15: ffff90395d605840
       FS:  00007fc47e1e1000(0000) GS:ffff9039ac600000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f8c1c0a51c8 CR3: 00000003d9e4e004 CR4: 00000000003606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        ulist_free+0x13/0x20 [btrfs]
        btrfs_qgroup_account_extents+0xf3/0x390 [btrfs]
        btrfs_commit_transaction+0x4f7/0xb20 [btrfs]
        btrfs_sync_file+0x3d4/0x4d0 [btrfs]
        do_fsync+0x38/0x70
        __x64_sys_fdatasync+0x13/0x20
        do_syscall_64+0x5c/0xe0
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7fc47e2d72e3
       Code: Bad RIP value.
       RSP: 002b:00007fffa32098c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004b
       RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc47e2d72e3
       RDX: 00007fffa3209830 RSI: 00007fffa3209830 RDI: 0000000000000003
       RBP: 000000000000072e R08: 0000000000000001 R09: 0000000000000003
       R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000003e8
       R13: 0000000051eb851f R14: 00007fffa3209970 R15: 00005607c4ac8b50
       Modules linked in: dm_snapshot dm_thin_pool (...)
       ---[ end trace 8639237550317b49 ]---
       RIP: 0010:ulist_release+0x14/0x60 [btrfs]
       Code: c7 07 00 (...)
       RSP: 0018:ffffb89b47377d60 EFLAGS: 00010282
       RAX: 6b6b6b6b6b6b6b6b RBX: ffff903959b56b90 RCX: 0000000000000000
       RDX: 0000000000000001 RSI: 0000000000270024 RDI: ffff9036e2adc840
       RBP: ffff9036e2adc848 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000000 R12: ffff9036e2adc840
       R13: 0000000000000015 R14: ffff9039a419ccf8 R15: ffff90395d605840
       FS:  00007fc47e1e1000(0000) GS:ffff9039ad200000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f6a776f7d40 CR3: 00000003d9e4e002 CR4: 00000000003606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      
      Fix this by making btrfs_find_all_roots_safe() set *roots to NULL after
      it frees the ulist.
      
      Fixes: 8da6d581 ("Btrfs: added btrfs_find_all_roots()")
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6ff26b1
    • Hans de Goede's avatar
      ASoC: rt5670: Correct RT5670_LDO_SEL_MASK · f9162054
      Hans de Goede authored
      commit 5cacc6f5 upstream.
      
      The RT5670_PWR_ANLG1 register has 3 bits to select the LDO voltage,
      so the correct mask is 0x7 not 0x3.
      
      Because of this wrong mask we were programming the ldo bits
      to a setting of binary 001 (0x05 & 0x03) instead of binary 101
      when moving to SND_SOC_BIAS_PREPARE.
      
      According to the datasheet 001 is a reserved value, so no idea
      what it did, since the driver was working fine before I guess we
      got lucky and it does something which is ok.
      
      Fixes: 5e8351de ("ASoC: add RT5670 CODEC driver")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20200628155231.71089-3-hdegoede@redhat.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9162054
    • Takashi Iwai's avatar
      ALSA: info: Drop WARN_ON() from buffer NULL sanity check · 4881d9b6
      Takashi Iwai authored
      commit 60379ba0 upstream.
      
      snd_info_get_line() has a sanity check of NULL buffer -- both buffer
      itself being NULL and buffer->buffer being NULL.  Basically both
      checks are valid and necessary, but the problem is that it's with
      snd_BUG_ON() macro that triggers WARN_ON().  The latter condition
      (NULL buffer->buffer) can be met arbitrarily by user since the buffer
      is allocated at the first write, so it means that user can trigger
      WARN_ON() at will.
      
      This patch addresses it by simply moving buffer->buffer NULL check out
      of snd_BUG_ON() so that spurious WARNING is no longer triggered.
      
      Reported-by: syzbot+e42d0746c3c3699b6061@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200717084023.5928-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4881d9b6
    • Oleg Nesterov's avatar
      uprobes: Change handle_swbp() to send SIGTRAP with si_code=SI_KERNEL, to fix GDB regression · fe6ba50d
      Oleg Nesterov authored
      commit fe5ed7ab upstream.
      
      If a tracee is uprobed and it hits int3 inserted by debugger, handle_swbp()
      does send_sig(SIGTRAP, current, 0) which means si_code == SI_USER. This used
      to work when this code was written, but then GDB started to validate si_code
      and now it simply can't use breakpoints if the tracee has an active uprobe:
      
      	# cat test.c
      	void unused_func(void)
      	{
      	}
      	int main(void)
      	{
      		return 0;
      	}
      
      	# gcc -g test.c -o test
      	# perf probe -x ./test -a unused_func
      	# perf record -e probe_test:unused_func gdb ./test -ex run
      	GNU gdb (GDB) 10.0.50.20200714-git
      	...
      	Program received signal SIGTRAP, Trace/breakpoint trap.
      	0x00007ffff7ddf909 in dl_main () from /lib64/ld-linux-x86-64.so.2
      	(gdb)
      
      The tracee hits the internal breakpoint inserted by GDB to monitor shared
      library events but GDB misinterprets this SIGTRAP and reports a signal.
      
      Change handle_swbp() to use force_sig(SIGTRAP), this matches do_int3_user()
      and fixes the problem.
      
      This is the minimal fix for -stable, arch/x86/kernel/uprobes.c is equally
      wrong; it should use send_sigtrap(TRAP_TRACE) instead of send_sig(SIGTRAP),
      but this doesn't confuse GDB and needs another x86-specific patch.
      Reported-by: default avatarAaron Merey <amerey@redhat.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Reviewed-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20200723154420.GA32043@redhat.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe6ba50d
    • Olga Kornievskaia's avatar
      SUNRPC reverting d03727b2 ("NFSv4 fix CLOSE not waiting for direct IO compeletion") · 968bef60
      Olga Kornievskaia authored
      commit 65caafd0 upstream.
      
      Reverting commit d03727b2 "NFSv4 fix CLOSE not waiting for
      direct IO compeletion". This patch made it so that fput() by calling
      inode_dio_done() in nfs_file_release() would wait uninterruptably
      for any outstanding directIO to the file (but that wait on IO should
      be killable).
      
      The problem the patch was also trying to address was REMOVE returning
      ERR_ACCESS because the file is still opened, is supposed to be resolved
      by server returning ERR_FILE_OPEN and not ERR_ACCESS.
      Signed-off-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      968bef60
    • Ben Skeggs's avatar
      drm/nouveau/i2c/g94-: increase NV_PMGR_DP_AUXCTL_TRANSACTREQ timeout · 237169c0
      Ben Skeggs authored
      [ Upstream commit 0156e76d ]
      
      Tegra TRM says worst-case reply time is 1216us, and this should fix some
      spurious timeouts that have been popping up.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      237169c0
    • Tom Rix's avatar
      net: sky2: initialize return of gm_phy_read · 31b10f2c
      Tom Rix authored
      [ Upstream commit 28b18e4e ]
      
      clang static analysis flags this garbage return
      
      drivers/net/ethernet/marvell/sky2.c:208:2: warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn]
              return v;
              ^~~~~~~~
      
      static inline u16 gm_phy_read( ...
      {
      	u16 v;
      	__gm_phy_read(hw, port, reg, &v);
      	return v;
      }
      
      __gm_phy_read can return without setting v.
      
      So handle similar to skge.c's gm_phy_read, initialize v.
      Signed-off-by: default avatarTom Rix <trix@redhat.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      31b10f2c
    • Xie He's avatar
      drivers/net/wan/lapbether: Fixed the value of hard_header_len · 4d565f46
      Xie He authored
      [ Upstream commit 9dc829a1 ]
      
      When this driver transmits data,
        first this driver will remove a pseudo header of 1 byte,
        then the lapb module will prepend the LAPB header of 2 or 3 bytes,
        then this driver will prepend a length field of 2 bytes,
        then the underlying Ethernet device will prepend its own header.
      
      So, the header length required should be:
        -1 + 3 + 2 + "the header length needed by the underlying device".
      
      This patch fixes kernel panic when this driver is used with AF_PACKET
      SOCK_DGRAM sockets.
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4d565f46
    • Max Filippov's avatar
      xtensa: update *pos in cpuinfo_op.next · 55ba6c92
      Max Filippov authored
      [ Upstream commit 0d5ab144 ]
      
      Increment *pos in the cpuinfo_op.next to fix the following warning
      triggered by cat /proc/cpuinfo:
      
        seq_file: buggy .next function c_next did not update position index
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      55ba6c92
    • Max Filippov's avatar
      xtensa: fix __sync_fetch_and_{and,or}_4 declarations · 068dae90
      Max Filippov authored
      [ Upstream commit 73f99413 ]
      
      Building xtensa kernel with gcc-10 produces the following warnings:
        arch/xtensa/kernel/xtensa_ksyms.c:90:15: warning: conflicting types
          for built-in function ‘__sync_fetch_and_and_4’;
          expected ‘unsigned int(volatile void *, unsigned int)’
          [-Wbuiltin-declaration-mismatch]
        arch/xtensa/kernel/xtensa_ksyms.c:96:15: warning: conflicting types
          for built-in function ‘__sync_fetch_and_or_4’;
          expected ‘unsigned int(volatile void *, unsigned int)’
          [-Wbuiltin-declaration-mismatch]
      
      Fix declarations of these functions to avoid the warning.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      068dae90
    • Tom Rix's avatar
      scsi: scsi_transport_spi: Fix function pointer check · f7a44712
      Tom Rix authored
      [ Upstream commit 5aee52c4 ]
      
      clang static analysis flags several null function pointer problems.
      
      drivers/scsi/scsi_transport_spi.c:374:1: warning: Called function pointer is null (null dereference) [core.CallAndMessage]
      spi_transport_max_attr(offset, "%d\n");
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Reviewing the store_spi_store_max macro
      
      	if (i->f->set_##field)
      		return -EINVAL;
      
      should be
      
      	if (!i->f->set_##field)
      		return -EINVAL;
      
      Link: https://lore.kernel.org/r/20200627133242.21618-1-trix@redhat.comReviewed-by: default avatarJames Bottomley <jejb@linux.ibm.com>
      Signed-off-by: default avatarTom Rix <trix@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f7a44712
    • Markus Theil's avatar
      mac80211: allow rx of mesh eapol frames with default rx key · 12b51380
      Markus Theil authored
      [ Upstream commit 0b467b63 ]
      
      Without this patch, eapol frames cannot be received in mesh
      mode, when 802.1X should be used. Initially only a MGTK is
      defined, which is found and set as rx->key, when there are
      no other keys set. ieee80211_drop_unencrypted would then
      drop these eapol frames, as they are data frames without
      encryption and there exists some rx->key.
      
      Fix this by differentiating between mesh eapol frames and
      other data frames with existing rx->key. Allow mesh mesh
      eapol frames only if they are for our vif address.
      
      With this patch in-place, ieee80211_rx_h_mesh_fwding continues
      after the ieee80211_drop_unencrypted check and notices, that
      these eapol frames have to be delivered locally, as they should.
      Signed-off-by: default avatarMarkus Theil <markus.theil@tu-ilmenau.de>
      Link: https://lore.kernel.org/r/20200625104214.50319-1-markus.theil@tu-ilmenau.de
      [small code cleanups]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      12b51380
    • Jacky Hu's avatar
      pinctrl: amd: fix npins for uart0 in kerncz_groups · 309767db
      Jacky Hu authored
      [ Upstream commit 69339d08 ]
      
      uart0_pins is defined as:
      static const unsigned uart0_pins[] = {135, 136, 137, 138, 139};
      
      which npins is wronly specified as 9 later
      	{
      		.name = "uart0",
      		.pins = uart0_pins,
      		.npins = 9,
      	},
      
      npins should be 5 instead of 9 according to the definition.
      Signed-off-by: default avatarJacky Hu <hengqing.hu@gmail.com>
      Link: https://lore.kernel.org/r/20200616015024.287683-1-hengqing.hu@gmail.comSigned-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      309767db
  2. 22 Jul, 2020 18 commits