1. 20 Dec, 2023 1 commit
  2. 19 Dec, 2023 4 commits
    • Linus Torvalds's avatar
      Merge tag 'trace-v6.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace · 55cb5f43
      Linus Torvalds authored
      Pull tracing fix from Steven Rostedt:
       "While working on the ring buffer, I found one more bug with the
        timestamp code, and the fix for this removed the need for the final
        64-bit cmpxchg!
      
        The ring buffer events hold a "delta" from the previous event. If it
        is determined that the delta can not be calculated, it falls back to
        adding an absolute timestamp value. The way to know if the delta can
        be used is via two stored timestamps in the per-cpu buffer meta data:
      
         before_stamp and write_stamp
      
        The before_stamp is written by every event before it tries to allocate
        its space on the ring buffer. The write_stamp is written after it
        allocates its space and knows that nothing came in after it read the
        previous before_stamp and write_stamp and the two matched.
      
        A previous fix dd939425 ("ring-buffer: Do not try to put back
        write_stamp") removed putting back the write_stamp to match the
        before_stamp so that the next event could use the delta, but races
        were found where the two would match, but not be for of the previous
        event.
      
        It was determined to allow the event reservation to not have a valid
        write_stamp when it is finished, and this fixed a lot of races.
      
        The last use of the 64-bit timestamp cmpxchg depended on the
        write_stamp being valid after an interruption. But this is no longer
        the case, as if an event is interrupted by a softirq that writes an
        event, and that event gets interrupted by a hardirq or NMI and that
        writes an event, then the softirq could finish its reservation without
        a valid write_stamp.
      
        In the slow path of the event reservation, a delta can still be used
        if the write_stamp is valid. Instead of using a cmpxchg against the
        write stamp, the before_stamp needs to be read again to validate the
        write_stamp. The cmpxchg is not needed.
      
        This updates the slowpath to validate the write_stamp by comparing it
        to the before_stamp and removes all rb_time_cmpxchg() as there are no
        more users of that function.
      
        The removal of the 32-bit updates of rb_time_t will be done in the
        next merge window"
      
      * tag 'trace-v6.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
        ring-buffer: Fix slowpath of interrupted event
      55cb5f43
    • Linus Torvalds's avatar
      Merge tag 'arc-6.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc · 9c749e61
      Linus Torvalds authored
      Pull ARC fixes from Vineet Gupta:
      
       - build error for hugetlb, sparse and smatch fixes
      
       - removal of VIPT aliasing cache code
      
      * tag 'arc-6.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
        ARC: add hugetlb definitions
        ARC: fix smatch warning
        ARC: fix spare error
        ARC: mm: retire support for aliasing VIPT D$
        ARC: entry: move ARCompact specific bits out of entry.h
        ARC: entry: SAVE_ABI_CALLEE_REG: ISA/ABI specific helper
      9c749e61
    • Steven Rostedt (Google)'s avatar
      ring-buffer: Fix slowpath of interrupted event · b803d7c6
      Steven Rostedt (Google) authored
      To synchronize the timestamps with the ring buffer reservation, there are
      two timestamps that are saved in the buffer meta data.
      
      1. before_stamp
      2. write_stamp
      
      When the two are equal, the write_stamp is considered valid, as in, it may
      be used to calculate the delta of the next event as the write_stamp is the
      timestamp of the previous reserved event on the buffer.
      
      This is done by the following:
      
       /*A*/	w = current position on the ring buffer
      	before = before_stamp
      	after = write_stamp
      	ts = read current timestamp
      
      	if (before != after) {
      		write_stamp is not valid, force adding an absolute
      		timestamp.
      	}
      
       /*B*/	before_stamp = ts
      
       /*C*/	write = local_add_return(event length, position on ring buffer)
      
      	if (w == write - event length) {
      		/* Nothing interrupted between A and C */
       /*E*/		write_stamp = ts;
      		delta = ts - after
      		/*
      		 * If nothing interrupted again,
      		 * before_stamp == write_stamp and write_stamp
      		 * can be used to calculate the delta for
      		 * events that come in after this one.
      		 */
      	} else {
      
      		/*
      		 * The slow path!
      		 * Was interrupted between A and C.
      		 */
      
      This is the place that there's a bug. We currently have:
      
      		after = write_stamp
      		ts = read current timestamp
      
       /*F*/		if (write == current position on the ring buffer &&
      		    after < ts && cmpxchg(write_stamp, after, ts)) {
      
      			delta = ts - after;
      
      		} else {
      			delta = 0;
      		}
      
      The assumption is that if the current position on the ring buffer hasn't
      moved between C and F, then it also was not interrupted, and that the last
      event written has a timestamp that matches the write_stamp. That is the
      write_stamp is valid.
      
      But this may not be the case:
      
      If a task context event was interrupted by softirq between B and C.
      
      And the softirq wrote an event that got interrupted by a hard irq between
      C and E.
      
      and the hard irq wrote an event (does not need to be interrupted)
      
      We have:
      
       /*B*/ before_stamp = ts of normal context
      
         ---> interrupted by softirq
      
      	/*B*/ before_stamp = ts of softirq context
      
      	  ---> interrupted by hardirq
      
      		/*B*/ before_stamp = ts of hard irq context
      		/*E*/ write_stamp = ts of hard irq context
      
      		/* matches and write_stamp valid */
      	  <----
      
      	/*E*/ write_stamp = ts of softirq context
      
      	/* No longer matches before_stamp, write_stamp is not valid! */
      
         <---
      
       w != write - length, go to slow path
      
      // Right now the order of events in the ring buffer is:
      //
      // |-- softirq event --|-- hard irq event --|-- normal context event --|
      //
      
       after = write_stamp (this is the ts of softirq)
       ts = read current timestamp
      
       if (write == current position on the ring buffer [true] &&
           after < ts [true] && cmpxchg(write_stamp, after, ts) [true]) {
      
      	delta = ts - after  [Wrong!]
      
      The delta is to be between the hard irq event and the normal context
      event, but the above logic made the delta between the softirq event and
      the normal context event, where the hard irq event is between the two. This
      will shift all the remaining event timestamps on the sub-buffer
      incorrectly.
      
      The write_stamp is only valid if it matches the before_stamp. The cmpxchg
      does nothing to help this.
      
      Instead, the following logic can be done to fix this:
      
      	before = before_stamp
      	ts = read current timestamp
      	before_stamp = ts
      
      	after = write_stamp
      
      	if (write == current position on the ring buffer &&
      	    after == before && after < ts) {
      
      		delta = ts - after
      
      	} else {
      		delta = 0;
      	}
      
      The above will only use the write_stamp if it still matches before_stamp
      and was tested to not have changed since C.
      
      As a bonus, with this logic we do not need any 64-bit cmpxchg() at all!
      
      This means the 32-bit rb_time_t workaround can finally be removed. But
      that's for a later time.
      
      Link: https://lore.kernel.org/linux-trace-kernel/20231218175229.58ec3daf@gandalf.local.home/
      Link: https://lore.kernel.org/linux-trace-kernel/20231218230712.3a76b081@gandalf.local.home
      
      Cc: stable@vger.kernel.org
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Fixes: dd939425 ("ring-buffer: Do not try to put back write_stamp")
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      b803d7c6
    • Linus Torvalds's avatar
      Merge tag 'hid-for-linus-2023121901' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid · 3f10e214
      Linus Torvalds authored
      Pull HID fixes from Jiri Kosina:
      
       - fix for division by zero in Nintendo driver when generic joycon is
         attached, reported and fixed by SteamOS folks (Guilherme G. Piccoli)
      
       - GCC-7 build fix (which is a good cleanup anyway) for Nintendo driver
         (Ryan McClelland)
      
      * tag 'hid-for-linus-2023121901' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
        HID: nintendo: Prevent divide-by-zero on code
        HID: nintendo: fix initializer element is not constant error
      3f10e214
  3. 18 Dec, 2023 8 commits
  4. 17 Dec, 2023 10 commits
  5. 16 Dec, 2023 3 commits
    • Linus Torvalds's avatar
      Merge tag 'trace-v6.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace · 3b8a9b2e
      Linus Torvalds authored
      Pull tracing fixes from Steven Rostedt:
      
       - Fix eventfs to check creating new files for events with names greater
         than NAME_MAX. The eventfs lookup needs to check the return result of
         simple_lookup().
      
       - Fix the ring buffer to check the proper max data size. Events must be
         able to fit on the ring buffer sub-buffer, if it cannot, then it
         fails to be written and the logic to add the event is avoided. The
         code to check if an event can fit failed to add the possible absolute
         timestamp which may make the event not be able to fit. This causes
         the ring buffer to go into an infinite loop trying to find a
         sub-buffer that would fit the event. Luckily, there's a check that
         will bail out if it looped over a 1000 times and it also warns.
      
         The real fix is not to add the absolute timestamp to an event that is
         starting at the beginning of a sub-buffer because it uses the
         sub-buffer timestamp.
      
         By avoiding the timestamp at the start of the sub-buffer allows
         events that pass the first check to always find a sub-buffer that it
         can fit on.
      
       - Have large events that do not fit on a trace_seq to print "LINE TOO
         BIG" like it does for the trace_pipe instead of what it does now
         which is to silently drop the output.
      
       - Fix a memory leak of forgetting to free the spare page that is saved
         by a trace instance.
      
       - Update the size of the snapshot buffer when the main buffer is
         updated if the snapshot buffer is allocated.
      
       - Fix ring buffer timestamp logic by removing all the places that tried
         to put the before_stamp back to the write stamp so that the next
         event doesn't add an absolute timestamp. But each of these updates
         added a race where by making the two timestamp equal, it was
         validating the write_stamp so that it can be incorrectly used for
         calculating the delta of an event.
      
       - There's a temp buffer used for printing the event that was using the
         event data size for allocation when it needed to use the size of the
         entire event (meta-data and payload data)
      
       - For hardening, use "%.*s" for printing the trace_marker output, to
         limit the amount that is printed by the size of the event. This was
         discovered by development that added a bug that truncated the '\0'
         and caused a crash.
      
       - Fix a use-after-free bug in the use of the histogram files when an
         instance is being removed.
      
       - Remove a useless update in the rb_try_to_discard of the write_stamp.
         The before_stamp was already changed to force the next event to add
         an absolute timestamp that the write_stamp is not used. But the
         write_stamp is modified again using an unneeded 64-bit cmpxchg.
      
       - Fix several races in the 32-bit implementation of the
         rb_time_cmpxchg() that does a 64-bit cmpxchg.
      
       - While looking at fixing the 64-bit cmpxchg, I noticed that because
         the ring buffer uses normal cmpxchg, and this can be done in NMI
         context, there's some architectures that do not have a working
         cmpxchg in NMI context. For these architectures, fail recording
         events that happen in NMI context.
      
      * tag 'trace-v6.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
        ring-buffer: Do not record in NMI if the arch does not support cmpxchg in NMI
        ring-buffer: Have rb_time_cmpxchg() set the msb counter too
        ring-buffer: Fix 32-bit rb_time_read() race with rb_time_cmpxchg()
        ring-buffer: Fix a race in rb_time_cmpxchg() for 32 bit archs
        ring-buffer: Remove useless update to write_stamp in rb_try_to_discard()
        ring-buffer: Do not try to put back write_stamp
        tracing: Fix uaf issue when open the hist or hist_debug file
        tracing: Add size check when printing trace_marker output
        ring-buffer: Have saved event hold the entire event
        ring-buffer: Do not update before stamp when switching sub-buffers
        tracing: Update snapshot buffer on resize if it is allocated
        ring-buffer: Fix memory leak of free page
        eventfs: Fix events beyond NAME_MAX blocking tasks
        tracing: Have large events show up as '[LINE TOO BIG]' instead of nothing
        ring-buffer: Fix writing to the buffer with max_data_size
      3b8a9b2e
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · c8e97fc6
      Linus Torvalds authored
      Pull arm64 fixes from Catalin Marinas:
      
       - Arm CMN perf: fix the DTC allocation failure path which can end up
         erroneously clearing live counters
      
       - arm64/mm: fix hugetlb handling of the dirty page state leading to a
         continuous fault loop in user on hardware without dirty bit
         management (DBM). That's caused by the dirty+writeable information
         not being properly preserved across a series of mprotect(PROT_NONE),
         mprotect(PROT_READ|PROT_WRITE)
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        arm64: mm: Always make sw-dirty PTEs hw-dirty in pte_modify
        perf/arm-cmn: Fail DTC counter allocation correctly
      c8e97fc6
    • Linus Torvalds's avatar
      Merge tag 'pci-v6.7-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci · 2e3f280b
      Linus Torvalds authored
      Pull pci fixes from Bjorn Helgaas:
      
       - Limit Max_Read_Request_Size (MRRS) on some MIPS Loongson systems
         because they don't all support MRRS > 256, and firmware doesn't
         always initialize it correctly, which meant some PCIe devices didn't
         work (Jiaxun Yang)
      
       - Add and use pci_enable_link_state_locked() to prevent potential
         deadlocks in vmd and qcom drivers (Johan Hovold)
      
       - Revert recent (v6.5) acpiphp resource assignment changes that fixed
         issues with hot-adding devices on a root bus or with large BARs, but
         introduced new issues with GPU initialization and hot-adding SCSI
         disks in QEMU VMs and (Bjorn Helgaas)
      
      * tag 'pci-v6.7-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci:
        Revert "PCI: acpiphp: Reassign resources on bridge if necessary"
        PCI/ASPM: Add pci_disable_link_state_locked() lockdep assert
        PCI/ASPM: Clean up __pci_disable_link_state() 'sem' parameter
        PCI: qcom: Clean up ASPM comment
        PCI: qcom: Fix potential deadlock when enabling ASPM
        PCI: vmd: Fix potential deadlock when enabling ASPM
        PCI/ASPM: Add pci_enable_link_state_locked()
        PCI: loongson: Limit MRRS to 256
      2e3f280b
  6. 15 Dec, 2023 14 commits
    • Josef Bacik's avatar
      btrfs: do not allow non subvolume root targets for snapshot · a8892fd7
      Josef Bacik authored
      Our btrfs subvolume snapshot <source> <destination> utility enforces
      that <source> is the root of the subvolume, however this isn't enforced
      in the kernel.  Update the kernel to also enforce this limitation to
      avoid problems with other users of this ioctl that don't have the
      appropriate checks in place.
      Reported-by: default avatarMartin Michaelis <code@mgjm.de>
      CC: stable@vger.kernel.org # 4.14+
      Reviewed-by: default avatarNeal Gompa <neal@gompa.dev>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      a8892fd7
    • Jens Axboe's avatar
      cred: get rid of CONFIG_DEBUG_CREDENTIALS · ae191417
      Jens Axboe authored
      This code is rarely (never?) enabled by distros, and it hasn't caught
      anything in decades. Let's kill off this legacy debug code.
      Suggested-by: default avatarLinus Torvalds <torvalds@linuxfoundation.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ae191417
    • Jens Axboe's avatar
      cred: switch to using atomic_long_t · f8fa5d76
      Jens Axboe authored
      There are multiple ways to grab references to credentials, and the only
      protection we have against overflowing it is the memory required to do
      so.
      
      With memory sizes only moving in one direction, let's bump the reference
      count to 64-bit and move it outside the realm of feasibly overflowing.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f8fa5d76
    • Bjorn Helgaas's avatar
      Revert "PCI: acpiphp: Reassign resources on bridge if necessary" · 5df12742
      Bjorn Helgaas authored
      This reverts commit 40613da5 and the
      subsequent fix to it:
      
        cc22522f ("PCI: acpiphp: Use pci_assign_unassigned_bridge_resources() only for non-root bus")
      
      40613da5 fixed a problem where hot-adding a device with large BARs
      failed if the bridge windows programmed by firmware were not large enough.
      
      cc22522f ("PCI: acpiphp: Use pci_assign_unassigned_bridge_resources()
      only for non-root bus") fixed a problem with 40613da5: an ACPI hot-add
      of a device on a PCI root bus (common in the virt world) or firmware
      sending ACPI Bus Check to non-existent Root Ports (e.g., on Dell Inspiron
      7352/0W6WV0) caused a NULL pointer dereference and suspend/resume hangs.
      
      Unfortunately the combination of 40613da5 and cc22522f caused other
      problems:
      
        - Fiona reported that hot-add of SCSI disks in QEMU virtual machine fails
          sometimes.
      
        - Dongli reported a similar problem with hot-add of SCSI disks.
      
        - Jonathan reported a console freeze during boot on bare metal due to an
          error in radeon GPU initialization.
      
      Revert both patches to avoid adding these problems.  This means we will
      again see the problems with hot-adding devices with large BARs and the NULL
      pointer dereferences and suspend/resume issues that 40613da5 and
      cc22522f were intended to fix.
      
      Fixes: 40613da5 ("PCI: acpiphp: Reassign resources on bridge if necessary")
      Fixes: cc22522f ("PCI: acpiphp: Use pci_assign_unassigned_bridge_resources() only for non-root bus")
      Reported-by: default avatarFiona Ebner <f.ebner@proxmox.com>
      Closes: https://lore.kernel.org/r/9eb669c0-d8f2-431d-a700-6da13053ae54@proxmox.comReported-by: default avatarDongli Zhang <dongli.zhang@oracle.com>
      Closes: https://lore.kernel.org/r/3c4a446a-b167-11b8-f36f-d3c1b49b42e9@oracle.comReported-by: default avatarJonathan Woithe <jwoithe@just42.net>
      Closes: https://lore.kernel.org/r/ZXpaNCLiDM+Kv38H@marvin.atrad.com.auSigned-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Cc: <stable@vger.kernel.org>
      5df12742
    • Linus Torvalds's avatar
      Merge tag 'io_uring-6.7-2023-12-15' of git://git.kernel.dk/linux · 3bd7d748
      Linus Torvalds authored
      Pull io_uring fixes from Jens Axboe:
       "Just two minor fixes:
      
         - Fix for the io_uring socket option commands using the wrong value
           on some archs (Al)
      
         - Tweak to the poll lazy wake enable (me)"
      
      * tag 'io_uring-6.7-2023-12-15' of git://git.kernel.dk/linux:
        io_uring/cmd: fix breakage in SOCKET_URING_OP_SIOC* implementation
        io_uring/poll: don't enable lazy wake for POLLEXCLUSIVE
      3bd7d748
    • Linus Torvalds's avatar
      Merge tag 'mm-hotfixes-stable-2023-12-15-07-11' of... · a62aa88b
      Linus Torvalds authored
      Merge tag 'mm-hotfixes-stable-2023-12-15-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
      
      Pull misc fixes from Andrew Morton:
       "17 hotfixes. 8 are cc:stable and the other 9 pertain to post-6.6
        issues"
      
      * tag 'mm-hotfixes-stable-2023-12-15-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
        mm/mglru: reclaim offlined memcgs harder
        mm/mglru: respect min_ttl_ms with memcgs
        mm/mglru: try to stop at high watermarks
        mm/mglru: fix underprotected page cache
        mm/shmem: fix race in shmem_undo_range w/THP
        Revert "selftests: error out if kernel header files are not yet built"
        crash_core: fix the check for whether crashkernel is from high memory
        x86, kexec: fix the wrong ifdeffery CONFIG_KEXEC
        sh, kexec: fix the incorrect ifdeffery and dependency of CONFIG_KEXEC
        mips, kexec: fix the incorrect ifdeffery and dependency of CONFIG_KEXEC
        m68k, kexec: fix the incorrect ifdeffery and build dependency of CONFIG_KEXEC
        loongarch, kexec: change dependency of object files
        mm/damon/core: make damon_start() waits until kdamond_fn() starts
        selftests/mm: cow: print ksft header before printing anything else
        mm: fix VMA heap bounds checking
        riscv: fix VMALLOC_START definition
        kexec: drop dependency on ARCH_SUPPORTS_KEXEC from CRASH_DUMP
      a62aa88b
    • Linus Torvalds's avatar
      Merge tag 'sound-6.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 26e7a301
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "A collection of HD-audio quirks for TAS2781 codec and device-specific
        workarounds"
      
      * tag 'sound-6.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: hda/tas2781: reset the amp before component_add
        ALSA: hda/tas2781: call cleanup functions only once
        ALSA: hda/tas2781: handle missing EFI calibration data
        ALSA: hda/tas2781: leave hda_component in usable state
        ALSA: hda/realtek: Apply mute LED quirk for HP15-db
        ALSA: hda/hdmi: add force-connect quirks for ASUSTeK Z170 variants
        ALSA: hda/hdmi: add force-connect quirk for NUC5CPYB
      26e7a301
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2023-12-15' of git://anongit.freedesktop.org/drm/drm · 595609b2
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "More regular fixes, amdgpu, i915, mediatek and nouveau are most of
        them this week. Nothing too major, then a few misc bits and pieces in
        core, panel and ivpu.
      
        drm:
         - fix uninit problems in crtc
         - fix fd ownership check
         - edid: add modes in fallback paths
      
        panel:
         - move LG panel into DSI yaml
         - ltk050h3146w: set burst mode
      
        mediatek:
         - mtk_disp_gamma: Fix breakage due to merge issue
         - fix kernel oops if no crtc is found
         - Add spinlock for setting vblank event in atomic_begin
         - Fix access violation in mtk_drm_crtc_dma_dev_get
      
        i915:
         - Fix selftest engine reset count storage for multi-tile
         - Fix out-of-bounds reads for engine reset counts
         - Fix ADL+ remapped stride with CCS
         - Fix intel_atomic_setup_scalers() plane_state handling
         - Fix ADL+ tiled plane stride when the POT stride is smaller than the original
         - Fix eDP 1.4 rate select method link configuration
      
        amdgpu:
         - Fix suspend fix that got accidently mangled last week
         - Fix OD regression
         - PSR fixes
         - OLED Backlight regression fix
         - JPEG 4.0.5 fix
         - Misc display fixes
         - SDMA 5.2 fix
         - SDMA 2.4 regression fix
         - GPUVM race fix
      
        nouveau:
         - fix gk20a instobj hierarchy
         - fix headless iors inheritance regression
      
        ivpu:
         - fix WA initialisation"
      
      * tag 'drm-fixes-2023-12-15' of git://anongit.freedesktop.org/drm/drm: (31 commits)
        drm/nouveau/kms/nv50-: Don't allow inheritance of headless iors
        drm/nouveau: Fixup gk20a instobj hierarchy
        drm/amdgpu: warn when there are still mappings when a BO is destroyed v2
        drm/amdgpu: fix tear down order in amdgpu_vm_pt_free
        drm/amd: Fix a probing order problem on SDMA 2.4
        drm/amdgpu/sdma5.2: add begin/end_use ring callbacks
        drm/panel: ltk050h3146w: Set burst mode for ltk050h3148w
        dt-bindings: panel-simple-dsi: move LG 5" HD TFT LCD panel into DSI yaml
        drm/amd/display: Disable PSR-SU on Parade 0803 TCON again
        drm/amd/display: Populate dtbclk from bounding box
        drm/amd/display: Revert "Fix conversions between bytes and KB"
        drm/amdgpu/jpeg: configure doorbell for each playback
        drm/amd/display: Restore guard against default backlight value < 1 nit
        drm/amd/display: fix hw rotated modes when PSR-SU is enabled
        drm/amd/pm: fix pp_*clk_od typo
        drm/amdgpu: fix buffer funcs setting order on suspend harder
        drm/mediatek: Fix access violation in mtk_drm_crtc_dma_dev_get
        drm/edid: also call add modes in EDID connector update fallback
        drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select
        drm/i915: Fix ADL+ tiled plane stride when the POT stride is smaller than the original
        ...
      595609b2
    • Steven Rostedt (Google)'s avatar
      ring-buffer: Do not record in NMI if the arch does not support cmpxchg in NMI · 71229230
      Steven Rostedt (Google) authored
      As the ring buffer recording requires cmpxchg() to work, if the
      architecture does not support cmpxchg in NMI, then do not do any recording
      within an NMI.
      
      Link: https://lore.kernel.org/linux-trace-kernel/20231213175403.6fc18540@gandalf.local.home
      
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      71229230
    • Steven Rostedt (Google)'s avatar
      ring-buffer: Have rb_time_cmpxchg() set the msb counter too · 0aa0e528
      Steven Rostedt (Google) authored
      The rb_time_cmpxchg() on 32-bit architectures requires setting three
      32-bit words to represent the 64-bit timestamp, with some salt for
      synchronization. Those are: msb, top, and bottom
      
      The issue is, the rb_time_cmpxchg() did not properly salt the msb portion,
      and the msb that was written was stale.
      
      Link: https://lore.kernel.org/linux-trace-kernel/20231215084114.20899342@rorschach.local.home
      
      Cc: stable@vger.kernel.org
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Fixes: f03f2abc ("ring-buffer: Have 32 bit time stamps use all 64 bits")
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      0aa0e528
    • Mathieu Desnoyers's avatar
      ring-buffer: Fix 32-bit rb_time_read() race with rb_time_cmpxchg() · dec89008
      Mathieu Desnoyers authored
      The following race can cause rb_time_read() to observe a corrupted time
      stamp:
      
      rb_time_cmpxchg()
      [...]
              if (!rb_time_read_cmpxchg(&t->msb, msb, msb2))
                      return false;
              if (!rb_time_read_cmpxchg(&t->top, top, top2))
                      return false;
      <interrupted before updating bottom>
      __rb_time_read()
      [...]
              do {
                      c = local_read(&t->cnt);
                      top = local_read(&t->top);
                      bottom = local_read(&t->bottom);
                      msb = local_read(&t->msb);
              } while (c != local_read(&t->cnt));
      
              *cnt = rb_time_cnt(top);
      
              /* If top and msb counts don't match, this interrupted a write */
              if (*cnt != rb_time_cnt(msb))
                      return false;
                ^ this check fails to catch that "bottom" is still not updated.
      
      So the old "bottom" value is returned, which is wrong.
      
      Fix this by checking that all three of msb, top, and bottom 2-bit cnt
      values match.
      
      The reason to favor checking all three fields over requiring a specific
      update order for both rb_time_set() and rb_time_cmpxchg() is because
      checking all three fields is more robust to handle partial failures of
      rb_time_cmpxchg() when interrupted by nested rb_time_set().
      
      Link: https://lore.kernel.org/lkml/20231211201324.652870-1-mathieu.desnoyers@efficios.com/
      Link: https://lore.kernel.org/linux-trace-kernel/20231212193049.680122-1-mathieu.desnoyers@efficios.com
      
      Fixes: f458a145 ("ring-buffer: Test last update in 32bit version of __rb_time_read()")
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      dec89008
    • Steven Rostedt (Google)'s avatar
      ring-buffer: Fix a race in rb_time_cmpxchg() for 32 bit archs · fff88fa0
      Steven Rostedt (Google) authored
      Mathieu Desnoyers pointed out an issue in the rb_time_cmpxchg() for 32 bit
      architectures. That is:
      
       static bool rb_time_cmpxchg(rb_time_t *t, u64 expect, u64 set)
       {
      	unsigned long cnt, top, bottom, msb;
      	unsigned long cnt2, top2, bottom2, msb2;
      	u64 val;
      
      	/* The cmpxchg always fails if it interrupted an update */
      	 if (!__rb_time_read(t, &val, &cnt2))
      		 return false;
      
      	 if (val != expect)
      		 return false;
      
      <<<< interrupted here!
      
      	 cnt = local_read(&t->cnt);
      
      The problem is that the synchronization counter in the rb_time_t is read
      *after* the value of the timestamp is read. That means if an interrupt
      were to come in between the value being read and the counter being read,
      it can change the value and the counter and the interrupted process would
      be clueless about it!
      
      The counter needs to be read first and then the value. That way it is easy
      to tell if the value is stale or not. If the counter hasn't been updated,
      then the value is still good.
      
      Link: https://lore.kernel.org/linux-trace-kernel/20231211201324.652870-1-mathieu.desnoyers@efficios.com/
      Link: https://lore.kernel.org/linux-trace-kernel/20231212115301.7a9c9a64@gandalf.local.home
      
      Cc: stable@vger.kernel.org
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Fixes: 10464b4a ("ring-buffer: Add rb_time_t 64 bit operations for speeding up 32 bit")
      Reported-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Reviewed-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      fff88fa0
    • Steven Rostedt (Google)'s avatar
      ring-buffer: Remove useless update to write_stamp in rb_try_to_discard() · 083e9f65
      Steven Rostedt (Google) authored
      When filtering is enabled, a temporary buffer is created to place the
      content of the trace event output so that the filter logic can decide
      from the trace event output if the trace event should be filtered out or
      not. If it is to be filtered out, the content in the temporary buffer is
      simply discarded, otherwise it is written into the trace buffer.
      
      But if an interrupt were to come in while a previous event was using that
      temporary buffer, the event written by the interrupt would actually go
      into the ring buffer itself to prevent corrupting the data on the
      temporary buffer. If the event is to be filtered out, the event in the
      ring buffer is discarded, or if it fails to discard because another event
      were to have already come in, it is turned into padding.
      
      The update to the write_stamp in the rb_try_to_discard() happens after a
      fix was made to force the next event after the discard to use an absolute
      timestamp by setting the before_stamp to zero so it does not match the
      write_stamp (which causes an event to use the absolute timestamp).
      
      But there's an effort in rb_try_to_discard() to put back the write_stamp
      to what it was before the event was added. But this is useless and
      wasteful because nothing is going to be using that write_stamp for
      calculations as it still will not match the before_stamp.
      
      Remove this useless update, and in doing so, we remove another
      cmpxchg64()!
      
      Also update the comments to reflect this change as well as remove some
      extra white space in another comment.
      
      Link: https://lore.kernel.org/linux-trace-kernel/20231215081810.1f4f38fe@rorschach.local.home
      
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Joel Fernandes <joel@joelfernandes.org>
      Cc: Vincent Donnefort   <vdonnefort@google.com>
      Fixes: b2dd7975 ("ring-buffer: Force absolute timestamp on discard of event")
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      083e9f65
    • Steven Rostedt (Google)'s avatar
      ring-buffer: Do not try to put back write_stamp · dd939425
      Steven Rostedt (Google) authored
      If an update to an event is interrupted by another event between the time
      the initial event allocated its buffer and where it wrote to the
      write_stamp, the code try to reset the write stamp back to the what it had
      just overwritten. It knows that it was overwritten via checking the
      before_stamp, and if it didn't match what it wrote to the before_stamp
      before it allocated its space, it knows it was overwritten.
      
      To put back the write_stamp, it uses the before_stamp it read. The problem
      here is that by writing the before_stamp to the write_stamp it makes the
      two equal again, which means that the write_stamp can be considered valid
      as the last timestamp written to the ring buffer. But this is not
      necessarily true. The event that interrupted the event could have been
      interrupted in a way that it was interrupted as well, and can end up
      leaving with an invalid write_stamp. But if this happens and returns to
      this context that uses the before_stamp to update the write_stamp again,
      it can possibly incorrectly make it valid, causing later events to have in
      correct time stamps.
      
      As it is OK to leave this function with an invalid write_stamp (one that
      doesn't match the before_stamp), there's no reason to try to make it valid
      again in this case. If this race happens, then just leave with the invalid
      write_stamp and the next event to come along will just add a absolute
      timestamp and validate everything again.
      
      Bonus points: This gets rid of another cmpxchg64!
      
      Link: https://lore.kernel.org/linux-trace-kernel/20231214222921.193037a7@gandalf.local.home
      
      Cc: stable@vger.kernel.org
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Joel Fernandes <joel@joelfernandes.org>
      Cc: Vincent Donnefort <vdonnefort@google.com>
      Fixes: a389d86f ("ring-buffer: Have nested events still record running time stamp")
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      dd939425