Commit graph

1,323,830 commits

Author SHA1 Message Date
Thomas Gleixner
97e5379253 timekeeping: Provide timekeeping_restore_shadow()
Functions which operate on the real timekeeper, e.g. do_settimeofday(),
have error conditions. If they are hit a full timekeeping update is still
required because the already committed operations modified the timekeeper.

When switching these functions to operate on the shadow timekeeper then the
full update can be avoided in the error case, but the modified shadow
timekeeper has to be restored.

Provide a helper function for that.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-15-554456a44a15@linutronix.de
2024-10-25 19:49:14 +02:00
Anna-Maria Behnsen
6b1ef640f4 timekeeping: Introduce combined timekeeping action flag
Instead of explicitly listing all the separate timekeeping actions flags,
introduce a new one which covers all actions except TK_MIRROR action.

No functional change.

Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-14-554456a44a15@linutronix.de
2024-10-25 19:49:14 +02:00
Anna-Maria Behnsen
5aa6c43eca timekeeping: Split out timekeeper update of timekeeping_advanced()
timekeeping_advance() is the only optimized function which uses
shadow_timekeeper for updating the real timekeeper to keep the sequence
counter protected region as small as possible.

To be able to transform timekeeper updates in other functions to use the
same logic, split out functionality into a separate function
timekeeper_update_staged().

While at it, document the reason why the sequence counter must be write
held over the call to timekeeping_update() and the copying to the real
timekeeper and why using a pointer based update is suboptimal.

No functional change.

Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-13-554456a44a15@linutronix.de
2024-10-25 19:49:14 +02:00
Anna-Maria Behnsen
1d72d7b5fd timekeeping: Add struct tk_data as argument to timekeeping_update()
Updates of the timekeeper are done in two ways:

 1. Updating timekeeper and afterwards memcpy()'ing the result into
    shadow_timekeeper using timekeeping_update(). Used everywhere for
    updates except in timekeeping_advance(); the sequence counter protected
    region starts before the first change to the timekeeper is done.

 2. Updating shadow_timekeeper and then memcpy()'ing the result into
    timekeeper.  Used only by in timekeeping_advance(); The seqence counter
    protected region is only around timekeeping_update() and the memcpy for
    copy from shadow to timekeeper.

The second option is fast path optimized. The sequence counter protected
region is as short as possible.

As this behaviour is mainly documented by commit messages, but not in code,
it makes the not easy timekeeping code more complicated to read.

There is no reason why updates to the timekeeper can't use the optimized
version everywhere. With this, the code will be cleaner, as code is reused
instead of duplicated.

To be able to access tk_data which contains all required information, add a
pointer to tk_data as an argument to timekeeping_update(). With that
convert the comment about holding the lock into a lockdep assert.

No functional change.

Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-12-554456a44a15@linutronix.de
2024-10-25 19:49:14 +02:00
Anna-Maria Behnsen
a5f9e4e4ef timekeeping: Introduce tkd_basic_setup() to make lock and seqcount init reusable
Initialization of lock and seqcount needs to be done for every instance of
timekeeper struct. To be able to easily reuse it, create a separate
function for it.

Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-11-554456a44a15@linutronix.de
2024-10-25 19:49:14 +02:00
Anna-Maria Behnsen
10f7c178a9 timekeeping: Define a struct type for tk_core to make it reusable
The struct tk_core uses is not reusable. As long as there is only a single
timekeeper, this is not a problem. But when the timekeeper infrastructure
will be reused for per ptp clock timekeepers, an explicit struct type is
required.

Define struct tk_data as explicit struct type for tk_core.

Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-10-554456a44a15@linutronix.de
2024-10-25 19:49:14 +02:00
Anna-Maria Behnsen
8c4799b184 timekeeping: Move timekeeper_lock into tk_core
timekeeper_lock protects updates to struct tk_core but is not part of
struct tk_core. As long as there is only a single timekeeper, this is not a
problem. But when the timekeeper infrastructure will be reused for per ptp
clock timekeepers, timekeeper_lock needs to be part of tk_core.

Move the lock into tk_core, move initialisation of the lock and sequence
counter into timekeeping_init() and update all users of timekeeper_lock.

As this is touching all lock sites, convert them to use:

  guard(raw_spinlock_irqsave)(&tk_core.lock);

instead of lock/unlock functions whenever possible.

Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-9-554456a44a15@linutronix.de
2024-10-25 19:49:14 +02:00
Thomas Gleixner
dbdcf8c4ca timekeeping: Encapsulate locking/unlocking of timekeeper_lock
timekeeper_lock protects updates of timekeeper (tk_core). It is also used
by vdso_update_begin/end() and not only internally by the timekeeper code.

As long as there is only a single timekeeper, this works fine.  But when
the timekeeper infrastructure will be reused for per ptp clock timekeepers,
timekeeper_lock needs to be part of tk_core..

Therefore encapuslate locking/unlocking of timekeeper_lock and make the
lock static.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-8-554456a44a15@linutronix.de
2024-10-25 19:49:13 +02:00
Thomas Gleixner
20c7b582e8 timekeeping: Move shadow_timekeeper into tk_core
tk_core requires shadow_timekeeper to allow timekeeping_advance() updating
without holding the timekeeper sequence count write locked. This allows the
readers to make progress up to the actual update where the shadow
timekeeper is copied over to the real timekeeper.

As long as there is only a single timekeeper, having them separate is
fine. But when the timekeeper infrastructure will be reused for per ptp
clock timekeepers, shadow_timekeeper needs to be part of tk_core.

No functional change.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-7-554456a44a15@linutronix.de
2024-10-25 19:49:13 +02:00
Thomas Gleixner
6860d28ccb timekeeping: Reorder struct timekeeper
struct timekeeper is ordered suboptimal vs. cachelines. The layout,
including the preceding seqcount (see struct tk_core in timekeeper.c) is:

 cacheline 0:   seqcount, tkr_mono
 cacheline 1:   tkr_raw, xtime_sec
 cacheline 2:   ktime_sec ... tai_offset, internal variables
 cacheline 3:	next_leap_ktime, raw_sec, internal variables
 cacheline 4:	internal variables

So any access to via ktime_get*() except for access to CLOCK_MONOTONIC_RAW
will use either cachelines 0 + 1 or cachelines 0 + 2. Access to
CLOCK_MONOTONIC_RAW uses cachelines 0 + 1 + 3.

Reorder the members so that the result is more efficient:

 cacheline 0:   seqcount, tkr_mono
 cacheline 1:   xtime_sec, ktime_sec ... tai_offset
 cacheline 2:	tkr_raw, raw_sec
 cacheline 3:	internal variables
 cacheline 4:	internal variables

That means ktime_get*() will access cacheline 0 + 1 and CLOCK_MONOTONIC_RAW
access will use cachelines 0 + 2.

Update kernel-doc and fix formatting issues while at it. Also fix a typo
in struct tk_read_base kernel-doc.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241015100839.12702-1-anna-maria@linutronix.de
2024-10-25 19:49:13 +02:00
Thomas Gleixner
c2a329566a timekeeping: Simplify code in timekeeping_advance()
timekeeping_advance() takes the timekeeper_lock and releases it before
returning. When an early return is required, goto statements are used to
make sure the lock is realeased properly. When the code was written the
locking guard() was not yet available.

Use the guard() to simplify the code and while at it cleanup ordering of
function variables. No functional change.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-5-554456a44a15@linutronix.de
2024-10-25 19:49:13 +02:00
Thomas Gleixner
1f7226b1e7 timekeeping: Abort clocksource change in case of failure
There is no point to go through a full timekeeping update when acquiring a
module reference or enabling the new clocksource fails.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-4-554456a44a15@linutronix.de
2024-10-25 19:49:13 +02:00
Anna-Maria Behnsen
9fe7d9a984 timekeeping: Avoid duplicate leap state update
do_adjtimex() invokes tk_update_leap_state() unconditionally even when a
previous invocation of timekeeping_update() already did that update.

Put it into the else path which is invoked when timekeeping_update() is not
called.

Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-3-554456a44a15@linutronix.de
2024-10-25 19:49:13 +02:00
Thomas Gleixner
886150fb4f timekeeping: Don't stop time readers across hard_pps() update
hard_pps() update does not modify anything which might be required by time
readers so forcing readers out of the way during the update is a pointless
exercise.

The interaction with adjtimex() and timekeeper updates which call into the
NTP code is properly serialized by timekeeper_lock.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-2-554456a44a15@linutronix.de
2024-10-25 19:49:13 +02:00
Thomas Gleixner
14f1e3b3df timekeeping: Read NTP tick length only once
No point in reading it a second time when the comparison fails.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/all/20241009-devel-anna-maria-b4-timers-ptp-timekeeping-v2-1-554456a44a15@linutronix.de
2024-10-25 19:49:12 +02:00
Linus Torvalds
f0560f974e gpio fixes for v6.12-rc5
- update MAINTAINERS with a keyword pattern for legacy GPIO API
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmcbqQoACgkQEacuoBRx
 13ICYw//am8bZWIX+VYx1H790TjQeIkGcuut4NJ1Gxeec9Ry0acR4T0Rkfn0WxO7
 5iNBReqAhCgVBwVoh5QPjxyU1a+PBqGGw+TzA5wa2tFRhdSKqnLHsIA22CMbWQgN
 7QRssMHJ/4avlFE6Jn4Qgd4S+sxrD8HSNHH6+p7qxT9EgIHuulRXFrRg6+xc9HUJ
 DsBqC40Mr0hwliuTHrpqXYLFE/e5Icm8KDyJy/laJHoHfPQGwz4anWWBQ/HSXNFs
 LBi/F+tx47LSjENex1L6u/QwZWNcwYXMLyWOgEEuBHRlspOaQryTY5OfEouGO4XD
 jRAzYtyjj0TkQTioyH6uuRwgzB5CnAh5eDbjYU7VC/UO3+rzYOURMR9IrM9ylv+r
 4V0uM9pFQ9KUEDX+xVG1f+pLcort+NG5mbEtXWlo1PL/xjHbyH2Wy+XVBw6uSmm6
 9rbvc1qqGSBGfaG2RZBMFsuVm3UY8DwgQR8hw0mOnRPGopHrCzQjslzMunXGKImX
 vEbql68WG56nHFTLrXNsGILQ77GG6W293saY2/y5WDjNEaYBWHJGoWZEZctRFXWh
 pQfhgZ5sLa6rzTNcX92XME8zz7K2y7LesGfJxJ6VXU+FxFXK3gDext0O/SmIOXNH
 1XEM8UTAPSZggIo1l7BYqiLnQwx6ar8tf0YzgESaEWWY3WryA48=
 =AiNK
 -----END PGP SIGNATURE-----

Merge tag 'gpio-fixes-for-v6.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

Pull gpio fix from Bartosz Golaszewski:
 "Update MAINTAINERS with a keyword pattern for legacy GPIO API

  The goal is to alert us to anyone trying to use the deprecated, legacy
  API (this happens almost every release)"

* tag 'gpio-fixes-for-v6.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  MAINTAINERS: add a keyword entry for the GPIO subsystem
2024-10-25 10:47:51 -07:00
Gustavo Sousa
8793d092ae drm/i915/display: Cover all possible pipes in TP_printk()
Tracepoints that display frame and scanline counters for all pipes were
added with commit 1489bba824 ("drm/i915: Add cxsr toggle tracepoint")
and commit 0b2599a43c ("drm/i915: Add pipe enable/disable
tracepoints"). At that time, we only had pipes A, B and C. Now that we
can also have pipe D, the TP_printk() calls are missing it.

As a quick and dirty fix for that, let's define two common macros to be
used for the format and values respectively, and also ensure we raise a
build bug if more pipes are added to enum pipe.

In the future, we should probably have a way of printing information for
available pipes only.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-6-gustavo.sousa@intel.com
2024-10-25 14:47:20 -03:00
Gustavo Sousa
2698bdbf70 drm/i915/display: Do not use ids from enum pipe in TP_printk()
Because much of kernel tracepoints is implemented at the C preprocessor
level, C identifiers used in TP_printk() are saved verbatim in the event
format, even when they represent compile-time constant values.

As an example, we can look at the format for the intel_pipe_enable
event:

    # cat /sys/kernel/debug/tracing/events/i915/intel_pipe_enable/format | grep '^print fmt'
    print fmt: "dev %s, pipe %c enable, pipe A: frame=%u, scanline=%u, pipe B: frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u", __get_str(dev), REC->pipe_name, REC->frame[PIPE_A], REC->scanline[PIPE_A], REC->frame[PIPE_B], REC->scanline[PIPE_B], REC->frame[PIPE_C], REC->scanline[PIPE_C]

We see that PIPE_A, PIPE_B and PIPE_C are pasted directly in the format.
Because tools that interact with kernel tracepoints don't know about
those ids, they'll endup failing to parse the format or produce
corrupted output.

For example, we can see below that trace-cmd repeats PIPE_A's
frame/scanline counts for all pipes (probably because it evaluates
unknown ids as zero):

   $ trace-cmd report -F intel_pipe_enable | tail -n5
        testdisplay-8616  [000] 22048.276758: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=861, scanline=480, pipe B: frame=861, scanline=480, pipe C: frame=861, scanline=480
        testdisplay-8616  [001] 22048.490287: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=867, scanline=480, pipe B: frame=867, scanline=480, pipe C: frame=867, scanline=480
        testdisplay-8616  [003] 22048.700181: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=872, scanline=400, pipe B: frame=872, scanline=400, pipe C: frame=872, scanline=400
        testdisplay-8616  [002] 22049.054220: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=881, scanline=2170, pipe B: frame=881, scanline=2170, pipe C: frame=881, scanline=2170
        testdisplay-8616  [002] 22049.166851: intel_pipe_enable:    dev 0000:00:02.0, pipe B enable, pipe A: frame=887, scanline=1632, pipe B: frame=887, scanline=1632, pipe C: frame=887, scanline=1632

, while in fact we have different values for each pipe, which can be
confirmed with the raw view of the events:

    $ trace-cmd report -R -F intel_pipe_enable | tail -n5
         testdisplay-8616  [000] 22048.276758: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[5d, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
         testdisplay-8616  [001] 22048.490287: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[63, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
         testdisplay-8616  [003] 22048.700181: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[68, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[90, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
         testdisplay-8616  [002] 22049.054220: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[71, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[7a, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
         testdisplay-8616  [002] 22049.166851: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[77, 03, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[60, 06, 00, 00, 39, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=B

To fix that, we need a fix that looks more like a hack: use macros that
result to integer constants instead of enum pipe values. This fixes the
issue, but could break if, for whatever unlikely reason, the underlying
values in the enum are changed.

In the future, we should find a better way to handle this, but for now,
the hack took care of the job:

    $ trace-cmd report -F intel_pipe_enable | tail -n5
         testdisplay-9224  [003] 24324.455375: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=1103, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
         testdisplay-9224  [002] 24324.669845: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=1109, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
         testdisplay-9224  [003] 24324.900105: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=1115, scanline=31, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
         testdisplay-9224  [002] 24325.256408: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=1124, scanline=2171, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
         testdisplay-9224  [003] 24325.380789: intel_pipe_enable:    dev 0000:00:02.0, pipe B enable, pipe A: frame=1131, scanline=979, pipe B: frame=1, scanline=1082, pipe C: frame=0, scanline=0

v2:
  - Statically assert that PIPE_A == _TRACE_PIPE_A. (MattR)

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-5-gustavo.sousa@intel.com
2024-10-25 14:47:19 -03:00
Gustavo Sousa
60e82e56d3 drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():

    "Do not create new tracepoint-specific helpers, because that will
    confuse user-space tools that know about the TRACE_EVENT() helper
    macros but will not know how to handle ones created for individual
    tracepoints."

It seems this is what we ended up doing when using pipe_name() in
TP_printk().

For example, the format for the intel_pipe_update_start event is as
follows:

    # cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
    name: intel_pipe_update_start
    ID: 1136
    format:
            field:unsigned short common_type;       offset:0;       size:2; signed:0;
            field:unsigned char common_flags;       offset:2;       size:1; signed:0;
            field:unsigned char common_preempt_count;       offset:3;       size:1; signed:0;
            field:int common_pid;   offset:4;       size:4; signed:1;

            field:__data_loc char[] dev;    offset:8;       size:4; signed:0;
            field:enum pipe pipe;   offset:12;      size:4; signed:1;
            field:u32 frame;        offset:16;      size:4; signed:0;
            field:u32 scanline;     offset:20;      size:4; signed:0;
            field:u32 min;  offset:24;      size:4; signed:0;
            field:u32 max;  offset:28;      size:4; signed:0;

    print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max

The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.

Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.

While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":

    $ trace-cmd report \
    > | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
    > | cat -v | uniq -c
         34 pipe ^A

, where ^A is a non-printable character.

As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:

    s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
    s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
    s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/

After these changes, using the same example, we have the following:

    $ trace-cmd report \
    > | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
    > | cat -v | sort | uniq -c
        396 pipe A
         34 pipe B

[1] https://lwn.net/Articles/379903/

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-25 14:47:19 -03:00
Gustavo Sousa
85c5cad1bf drm/i915/display: Zero-initialize frame/scanline counts in tracepoints
In an upcoming change, we will also add support for logging
frame/scanline counts for pipe D in relevant tracepoints.

In [1], Matt mentioned the possibility of having garbage in those counts
for pipe D on a platform containing only 3 pipes. Indeed, it has been
verified that the counts for the extra pipe would not be
zero-initialized by the tracing system.

Since it is also possible that the same would happen for a fused-off
pipe, let's go ahead and add the logic to zero-initialize the arrays
now.

[1] https://lore.kernel.org/all/20240918224927.GU5091@mdroper-desk1.amr.corp.intel.com/

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-3-gustavo.sousa@intel.com
2024-10-25 14:47:18 -03:00
Gustavo Sousa
dba8bed8b6 drm/i915/display: Fix out-of-bounds access in pipe-related tracepoints
Some display trace events use array members to store frame and scanline
counts for each pipe. However, those arrays are declared with 3 as the
hardcoded size, which cause out-of-bounds access when the trace event is
enabled on a platform that contains pipe D.

For example, when looking at the last 10 intel_pipe_enable events after
running IGT's testdisplay, we see the following on a MTL machine that
has pipe D available:

    $ trace-cmd report -R -F intel_pipe_enable \
    > | tail \
    > | sed 's,\(frame=.*\) \(scanline=.*\),\n\t   \1\n\t\2,'
         testdisplay-6715  [002] 17591.063491: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[83, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [003] 17591.264742: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[89, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [003] 17591.464541: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[8f, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [001] 17591.695827: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[95, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [000] 17591.915841: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[9a, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [000] 17592.127114: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[a0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [002] 17592.358351: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [002] 17592.580467: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [000] 17592.950946: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[b8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [004] 17593.079597: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[bf, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00] pipe=1

Which shows zeros for pipe A's scanline counts. That happens because
pipe D's frame counts are overwriting them.

Let's fix that by making the arrays bring able to store info for all
possible pipes.

With the fix, we get the following:

    $ trace-cmd report -R -F intel_pipe_enable \
    > | tail \
    > | sed 's,\(frame=.*\) \(scanline=.*\),\n\t   \1\n\t\2,'
         testdisplay-7040  [003] 18067.489565: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[8c, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[8e, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18067.699312: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[92, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18067.908868: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[98, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18068.122802: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[9d, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [003] 18068.331019: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[a2, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18068.529067: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [003] 18068.742033: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18068.956229: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[b3, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[1f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18069.295322: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[bb, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[7b, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [010] 18069.423527: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[c2, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[d0, 05, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=1

Which makes more sense now.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-2-gustavo.sousa@intel.com
2024-10-25 14:47:17 -03:00
Linus Torvalds
7a7aecd9c0 ata fix for 6.12-rc5
- Fix the handling of ATA commands that timeout (command that did not
    receive a completion interrupt within the configured timeout time).
 
    Commands that timeout, while also having either the FAILFAST flag
    set, or the command being a passthrough command, should never be
    retried. Restore this behavior (as it was before v6.12-rc1).
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYKAB0WIQRN+ES/c4tHlMch3DzJZDGjmcZNcgUCZxtiEgAKCRDJZDGjmcZN
 ctcdAQCWUhTs6m7MZmIP77c5XbPd3czeY8ZuHSkSu0aBnCDZvAD+O6mvuG6w2fyW
 tTQihAubX16fbgamCA5+sBWPNnWtcw0=
 =jiWe
 -----END PGP SIGNATURE-----

Merge tag 'ata-6.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux

Pull ata fix from Niklas Cassel:

 - Fix the handling of ATA commands that timeout (command that did not
   receive a completion interrupt within the configured timeout time).

   Commands that timeout, while also having either the FAILFAST flag
   set, or the command being a passthrough command, should never be
   retried. Restore this behavior (as it was before v6.12-rc1).

* tag 'ata-6.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
  ata: libata: Set DID_TIME_OUT for commands that actually timed out
2024-10-25 10:42:29 -07:00
Paolo Bonzini
5cb1659f41 Merge branch 'kvm-no-struct-page' into HEAD
TL;DR: Eliminate KVM's long-standing (and heinous) behavior of essentially
guessing which pfns are refcounted pages (see kvm_pfn_to_refcounted_page()).

Getting there requires "fixing" arch code that isn't obviously broken.
Specifically, to get rid of kvm_pfn_to_refcounted_page(), KVM needs to
stop marking pages/folios dirty/accessed based solely on the pfn that's
stored in KVM's stage-2 page tables.

Instead of tracking which SPTEs correspond to refcounted pages, simply
remove all of the code that operates on "struct page" based ona the pfn
in stage-2 PTEs.  This is the back ~40-50% of the series.

For x86 in particular, which sets accessed/dirty status when that info
would be "lost", e.g. when SPTEs are zapped or KVM clears the dirty flag
in a SPTE, foregoing the updates provides very measurable performance
improvements for related operations.  E.g. when clearing dirty bits as
part of dirty logging, and zapping SPTEs to reconstitue huge pages when
disabling dirty logging.

The front ~40% of the series is cleanups and prep work, and most of it is
x86 focused (purely because x86 added the most special cases, *sigh*).
E.g. several of the inputs to hva_to_pfn() (and it's myriad wrappers),
can be removed by cleaning up and deduplicating x86 code.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-10-25 13:38:16 -04:00
Linus Torvalds
01154cc30e sound fixes for 6.12-rc5
The majority of changes here are about ASoC.
 
 There are two core changes in ASoC (the bump of minimal topology
 ABI version and the fix for references of components in DAPM code),
 and others are mostly various device-specific fixes for SoundWire,
 AMD, Intel, SOF, Qualcomm and FSL, in addition to a few usual
 HD-audio quirks and fixes.
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmcbWbMOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE/YKxAAt4WhN/98T2y5RBZEpDyDrxFF3TGNhgHO61tv
 9zEpOpz2CR4vP7qbImTlzWZ8ehcbqQK3I3xlq/xsD8/nRacUyVO1XX3Zb+SlSYGp
 Ln6IFiLSnCuJKavEJtoWbEIsg+jhKQCvApq55Yxvxk/PO91Sehx+/LWa0ZeHbVrG
 ChJRXStBEfUu1eBQL/7oMPkXm7QJYzR3pE4eieom33I4wJXFRHrBtSR4Ldj1kpCJ
 GQKVqZVkUgFLLzHckJyHTswi2wX1w8H6FWTIQydqK8beHCCEBR3c3PzUQgI5QXwS
 Hfe2lyvOkK78eAPn8GdAAT1cMdMfAy/iLC78QDGhk117JACOzEU8mRWYS3Dh268a
 W8iiNYhnTRC/7M6OM+boD7IhCXADlA3wiEwV4n5BtqkjmXkNJDEWxMZrUyk6R/rO
 csEsARtue3ISClEnU0ih3Ebl3iHCUlzzCkG0bNPkMnw6dRtJyppg9LpBijt7Y6Ep
 DyaAGFBI5qMcOHIh6A35m8K3d9YwnqhAj/ZdmMLS34r8e96KdBNH4yKo7ftqqHXW
 eRDCDSjKdeWSfymutwV2jfVLR0e1C77ysL9z1MZgoRfLskjpET3Qp526hIBe+qoG
 TbGl5VLyZqhRmHwYxdDsAq+XbMm41eHJskg49iOIG3Cru1y30y0or2R1e9r10/eB
 Ue8Pb1w=
 =hhTD
 -----END PGP SIGNATURE-----

Merge tag 'sound-6.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "The majority of changes here are about ASoC.

  There are two core changes in ASoC (the bump of minimal topology ABI
  version and the fix for references of components in DAPM code), and
  others are mostly various device-specific fixes for SoundWire, AMD,
  Intel, SOF, Qualcomm and FSL, in addition to a few usual HD-audio
  quirks and fixes"

* tag 'sound-6.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (33 commits)
  ALSA: hda/realtek: Update default depop procedure
  ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc
  ASoC: fsl_micfil: Add sample rate constraint
  ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop issue
  ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE
  ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593
  ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()
  ASoC: fsl_micfil: Add a flag to distinguish with different volume control types
  ASoC: codecs: lpass-rx-macro: fix RXn(rx,n) macro for DSM_CTL and SEC7 regs
  ASoC: Change my e-mail to gmail
  ASoC: Intel: soc-acpi: lnl: Add match entry for TM2 laptops
  ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA
  ASoC: SOF: Intel: hda: Always clean up link DMA during stop
  soundwire: intel_ace2x: Send PDI stream number during prepare
  ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's
  ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs
  MAINTAINERS: Update maintainer list for MICROCHIP ASOC, SSC and MCP16502 drivers
  ASoC: qcom: Select missing common Soundwire module code on SDM845
  ASoC: fsl_esai: change dev_warn to dev_dbg in irq handler
  ASoC: rsnd: Fix probe failure on HiHope boards due to endpoint parsing
  ...
2024-10-25 10:35:29 -07:00
Linus Torvalds
fd143856b0 drm fixes for 6.12-rc5
amdgpu:
 - ACPI method handling fixes
 - SMU 14.x fixes
 - Display idle optimization fix
 - DP link layer compliance fix
 - SDMA 7.x fix
 - PSR-SU fix
 - SWSMU fix
 
 i915:
 - Fix DRM_I915_GVT_KVMGT dependencies in Kconfig
 
 xe:
 - Increase invalidation timeout to avoid errors in some hosts
 - Flush worker on timeout
 - Better handling for force wake failure
 - Improve argument check on user fence creation
 - Don't restart parallel queues multiple times on GT reset
 
 bridge:
 - aux: Fix assignment of OF node
 - tc358767: Add missing of_node_put() in error path
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmcbQzgACgkQDHTzWXnE
 hr7IfQ/+OiFjGAZp6cESUUc+NQAbiFtLUFw2Z6oholsu6gYhq20Zelp80iue2CvM
 leIl22tvdZbILigfKPCC4Om5lm4ffOesA4OVv5FDugrZ0VSN9eqnN6HYfKkRTwxZ
 P9sAh59eMCniHsejja1SBY7HuqUIvT+ONE/5jyWb+BObRlZLCg9o9zTaf0KGAtzk
 OSFQOR9APW08jdtDPvzEVAevC8aPpFR4LMCuuE7U+vINVW7mkm4aliixFm+rnr7y
 WhHhzy2TCZXUmXiCAIIPITGp0LEE9vWyO3oxtSr570a0/80uK3cpUTGydbFWqr6x
 mN/5du21JZrkw/RbImNyerKcatxQef+cxYA1cLl64mfRYf+8BcPd/ORVc2h7YJrR
 YrazB6+QwwUwLhMvls24z180MEZtk7uZ2v6eNfxLseogkJhqRJdLUxAhf9+BE2AV
 g1VBQjl3dO3XX2nYU67LCn/6/bBtnGoOaoUidr5O1gF1bWfIezCDUes8p0oXjk1X
 RhIUSUgW5Cy/G8Nodx/XQgVLC/pRfLqwSakb0XquhqVS63pZbeDdx69UNtbON0aN
 cb/2S2bgFnTN3HYTCrOG243B1BNkusauGEi+ACJfL2GxjTF848NA+K8G8OkpfuPl
 nAZvi2hMtDpuJEcDiVk0AgutPp2+e+lyeQCbCpERvPbt0/7w/O8=
 =dyE6
 -----END PGP SIGNATURE-----

Merge tag 'drm-fixes-2024-10-25' of https://gitlab.freedesktop.org/drm/kernel

Pull drm fixes from Dave Airlie:
 "Weekly drm fixes, mostly amdgpu and xe, with minor bridge and an i915
  Kconfig fix. Nothing too scary and it seems to be pretty quiet.

  amdgpu:
   - ACPI method handling fixes
   - SMU 14.x fixes
   - Display idle optimization fix
   - DP link layer compliance fix
   - SDMA 7.x fix
   - PSR-SU fix
   - SWSMU fix

  i915:
   - Fix DRM_I915_GVT_KVMGT dependencies in Kconfig

  xe:
   - Increase invalidation timeout to avoid errors in some hosts
   - Flush worker on timeout
   - Better handling for force wake failure
   - Improve argument check on user fence creation
   - Don't restart parallel queues multiple times on GT reset

  bridge:
   - aux: Fix assignment of OF node
   - tc358767: Add missing of_node_put() in error path"

* tag 'drm-fixes-2024-10-25' of https://gitlab.freedesktop.org/drm/kernel:
  drm/xe: Don't restart parallel queues multiple times on GT reset
  drm/xe/ufence: Prefetch ufence addr to catch bogus address
  drm/xe: Handle unreliable MMIO reads during forcewake
  drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout
  drm/xe: Enlarge the invalidation timeout from 150 to 500
  drm/amdgpu: handle default profile on on devices without fullscreen 3D
  drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too
  drm/amdgpu: fix random data corruption for sdma 7
  drm/amd/display: temp w/a for DP Link Layer compliance
  drm/amd/display: temp w/a for dGPU to enter idle optimizations
  drm/amd/pm: update deep sleep status on smu v14.0.2/3
  drm/amd/pm: update overdrive function on smu v14.0.2/3
  drm/amd/pm: update the driver-fw interface file for smu v14.0.2/3
  drm/amd: Guard against bad data for ATIF ACPI method
  drm/bridge: tc358767: fix missing of_node_put() in for_each_endpoint_of_node()
  drm/bridge: Fix assignment of the of_node of the parent to aux bridge
  i915: fix DRM_I915_GVT_KVMGT dependencies
2024-10-25 10:29:51 -07:00
Kent Overstreet
8e910ca20e bcachefs: Fix UAF in bch2_reconstruct_alloc()
write_super() -> sb_counters_from_cpu() may reallocate the superblock

Reported-by: syzbot+9fc4dac4775d07bcfe34@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2024-10-25 13:17:23 -04:00
Jeongjun Park
a25a83de45 bcachefs: fix null-ptr-deref in have_stripes()
c->btree_roots_known[i].b can be NULL. In this case, a NULL pointer dereference
occurs, so you need to add code to check the variable.

Reported-by: syzbot+b468b9fef56949c3b528@syzkaller.appspotmail.com
Fixes: 7773df19c3 ("bcachefs: metadata version bucket_stripe_sectors")
Signed-off-by: Jeongjun Park <aha310510@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2024-10-25 13:17:06 -04:00
Jeffrey Hugo
93accc16a8 accel/qaic: Add crashdump to Sahara
The Sahara protocol has a crashdump functionality. In the hello
exchange, the device can advertise it has a memory dump available for
the host to collect. Instead of the device making requests of the host,
the host requests data from the device which can be later analyzed.

Implement this functionality and utilize the devcoredump framework for
handing the dump over to userspace.

Similar to how firmware loading in Sahara involves multiple files,
crashdump can consist of multiple files for different parts of the dump.
Structure these into a single buffer that userspace can parse and
extract the original files from.

Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com>
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241021200355.544126-1-quic_jhugo@quicinc.com
2024-10-25 11:10:34 -06:00
David Vernet
895669fd0d scx: Fix exit selftest to use custom DSQ
In commit 63fb3ec805 ("sched_ext: Allow only user DSQs for
scx_bpf_consume(), scx_bpf_dsq_nr_queued() and bpf_iter_scx_dsq_new()"), we
updated the consume path to only accept user DSQs, thus making it invalid
to consume SCX_DSQ_GLOBAL. This selftest was doing that, so let's create a
custom DSQ and use that instead.  The test now passes:

[root@virtme-ng sched_ext]# ./runner -t exit
===== START =====
TEST: exit
DESCRIPTION: Verify we can cleanly exit a scheduler in multiple places
OUTPUT:
[   12.387229] sched_ext: BPF scheduler "exit" enabled
[   12.406064] sched_ext: BPF scheduler "exit" disabled (unregistered from BPF)
[   12.453325] sched_ext: BPF scheduler "exit" enabled
[   12.474064] sched_ext: BPF scheduler "exit" disabled (unregistered from BPF)
[   12.515241] sched_ext: BPF scheduler "exit" enabled
[   12.532064] sched_ext: BPF scheduler "exit" disabled (unregistered from BPF)
[   12.592063] sched_ext: BPF scheduler "exit" disabled (unregistered from BPF)
[   12.654063] sched_ext: BPF scheduler "exit" disabled (unregistered from BPF)
[   12.715062] sched_ext: BPF scheduler "exit" disabled (unregistered from BPF)
ok 1 exit #
=====  END  =====

Signed-off-by: David Vernet <void@manifault.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2024-10-25 07:03:36 -10:00
Sean Christopherson
8b15c3764c KVM: Don't grab reference on VM_MIXEDMAP pfns that have a "struct page"
Now that KVM no longer relies on an ugly heuristic to find its struct page
references, i.e. now that KVM can't get false positives on VM_MIXEDMAP
pfns, remove KVM's hack to elevate the refcount for pfns that happen to
have a valid struct page.  In addition to removing a long-standing wart
in KVM, this allows KVM to map non-refcounted struct page memory into the
guest, e.g. for exposing GPU TTM buffers to KVM guests.

Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-86-seanjc@google.com>
2024-10-25 13:01:35 -04:00
Sean Christopherson
93b7da404f KVM: Drop APIs that manipulate "struct page" via pfns
Remove all kvm_{release,set}_pfn_*() APIs now that all users are gone.

No functional change intended.

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-85-seanjc@google.com>
2024-10-25 13:01:35 -04:00
Sean Christopherson
2362506f7c KVM: arm64: Don't mark "struct page" accessed when making SPTE young
Don't mark pages/folios as accessed in the primary MMU when making a SPTE
young in KVM's secondary MMU, as doing so relies on
kvm_pfn_to_refcounted_page(), and generally speaking is unnecessary and
wasteful.  KVM participates in page aging via mmu_notifiers, so there's no
need to push "accessed" updates to the primary MMU.

Dropping use of kvm_set_pfn_accessed() also paves the way for removing
kvm_pfn_to_refcounted_page() and all its users.

Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-84-seanjc@google.com>
2024-10-25 13:01:35 -04:00
Sean Christopherson
66bc627e7f KVM: x86/mmu: Don't mark "struct page" accessed when zapping SPTEs
Don't mark pages/folios as accessed in the primary MMU when zapping SPTEs,
as doing so relies on kvm_pfn_to_refcounted_page(), and generally speaking
is unnecessary and wasteful.  KVM participates in page aging via
mmu_notifiers, so there's no need to push "accessed" updates to the
primary MMU.

And if KVM zaps a SPTe in response to an mmu_notifier, marking it accessed
_after_ the primary MMU has decided to zap the page is likely to go
unnoticed, i.e. odds are good that, if the page is being zapped for
reclaim, the page will be swapped out regardless of whether or not KVM
marks the page accessed.

Dropping x86's use of kvm_set_pfn_accessed() also paves the way for
removing kvm_pfn_to_refcounted_page() and all its users.

Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-83-seanjc@google.com>
2024-10-25 13:01:35 -04:00
Sean Christopherson
31fccdd212 KVM: Make kvm_follow_pfn.refcounted_page a required field
Now that the legacy gfn_to_pfn() APIs are gone, and all callers of
hva_to_pfn() pass in a refcounted_page pointer, make it a required field
to ensure all future usage in KVM plays nice.

Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-82-seanjc@google.com>
2024-10-25 13:01:35 -04:00
Sean Christopherson
d0ef8d9fbe KVM: s390: Use kvm_release_page_dirty() to unpin "struct page" memory
Use kvm_release_page_dirty() when unpinning guest pages, as the pfn was
retrieved via pin_guest_page(), i.e. is guaranteed to be backed by struct
page memory.  This will allow dropping kvm_release_pfn_dirty() and
friends.

Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-81-seanjc@google.com>
2024-10-25 13:01:35 -04:00
Sean Christopherson
06cdaff80e KVM: Drop gfn_to_pfn() APIs now that all users are gone
Drop gfn_to_pfn() and all its variants now that all users are gone.

No functional change intended.

Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-80-seanjc@google.com>
2024-10-25 13:01:35 -04:00
Sean Christopherson
040537ce87 KVM: PPC: Explicitly require struct page memory for Ultravisor sharing
Explicitly require "struct page" memory when sharing memory between
guest and host via an Ultravisor.  Given the number of pfn_to_page()
calls in the code, it's safe to assume that KVM already requires that the
pfn returned by gfn_to_pfn() is backed by struct page, i.e. this is
likely a bug fix, not a reduction in KVM capabilities.

Switching to gfn_to_page() will eventually allow removing gfn_to_pfn()
and kvm_pfn_to_refcounted_page().

Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-79-seanjc@google.com>
2024-10-25 13:00:50 -04:00
Sean Christopherson
570d666c11 KVM: arm64: Use __gfn_to_page() when copying MTE tags to/from userspace
Use __gfn_to_page() instead when copying MTE tags between guest and
userspace.  This will eventually allow removing gfn_to_pfn_prot(),
gfn_to_pfn(), kvm_pfn_to_refcounted_page(), and related APIs.

Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-78-seanjc@google.com>
2024-10-25 13:00:50 -04:00
Sean Christopherson
f42e289a20 KVM: Add support for read-only usage of gfn_to_page()
Rework gfn_to_page() to support read-only accesses so that it can be used
by arm64 to get MTE tags out of guest memory.

Opportunistically rewrite the comment to be even more stern about using
gfn_to_page(), as there are very few scenarios where requiring a struct
page is actually the right thing to do (though there are such scenarios).
Add a FIXME to call out that KVM probably should be pinning pages, not
just getting pages.

Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-77-seanjc@google.com>
2024-10-25 13:00:50 -04:00
Sean Christopherson
ce6bf70346 KVM: Convert gfn_to_page() to use kvm_follow_pfn()
Convert gfn_to_page() to the new kvm_follow_pfn() internal API, which will
eventually allow removing gfn_to_pfn() and kvm_pfn_to_refcounted_page().

Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-76-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
ee0fa69354 KVM: PPC: Use kvm_vcpu_map() to map guest memory to patch dcbz instructions
Use kvm_vcpu_map() when patching dcbz in guest memory, as a regular GUP
isn't technically sufficient when writing to data in the target pages.
As per Documentation/core-api/pin_user_pages.rst:

      Correct (uses FOLL_PIN calls):
          pin_user_pages()
          write to the data within the pages
          unpin_user_pages()

      INCORRECT (uses FOLL_GET calls):
          get_user_pages()
          write to the data within the pages
          put_page()

As a happy bonus, using kvm_vcpu_{,un}map() takes care of creating a
mapping and marking the page dirty.

Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-75-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
17b7dbaf18 KVM: PPC: Remove extra get_page() to fix page refcount leak
Don't manually do get_page() when patching dcbz, as gfn_to_page() gifts
the caller a reference.  I.e. doing get_page() will leak the page due to
not putting all references.

Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-74-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
7e8f1aa59d KVM: MIPS: Use kvm_faultin_pfn() to map pfns into the guest
Convert MIPS to kvm_faultin_pfn()+kvm_release_faultin_page(), which
are new APIs to consolidate arch code and provide consistent behavior
across all KVM architectures.

Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-73-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
13d66fddaa KVM: MIPS: Mark "struct page" pfns accessed prior to dropping mmu_lock
Mark pages accessed before dropping mmu_lock when faulting in guest memory
so that MIPS can convert to kvm_release_faultin_page() without tripping
its lockdep assertion on mmu_lock being held.

Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-72-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
4d75f14fc8 KVM: MIPS: Mark "struct page" pfns accessed only in "slow" page fault path
Mark pages accessed only in the slow page fault path in order to remove
an unnecessary user of kvm_pfn_to_refcounted_page().  Marking pages
accessed in the primary MMU during KVM page fault handling isn't harmful,
but it's largely pointless and likely a waste of a cycles since the
primary MMU will call into KVM via mmu_notifiers when aging pages.  I.e.
KVM participates in a "pull" model, so there's no need to also "push"
updates.

Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-71-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
d8f4cda748 KVM: MIPS: Mark "struct page" pfns dirty only in "slow" page fault path
Mark pages/folios dirty only the slow page fault path, i.e. only when
mmu_lock is held and the operation is mmu_notifier-protected, as marking a
page/folio dirty after it has been written back can make some filesystems
unhappy (backing KVM guests will such filesystem files is uncommon, and
the race is minuscule, hence the lack of complaints).

See the link below for details.

Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-70-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
14d02b7ff9 KVM: LoongArch: Use kvm_faultin_pfn() to map pfns into the guest
Convert LoongArch to kvm_faultin_pfn()+kvm_release_faultin_page(), which
are new APIs to consolidate arch code and provide consistent behavior
across all KVM architectures.

Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-69-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
35b80f7b49 KVM: LoongArch: Mark "struct page" pfn accessed before dropping mmu_lock
Mark pages accessed before dropping mmu_lock when faulting in guest memory
so that LoongArch can convert to kvm_release_faultin_page() without
tripping its lockdep assertion on mmu_lock being held.

Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-68-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
4a2bc01b7a KVM: LoongArch: Mark "struct page" pfns accessed only in "slow" page fault path
Mark pages accessed only in the slow path, before dropping mmu_lock when
faulting in guest memory so that LoongArch can convert to
kvm_release_faultin_page() without tripping its lockdep assertion on
mmu_lock being held.

Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-67-seanjc@google.com>
2024-10-25 13:00:49 -04:00
Sean Christopherson
0fe133a33e KVM: LoongArch: Mark "struct page" pfns dirty only in "slow" page fault path
Mark pages/folios dirty only the slow page fault path, i.e. only when
mmu_lock is held and the operation is mmu_notifier-protected, as marking a
page/folio dirty after it has been written back can make some filesystems
unhappy (backing KVM guests will such filesystem files is uncommon, and
the race is minuscule, hence the lack of complaints).

See the link below for details.

Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.com
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20241010182427.1434605-66-seanjc@google.com>
2024-10-25 13:00:49 -04:00