1. 12 Feb, 2023 6 commits
  2. 11 Feb, 2023 5 commits
  3. 10 Feb, 2023 16 commits
  4. 09 Feb, 2023 13 commits
    • Dave Airlie's avatar
      Merge tag 'amd-drm-fixes-6.2-2023-02-09' of... · 777c1e01
      Dave Airlie authored
      Merge tag 'amd-drm-fixes-6.2-2023-02-09' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
      
      amd-drm-fixes-6.2-2023-02-09:
      
      amdgpu:
      - Add a parameter to disable S/G display
      - Re-enable S/G display on all DCNs
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      From: Alex Deucher <alexander.deucher@amd.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20230209174504.7577-1-alexander.deucher@amd.com
      777c1e01
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2023-02-09' of... · 0ed90416
      Dave Airlie authored
      Merge tag 'drm-intel-fixes-2023-02-09' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
      
      - Display watermark fix (Ville)
      - fbdev fix for PSR, FBC, DRRS (Jouni)
      - Move fd_install after last use of fence (Rob)
      - Initialize the obj flags for shmem objects (Aravind)
      - Fix VBT DSI DVO port handling (Ville)
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      
      From: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/Y+UZ0rh2YlhTrE4t@intel.com
      0ed90416
    • Dave Airlie's avatar
      Merge tag 'drm-misc-fixes-2023-02-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes · 337d5b5e
      Dave Airlie authored
      A fix for a circular refcounting in drm/client, one for a memory leak in
      amdgpu and a virtio fence fix when interrupted
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      
      From: Maxime Ripard <maxime@cerno.tech>
      Link: https://patchwork.freedesktop.org/patch/msgid/20230209083600.7hi6roht6xxgldgz@houat
      337d5b5e
    • Guo Ren's avatar
      riscv: Fixup race condition on PG_dcache_clean in flush_icache_pte · 950b879b
      Guo Ren authored
      In commit 588a513d ("arm64: Fix race condition on PG_dcache_clean
      in __sync_icache_dcache()"), we found RISC-V has the same issue as the
      previous arm64. The previous implementation didn't guarantee the correct
      sequence of operations, which means flush_icache_all() hasn't been
      called when the PG_dcache_clean was set. That would cause a risk of page
      synchronization.
      
      Fixes: 08f051ed ("RISC-V: Flush I$ when making a dirty page executable")
      Signed-off-by: default avatarGuo Ren <guoren@linux.alibaba.com>
      Signed-off-by: default avatarGuo Ren <guoren@kernel.org>
      Reviewed-by: default avatarAndrew Jones <ajones@ventanamicro.com>
      Reviewed-by: default avatarConor Dooley <conor.dooley@microchip.com>
      Link: https://lore.kernel.org/r/20230127035306.1819561-1-guoren@kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      950b879b
    • Guo Ren's avatar
      riscv: kprobe: Fixup misaligned load text · eb742327
      Guo Ren authored
      The current kprobe would cause a misaligned load for the probe point.
      This patch fixup it with two half-word loads instead.
      
      Fixes: c22b0bcb ("riscv: Add kprobes supported")
      Signed-off-by: default avatarGuo Ren <guoren@linux.alibaba.com>
      Signed-off-by: default avatarGuo Ren <guoren@kernel.org>
      Link: https://lore.kernel.org/linux-riscv/878rhig9zj.fsf@all.your.base.are.belong.to.us/Reported-by: default avatarBjorn Topel <bjorn.topel@gmail.com>
      Reviewed-by: default avatarBjörn Töpel <bjorn@kernel.org>
      Link: https://lore.kernel.org/r/20230204063531.740220-1-guoren@kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      eb742327
    • Linus Torvalds's avatar
      Merge tag 'pm-6.2-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · e544a074
      Linus Torvalds authored
      Pull power management fix from Rafael Wysocki:
       "Fix the incorrect value returned by cpufreq driver's ->get() callback
        for Qualcomm platforms (Douglas Anderson)"
      
      * tag 'pm-6.2-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        cpufreq: qcom-hw: Fix cpufreq_driver->get() for non-LMH systems
      e544a074
    • Linus Torvalds's avatar
      Merge tag 'net-6.2-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 35674e78
      Linus Torvalds authored
      Pull networking fixes from Paolo Abeni:
       "Including fixes from can and ipsec subtrees.
      
        Current release - regressions:
      
         - sched: fix off by one in htb_activate_prios()
      
         - eth: mana: fix accessing freed irq affinity_hint
      
         - eth: ice: fix out-of-bounds KASAN warning in virtchnl
      
        Current release - new code bugs:
      
         - eth: mtk_eth_soc: enable special tag when any MAC uses DSA
      
        Previous releases - always broken:
      
         - core: fix sk->sk_txrehash default
      
         - neigh: make sure used and confirmed times are valid
      
         - mptcp: be careful on subflow status propagation on errors
      
         - xfrm: prevent potential spectre v1 gadget in xfrm_xlate32_attr()
      
         - phylink: move phy_device_free() to correctly release phy device
      
         - eth: mlx5:
            - fix crash unsetting rx-vlan-filter in switchdev mode
            - fix hang on firmware reset
            - serialize module cleanup with reload and remove"
      
      * tag 'net-6.2-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (57 commits)
        selftests: forwarding: lib: quote the sysctl values
        net: mscc: ocelot: fix all IPv6 getting trapped to CPU when PTP timestamping is used
        rds: rds_rm_zerocopy_callback() use list_first_entry()
        net: txgbe: Update support email address
        selftests: Fix failing VXLAN VNI filtering test
        selftests: mptcp: stop tests earlier
        selftests: mptcp: allow more slack for slow test-case
        mptcp: be careful on subflow status propagation on errors
        mptcp: fix locking for in-kernel listener creation
        mptcp: fix locking for setsockopt corner-case
        mptcp: do not wait for bare sockets' timeout
        net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
        nfp: ethtool: fix the bug of setting unsupported port speed
        txhash: fix sk->sk_txrehash default
        net: ethernet: mtk_eth_soc: fix wrong parameters order in __xdp_rxq_info_reg()
        net: ethernet: mtk_eth_soc: enable special tag when any MAC uses DSA
        net: sched: sch: Fix off by one in htb_activate_prios()
        igc: Add ndo_tx_timeout support
        net: mana: Fix accessing freed irq affinity_hint
        hv_netvsc: Allocate memory in netvsc_dma_map() with GFP_ATOMIC
        ...
      35674e78
    • Linus Torvalds's avatar
      Merge tag 'for-linus-2023020901' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid · 0b028189
      Linus Torvalds authored
      Pull HID fixes from Benjamin Tissoires:
      
       - fix potential infinite loop with a badly crafted HID device (Xin
         Zhao)
      
       - fix regression from 6.1 in USB logitech devices potentially making
         their mouse wheel not working (Bastien Nocera)
      
       - clean up in AMD sensors, which fixes a long time resume bug (Mario
         Limonciello)
      
       - few device small fixes and quirks
      
      * tag 'for-linus-2023020901' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
        HID: Ignore battery for ELAN touchscreen 29DF on HP
        HID: amd_sfh: if no sensors are enabled, clean up
        HID: logitech: Disable hi-res scrolling on USB
        HID: core: Fix deadloop in hid_apply_multiplier.
        HID: Ignore battery for Elan touchscreen on Asus TP420IA
        HID: elecom: add support for TrackBall 056E:011C
      0b028189
    • Linus Torvalds's avatar
      Merge tag '6.2-rc8-smb3-client-fix' of git://git.samba.org/sfrench/cifs-2.6 · 94a1f56d
      Linus Torvalds authored
      Pull cifx fix from Steve French:
       "Small fix for use after free"
      
      * tag '6.2-rc8-smb3-client-fix' of git://git.samba.org/sfrench/cifs-2.6:
        cifs: Fix use-after-free in rdata->read_into_pages()
      94a1f56d
    • Anand Jain's avatar
      btrfs: free device in btrfs_close_devices for a single device filesystem · 5f58d783
      Anand Jain authored
      We have this check to make sure we don't accidentally add older devices
      that may have disappeared and re-appeared with an older generation from
      being added to an fs_devices (such as a replace source device). This
      makes sense, we don't want stale disks in our file system. However for
      single disks this doesn't really make sense.
      
      I've seen this in testing, but I was provided a reproducer from a
      project that builds btrfs images on loopback devices. The loopback
      device gets cached with the new generation, and then if it is re-used to
      generate a new file system we'll fail to mount it because the new fs is
      "older" than what we have in cache.
      
      Fix this by freeing the cache when closing the device for a single device
      filesystem. This will ensure that the mount command passed device path is
      scanned successfully during the next mount.
      
      CC: stable@vger.kernel.org # 5.10+
      Reported-by: default avatarDaan De Meyer <daandemeyer@fb.com>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarAnand Jain <anand.jain@oracle.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      5f58d783
    • Filipe Manana's avatar
      btrfs: lock the inode in shared mode before starting fiemap · 519b7e13
      Filipe Manana authored
      Currently fiemap does not take the inode's lock (VFS lock), it only locks
      a file range in the inode's io tree. This however can lead to a deadlock
      if we have a concurrent fsync on the file and fiemap code triggers a fault
      when accessing the user space buffer with fiemap_fill_next_extent(). The
      deadlock happens on the inode's i_mmap_lock semaphore, which is taken both
      by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by
      syzbot and triggers a trace like the following:
      
         task:syz-executor361 state:D stack:20264 pid:5668  ppid:5119   flags:0x00004004
         Call Trace:
          <TASK>
          context_switch kernel/sched/core.c:5293 [inline]
          __schedule+0x995/0xe20 kernel/sched/core.c:6606
          schedule+0xcb/0x190 kernel/sched/core.c:6682
          wait_on_state fs/btrfs/extent-io-tree.c:707 [inline]
          wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751
          lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742
          find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488
          writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863
          __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174
          extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091
          extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211
          do_writepages+0x3c3/0x680 mm/page-writeback.c:2581
          filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388
          __filemap_fdatawrite_range mm/filemap.c:421 [inline]
          filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439
          btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline]
          start_ordered_ops fs/btrfs/file.c:1737 [inline]
          btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839
          generic_write_sync include/linux/fs.h:2885 [inline]
          btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684
          call_write_iter include/linux/fs.h:2189 [inline]
          new_sync_write fs/read_write.c:491 [inline]
          vfs_write+0x7dc/0xc50 fs/read_write.c:584
          ksys_write+0x177/0x2a0 fs/read_write.c:637
          do_syscall_x64 arch/x86/entry/common.c:50 [inline]
          do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
          entry_SYSCALL_64_after_hwframe+0x63/0xcd
         RIP: 0033:0x7f7d4054e9b9
         RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
         RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9
         RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006
         RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000
         R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69
         R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8
          </TASK>
         INFO: task syz-executor361:5697 blocked for more than 145 seconds.
               Not tainted 6.2.0-rc3-syzkaller-00376-g7c698440 #0
         "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
         task:syz-executor361 state:D stack:21216 pid:5697  ppid:5119   flags:0x00004004
         Call Trace:
          <TASK>
          context_switch kernel/sched/core.c:5293 [inline]
          __schedule+0x995/0xe20 kernel/sched/core.c:6606
          schedule+0xcb/0x190 kernel/sched/core.c:6682
          rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095
          __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260
          btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526
          do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947
          wp_page_shared+0x15e/0x380 mm/memory.c:3295
          handle_pte_fault mm/memory.c:4949 [inline]
          __handle_mm_fault mm/memory.c:5073 [inline]
          handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219
          do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428
          handle_page_fault arch/x86/mm/fault.c:1519 [inline]
          exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575
          asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570
         RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233
         Code: 74 0a 89 (...)
         RSP: 0018:ffffc9000570f330 EFLAGS: 00050202
         RAX: ffffffff843e6601 RBX: 00007fffffffefc8 RCX: 0000000000000007
         RDX: 0000000000000000 RSI: ffffc9000570f3e0 RDI: 0000000020000120
         RBP: ffffc9000570f490 R08: 0000000000000000 R09: fffff52000ae1e83
         R10: fffff52000ae1e83 R11: 1ffff92000ae1e7c R12: 0000000000000038
         R13: ffffc9000570f3e0 R14: 0000000020000120 R15: ffffc9000570f3e0
          copy_user_generic arch/x86/include/asm/uaccess_64.h:37 [inline]
          raw_copy_to_user arch/x86/include/asm/uaccess_64.h:58 [inline]
          _copy_to_user+0xe9/0x130 lib/usercopy.c:34
          copy_to_user include/linux/uaccess.h:169 [inline]
          fiemap_fill_next_extent+0x22e/0x410 fs/ioctl.c:144
          emit_fiemap_extent+0x22d/0x3c0 fs/btrfs/extent_io.c:3458
          fiemap_process_hole+0xa00/0xad0 fs/btrfs/extent_io.c:3716
          extent_fiemap+0xe27/0x2100 fs/btrfs/extent_io.c:3922
          btrfs_fiemap+0x172/0x1e0 fs/btrfs/inode.c:8209
          ioctl_fiemap fs/ioctl.c:219 [inline]
          do_vfs_ioctl+0x185b/0x2980 fs/ioctl.c:810
          __do_sys_ioctl fs/ioctl.c:868 [inline]
          __se_sys_ioctl+0x83/0x170 fs/ioctl.c:856
          do_syscall_x64 arch/x86/entry/common.c:50 [inline]
          do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
          entry_SYSCALL_64_after_hwframe+0x63/0xcd
         RIP: 0033:0x7f7d4054e9b9
         RSP: 002b:00007f7d390d92f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
         RAX: ffffffffffffffda RBX: 00007f7d405d87b0 RCX: 00007f7d4054e9b9
         RDX: 0000000020000100 RSI: 00000000c020660b RDI: 0000000000000005
         RBP: 00007f7d405a51d0 R08: 00007f7d390d9700 R09: 0000000000000000
         R10: 00007f7d390d9700 R11: 0000000000000246 R12: 61635f65646f6e69
         R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87b8
          </TASK>
      
      What happens is the following:
      
      1) Task A is doing an fsync, enters btrfs_sync_file() and flushes delalloc
         before locking the inode and the i_mmap_lock semaphore, that is, before
         calling btrfs_inode_lock();
      
      2) After task A flushes delalloc and before it calls btrfs_inode_lock(),
         another task dirties a page;
      
      3) Task B starts a fiemap without FIEMAP_FLAG_SYNC, so the page dirtied
         at step 2 remains dirty and unflushed. Then when it enters
         extent_fiemap() and it locks a file range that includes the range of
         the page dirtied in step 2;
      
      4) Task A calls btrfs_inode_lock() and locks the inode (VFS lock) and the
         inode's i_mmap_lock semaphore in write mode. Then it tries to flush
         delalloc by calling start_ordered_ops(), which will block, at
         find_lock_delalloc_range(), when trying to lock the range of the page
         dirtied at step 2, since this range was locked by the fiemap task (at
         step 3);
      
      5) Task B generates a page fault when accessing the user space fiemap
         buffer with a call to fiemap_fill_next_extent().
      
         The fault handler needs to call btrfs_page_mkwrite() for some other
         page of our inode, and there we deadlock when trying to lock the
         inode's i_mmap_lock semaphore in read mode, since the fsync task locked
         it in write mode (step 4) and the fsync task can not progress because
         it's waiting to lock a file range that is currently locked by us (the
         fiemap task, step 3).
      
      Fix this by taking the inode's lock (VFS lock) in shared mode when
      entering fiemap. This effectively serializes fiemap with fsync (except the
      most expensive part of fsync, the log sync), preventing this deadlock.
      
      Reported-by: syzbot+cc35f55c41e34c30dcb5@syzkaller.appspotmail.com
      Link: https://lore.kernel.org/linux-btrfs/00000000000032dc7305f2a66f46@google.com/
      CC: stable@vger.kernel.org # 6.1+
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      519b7e13
    • Alex Deucher's avatar
      Revert "drm/amd/display: disable S/G display on DCN 3.1.5" · e7d63647
      Alex Deucher authored
      This reverts commit 3cc67fe1.
      
      Some users have reported flickerng with S/G display.  We've
      tried extensively to reproduce and debug the issue on a wide
      variety of platform configurations (DRAM bandwidth, etc.) and
      a variety of monitors, but so far have not been able to.  We
      disabled S/G display on a number of platforms to address this
      but that leads to failure to pin framebuffers errors and
      blank displays when there is memory pressure or no displays
      at all on systems with limited carveout (e.g., Chromebooks).
      We have a parameter to disable this as a debugging option as a
      way for users to disable this, depending on their use case,
      and for us to help debug this further.  Having this enabled
      seems like the lesser of to evils.
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      e7d63647
    • Alex Deucher's avatar
      Revert "drm/amd/display: disable S/G display on DCN 2.1.0" · 1b7ac798
      Alex Deucher authored
      This reverts commit 2404f9b0.
      
      Some users have reported flickerng with S/G display.  We've
      tried extensively to reproduce and debug the issue on a wide
      variety of platform configurations (DRAM bandwidth, etc.) and
      a variety of monitors, but so far have not been able to.  We
      disabled S/G display on a number of platforms to address this
      but that leads to failure to pin framebuffers errors and
      blank displays when there is memory pressure or no displays
      at all on systems with limited carveout (e.g., Chromebooks).
      We have a parameter to disable this as a debugging option as a
      way for users to disable this, depending on their use case,
      and for us to help debug this further.  Having this enabled
      seems like the lesser of to evils.
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      1b7ac798