1. 25 Jun, 2024 6 commits
    • Jan Kara's avatar
      ocfs2: fix DIO failure due to insufficient transaction credits · be346c1a
      Jan Kara authored
      The code in ocfs2_dio_end_io_write() estimates number of necessary
      transaction credits using ocfs2_calc_extend_credits().  This however does
      not take into account that the IO could be arbitrarily large and can
      contain arbitrary number of extents.
      
      Extent tree manipulations do often extend the current transaction but not
      in all of the cases.  For example if we have only single block extents in
      the tree, ocfs2_mark_extent_written() will end up calling
      ocfs2_replace_extent_rec() all the time and we will never extend the
      current transaction and eventually exhaust all the transaction credits if
      the IO contains many single block extents.  Once that happens a
      WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in
      jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
      this error.  This was actually triggered by one of our customers on a
      heavily fragmented OCFS2 filesystem.
      
      To fix the issue make sure the transaction always has enough credits for
      one extent insert before each call of ocfs2_mark_extent_written().
      
      Heming Zhao said:
      
      ------
      PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
      
      PID: xxx  TASK: xxxx  CPU: 5  COMMAND: "SubmitThread-CA"
        #0 machine_kexec at ffffffff8c069932
        #1 __crash_kexec at ffffffff8c1338fa
        #2 panic at ffffffff8c1d69b9
        #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
        #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
        #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
        #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
        #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
        #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
        #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
      #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
      #11 dio_complete at ffffffff8c2b9fa7
      #12 do_blockdev_direct_IO at ffffffff8c2bc09f
      #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
      #14 generic_file_direct_write at ffffffff8c1dcf14
      #15 __generic_file_write_iter at ffffffff8c1dd07b
      #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
      #17 aio_write at ffffffff8c2cc72e
      #18 kmem_cache_alloc at ffffffff8c248dde
      #19 do_io_submit at ffffffff8c2ccada
      #20 do_syscall_64 at ffffffff8c004984
      #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba
      
      Link: https://lkml.kernel.org/r/20240617095543.6971-1-jack@suse.cz
      Link: https://lkml.kernel.org/r/20240614145243.8837-1-jack@suse.cz
      Fixes: c15471f7 ("ocfs2: fix sparse file & data ordering issue in direct io")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Reviewed-by: default avatarHeming Zhao <heming.zhao@suse.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Changwei Ge <gechangwei@live.cn>
      Cc: Gang He <ghe@suse.com>
      Cc: Jun Piao <piaojun@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      be346c1a
    • Andrey Konovalov's avatar
      kasan: fix bad call to unpoison_slab_object · 1c61990d
      Andrey Konovalov authored
      Commit 29d7355a ("kasan: save alloc stack traces for mempool") messed
      up one of the calls to unpoison_slab_object: the last two arguments are
      supposed to be GFP flags and whether to init the object memory.
      
      Fix the call.
      
      Without this fix, __kasan_mempool_unpoison_object provides the object's
      size as GFP flags to unpoison_slab_object, which can cause LOCKDEP reports
      (and probably other issues).
      
      Link: https://lkml.kernel.org/r/20240614143238.60323-1-andrey.konovalov@linux.dev
      Fixes: 29d7355a ("kasan: save alloc stack traces for mempool")
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@gmail.com>
      Reported-by: default avatarBrad Spengler <spender@grsecurity.net>
      Acked-by: default avatarMarco Elver <elver@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      1c61990d
    • Suren Baghdasaryan's avatar
      mm: handle profiling for fake memory allocations during compaction · 34a023dc
      Suren Baghdasaryan authored
      During compaction isolated free pages are marked allocated so that they
      can be split and/or freed.  For that, post_alloc_hook() is used inside
      split_map_pages() and release_free_list().  split_map_pages() marks free
      pages allocated, splits the pages and then lets
      alloc_contig_range_noprof() free those pages.  release_free_list() marks
      free pages and immediately frees them.  This usage of post_alloc_hook()
      affect memory allocation profiling because these functions might not be
      called from an instrumented allocator, therefore current->alloc_tag is
      NULL and when debugging is enabled (CONFIG_MEM_ALLOC_PROFILING_DEBUG=y)
      that causes warnings.  To avoid that, wrap such post_alloc_hook() calls
      into an instrumented function which acts as an allocator which will be
      charged for these fake allocations.  Note that these allocations are very
      short lived until they are freed, therefore the associated counters should
      usually read 0.
      
      Link: https://lkml.kernel.org/r/20240614230504.3849136-1-surenb@google.comSigned-off-by: default avatarSuren Baghdasaryan <surenb@google.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Kent Overstreet <kent.overstreet@linux.dev>
      Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
      Cc: Sourav Panda <souravpanda@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      34a023dc
    • Suren Baghdasaryan's avatar
      mm/slab: fix 'variable obj_exts set but not used' warning · b4601d09
      Suren Baghdasaryan authored
      slab_post_alloc_hook() uses prepare_slab_obj_exts_hook() to obtain
      slabobj_ext object.  Currently the only user of slabobj_ext object in this
      path is memory allocation profiling, therefore when it's not enabled this
      object is not needed.  This also generates a warning when compiling with
      CONFIG_MEM_ALLOC_PROFILING=n.  Move the code under this configuration to
      fix the warning.  If more slabobj_ext users appear in the future, the code
      will have to be changed back to call prepare_slab_obj_exts_hook().
      
      Link: https://lkml.kernel.org/r/20240614225951.3845577-1-surenb@google.com
      Fixes: 4b873696 ("mm/slab: add allocation accounting into slab allocation and free paths")
      Signed-off-by: default avatarSuren Baghdasaryan <surenb@google.com>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Closes: https://lore.kernel.org/oe-kbuild-all/202406150444.F6neSaiy-lkp@intel.com/
      Cc: Kent Overstreet <kent.overstreet@linux.dev>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      b4601d09
    • Jeff Xu's avatar
      /proc/pid/smaps: add mseal info for vma · 399ab86e
      Jeff Xu authored
      Add sl in /proc/pid/smaps to indicate vma is sealed
      
      Link: https://lkml.kernel.org/r/20240614232014.806352-2-jeffxu@google.com
      Fixes: 8be7258a ("mseal: add mseal syscall")
      Signed-off-by: default avatarJeff Xu <jeffxu@chromium.org>
      Acked-by: default avatarDavid Hildenbrand <david@redhat.com>
      Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>
      Cc: Jann Horn <jannh@google.com>
      Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Stephen Röttger <sroettger@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      399ab86e
    • Zhaoyang Huang's avatar
      mm: fix incorrect vbq reference in purge_fragmented_block · 8c61291f
      Zhaoyang Huang authored
      xa_for_each() in _vm_unmap_aliases() loops through all vbs.  However,
      since commit 062eacf5 ("mm: vmalloc: remove a global vmap_blocks
      xarray") the vb from xarray may not be on the corresponding CPU
      vmap_block_queue.  Consequently, purge_fragmented_block() might use the
      wrong vbq->lock to protect the free list, leading to vbq->free breakage.
      
      Incorrect lock protection can exhaust all vmalloc space as follows:
      CPU0                                            CPU1
      +--------------------------------------------+
      |    +--------------------+     +-----+      |
      +--> |                    |---->|     |------+
           | CPU1:vbq free_list |     | vb1 |
      +--- |                    |<----|     |<-----+
      |    +--------------------+     +-----+      |
      +--------------------------------------------+
      
      _vm_unmap_aliases()                             vb_alloc()
                                                      new_vmap_block()
      xa_for_each(&vbq->vmap_blocks, idx, vb)
      --> vb in CPU1:vbq->freelist
      
      purge_fragmented_block(vb)
      spin_lock(&vbq->lock)                           spin_lock(&vbq->lock)
      --> use CPU0:vbq->lock                          --> use CPU1:vbq->lock
      
      list_del_rcu(&vb->free_list)                    list_add_tail_rcu(&vb->free_list, &vbq->free)
          __list_del(vb->prev, vb->next)
              next->prev = prev
          +--------------------+
          |                    |
          | CPU1:vbq free_list |
      +---|                    |<--+
      |   +--------------------+   |
      +----------------------------+
                                                      __list_add(new, head->prev, head)
      +--------------------------------------------+
      |    +--------------------+     +-----+      |
      +--> |                    |---->|     |------+
           | CPU1:vbq free_list |     | vb2 |
      +--- |                    |<----|     |<-----+
      |    +--------------------+     +-----+      |
      +--------------------------------------------+
      
              prev->next = next
      +--------------------------------------------+
      |----------------------------+               |
      |    +--------------------+  |  +-----+      |
      +--> |                    |--+  |     |------+
           | CPU1:vbq free_list |     | vb2 |
      +--- |                    |<----|     |<-----+
      |    +--------------------+     +-----+      |
      +--------------------------------------------+
      Here’s a list breakdown. All vbs, which were to be added to
      ‘prev’, cannot be used by list_for_each_entry_rcu(vb, &vbq->free,
      free_list) in vb_alloc(). Thus, vmalloc space is exhausted.
      
      This issue affects both erofs and f2fs, the stacktrace is as follows:
      erofs:
      [<ffffffd4ffb93ad4>] __switch_to+0x174
      [<ffffffd4ffb942f0>] __schedule+0x624
      [<ffffffd4ffb946f4>] schedule+0x7c
      [<ffffffd4ffb947cc>] schedule_preempt_disabled+0x24
      [<ffffffd4ffb962ec>] __mutex_lock+0x374
      [<ffffffd4ffb95998>] __mutex_lock_slowpath+0x14
      [<ffffffd4ffb95954>] mutex_lock+0x24
      [<ffffffd4fef2900c>] reclaim_and_purge_vmap_areas+0x44
      [<ffffffd4fef25908>] alloc_vmap_area+0x2e0
      [<ffffffd4fef24ea0>] vm_map_ram+0x1b0
      [<ffffffd4ff1b46f4>] z_erofs_lz4_decompress+0x278
      [<ffffffd4ff1b8ac4>] z_erofs_decompress_queue+0x650
      [<ffffffd4ff1b8328>] z_erofs_runqueue+0x7f4
      [<ffffffd4ff1b66a8>] z_erofs_read_folio+0x104
      [<ffffffd4feeb6fec>] filemap_read_folio+0x6c
      [<ffffffd4feeb68c4>] filemap_fault+0x300
      [<ffffffd4fef0ecac>] __do_fault+0xc8
      [<ffffffd4fef0c908>] handle_mm_fault+0xb38
      [<ffffffd4ffb9f008>] do_page_fault+0x288
      [<ffffffd4ffb9ed64>] do_translation_fault[jt]+0x40
      [<ffffffd4fec39c78>] do_mem_abort+0x58
      [<ffffffd4ffb8c3e4>] el0_ia+0x70
      [<ffffffd4ffb8c260>] el0t_64_sync_handler[jt]+0xb0
      [<ffffffd4fec11588>] ret_to_user[jt]+0x0
      
      f2fs:
      [<ffffffd4ffb93ad4>] __switch_to+0x174
      [<ffffffd4ffb942f0>] __schedule+0x624
      [<ffffffd4ffb946f4>] schedule+0x7c
      [<ffffffd4ffb947cc>] schedule_preempt_disabled+0x24
      [<ffffffd4ffb962ec>] __mutex_lock+0x374
      [<ffffffd4ffb95998>] __mutex_lock_slowpath+0x14
      [<ffffffd4ffb95954>] mutex_lock+0x24
      [<ffffffd4fef2900c>] reclaim_and_purge_vmap_areas+0x44
      [<ffffffd4fef25908>] alloc_vmap_area+0x2e0
      [<ffffffd4fef24ea0>] vm_map_ram+0x1b0
      [<ffffffd4ff1a3b60>] f2fs_prepare_decomp_mem+0x144
      [<ffffffd4ff1a6c24>] f2fs_alloc_dic+0x264
      [<ffffffd4ff175468>] f2fs_read_multi_pages+0x428
      [<ffffffd4ff17b46c>] f2fs_mpage_readpages+0x314
      [<ffffffd4ff1785c4>] f2fs_readahead+0x50
      [<ffffffd4feec3384>] read_pages+0x80
      [<ffffffd4feec32c0>] page_cache_ra_unbounded+0x1a0
      [<ffffffd4feec39e8>] page_cache_ra_order+0x274
      [<ffffffd4feeb6cec>] do_sync_mmap_readahead+0x11c
      [<ffffffd4feeb6764>] filemap_fault+0x1a0
      [<ffffffd4ff1423bc>] f2fs_filemap_fault+0x28
      [<ffffffd4fef0ecac>] __do_fault+0xc8
      [<ffffffd4fef0c908>] handle_mm_fault+0xb38
      [<ffffffd4ffb9f008>] do_page_fault+0x288
      [<ffffffd4ffb9ed64>] do_translation_fault[jt]+0x40
      [<ffffffd4fec39c78>] do_mem_abort+0x58
      [<ffffffd4ffb8c3e4>] el0_ia+0x70
      [<ffffffd4ffb8c260>] el0t_64_sync_handler[jt]+0xb0
      [<ffffffd4fec11588>] ret_to_user[jt]+0x0
      
      To fix this, introducee cpu within vmap_block to record which this vb
      belongs to.
      
      Link: https://lkml.kernel.org/r/20240614021352.1822225-1-zhaoyang.huang@unisoc.com
      Link: https://lkml.kernel.org/r/20240607023116.1720640-1-zhaoyang.huang@unisoc.com
      Fixes: fc1e0d98 ("mm/vmalloc: prevent stale TLBs in fully utilized blocks")
      Signed-off-by: default avatarZhaoyang Huang <zhaoyang.huang@unisoc.com>
      Suggested-by: default avatarHailong.Liu <hailong.liu@oppo.com>
      Reviewed-by: default avatarUladzislau Rezki (Sony) <urezki@gmail.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Lorenzo Stoakes <lstoakes@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      8c61291f
  2. 23 Jun, 2024 8 commits
  3. 22 Jun, 2024 19 commits
  4. 21 Jun, 2024 7 commits
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 35bb670d
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Two fixes: one in the ufs driver fixing an obvious memory leak and the
        other (with a core flag based update) trying to prevent USB crashes by
        stopping the core from issuing a request for the I/O Hints mode page"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: usb: uas: Do not query the IO Advice Hints Grouping mode page for USB/UAS devices
        scsi: core: Introduce the BLIST_SKIP_IO_HINTS flag
        scsi: ufs: core: Free memory allocated for model before reinit
      35bb670d
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2024-06-22' of https://gitlab.freedesktop.org/drm/kernel · d6c94157
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Still pretty quiet, two weeks worth of amdgpu fixes, with one i915 and
        one xe. I didn't get the drm-misc-fixes tree PR this week, but there
        was only one fix queued and I think it can wait another week, so seems
        pretty normal.
      
        xe:
         - Fix for invalid register access
      
        i915:
         - Fix conditions for joiner usage, it's not possible with eDP MSO
      
        amdgpu:
         - Fix display idle optimization race
         - Fix GPUVM TLB flush locking scope
         - IPS fix
         - GFX 9.4.3 harvesting fix
         - Runtime pm fix for shared buffers
         - DCN 3.5.x fixes
         - USB4 fix
         - RISC-V clang fix
         - Silence UBSAN warnings
         - MES11 fix
         - PSP 14.0.x fix"
      
      * tag 'drm-fixes-2024-06-22' of https://gitlab.freedesktop.org/drm/kernel:
        drm/xe/vf: Don't touch GuC irq registers if using memory irqs
        drm/amdgpu: init TA fw for psp v14
        drm/amdgpu: cleanup MES11 command submission
        drm/amdgpu: fix UBSAN warning in kv_dpm.c
        drm/radeon: fix UBSAN warning in kv_dpm.c
        drm/amd/display: Disable CONFIG_DRM_AMD_DC_FP for RISC-V with clang
        drm/amd/display: Attempt to avoid empty TUs when endpoint is DPIA
        drm/amd/display: change dram_clock_latency to 34us for dcn35
        drm/amd/display: Change dram_clock_latency to 34us for dcn351
        drm/amdgpu: revert "take runtime pm reference when we attach a buffer" v2
        drm/amdgpu: Indicate CU havest info to CP
        drm/amd/display: prevent register access while in IPS
        drm/amdgpu: fix locking scope when flushing tlb
        drm/amd/display: Remove redundant idle optimization check
        drm/i915/mso: using joiner is not possible with eDP MSO
      d6c94157
    • Linus Torvalds's avatar
      Merge tag 'ovl-fixes-6.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs · 264efe48
      Linus Torvalds authored
      Pull overlayfs fixes from Miklos Szeredi:
       "Fix two bugs, one originating in this cycle and one from 6.6"
      
      * tag 'ovl-fixes-6.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs:
        ovl: fix encoding fid for lower only root
        ovl: fix copy-up in tmpfile
      264efe48
    • Linus Torvalds's avatar
      Merge tag 'io_uring-6.10-20240621' of git://git.kernel.dk/linux · a502e727
      Linus Torvalds authored
      Pull io_uring fix from Jens Axboe:
       "Just a single cleanup for the fixed buffer iov_iter import.
      
        More cosmetic than anything else, but let's get it cleaned up as it's
        confusing"
      
      * tag 'io_uring-6.10-20240621' of git://git.kernel.dk/linux:
        io_uring/rsrc: fix incorrect assignment of iter->nr_segs in io_import_fixed
      a502e727
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma · ffdf504c
      Linus Torvalds authored
      Pull rdma fixes from Jason Gunthorpe:
       "Small bug fixes:
      
         - Prevent a crash in bnxt if the en and rdma drivers disagree on the
           MSI vectors
      
         - Have rxe memcpy inline data from the correct address
      
         - Fix rxe's validation of UD packets
      
         - Several mlx5 mr cache issues: bad lock balancing on error, missing
           propagation of the ATS property to the HW, wrong bucketing of freed
           mrs in some cases
      
         - Incorrect goto error unwind in mlx5 driver probe
      
         - Missed userspace input validation in mlx5 SRQ create
      
         - Incorrect uABI in MANA rejecting valid optional MR creation flags"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
        RDMA/mana_ib: Ignore optional access flags for MRs
        RDMA/mlx5: Add check for srq max_sge attribute
        RDMA/mlx5: Fix unwind flow as part of mlx5_ib_stage_init_init
        RDMA/mlx5: Ensure created mkeys always have a populated rb_key
        RDMA/mlx5: Follow rb_key.ats when creating new mkeys
        RDMA/mlx5: Remove extra unlock on error path
        RDMA/rxe: Fix responder length checking for UD request packets
        RDMA/rxe: Fix data copy for IB_SEND_INLINE
        RDMA/bnxt_re: Fix the max msix vectors macro
      ffdf504c
    • Linus Torvalds's avatar
      Merge tag 'sound-6.10-rc5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 4545981f
      Linus Torvalds authored
      Pull  more sound fixes from Takashi Iwai:
       "A follow-up fix for a random build issue, as well as another trivial
        HD-audio quirk"
      
      * tag 'sound-6.10-rc5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: hda: Use imply for suggesting CONFIG_SERIAL_MULTI_INSTANTIATE
        ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14AHP9
      4545981f
    • Linus Torvalds's avatar
      Merge tag 'acpi-6.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 36c07583
      Linus Torvalds authored
      Pull ACPI fixes from Rafael Wysocki:
       "These address a possible NULL pointer dereference in the ACPICA code
        and quirk camera enumeration on multiple platforms where incorrect
        data are present in the platform firmware.
      
        Specifics:
      
         - Undo an ACPICA code change that attempted to keep operation regions
           within a page boundary, but allowed accesses to unmapped memory to
           occur (Raju Rangoju)
      
         - Ignore MIPI camera graph port nodes created with the help of the
           information from the ACPI tables on all Dell Tiger, Alder and
           Raptor Lake models as that information is reported to be invalid on
           the platforms in question (Hans de Goede)
      
         - Use new Intel CPU model matching macros in the MIPI DisCo for
           Imaging part of ACPI device enumeration (Hans de Goede)"
      
      * tag 'acpi-6.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        ACPI: mipi-disco-img: Switch to new Intel CPU model defines
        ACPI: scan: Ignore camera graph port nodes on all Dell Tiger, Alder and Raptor Lake models
        ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
      36c07583