* [PATCH v4 net-next 1/7] ptp: Add ioctls for PHC timestamps with quality attributes
From: Arthur Kiyanovski @ 2026-07-14 2:03 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, netdev
Cc: Arthur Kiyanovski, Richard Cochran, Eric Dumazet, Paolo Abeni,
David Woodhouse, Thomas Gleixner, Miroslav Lichvar, Andrew Lunn,
Wen Gu, Xuan Zhuo, David Woodhouse, Yonatan Sarna,
Zorik Machulsky, Alexander Matushevsky, Saeed Bshara, Matt Wilson,
Anthony Liguori, Nafea Bshara, Evgeny Schmeilin, Netanel Belgazal,
Ali Saidi, Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
vadim.fedorenko
In-Reply-To: <20260714020340.25014-1-akiyano@amazon.com>
Introduce two new ioctls that extend existing PTP timestamp interfaces
with clock quality information:
- PTP_SYS_OFFSET_EXTENDED_ATTRS: Extends PTP_SYS_OFFSET_EXTENDED
- PTP_SYS_OFFSET_PRECISE_ATTRS: Extends PTP_SYS_OFFSET_PRECISE
These ioctls provide quality attributes alongside timestamps:
1. error_bound: Maximum deviation from true time (nanoseconds), based
on device's internal clock state
2. clock_status: Synchronization state (unknown, initializing,
synchronized, free-running, unreliable)
3. timescale: Time reference (TAI, UTC, etc.)
4. counter_value: Raw system counter (e.g. TSC ticks) captured by the
timekeeping core alongside each system timestamp
5. counter_id: Identifies the counter source (e.g. TSC, ARM arch counter)
This supports three use cases:
1. Managed PHC devices (e.g., ENA, vmclock) that maintain their own
synchronization and can report quality metrics directly to userspace
without requiring ptp4l
2. Applications that need complete time quality information in a single
call, regardless of how the PHC is synchronized
3. VMMs that need raw system counter values paired
with PTP timestamps for feed-forward clock calibration, avoiding the
feedback loop inherent in NTP-style synchronization
Timescale definitions use a Continuity/Discipline framework to describe
timeline properties and steering behavior consistently across all
entries.
This implementation is based on the original RFC and the UAPI design
discussion linked below.
Link: https://lore.kernel.org/netdev/20250724115657.150-1-darinzon@amazon.com/
Link: https://lore.kernel.org/all/87se7ht25o.ffs@tglx/
Signed-off-by: Amit Bernstein <amitbern@amazon.com>
Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
---
drivers/ptp/ptp_chardev.c | 166 ++++++++++++++++++--
drivers/ptp/ptp_clock.c | 4 +-
include/linux/ptp_clock_kernel.h | 30 ++++
include/uapi/linux/ptp_clock.h | 254 ++++++++++++++++++++++++++++++-
4 files changed, 439 insertions(+), 15 deletions(-)
diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index dc23cd708cfe..be33f8ead727 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -190,6 +190,8 @@ static long ptp_clock_getcaps(struct ptp_clock *ptp, void __user *arg)
.cross_timestamping = ptp->info->getcrosststamp != NULL,
.adjust_phase = ptp->info->adjphase != NULL &&
ptp->info->getmaxphase != NULL,
+ .extended_attrs = ptp->info->gettimexattrs64 != NULL,
+ .precise_attrs = ptp->info->getcrosststampattrs != NULL,
};
if (caps.adjust_phase)
@@ -347,11 +349,28 @@ typedef int (*ptp_gettimex_fn)(struct ptp_clock_info *,
struct timespec64 *,
struct ptp_system_timestamp *);
+static int ptp_validate_sys_offset_clockid(__kernel_clockid_t clockid)
+{
+ switch (clockid) {
+ case CLOCK_REALTIME:
+ case CLOCK_MONOTONIC:
+ case CLOCK_MONOTONIC_RAW:
+ return 0;
+ case CLOCK_AUX ... CLOCK_AUX_LAST:
+ if (IS_ENABLED(CONFIG_POSIX_AUX_CLOCKS))
+ return 0;
+ fallthrough;
+ default:
+ return -EINVAL;
+ }
+}
+
static long ptp_sys_offset_extended(struct ptp_clock *ptp, void __user *arg,
ptp_gettimex_fn gettimex_fn)
{
struct ptp_sys_offset_extended *extoff __free(kfree) = NULL;
struct ptp_system_timestamp sts;
+ int err;
if (!gettimex_fn)
return -EOPNOTSUPP;
@@ -363,23 +382,13 @@ static long ptp_sys_offset_extended(struct ptp_clock *ptp, void __user *arg,
if (extoff->n_samples > PTP_MAX_SAMPLES || extoff->rsv[0] || extoff->rsv[1])
return -EINVAL;
- switch (extoff->clockid) {
- case CLOCK_REALTIME:
- case CLOCK_MONOTONIC:
- case CLOCK_MONOTONIC_RAW:
- break;
- case CLOCK_AUX ... CLOCK_AUX_LAST:
- if (IS_ENABLED(CONFIG_POSIX_AUX_CLOCKS))
- break;
- fallthrough;
- default:
- return -EINVAL;
- }
+ err = ptp_validate_sys_offset_clockid(extoff->clockid);
+ if (err)
+ return err;
sts.clockid = extoff->clockid;
for (unsigned int i = 0; i < extoff->n_samples; i++) {
struct timespec64 ts;
- int err;
err = gettimex_fn(ptp->info, &ts, &sts);
if (err)
@@ -404,6 +413,131 @@ static long ptp_sys_offset_extended(struct ptp_clock *ptp, void __user *arg,
return copy_to_user(arg, extoff, sizeof(*extoff)) ? -EFAULT : 0;
}
+static long ptp_sys_offset_extended_attrs(struct ptp_clock *ptp, void __user *arg)
+{
+ struct ptp_sys_offset_attrs *data __free(kfree) = NULL;
+ struct ptp_system_timestamp sts;
+ unsigned int n_samples;
+ int err;
+
+ data = memdup_user(arg, sizeof(*data));
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ if (data->request.valid ||
+ data->request.num_samples > PTP_MAX_SAMPLES ||
+ data->request.num_samples == 0)
+ return -EINVAL;
+
+ err = ptp_validate_sys_offset_clockid(data->request.clock_id);
+ if (err)
+ return err;
+
+ n_samples = data->request.num_samples;
+ sts.clockid = data->request.clock_id;
+ kfree(data);
+ data = kzalloc(struct_size(data, timestamps, n_samples), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->request.num_samples = n_samples;
+
+ for (unsigned int i = 0; i < n_samples; i++) {
+ struct ptp_clock_attrs att = {};
+ struct timespec64 ts;
+
+ if (ptp->info->gettimexattrs64)
+ err = ptp->info->gettimexattrs64(ptp->info, &ts,
+ &sts, &att);
+ else if (ptp->info->gettimex64)
+ err = ptp->info->gettimex64(ptp->info, &ts, &sts);
+ else
+ return -EOPNOTSUPP;
+
+ if (err)
+ return err;
+
+ /* Filter out disabled or unavailable clocks */
+ if (!sts.pre_sts.valid || !sts.post_sts.valid)
+ return -EINVAL;
+
+ data->timestamps[i].pre_systime.sys_time =
+ ktime_to_ns(sts.pre_sts.systime);
+ data->timestamps[i].pre_systime.sys_rawtime =
+ ktime_to_ns(sts.pre_sts.monoraw);
+ data->timestamps[i].pre_systime.sys_counter =
+ sts.pre_sts.cycles;
+ data->timestamps[i].pre_systime.sys_counter_id =
+ sts.pre_sts.cs_id;
+ data->timestamps[i].devtime.device_time.sec = ts.tv_sec;
+ data->timestamps[i].devtime.device_time.nsec = ts.tv_nsec;
+ data->timestamps[i].devtime.attrs = att;
+ data->timestamps[i].post_systime.sys_time =
+ ktime_to_ns(sts.post_sts.systime);
+ data->timestamps[i].post_systime.sys_rawtime =
+ ktime_to_ns(sts.post_sts.monoraw);
+ data->timestamps[i].post_systime.sys_counter =
+ sts.post_sts.cycles;
+ data->timestamps[i].post_systime.sys_counter_id =
+ sts.post_sts.cs_id;
+ }
+
+ return copy_to_user(arg, data,
+ struct_size(data, timestamps, n_samples)) ? -EFAULT : 0;
+}
+
+static long ptp_sys_offset_precise_attrs(struct ptp_clock *ptp, void __user *arg)
+{
+ struct ptp_sys_offset_attrs *data __free(kfree) = NULL;
+ struct system_device_crosststamp xtstamp;
+ struct ptp_clock_attrs att = {};
+ struct timespec64 ts;
+ int err;
+
+ data = memdup_user(arg, sizeof(*data));
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ if (data->request.valid ||
+ data->request.num_samples != 1)
+ return -EINVAL;
+
+ err = ptp_validate_sys_offset_clockid(data->request.clock_id);
+ if (err)
+ return err;
+
+ kfree(data);
+ data = kzalloc(struct_size(data, timestamps, 1), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ if (ptp->info->getcrosststampattrs)
+ err = ptp->info->getcrosststampattrs(ptp->info, &xtstamp, &att);
+ else if (ptp->info->getcrosststamp)
+ err = ptp->info->getcrosststamp(ptp->info, &xtstamp);
+ else
+ return -EOPNOTSUPP;
+
+ if (err)
+ return err;
+
+ ts = ktime_to_timespec64(xtstamp.device);
+ data->timestamps[0].systime.sys_time =
+ ktime_to_ns(xtstamp.sys_systime);
+ data->timestamps[0].systime.sys_rawtime =
+ ktime_to_ns(xtstamp.sys_monoraw);
+ data->timestamps[0].systime.sys_counter =
+ xtstamp.sys_counter.cycles;
+ data->timestamps[0].systime.sys_counter_id =
+ xtstamp.sys_counter.cs_id;
+ data->timestamps[0].devtime.device_time.sec = ts.tv_sec;
+ data->timestamps[0].devtime.device_time.nsec = ts.tv_nsec;
+ data->timestamps[0].devtime.attrs = att;
+
+ return copy_to_user(arg, data,
+ struct_size(data, timestamps, 1)) ? -EFAULT : 0;
+}
+
static long ptp_sys_offset(struct ptp_clock *ptp, void __user *arg)
{
struct ptp_sys_offset *sysoff __free(kfree) = NULL;
@@ -539,11 +673,17 @@ long ptp_ioctl(struct posix_clock_context *pccontext, unsigned int cmd,
return ptp_sys_offset_precise(ptp, argptr,
ptp->info->getcrosststamp);
+ case PTP_SYS_OFFSET_PRECISE_ATTRS:
+ return ptp_sys_offset_precise_attrs(ptp, argptr);
+
case PTP_SYS_OFFSET_EXTENDED:
case PTP_SYS_OFFSET_EXTENDED2:
return ptp_sys_offset_extended(ptp, argptr,
ptp->info->gettimex64);
+ case PTP_SYS_OFFSET_EXTENDED_ATTRS:
+ return ptp_sys_offset_extended_attrs(ptp, argptr);
+
case PTP_SYS_OFFSET:
case PTP_SYS_OFFSET2:
return ptp_sys_offset(ptp, argptr);
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index d6f54ccaf93b..849aef8191c5 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -112,7 +112,9 @@ static int ptp_clock_gettime(struct posix_clock *pc, struct timespec64 *tp)
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
int err;
- if (ptp->info->gettimex64)
+ if (ptp->info->gettimexattrs64)
+ err = ptp->info->gettimexattrs64(ptp->info, tp, NULL, NULL);
+ else if (ptp->info->gettimex64)
err = ptp->info->gettimex64(ptp->info, tp, NULL);
else
err = ptp->info->gettime64(ptp->info, tp);
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index 36a27a910595..b2a418081687 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -123,11 +123,34 @@ struct ptp_system_timestamp {
* reading the lowest bits of the PHC timestamp and the second
* reading immediately follows that.
*
+ * @gettimexattrs64: Reads the current time from the hardware clock and
+ * optionally also the system clock with additional clock
+ * attributes.
+ * parameter ts: Holds the PHC timestamp.
+ * parameter sts: If not NULL, it holds a pair of
+ * timestamps from the system clock. The first reading is
+ * made right before reading the lowest bits of the PHC
+ * timestamp and the second reading immediately follows that.
+ * parameter att: If not NULL, it holds the maximum error
+ * bound for the returned PHC timestamp in nanoseconds,
+ * the timescale for the returned PHC timestamp and the
+ * clock's qualitative synchronization status.
+ *
* @getcrosststamp: Reads the current time from the hardware clock and
* system clock simultaneously.
* parameter cts: Contains timestamp (device,system) pair,
* where system time is realtime and monotonic.
*
+ * @getcrosststampattrs: Reads the current time from the hardware clock and
+ * system clock simultaneously with additional data on
+ * hardware clock accuracy and reliability.
+ * parameter cts: Contains timestamp (device,system)
+ * pair, where system time is realtime and monotonic.
+ * parameter att: If not NULL, it holds the maximum error
+ * bound for the returned PHC timestamp in nanoseconds,
+ * the timescale for the returned PHC timestamp and the
+ * clock's qualitative synchronization status.
+ *
* @settime64: Set the current time on the hardware clock.
* parameter ts: Time value to set.
*
@@ -209,8 +232,15 @@ struct ptp_clock_info {
int (*gettime64)(struct ptp_clock_info *ptp, struct timespec64 *ts);
int (*gettimex64)(struct ptp_clock_info *ptp, struct timespec64 *ts,
struct ptp_system_timestamp *sts);
+ int (*gettimexattrs64)(struct ptp_clock_info *ptp,
+ struct timespec64 *ts,
+ struct ptp_system_timestamp *sts,
+ struct ptp_clock_attrs *att);
int (*getcrosststamp)(struct ptp_clock_info *ptp,
struct system_device_crosststamp *cts);
+ int (*getcrosststampattrs)(struct ptp_clock_info *ptp,
+ struct system_device_crosststamp *cts,
+ struct ptp_clock_attrs *att);
int (*settime64)(struct ptp_clock_info *p, const struct timespec64 *ts);
int (*getcycles64)(struct ptp_clock_info *ptp, struct timespec64 *ts);
int (*getcyclesx64)(struct ptp_clock_info *ptp, struct timespec64 *ts,
diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
index 46d45f902486..88c2da6bc8c6 100644
--- a/include/uapi/linux/ptp_clock.h
+++ b/include/uapi/linux/ptp_clock.h
@@ -79,6 +79,137 @@
*/
#define PTP_PEROUT_V1_VALID_FLAGS (0)
+/*
+ * Clock status values for struct ptp_clock_attrs.status
+ */
+enum ptp_clock_status {
+ /* Clock synchronization status cannot be reliably determined */
+ PTP_CLOCK_STATUS_UNKNOWN = 0,
+
+ /* Clock is acquiring synchronization */
+ PTP_CLOCK_STATUS_INITIALIZING = 1,
+
+ /* Clock is synchronized and maintained accurately by the device */
+ PTP_CLOCK_STATUS_SYNCED = 2,
+
+ /* Clock is drifting but remains within acceptable error bounds */
+ PTP_CLOCK_STATUS_HOLDOVER = 3,
+
+ /* Clock is drifting without adjustments or synchronization */
+ PTP_CLOCK_STATUS_FREE_RUNNING = 4,
+
+ /* Clock is unreliable, the error_bound value cannot be trusted */
+ PTP_CLOCK_STATUS_UNRELIABLE = 5
+};
+
+/*
+ * Clock timescale values for struct ptp_clock_attrs.timescale.
+ *
+ * These definitions describe the mathematical properties and reference
+ * epochs of the timescale provided by the PHC.
+ *
+ * Discipline: Describes the frequency/phase steering behavior.
+ * Continuity: Describes whether the timeline is uninterrupted.
+ */
+enum ptp_clock_timescale {
+ /* Unknown or unspecified timescale */
+ PTP_TIMESCALE_UNKNOWN = 0,
+
+ /********************* Absolute Atomic Timescales *********************
+ * These timescales are continuous, monotonic standards based on atomic
+ * physics. They do not experience phase jumps.
+ **********************************************************************/
+
+ /**
+ * International Atomic Time (TAI)
+ * Epoch: 1958-01-01 00:00:00.
+ * Continuity: Strictly monotonic and continuous; no leap seconds.
+ * Discipline: Primary atomic reference; no phase jumps.
+ */
+ PTP_TIMESCALE_TAI = 1,
+
+ /**
+ * Terrestrial Time (TT)
+ * Epoch: 1958-01-01 00:00:00.
+ * Continuity: Strictly monotonic and continuous; no leap seconds.
+ * Discipline: Defined as TAI + 32.184s constant offset.
+ */
+ PTP_TIMESCALE_TT = 2,
+
+ /**
+ * Global Positioning System (GPS) Time
+ * Epoch: 1980-01-06 00:00:00.
+ * Continuity: Strictly monotonic and continuous; no leap seconds.
+ * Discipline: Defined by the GPS constellation; fixed offset from TAI.
+ */
+ PTP_TIMESCALE_GPS = 3,
+
+ /****************** UTC-Based Timescales (Civil Time) *****************
+ * These timescales are derived from TAI but adjusted to align with
+ * the Earth's rotation, primarily through leap seconds.
+ **********************************************************************/
+
+ /**
+ * Coordinated Universal Time (UTC) - Wall-clock (CLOCK_REALTIME)
+ * Epoch: 1970-01-01 00:00:00 (Unix epoch).
+ * Continuity: Discontinuous; subject to 1-second leap second
+ * phase jumps.
+ * Discipline: Frequency steered; incorporates leap second corrections.
+ *
+ * Note: Leap-smeared UTC MUST NOT be advertised as PTP_TIMESCALE_UTC.
+ * Smear algorithms are not standardized and the resulting timescale
+ * is ambiguous. Implementations using smeared UTC MUST advertise
+ * PTP_TIMESCALE_UNKNOWN or PTP_TIMESCALE_PROPRIETARY instead.
+ */
+ PTP_TIMESCALE_UTC = 4,
+
+ /**
+ * POSIX Time (Unix Time)
+ * Epoch: 1970-01-01 00:00:00.
+ * Continuity: Discontinuous; leap seconds handled by
+ * repeating/skipping values.
+ * Discipline: Follows UTC frequency steering and phase jumps.
+ */
+ PTP_TIMESCALE_POSIX = 5,
+
+ /****************** System-Relative Monotonic Clocks ******************
+ * These timescales are relative to a system event (like boot)
+ * and are not synchronized to an external atomic standard.
+ **********************************************************************/
+
+ /**
+ * Monotonic System Clock (CLOCK_MONOTONIC)
+ * Epoch: Arbitrary (System boot time).
+ * Continuity: Strictly monotonic; no leap seconds.
+ * Discipline: Frequency steered to match system reference;
+ * does not advance during suspend.
+ */
+ PTP_TIMESCALE_MONOTONIC = 6,
+
+ /**
+ * Raw Monotonic System Clock (CLOCK_MONOTONIC_RAW)
+ * Epoch: Arbitrary (System boot time).
+ * Continuity: Strictly monotonic; no leap seconds.
+ * Discipline: Raw hardware oscillator; no frequency steering
+ * or discipline.
+ */
+ PTP_TIMESCALE_MONOTONIC_RAW = 7,
+
+ /**
+ * Boot Time System Clock (CLOCK_BOOTTIME)
+ * Epoch: Arbitrary (System boot time).
+ * Continuity: Strictly monotonic and continuous; no leap seconds.
+ * Discipline: Frequency steered to match system reference;
+ * advances during suspend.
+ */
+ PTP_TIMESCALE_BOOTTIME = 8,
+
+ /********************** Vendor-Specific Timescale *********************/
+
+ /* A proprietary or vendor-specific timescale with custom rules. */
+ PTP_TIMESCALE_PROPRIETARY = 9,
+};
+
/*
* struct ptp_clock_time - represents a time value
*
@@ -94,6 +225,119 @@ struct ptp_clock_time {
__u32 reserved;
};
+/*
+ * Hardware counter identifiers for struct ptp_sys_time.sys_counter_id
+ */
+enum ptp_counter_id {
+ /* Counter value not available or type not specified */
+ PTP_COUNTER_UNKNOWN = 0,
+
+ /* x86 Time Stamp Counter (TSC) */
+ PTP_COUNTER_X86_TSC = 1,
+
+ /* ARM Generic Timer virtual counter */
+ PTP_COUNTER_ARM_ARCH = 2,
+};
+
+/* Valid flags for struct ptp_clock_attrs.valid */
+#define PTP_ATTRS_VALID_ERROR_BOUND (1 << 0)
+#define PTP_ATTRS_VALID_TIMESCALE (1 << 1)
+#define PTP_ATTRS_VALID_STATUS (1 << 2)
+
+/**
+ * struct ptp_clock_attrs - quality attributes for a PHC timestamp
+ *
+ * @valid: Bitmask of PTP_ATTRS_VALID_* indicating which fields
+ * are populated. Zero means no attributes available.
+ * @error_bound: Maximum error in nanoseconds. Valid only when
+ * PTP_ATTRS_VALID_ERROR_BOUND is set.
+ * @timescale: Clock timescale (enum ptp_clock_timescale). Valid only
+ * when PTP_ATTRS_VALID_TIMESCALE is set.
+ * @status: Synchronization status (enum ptp_clock_status). Valid
+ * only when PTP_ATTRS_VALID_STATUS is set.
+ * @rsv: Reserved for future use, must be zero.
+ */
+struct ptp_clock_attrs {
+ __u32 valid;
+ __u32 error_bound;
+ __u32 timescale;
+ __u32 status;
+ __u32 rsv[4];
+};
+
+/**
+ * struct ptp_sys_time - system time snapshot with counter value
+ *
+ * @sys_time: System time in nanoseconds (clock selected by request).
+ * @sys_rawtime: CLOCK_MONOTONIC_RAW time in nanoseconds.
+ * @sys_counter: Raw clocksource counter value (0 = unavailable).
+ * @sys_counter_id: Identifies the counter (enum ptp_counter_id).
+ * @rsv: Reserved for future use, must be zero.
+ */
+struct ptp_sys_time {
+ __s64 sys_time;
+ __s64 sys_rawtime;
+ __u64 sys_counter;
+ __u32 sys_counter_id;
+ __u32 rsv;
+};
+
+/**
+ * struct ptp_dev_time - device timestamp with quality attributes
+ *
+ * @device_time: PHC timestamp value.
+ * @attrs: Quality attributes for this timestamp.
+ */
+struct ptp_dev_time {
+ struct ptp_clock_time device_time;
+ struct ptp_clock_attrs attrs;
+};
+
+/**
+ * struct ptp_timestamp - a complete timestamp sample
+ *
+ * For PTP_SYS_OFFSET_EXTENDED_ATTRS: pre_systime and post_systime bracket
+ * the device read (ABA sandwich).
+ * For PTP_SYS_OFFSET_PRECISE_ATTRS: only systime (union with pre_systime)
+ * is meaningful; post_systime is zeroed.
+ */
+struct ptp_timestamp {
+ union {
+ struct ptp_sys_time systime;
+ struct ptp_sys_time pre_systime;
+ };
+ struct ptp_dev_time devtime;
+ struct ptp_sys_time post_systime;
+};
+
+/**
+ * struct ptp_attrs_request - request parameters for attrs ioctls
+ *
+ * @valid: Bitmask for future request extensions. Must be zero for now.
+ * @clock_id: Clock base for system timestamps (CLOCK_REALTIME, etc).
+ * @num_samples: Number of timestamp samples requested.
+ * For PTP_SYS_OFFSET_PRECISE_ATTRS must be 1.
+ * @rsv: Reserved for future use, must be zero.
+ */
+struct ptp_attrs_request {
+ __u32 valid;
+ __kernel_clockid_t clock_id;
+ __u32 num_samples;
+ __u32 rsv[3];
+};
+
+/**
+ * struct ptp_sys_offset_attrs - unified data structure for attrs ioctls
+ *
+ * Used by both PTP_SYS_OFFSET_EXTENDED_ATTRS and
+ * PTP_SYS_OFFSET_PRECISE_ATTRS. Userspace allocates space for
+ * request.num_samples entries in the timestamps array.
+ */
+struct ptp_sys_offset_attrs {
+ struct ptp_attrs_request request;
+ struct ptp_timestamp timestamps[];
+};
+
struct ptp_clock_caps {
int max_adj; /* Maximum frequency adjustment in parts per billon. */
int n_alarm; /* Number of programmable alarms. */
@@ -106,7 +350,11 @@ struct ptp_clock_caps {
/* Whether the clock supports adjust phase */
int adjust_phase;
int max_phase_adj; /* Maximum phase adjustment in nanoseconds. */
- int rsv[11]; /* Reserved for future use. */
+ /* Whether the clock supports extended timestamps with attributes */
+ int extended_attrs;
+ /* Whether the clock supports precise cross-timestamps with attributes */
+ int precise_attrs;
+ int rsv[9]; /* Reserved for future use. */
};
struct ptp_extts_request {
@@ -252,6 +500,10 @@ struct ptp_pin_desc {
_IOWR(PTP_CLK_MAGIC, 21, struct ptp_sys_offset_precise)
#define PTP_SYS_OFFSET_EXTENDED_CYCLES \
_IOWR(PTP_CLK_MAGIC, 22, struct ptp_sys_offset_extended)
+#define PTP_SYS_OFFSET_PRECISE_ATTRS \
+ _IOWR(PTP_CLK_MAGIC, 23, struct ptp_sys_offset_attrs)
+#define PTP_SYS_OFFSET_EXTENDED_ATTRS \
+ _IOWR(PTP_CLK_MAGIC, 24, struct ptp_sys_offset_attrs)
struct ptp_extts_event {
struct ptp_clock_time t; /* Time event occurred. */
--
2.47.3
^ permalink raw reply related
* [PATCH v4 net-next 0/7] ptp: Add PHC timestamp quality attributes
From: Arthur Kiyanovski @ 2026-07-14 2:03 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, netdev
Cc: Arthur Kiyanovski, Richard Cochran, Eric Dumazet, Paolo Abeni,
David Woodhouse, Thomas Gleixner, Miroslav Lichvar, Andrew Lunn,
Wen Gu, Xuan Zhuo, David Woodhouse, Yonatan Sarna,
Zorik Machulsky, Alexander Matushevsky, Saeed Bshara, Matt Wilson,
Anthony Liguori, Nafea Bshara, Evgeny Schmeilin, Netanel Belgazal,
Ali Saidi, Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
vadim.fedorenko
This series adds quality attributes to PTP Hardware Clock (PHC)
timestamps, allowing userspace to obtain error bound, clock status,
timescale, and system counter values alongside timestamps in a single
call.
Motivation
----------
The existing PTP APIs return timestamps without any indication of
their quality. Applications that need clock accuracy and
synchronization status commonly rely on external tools such as
ptp4l, which implement synchronization logic and can export their
measurement of clock accuracy. For managed PHC devices — such as
the ENA network adapter, whose clock is synchronized by the device
without userspace involvement — these tools are not available, and
the existing APIs lack a way to report quality metrics to consumers
of time.
This was previously proposed as an RFC [1] with a single ioctl.
Based on community feedback, the design was reworked to cover both
the extended (multi-sample) and precise (cross-timestamp) paths.
Design
------
The UAPI was redesigned based on Thomas Gleixner's proposal [2]:
- A unified data structure (struct ptp_sys_offset_attrs) is used
for both extended and precise ioctls.
- A u32 valid bitmask in struct ptp_clock_attrs indicates which
attributes are populated, replacing sentinel values. Drivers
set only the bits for attributes they provide.
- System counter values (cycles + counter_id) are carried in
struct ptp_sys_time alongside each system timestamp. These are
populated by the timekeeping core cross-timestamp infrastructure,
which is now merged in net-next [3] — drivers do not fill them.
This series therefore applies directly to net-next with no
out-of-tree dependency.
- Graceful degradation: the attrs ioctls work even on devices
without attrs callbacks, falling back to gettimex64 /
getcrosststamp and returning attrs.valid = 0.
A capability flag is added to ptp_clock_caps so userspace can
discover attributes support.
Patches 2-3 add testptp support for the new ioctls.
Patch 4 implements the attributes for ptp_vmclock, reporting
error bound, clock status, and timescale.
Patches 5-7 implement the attributes for the ENA driver,
reporting error bound from the device's PHC layer.
v4:
- Complete UAPI redesign per Thomas Gleixner's proposal [2]:
unified data structure with u32 valid bitmask, system counter
in ptp_sys_time (populated by core, not drivers), graceful
degradation for devices without attrs callbacks. (Thomas Gleixner,
David Woodhouse)
- Counter values moved from driver attrs callback to timekeeping
core infrastructure — drivers no longer set counter_id or
counter_value.
- Flexible array member for timestamps[] (kernel bounds the copy,
userspace allocates for num_samples requested).
- Drop separate ptp_clock_attributes kernel struct — driver
callbacks fill the UAPI ptp_clock_attrs directly.
v3:
- Remove patch 5/8 from v2 (return-code bugfix) — sent separately
as [PATCH net] to the net tree.
- Zero-initialize struct ptp_clock_attributes in PTP core ioctl
handlers to prevent stack leak of unset fields. (Simon Horman,
sashiko)
- ptp_vmclock: validate counter_period_shift < 128 to prevent
undefined behavior on untrusted hypervisor input. (sashiko)
- ptp_vmclock: add overflow check on err_hi * NSEC_PER_SEC to
prevent silent wraparound producing erroneously small error
bound. (sashiko)
- ptp_vmclock: report PTP_TIMESCALE_TAI after tai_adjust() to
avoid timescale mismatch. (sashiko)
- ENA: set counter_id = 0, counter_value = 0 in gettimexattrs64
for defense-in-depth. (sashiko)
v2:
- Fix build bisectability: move ena_com.c consumer updates into
patch 6/8 and ena_phc.c caller update into patch 7/8 so each
patch compiles independently.
- Add missing Cc for Amit Bernstein (co-author of ENA patches).
[1] https://lore.kernel.org/netdev/20250724115657.150-1-darinzon@amazon.com/
[2] https://lore.kernel.org/all/87se7ht25o.ffs@tglx/
[3] https://lore.kernel.org/all/20260526165826.392227559@kernel.org/
Arthur Kiyanovski (7):
ptp: Add ioctls for PHC timestamps with quality attributes
selftests/ptp: Extract print_system_timestamp helper in testptp
selftests/ptp: Add testptp support for attributes ioctls
ptp: ptp_vmclock: Implement attributes ioctls
net: ena: Update PHC admin interface for error bound support
net: ena: Add error bound to PHC communication layer
net: ena: Implement gettimexattrs64 callback for PTP attributes
.../device_drivers/ethernet/amazon/ena.rst | 2 +
.../net/ethernet/amazon/ena/ena_admin_defs.h | 17 +-
drivers/net/ethernet/amazon/ena/ena_com.c | 51 ++--
drivers/net/ethernet/amazon/ena/ena_com.h | 5 +-
drivers/net/ethernet/amazon/ena/ena_debugfs.c | 3 +
drivers/net/ethernet/amazon/ena/ena_phc.c | 61 ++++-
drivers/ptp/ptp_chardev.c | 166 +++++++++++-
drivers/ptp/ptp_clock.c | 4 +-
drivers/ptp/ptp_vmclock.c | 197 ++++++++++++--
include/linux/ptp_clock_kernel.h | 30 +++
include/uapi/linux/ptp_clock.h | 254 +++++++++++++++++-
tools/testing/selftests/ptp/testptp.c | 181 ++++++++++---
12 files changed, 862 insertions(+), 109 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: What's cooking in zh_CN (Jul 2026)
From: Alex Shi @ 2026-07-14 2:03 UTC (permalink / raw)
To: Weijie Yuan, linux-doc
Cc: Alex Shi, Yanteng Si, Dongliang Mu, Ben Guo, Gary Guo, Yan Zhu,
Doehyun Baek, Jiandong Qiu, chengyaqiang
In-Reply-To: <alUXH8qRRjno2eZG@wyuan.org>
On 2026/7/14 00:49, Weijie Yuan wrote:
> Hi all,
>
> Since I made many noise these days on the list, which took up a lot of
> maintainers' time. This email summarizes the patches for zh_CN that are
> currently pending on the mailing list.
>
It's a great summary.
Contribution isn't only from submit patches, but also from actively
document build, review, status update!
Thanks for you all!
^ permalink raw reply
* [PATCH 2/2] doc: LSM: fix module ordering description for /sys/kernel/security/lsm
From: Lincoln Wallace @ 2026-07-14 1:38 UTC (permalink / raw)
To: paul, corbet
Cc: skhan, linux-doc, linux-kernel, linux-security-module,
penguin-kernel, rdunlap, Lincoln Wallace
In-Reply-To: <20260714013832.977443-1-locnnil0@gmail.com>
The LSM usage document states that the capability module will always
be first in /sys/kernel/security/lsm, followed by any "minor" modules
and then the one "major" module.
This does not match the current LSM infrastructure:
- When CONFIG_SECURITY_LOCKDOWN_LSM_EARLY is enabled, lockdown is
initialized as an early LSM, before all other modules including
capability, and appears first in the list.
- The integrity modules (e.g. IMA and EVM) register with
LSM_ORDER_LAST and are always placed at the end of the list,
regardless of the position of the major module.
- The relative order of the remaining modules is not fixed by the
framework; it follows CONFIG_LSM or the "lsm=" kernel command
line parameter.
Rewrite the paragraph to describe the actual ordering: lockdown
first when early lockdown is enabled, capability otherwise,
integrity modules at the end, and the remaining modules in the
configured order.
Signed-off-by: Lincoln Wallace <locnnil0@gmail.com>
---
Documentation/admin-guide/LSM/index.rst | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/LSM/index.rst b/Documentation/admin-guide/LSM/index.rst
index c24310c709dc..9518495edfbc 100644
--- a/Documentation/admin-guide/LSM/index.rst
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -27,9 +27,15 @@ man-pages project.
A list of the active security modules can be found by reading
``/sys/kernel/security/lsm``. This is a comma separated list, and
will always include the capability module. The list reflects the
-order in which checks are made. The capability module will always
-be first, followed by any "minor" modules (e.g. Yama) and then
-the one "major" module (e.g. SELinux) if there is one configured.
+order in which checks are made. The capability module will be
+first, unless CONFIG_SECURITY_LOCKDOWN_LSM_EARLY is enabled, in
+which case the lockdown module will precede it. The integrity
+modules (e.g. IMA and EVM), if enabled in the kernel
+configuration, are always placed at the end of the list. Any
+other "minor" modules (e.g. Yama) and the one "major" module
+(e.g. SELinux), if there is one configured, appear in between,
+in the order given by CONFIG_LSM or the ``"lsm=..."`` kernel
+command line parameter.
Process attributes associated with "major" security modules should
be accessed and maintained using the special files in ``/proc/.../attr``.
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] doc: LSM: describe CONFIG_LSM and lsm= as the selection mechanism
From: Lincoln Wallace @ 2026-07-14 1:38 UTC (permalink / raw)
To: paul, corbet
Cc: skhan, linux-doc, linux-kernel, linux-security-module,
penguin-kernel, rdunlap, Lincoln Wallace
In-Reply-To: <20260714013832.977443-1-locnnil0@gmail.com>
The LSM usage document states that security modules are selectable at
build time via CONFIG_DEFAULT_SECURITY and can be overridden at boot
time via the "security=..." kernel command line argument.
CONFIG_DEFAULT_SECURITY no longer exists: LSMs are enabled via
CONFIG_LSM, an ordered list of the LSMs to initialize, which can be
overridden at boot time with the "lsm=" parameter. The "security="
parameter remains as a deprecated way to choose a legacy "major"
security module, and is ignored when "lsm=" is specified; see commit
89a9684ea158 ("LSM: Ignore "security=" when "lsm=" is specified").
A previous attempt replaced "security=" with "lsm=" in place [1],
which was rejected because the parameters are not equivalent:
"security=" selects a single major module while the built-in
CONFIG_LSM list otherwise remains active, whereas "lsm=" must list
every LSM to enable.
Update the paragraph to describe CONFIG_LSM and "lsm=" as the current
selection mechanism, keeping "security=" documented as the deprecated
legacy option, matching the wording in kernel-parameters.txt.
Link: https://lore.kernel.org/r/20250114225156.10458-1-rdunlap@infradead.org [1]
Signed-off-by: Lincoln Wallace <locnnil0@gmail.com>
---
Documentation/admin-guide/LSM/index.rst | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/LSM/index.rst b/Documentation/admin-guide/LSM/index.rst
index b44ef68f6e4d..c24310c709dc 100644
--- a/Documentation/admin-guide/LSM/index.rst
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -6,9 +6,11 @@ The Linux Security Module (LSM) framework provides a mechanism for
various security checks to be hooked by new kernel extensions. The name
"module" is a bit of a misnomer since these extensions are not actually
loadable kernel modules. Instead, they are selectable at build-time via
-CONFIG_DEFAULT_SECURITY and can be overridden at boot-time via the
-``"security=..."`` kernel command line argument, in the case where multiple
-LSMs were built into a given kernel.
+CONFIG_LSM, an ordered list of the LSMs to enable, and can be
+overridden at boot-time via the ``"lsm=..."`` kernel command line
+argument. The ``"security=..."`` kernel command line argument remains
+available to choose a legacy "major" security module, but has been
+deprecated by the ``"lsm=..."`` parameter.
The primary users of the LSM interface are Mandatory Access Control
(MAC) extensions which provide a comprehensive security policy. Examples
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] doc: LSM: update usage document for current LSM stacking
From: Lincoln Wallace @ 2026-07-14 1:38 UTC (permalink / raw)
To: paul, corbet
Cc: skhan, linux-doc, linux-kernel, linux-security-module,
penguin-kernel, rdunlap, Lincoln Wallace
The LSM usage document (Documentation/admin-guide/LSM/index.rst) has
not kept up with the LSM stacking infrastructure. It still describes
CONFIG_DEFAULT_SECURITY, which no longer exists, and its description
of the module ordering in /sys/kernel/security/lsm does not match
what the framework actually does.
Patch 1 updates the selection mechanism description to CONFIG_LSM and
the "lsm=" parameter, keeping "security=" documented as the deprecated
legacy option. This revisits an earlier attempt by Randy Dunlap [1]
that was rejected for treating the two parameters as equivalent; the
new text keeps them distinct.
Patch 2 fixes the ordering description: lockdown precedes capability
when CONFIG_SECURITY_LOCKDOWN_LSM_EARLY is enabled, the integrity
modules are always placed at the end of the list, and the remaining
modules follow the order given by CONFIG_LSM or "lsm=".
[1] https://lore.kernel.org/r/20250114225156.10458-1-rdunlap@infradead.org
Lincoln Wallace (2):
doc: LSM: describe CONFIG_LSM and lsm= as the selection mechanism
doc: LSM: fix module ordering description for /sys/kernel/security/lsm
Documentation/admin-guide/LSM/index.rst | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH RESEND 0/3] x86/vdso: Improve vdso=/vdso32= boot parameter validation
From: Dave Hansen @ 2026-07-13 23:40 UTC (permalink / raw)
To: Thorsten Blum, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Andrew Morton,
Jonathan Corbet, Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel
In-Reply-To: <20260713233422.127348-5-thorsten.blum@linux.dev>
On 7/13/26 16:34, Thorsten Blum wrote:
> Replace the deprecated simple_strtoul() [1] with kstrtouint() when
> parsing the vDSO boot parameters. This provides strict input validation,
> rejects partial input, and warns when disabling vDSO for invalid values.
Hey Thorsten,
I'm curious what motivated this change. Were you trying to manipulate
the VDSO and ran into some difficulties? Or is it a larger effort to
audit and simple_strtoul() users?
^ permalink raw reply
* Re: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device passthrough
From: Alex Williamson @ 2026-07-13 23:37 UTC (permalink / raw)
To: Manish Honap
Cc: djbw@kernel.org, jgg@ziepe.ca, jic23@kernel.org,
dave.jiang@intel.com, Ankit Agrawal,
alejandro.lucero-palau@amd.com, alison.schofield@intel.com,
dave@stgolabs.net, dmatlack@google.com, gourry@gourry.net,
ira.weiny@intel.com, Neo Jia, Krishnakant Jaju, Vikram Sethi,
Zhi Wang, kvm@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, alex
In-Reply-To: <IA1PR12MB9030E175587B09CEA7A4D90FBDFA2@IA1PR12MB9030.namprd12.prod.outlook.com>
On Mon, 13 Jul 2026 16:44:53 +0000
Manish Honap <mhonap@nvidia.com> wrote:
> > -----Original Message-----
> > From: Alex Williamson <alex@shazbot.org>
> > Sent: 11 July 2026 03:53
> > On Thu, 25 Jun 2026 22:24:01 +0530
> > <mhonap@nvidia.com> wrote:
> > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > index 5de618a3a5ee..3707d53c4de5 100644
> > > --- a/include/uapi/linux/vfio.h
> > > +++ b/include/uapi/linux/vfio.h
> > > @@ -215,6 +215,7 @@ struct vfio_device_info {
> > > #define VFIO_DEVICE_FLAGS_FSL_MC (1 << 6) /* vfio-fsl-mc device */
> > > #define VFIO_DEVICE_FLAGS_CAPS (1 << 7) /* Info supports
> > caps */
> > > #define VFIO_DEVICE_FLAGS_CDX (1 << 8) /* vfio-cdx
> > device */
> > > +#define VFIO_DEVICE_FLAGS_CXL (1 << 9) /* vfio-cxl
> > Type-2 device */
> >
> > Would we define a different flag for type-1/3 if we ever found a need to
> > expose them through vfio?
>
> Yes. The current flag is named VFIO_DEVICE_FLAGS_CXL and refers to
> Type-2 specifically. If Type-1 or Type-3 support is added later, a
> separate flag (or a VFIO_DEVICE_INFO_CAP sub-type field) would
> distinguish them. I can rename it VFIO_DEVICE_FLAGS_CXL_TYPE2 now if
> that is preferable; please advise.
I'd keep the broader flag, CXL, and use the device info capability to
zero in on the specific features we're trying to expose that can't be
readily obtained through DVSEC or needs a mechanism within the vfio
uAPI. Thanks,
Alex
^ permalink raw reply
* [PATCH RESEND 3/3] Documentation/arch/x86: Remove obsolete vdso32=2 compatibility note
From: Thorsten Blum @ 2026-07-13 23:34 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
In-Reply-To: <20260713233422.127348-5-thorsten.blum@linux.dev>
Commit b0b49f2673f0 ("x86, vdso: Remove compat vdso support") removed
compat vDSO support and documented vdso32=2 as an alias for vdso32=0.
However, since commit c06989da39cd ("x86/vdso: Ensure vdso32_enabled
gets set to valid values only"), vdso32_setup() accepts only 0 and 1.
Remove the obsolete vdso32=2 compatibility note and document only the
supported values.
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Documentation/admin-guide/kernel-parameters.txt | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b5493a7f8f22..8a55ec37d066 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -8260,15 +8260,12 @@ Kernel parameters
vdso32= [X86] Control the 32-bit vDSO
vdso32=1: enable 32-bit VDSO
- vdso32=0 or vdso32=2: disable 32-bit VDSO
+ vdso32=0: disable 32-bit VDSO
See the help text for CONFIG_COMPAT_VDSO for more
details. If CONFIG_COMPAT_VDSO is set, the default is
vdso32=0; otherwise, the default is vdso32=1.
- For compatibility with older kernels, vdso32=2 is an
- alias for vdso32=0.
-
Try vdso32=0 if you encounter an error that says:
dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
^ permalink raw reply related
* [PATCH RESEND 2/3] x86/vdso: Use kstrtouint() to validate vdso32= boot parameter
From: Thorsten Blum @ 2026-07-13 23:34 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
In-Reply-To: <20260713233422.127348-5-thorsten.blum@linux.dev>
Replace the deprecated simple_strtoul() with kstrtouint() when parsing
the vdso32= boot parameter and its X86_32 vdso= alias.
simple_strtoul() accepts partial input and silently converts invalid
input to 0. Use kstrtouint() for strict input validation instead and
reject malformed input. Accept only 0 and 1; warn and disable vDSO
support otherwise.
kstrtouint() converts the input string directly to an unsigned int,
avoiding an implicit conversion when assigning to vdso32_enabled.
Update the vdso32= handler comment to reflect the supported values.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/x86/entry/vdso/vdso32-setup.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso32-setup.c b/arch/x86/entry/vdso/vdso32-setup.c
index 8894013eea1d..5f3e548ebf19 100644
--- a/arch/x86/entry/vdso/vdso32-setup.c
+++ b/arch/x86/entry/vdso/vdso32-setup.c
@@ -30,10 +30,8 @@ unsigned int __read_mostly vdso32_enabled = VDSO_DEFAULT;
static int __init vdso32_setup(char *s)
{
- vdso32_enabled = simple_strtoul(s, NULL, 0);
-
- if (vdso32_enabled > 1) {
- pr_warn("vdso32 values other than 0 and 1 are no longer allowed; vdso disabled\n");
+ if (kstrtouint(s, 0, &vdso32_enabled) || vdso32_enabled > 1) {
+ pr_warn("vdso32= values other than 0 and 1 are invalid; vdso disabled\n");
vdso32_enabled = 0;
}
@@ -41,9 +39,9 @@ static int __init vdso32_setup(char *s)
}
/*
- * For consistency, the argument vdso32=[012] affects the 32-bit vDSO
+ * For consistency, the argument vdso32=[01] affects the 32-bit vDSO
* behavior on both 64-bit and 32-bit kernels.
- * On 32-bit kernels, vdso=[012] means the same thing.
+ * On 32-bit kernels, vdso=[01] means the same thing.
*/
__setup("vdso32=", vdso32_setup);
^ permalink raw reply related
* [PATCH RESEND 1/3] x86/vdso: Use kstrtouint() to validate vdso= boot parameter
From: Thorsten Blum @ 2026-07-13 23:34 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
In-Reply-To: <20260713233422.127348-5-thorsten.blum@linux.dev>
Replace the deprecated simple_strtoul() with kstrtouint() when parsing
the vdso= boot parameter.
simple_strtoul() accepts partial input and silently converts invalid
input to 0. Use kstrtouint() for strict input validation instead and
reject malformed input. Accept only 0 and 1; warn and disable vDSO
support otherwise.
kstrtouint() converts the input string directly to an unsigned int,
avoiding an implicit conversion when assigning to vdso64_enabled.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/x86/entry/vdso/vma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 18dfd80a81ef..c5c09c28388e 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -299,7 +299,11 @@ bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
#ifdef CONFIG_X86_64
static __init int vdso_setup(char *s)
{
- vdso64_enabled = simple_strtoul(s, NULL, 0);
+ if (kstrtouint(s, 0, &vdso64_enabled) || vdso64_enabled > 1) {
+ pr_warn("vdso= values other than 0 and 1 are invalid; vdso disabled\n");
+ vdso64_enabled = 0;
+ }
+
return 1;
}
__setup("vdso=", vdso_setup);
^ permalink raw reply related
* [PATCH RESEND 0/3] x86/vdso: Improve vdso=/vdso32= boot parameter validation
From: Thorsten Blum @ 2026-07-13 23:34 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
Replace the deprecated simple_strtoul() [1] with kstrtouint() when
parsing the vDSO boot parameters. This provides strict input validation,
rejects partial input, and warns when disabling vDSO for invalid values.
Adjust both warnings for consistency and update the documentation.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull
Thorsten Blum (3):
x86/vdso: Use kstrtouint() to validate vdso= boot parameter
x86/vdso: Use kstrtouint() to validate vdso32= boot parameter
Documentation/arch/x86: Remove obsolete vdso32=2 compatibility note
Documentation/admin-guide/kernel-parameters.txt | 5 +----
arch/x86/entry/vdso/vdso32-setup.c | 10 ++++------
arch/x86/entry/vdso/vma.c | 6 +++++-
3 files changed, 10 insertions(+), 11 deletions(-)
base-commit: 979c294509f9248fe1e7c358d582fb37dd5ca12d
^ permalink raw reply
* Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
From: Marek Vasut @ 2026-07-13 18:05 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Marc Zyngier, linux-pci, kernel test robot,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring,
Yoshihiro Shimoda, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260713175400.GA1258926@bhelgaas>
On 7/13/26 7:54 PM, Bjorn Helgaas wrote:
> On Fri, Jul 10, 2026 at 03:35:10PM +0200, Marek Vasut wrote:
>> On 7/10/26 10:30 AM, Marc Zyngier wrote:
>>> On Thu, 09 Jul 2026 21:10:03 +0100,
>>> Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>>>>
>>>> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h ,
>>>> copy the one GITS_TRANSLATER register offset macro directly into
>>>> the driver. This repairs the ability to build the driver on
>>>> non-ARM non-GIC targets the way it was possible until now, which
>>>> retains good build test coverage.
>> ...
>
>> So in the end, it is either this patch or limit the build to
>> arm/arm64 . At least this patch still allows building this driver
>> with more compilers on the various build bots, so I would opt for
>> this patch here.
>
> I like the build coverage, but duplicating the #define doesn't really
> seem good to me. It makes readability worse because cscope/tags now
> sees two definitions without an obvious reason.
I can rename the macro, or ... sigh ... I can reduce the driver to build
only on ARM/ARM64. Which one do you prefer ?
^ permalink raw reply
* Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
From: Marek Vasut @ 2026-07-13 16:20 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-pci, kernel test robot, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <87fr1m6hma.wl-maz@kernel.org>
On 7/13/26 5:20 PM, Marc Zyngier wrote:
> On Fri, 10 Jul 2026 14:35:10 +0100,
> Marek Vasut <marek.vasut@mailbox.org> wrote:
>>
>> On 7/10/26 10:30 AM, Marc Zyngier wrote:
>>> On Thu, 09 Jul 2026 21:10:03 +0100,
>>> Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>>>>
>>>> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h , copy the
>>>> one GITS_TRANSLATER register offset macro directly into the driver.
>>>> This repairs the ability to build the driver on non-ARM non-GIC targets
>>>> the way it was possible until now, which retains good build test coverage.
>>>>
>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>> Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>>>> ---
>>>> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
>>>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: Conor Dooley <conor+dt@kernel.org>
>>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>>>> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
>>>> Cc: Manivannan Sadhasivam <mani@kernel.org>
>>>> Cc: Marc Zyngier <maz@kernel.org>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>>>> Cc: devicetree@vger.kernel.org
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-doc@vger.kernel.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: linux-pci@vger.kernel.org
>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>> ---
>>>> Note: The alternative I could think of would be ifdeffery which
>>>> is not nice and thwarts the build coverage, or limit the
>>>> driver to ARM/ARM64 in Kconfig which also thwarts the build
>>>> coverage. I could also split off the register macros in
>>>> linux/irqchip/arm-gic-v3.h into some separate header
>>>> linux/irqchip/arm-gic-v3-regs.h and include that which
>>>> might be OKish and avoids duplication. Thoughts ?
>>>
>>> No, I'm not hacking something that is purely architecture specific for
>>> the purpose of a bizarre integration quirk that should be handled by
>>> the boot firmware, and not Linux.
>>
>> The PCIe controller is fully controlled by Linux.
>
> And it shouldn't. Why can't your favourite boot-loader use it, like on
> any reasonable machine?
Because U-Boot is designed to boot as quickly as possible and get out of
the way, which means lazy initialization of any and all resources, which
means skip initialization of any and all hardware that is not needed to
boot the machine. It is one of the core design decisions behind the
U-Boot driver model [1].
The R-Car V4H using mainline U-Boot can boot from PCIe/NVMe SSD, but
that is purely optional and some users might instead boot from SD cards
or eMMCs, and even then the PCIe hardware is shut down before booting
the OS to prevent any issues during OS boot or reinitialization by the OS.
[1]
https://git.u-boot-project.org/u-boot/u-boot/-/blob/main/doc/develop/driver-model/design.rst?ref_type=heads&plain=1#L794
^ permalink raw reply
* Re: [PATCH v8 5/8] drm/nouveau: Use hmm_range_fault_unlocked_timeout() for SVM faults
From: Andrew Morton @ 2026-07-13 23:18 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alUZZYIPY-UkhpY4@skinsburskii>
On Mon, 13 Jul 2026 09:59:17 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > > I'm not sure... The "timeout - jiffies" can become negative.
> > > Won't 1UL convert both of them to "UL" and thus make the comparison
> > > overflow?
> >
> > `timeout' and `jiffies' are both unsigned long.
>
> Yeah, I’m sorry for the sloppy wording.
>
> What I meant was: will "max(timeout - jiffies, 1UL)" correctly handle
> the case where jiffies < timeout?
That will return `timeout - jiffies': a smallish positive number.
I'm not sure what's intended here. Perhaps the code should be
using time_after() or similar?
^ permalink raw reply
* RE: [PATCH v2 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub
From: Ousherovitch, Alex @ 2026-07-13 23:17 UTC (permalink / raw)
To: Conor Dooley
Cc: Conor Dooley, Krishnamoorthy, Saravanakrishnan, Albert Ou,
Conor Dooley, David S. Miller, Herbert Xu, Jonathan Corbet,
Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley, Rob Herring,
Shuah Khan, Alexandre Ghiti, devicetree@vger.kernel.org,
Wittenauer, Joel, linux-api@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-riscv@lists.infradead.org, Shuah Khan, Nguyen, Thi
In-Reply-To: <20260712-washable-clapping-5dfb79d1bdef@spud>
On Sun, Jul 12, 2026 at 06:16, Conor Dooley <conor@kernel.org> wrote:
> Please fix your quoting, you need to retain context beyond what I said
> so that people who get 100s of mails per day (me) remember what it was
> in response to.
Apologies -- retained the context here, and I'll keep it in future
replies.
Short version: v3 switches the vendor prefix to "rambus", makes each
mailbox a subnode with its own reg (as agreed), adds a device-specific
compatible, and adds clocks + an optional reset. One property (the VCQ
ring geometry) I'd like to keep in DT -- reasoning below, happy to be
overruled.
> > > This company no longer exists, you should probably introduce a
> > > rambus vendor prefix instead.
> >
> > Cryptography Research, Inc. does still exist -- it's now a
> > wholly-owned subsidiary of Rambus (our co-maintainer is
> > @cryptography.com). The prefix names the IP originator, which is
> > consistent with existing subsidiary/acquired-vendor prefixes in the
> > tree (e.g. al = Annapurna Labs under Amazon, mstar noted as acquired
> > by MediaTek, fsl, cavium, xlnx). We'd prefer to keep "cri" on that
> > basis, and can annotate the description as "Cryptography Research,
> > Inc. (a Rambus company)" to make the ownership explicit. Happy to
> > switch if you feel strongly.
>
> I'm not sure that these examples actually aid your cause. al has been
> replaced by amazon, fsl is not used for new devices, new xlnx devices
> use amd (only example for now is the riscv stuff I think), cavium has
> had nothing added in donkey's years etc. mstar I don't see anything
> new in years either.
Fair enough -- point taken. v3 uses a "rambus" vendor prefix (added to
vendor-prefixes.yaml) and drops "cri". The description still credits
Cryptography Research, Inc. as the IP originator.
> > > This whole subnode thing seems like it is only required because you
> > > don't have device-specific compatibles [cores].
> >
> > Core presence is actually discoverable at runtime from the
> > CORE_ENABLE register, so v3 will drop the per-core child nodes
> > entirely and probe for enabled cores -- no per-variant compatible
> > needed.
>
> No, per-variant compatibles (for the devices/socs that this IP is
> integrated into) are a requirement. While it would have been handy for
> detecting capabilities, it's a requirement for other reasons:
> differences between integrations be that functional or enforcing the
> correct constraints on properties, issues only present on select
> devices, etc.
Agreed, and done. Runtime CORE_ENABLE probing stays only for capability
detection; it does not replace the compatible. v3 adds a device-specific
compatible keyed to the IP revision:
compatible = "rambus,cmh-v1030";
with an SoC integration expected to list its own compatible first and
fall back to the IP one:
compatible = "<vendor>,<soc>-cmh", "rambus,cmh-v1030";
This follows the pattern already used for licensable security IP, e.g.
inside-secure,safexcel-eip197b and arm,cryptocell-712-ree.
> On that note, I see there's no clocks or resets properties added by
> your patch. While the IP may not have a reset (although I suspect it
> probably does) there's no way it functions without a clock.
Correct on both. v3 adds them:
- clocks: the hub has a main functional input clock (plus, on
side-channel-core configurations, a half-rate variant, and a
real-time-tick clock). The block gates its clocks internally, so the
host doesn't gate them -- the property just describes the input
pin(s). Where a secure power controller owns the clock and Linux has
no handle, it's absent, as drivers/crypto/xilinx/zynqmp-* do.
- reset: the hub has two external, active-low reset inputs -- a power-on
reset and a hard reset. On an integration these are top-level wires
driven by a reset controller in the management domain, not by Linux.
Where the Linux host is the management host and one of those lines is
exposed to it as a GPIO, v3 describes it via reset-gpios; otherwise
it's absent and Linux doesn't reset the block.
> > > This looks like it should be deducible from a device-specific
> > > compatible. [slots/strides]
> >
> > These aren't fixed per silicon -- they're the per-mailbox layout of
> > the VCQ rings in host DMA memory, chosen at platform integration and
> > programmed by the driver into the mailbox QUEUE/SLOTS/STRIDE
> > registers. They can differ per mailbox on the same silicon, so a
> > compatible can't encode them. v3 will keep them as optional,
> > defaulted properties on the per-mailbox subnodes.
>
> I'm not sure. Unless there's more than one instance, this definitely
> sounds like something that you can determine from the compatible.
> Generally these kinds of accelerators tend not to have multiple
> instances though, so each platform will have a different compatible,
> and the driver can store an array of mailbox configurations.
This is the one I'd like to keep in DT. The slot count and stride are
the host-DMA ring geometry the driver programs into QUEUE_SLOTS /
QUEUE_STRIDE at probe. They're fixed neither by the silicon nor by the
integration: the same SoC (same compatible) ships to multiple customers
who provision different amounts of host memory for the rings, and a
customer may tune it further per board -- so two boards can share a
compatible yet need different geometry. They're optional with defaults
(6 / 9), so the common case sets nothing.
The reason I reached for DT is that the alternatives are each worse for
a per-board value that has to be known at probe: per-compatible
match_data means a new compatible and a driver patch for every board
that tunes it (two boards on the same SoC can't differ), and a module
parameter is exactly the sort of global knob I'd expect you'd rather not
add. DT lets the integrator set it without touching the driver. If you'd
still prefer one of those, tell me which and I'll switch.
> > > this could probably be handled via reg-names? [affinity]
> >
> > Yes -- v3 will express affinity per mailbox (a "role" of a specific
> > core type for a dedicated mailbox, or "generic" for the round-robin
> > pool), which is the subnode analog of your reg-names idea. One
> > caveat: this cleanly covers 1:1 core-to-mailbox dedication plus a
> > shared pool; a mailbox dedicated to several specific cores would need
> > multiple role tokens.
Following up on my own reply: I kept an explicit core-ID affinity list
on each mailbox node rather than roles/reg-names. As the caveat above
hinted, roles get awkward once a mailbox serves several cores, and they
can't distinguish separate instances of the same core type -- the core
ID handles both, and the driver would map a role back to an ID anyway.
Thanks for the review,
Alex
^ permalink raw reply
* Re: [PATCH v5 00/23] Introduce SCMI Telemetry support
From: Cristian Marussi @ 2026-07-13 22:54 UTC (permalink / raw)
To: Fayssal Benmlih
Cc: Cristian Marussi, arm-scmi@vger.kernel.org, brauner@kernel.org,
d-gole@ti.com, david@kernel.org, Elif Topuz,
etienne.carriere@st.com, f.fainelli@gmail.com,
james.quinlan@broadcom.com, jic23@kernel.org, kas@kernel.org,
kernel-team@meta.com, leitao@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Lukasz Luba, michal.simek@amd.com,
peng.fan@oss.nxp.com, Philip Radford, puranjay@kernel.org,
Souvik Chakravarty, sudeep.holla@kernel.org, usama.arif@linux.dev,
vincent.guittot@linaro.org
In-Reply-To: <DB9PR08MB86516141C5970B23D7340510FFFE2@DB9PR08MB8651.eurprd08.prod.outlook.com>
On Thu, Jul 09, 2026 at 03:46:23AM +0100, Fayssal Benmlih wrote:
> Overall, v5 is a good direction: dropping the filesystem ABI for a
> chardev/ioctl ABI is simpler, easier to version, and more appropriate
> for high-rate telemetry. The split between SCMI protocol support, UAPI,
Hi Fayçal,
in fact this same IOCTLs based interface (even if more rough) was also present in
the defunct FS approach, attached to the special 'control' files...nothing new
really...but a lot of rework and testing needed for sure...
> driver, docs, and test tool is also much cleaner. The main concern is
> that there are several correctness and usability issues that should be
> fixed before merge.
... of course, since this is the first ever posting with the IOCTLs being
the main and only ABI, it was never meant to be straight away ready for merge,
as I mentioned in the cover-letter there are a few TBD still pending and a
lot of cleanups as reported by the LLM reviews too... Sashiko is one great
example of existing LLM reviewing Kernel patches...
...some of these points are pretty much valid (also Sashiko has a few more
complaints) and I will take care of those....but some other are compeletely
OR slightly off, I will go through those in the following...
>
> Must-Fix Issues
> * scmi_tlm_to_uapi_base_info() uses out->flags |= ... on an
> uninitialized local struct scmi_tlm_base_info base; this can leak
> garbage flags. Use out->flags = ... or zero-initialize base.
> * scmi_tlm_update_interval.exp is documented and used as signed, but
> the UAPI declares it as __u32. It should be __s32, otherwise
> examples like exp = -3 are ABI-broken.
> * Group bounds checks use grp_id > num_groups; they should use grp_id
> >= num_groups to avoid out-of-bounds access.
> * Avoid casting UAPI integer fields to bool *, especially __u32
> enable/t_enable in scmi_tlm_de_config. Use local bool enable =
> !!tcfg.enable; variables and copy normalized values back explicitly
> if needed.
> * Array sizes from userspace need overflow and allocation hardening:
> use array_size(), kvmalloc_array(), and clear max limits for
> num_des, num_samples, num_grps, etc.
I really dont understand this, since the user allocates the buffers, that he
then provides via a __u64 ptr, and such allocation happens based on the maximum
number of items the platform has declared to exist (like num_des) so if the user
itself had lied or mistakenly provided a smaller buffer then declared, that is a
user problem that will trapped and result in a SIGSEGV (or a userspace malloc
corruption)...here a specific reference to the actual code causing the supposed
issue would have helped...
> * SCMI_TLM_GET_SHMTI_LIST loops over the user-provided count after
> only checking it is not too small; if it is too large it can read
> beyond in->shmtis[]. Loop over the actual firmware count.
Yes I definitely loop mistakenly on the wrong variable, BUT the missing
check on the too-large condition is an explicit design decision so that
userspace can optionally use the same common big buffer as a scratch
buffer to collect multiple kind of enumeration data...but of course the
loop must happen on the what is available in system NOT on what the user
has passed in...
> * The mmap path needs tighter validation: reject oversized mappings,
> handle mmap offsets deliberately, set appropriate VMA flags, and
> document the lifetime/security model for exposed SHMTI memory.
Beside a bit of hardening, I think here the only missing part is documenting
that you get direct RO access to an SCMI Telemetry area and that you are on
your own in how to parse that...format and lifetime is as specified in SCMIv4.0
Cannot do any deliberate offset handling really...any neeed offset is
dynamically discovered and communicated at runtime via SCMI_TLM_GET_SHMTI_LIST
(offset is rarely different than 0, ONLY if FW has NOT exposed such areas as
page aligned)
..probably worth security wise to check that FW shared areas are
properly page aligned (to the max 64k) and that nothing crititical lays
around when not aligned...so that I dont accidentally expose some other
bits of FW...but I cannot really check so much here from kernel Point of
view...mmm...maybe that the surrounding bytes are zeroed by FW ?
>
> Design Feedback
> * No ABI version/capability ioctl. GET_INFO gives protocol/platform
> info, but userspace also needs driver ABI version and supported
> ioctl feature bits.
> * Enumeration is awkward. List ioctls should support a clear two-call
> pattern: call with count 0 to get required count, allocate, call
> again. Returning EINVAL for “buffer too small” is not very
> ergonomic.
Well the only reason I have NOT implemented this idiom is that all of
this enumeration data is basically static RO (at least within the same
boot), so you can know very well in advance how many elements you have
by calling upfront just one single time SCMI_TLM_GET_INFO, instead of
having to issue twice each IOCTL to know how big the input buffer should
be...but I can implement also this idiomatic form in v6 of course as an
alternative mechanism if we want to support the standard/classic idiom...
...it will be certainly less performant by duplicating all IOCTLs calls x 2...
I will probably rework SCMI_TLM_GET_INFO, to be the new SCMI_TLM_GET_ABI_INFO
including version/capability/resource info IOCTLs...so that you can get the ABI
version, lookup feature bits and get the numebr of resources (like it is
now..to size the requests...)
> * No generation counter yet. Userspace needs to detect
> config/resource changes between discovery and read. This should
> probably land with the first ABI.
Yes that is NOT in this version, but it is definitely planned for this
series: there will be a way to read and more importantly some poll
support based on eventfd.
> * Global config is dangerous. SET_CFG, SET_DE_CFG, and
> SET_ALL_CFG mutate shared firmware state. Multiple users can race
> or disrupt each other. Consider documenting ownership semantics,
> adding locking/session model, or exposing read-only access
> separately.
Yes, this is the same as in the FS approach, multiple reader and writers
can coexist BUT the Kernel does NOT mediate concurrent configuration
attempts, last writer wins: kernel only guarantes serialization when
multiple configs are written...but anyway last wins.
> * SET_ALL_CFG is not atomic. If configuring all DEs fails midway,
> userspace gets partial state. Either make that explicit, add
> rollback/best-effort reporting, or prefer batched config with
> per-item status.
Mmm...if SET_ALL_CFG fails midway, an error is reported and the
subsequent GET_ALL_CFG will return the current state of 'ALL':
i.e. True if all enabled, False if any is disabled...
You can anyway lookup each single DE state subsequently.
I could implement an all or nothing with rollback but I am not sure the
complication in code is worth: on the other side I was thinking too about
the optional batched config as mentioned as a way to speed up multiple
configs mostly...
> * No event/poll model. For telemetry, userspace may want
> poll()/blocking reads/notification-driven collection rather than
> repeated synchronous ioctls.
Yes that is the future plan and most of the internal support is already in
place, I have not planned any dedicated IOCTL till now (similarly there was
no dedicated special file in the old FS approach) since, for such streaming
poll model to be feasible, SCMI Telemetry notifications are needed, but they
are optional by the spec and currently NOT planned FW side AFAIK... so I
lowered this in priority and delayed to a future extensions given the
increasingly tight timeline that we have. (even though I can devel and
plan against my emulation setup..)
I would like anyway to add a generic event IOCTL that allows the user to
register a custom eventfd for a specific event to be monitored....first
event being the generation counter change AND second the update
notification for event/poll telemetry ocnsumption....
> * Timestamp usability is underspecified. Userspace needs clear
> timestamp domain, rate conversion, wrap behavior, and correlation
> to Linux clocks.
All of the timestamps are originated by the platform and specified by
the SCMI spec: Kernel does NOT mediate/correct/trim anything here.
It will have to be documented better of course, but all you get is a 64
bit tinestamp and the clock rate in KhZ that has been used to generate
this specific timestamp for this DE..
> * Raw SHMTI mmap is powerful but has risks. It needs very clear
> lifetime, permissions, cacheability, offset/length, stale-data, and
> security documentation.
> * Batch APIs lack per-sample status. In BATCH_READ, one bad DE
> currently appears to fail the whole request. For tools, per-entry
> status is much better.
Can add status.
> * Text read() plus binary ioctls feels split-brain. Either document
> read() as debug/convenience only, or remove it from the stable
> interface and keep the ABI purely binary; no need for two different
> user interfaces with different semantics.
This was to try to supply some form of tool-independent human readable access
...indeed I was also tempted to re-introduce a limited form of proper SysFs for
global configs like update interval or global tlm_enable...(but not sure
about this really...)
> * Rename the generic #define SCMI 0xF1 to something scoped like
> SCMI_TLM_IOCTL_MAGIC; exporting a broad SCMImacro in UAPI is
> collision-prone.
> * Add .compat_ioctl = compat_ptr_ioctl or equivalent, and document
> that all structs are 32/64-bit compatible. The __u64user pointers
> help, but compat behavior should be explicit.
> * Clarify concurrency semantics: what happens when two processes
> enable/disable DEs, change intervals, or read while config changes?
> A generation counter/reset ioctl, already listed as TODO, should
> probably be part of the first ABI version.
No kernel mediation on this, ONLY a generation counter to spot unexpected
changes.
> * Define permissions. Configuration ioctls mutate global firmware
> telemetry state, so access control/default device mode/udev
> expectations should be documented.
>
As of now, no policying, whoever is privileged enough to write to the
device can configure the system, last writer wins.
Being now all of this based on a bunch of single devices (one per instance),
it could be more feasible to enable some sort of optional exclusive open mode
for the first privileged user to get hold of the device...I'll reason about it.
> Suggested additions before ABI freeze
> * SCMI_TLM_GET_ABI_INFO
> * SCMI_TLM_GET_GENERATION
> * SCMI_TLM_RESET
> * batched GET/SET_DE_CFG with per-entry status
> * pollable notification/event support, if telemetry notifications are
> meaningful to userspace
> * optional read-only open mode or permission model for non-mutating
> tools
>
> Usability / Docs
> * The docs need more precise examples for two-call enumeration, error
> handling, batch reads, and mmap cleanup/close semantics.
Yes that was minimal on purpose, given this was the first shot and a lot
can still change...
> * Fix typos before reposting: “Systemn”, “dwscriptors”, “istance”,
> “udpated”, “andc”, “A IOCTL”.
> * The sample tool should either be promoted into a real
> selftest-style utility or clearly kept out of the upstreamable set
> until it has robust argument parsing and error reporting.
>
Well...the tool as of now if a draft thing for testing...it is indeed
marked as RFC (and declared in a crappy state)...so it is clear NOT for
upstream as it is: as I mentioned in the commit itself it is meant to be
improved and used for testing in the future...not for upstream in this
state of course...
...BUT even in this state can be used to simply exercise most of the
IOCTL quickly...so that was the reason I included it as RFC.
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
From: Andrew Morton @ 2026-07-13 22:45 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alVRU38lMfvmUFqJ@skinsburskii>
On Mon, 13 Jul 2026 13:57:55 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > > I rebased this series on top of mm-new right before sending it out.
> > > Should I have used a different branch?
> >
> > mm-new is good - Sashiko attempts that. But it's changing rapidly at
> > this point in the development cycle.
> >
>
> I’d like to send another revision addressing a few comments and also
> replace the `max/max_t` check with something simpler.
>
> Which branch should I base it on so that Sashiko can apply it
> successfully?
mainline Linus would be safest.
> Or would it be better to send fixups against `mm-new`?
That should work as well, but it doesn't give us a Sashiko scan of the
whole patchset.
^ permalink raw reply
* Re: [PATCH v8 09/11] KVM: arm64: PMU: Implement fixed-counters-only emulation
From: Akihiko Odaki @ 2026-07-13 21:50 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, Shuah Khan,
Yury Norov, Rasmus Villemoes, linux-arm-kernel, kvmarm,
linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <alSWtwHVfYh0zdPy@kernel.org>
On 2026/07/13 16:41, Oliver Upton wrote:
> On Fri, Jul 10, 2026 at 08:15:03PM +0900, Akihiko Odaki wrote:
>> @@ -813,6 +842,15 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
>> if (!pmuv3_implemented(kvm_arm_pmu_get_pmuver_limit()))
>> return;
>>
>> + /*
>> + * IMPDEF PMUv3 traps are non-architectural, and KVM cannot assume a
>> + * uniform PMUv3-compatible arm_pmu is available on all CPUs.
>> + */
>> + if (cpus_have_final_cap(ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS)) {
>> + kvm_info("Non-architectural PMU, tainting kernel\n");
>> + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
>> + }
>> +
>
> This is an unrelated change, and really the taint should be added with the
> .cpu_enable() for this capability. That's the point where we flip the
> magic bit.
I'm abandoning this change because it does not effectively cover all
corner cases we don't want to support:
https://lore.kernel.org/all/0e5e64ea-2f3c-4ce6-88ac-08b66f13027c@rsg.ci.i.u-tokyo.ac.jp/
>
>> +void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu, int last_cpu)
>> +{
>> + if (!kvm_pmu_fixed_counters_only(vcpu->kvm) || vcpu->cpu == last_cpu || last_cpu == -1)
> ^~~~~~~~~~~~~~
>
> Does this do anything other than avoid a spurious reload on the first KVM_RUN?
Yes. Without this check, the value will be passed to cpu_max_bits_warn()
in the following call chain, resulting in a warning ifdef
CONFIG_DEBUG_PER_CPU_MAPS:
1. kvm_vcpu_load_pmu()
2. kvm_pmu_probe_armpmu()
3. cpumask_test_cpu()
4. cpumask_check()
5. cpu_max_bits_warn()
Regards,
Akihiko Odaki
^ permalink raw reply
* Re: [PATCH v4 4/4] slub: apply new pw_queue_on() interface
From: Leonardo Bras @ 2026-07-13 21:44 UTC (permalink / raw)
To: Vlastimil Babka (SUSE)
Cc: Leonardo Bras, Sebastian Andrzej Siewior, Jonathan Corbet,
Shuah Khan, Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng,
Waiman Long, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
Nathan Chancellor, Nicolas Schier, Miguel Ojeda,
Thomas Weißschuh, Thomas Gleixner, Douglas Anderson,
Gary Guo, Christian Brauner, Pasha Tatashin, Coiby Xu,
Masahiro Yamada, Frederic Weisbecker, linux-doc, linux-kernel,
linux-mm, linux-rt-devel, Marcelo Tosatti
In-Reply-To: <157f60cb-ff83-4fed-8b05-e6c6390f85bc@kernel.org>
On Mon, Jul 13, 2026 at 12:55:36PM +0200, Vlastimil Babka (SUSE) wrote:
> On 7/13/26 09:36, Sebastian Andrzej Siewior wrote:
> > On 2026-07-12 19:35:28 [-0300], Leonardo Bras wrote:
> >> On Wed, May 20, 2026 at 04:53:08PM +0200, Sebastian Andrzej Siewior wrote:
> >> > On 2026-05-18 22:27:50 [-0300], Leonardo Bras wrote:
> >> > > @@ -4733,121 +4735,121 @@ void *alloc_from_pcs(struct kmem_cache *s, gfp_t gfp, int node)
> >> > >
> >> > > /*
> >> > > * We assume the percpu sheaves contain only local objects although it's
> >> > > * not completely guaranteed, so we verify later.
> >> > > */
> >> > > if (unlikely(node_requested && node != numa_mem_id())) {
> >> > > stat(s, ALLOC_NODE_MISMATCH);
> >> > > return NULL;
> >> > > }
> >> > >
> >> > > - if (!local_trylock(&s->cpu_sheaves->lock))
> >> > > + if (!pw_trylock_local(&s->cpu_sheaves->lock))
> >> > > return NULL;
> >> >
> >> > alloc_from_pcs() can be called from kmalloc_nolock()/ NMI context.
> >> > I don't remember why exactly local_trylock_t was introduced here instead
> >> > of a per-CPU spinlock_t.
> >>
> >> Probably to save the cost of using atomic operations on locking, and having
>
> Yes. Also function call overhead as spinlocks are often not inlined.
Oh, right, I remember getting numbers on that. Inlined per-cpu spinlocks
take much less time.
>
> >> about the same restrictions that would allow using local_locks
>
> Indeed.
>
> >> > But there should be nothing wrong with a
> >> > trylock on it from NMI as you do here.
> >>
> >> Awesome!
> >
> > The problem is always the unlock which requires full locking and is
> > usually the problem from NMI.
> >
> >> >
> >> > One thing worth noting, on !PREEMPT_RT, spin_trylock() always succeeds
> >> > on UP. kmalloc_nolock() checks for it, not sure about other callers.
> >>
> >>
> >> Sorry, I did not sure I understand that part.
> >> You mean we have since it always returns true, we may be in NMI context,
> >> after it was interrupted holding this lock, and it will return true which
> >> will use the protected area even though the lock should avoid it?
> >
> > from include/linux/spinlock_api_up.h:
> > | static __always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
> > | __cond_acquires(true, lock)
> > | {
> > | __LOCK(lock);
> > | return 1;
> > | }
> >
> > on UP a spin_trylock() always succeeds.
>
> Indeed. This was a problem in the page allocator, because there we don't
> even disable irqs, so it wasn't just nmi, but an irq that could get a
> false-positive spin_trylock(). See 038a102535eb ("mm/page_alloc: prevent pcp
> corruption with SMP=n") which was a hot fix.
>
> This was later cleaned up with 3 commits starting with a373f371166d
> ("mm/page_alloc: effectively disable pcp with CONFIG_SMP=n").
>
> Since here you're also replacing local_trylock() (with no _irqsave) with
> effectively spin_trylock(), the problem also won't be limited to NMIs and
> thus the checks in kmalloc_nolock() won't help.
>
> But I see in Patch 1:
>
> +config PWLOCKS
> + bool "Per-CPU Work locks"
> + depends on SMP || COMPILE_TEST
>
> So that's basically avoiding the problem in the same way as the page
> allocator after the clean up.
> Maybe just remove the COMPILE_TEST part? It's not clear to me what it
> achieves. Just make it require SMP as there's no point for this on !SMP.
>
I don't mind removing it, but IIRC that was added by Marcelo, I have to
ask him the reason he added it.
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v4 4/4] slub: apply new pw_queue_on() interface
From: Leonardo Bras @ 2026-07-13 21:40 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Leonardo Bras, Jonathan Corbet, Shuah Khan, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
Nathan Chancellor, Nicolas Schier, Miguel Ojeda,
Thomas Weißschuh, Thomas Gleixner, Douglas Anderson,
Gary Guo, Christian Brauner, Pasha Tatashin, Coiby Xu,
Masahiro Yamada, Frederic Weisbecker, linux-doc, linux-kernel,
linux-mm, linux-rt-devel, Marcelo Tosatti
In-Reply-To: <20260713073634.3Hrxpfcx@linutronix.de>
On Mon, Jul 13, 2026 at 09:36:34AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-07-12 19:35:28 [-0300], Leonardo Bras wrote:
> > On Wed, May 20, 2026 at 04:53:08PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2026-05-18 22:27:50 [-0300], Leonardo Bras wrote:
> > > > @@ -4733,121 +4735,121 @@ void *alloc_from_pcs(struct kmem_cache *s, gfp_t gfp, int node)
> > > >
> > > > /*
> > > > * We assume the percpu sheaves contain only local objects although it's
> > > > * not completely guaranteed, so we verify later.
> > > > */
> > > > if (unlikely(node_requested && node != numa_mem_id())) {
> > > > stat(s, ALLOC_NODE_MISMATCH);
> > > > return NULL;
> > > > }
> > > >
> > > > - if (!local_trylock(&s->cpu_sheaves->lock))
> > > > + if (!pw_trylock_local(&s->cpu_sheaves->lock))
> > > > return NULL;
> > >
> > > alloc_from_pcs() can be called from kmalloc_nolock()/ NMI context.
> > > I don't remember why exactly local_trylock_t was introduced here instead
> > > of a per-CPU spinlock_t.
> >
> > Probably to save the cost of using atomic operations on locking, and having
> > about the same restrictions that would allow using local_locks
> >
> > > But there should be nothing wrong with a
> > > trylock on it from NMI as you do here.
> >
> > Awesome!
>
> The problem is always the unlock which requires full locking and is
> usually the problem from NMI.
>
You mean, like, the trylock succeeds in the NMI handle, does the per-cpu
operations, and then unlock()s?
Or by full locking you mean local_lock() instead of local_trylock() ?
> > >
> > > One thing worth noting, on !PREEMPT_RT, spin_trylock() always succeeds
> > > on UP. kmalloc_nolock() checks for it, not sure about other callers.
> >
> >
> > Sorry, I did not sure I understand that part.
> > You mean we have since it always returns true, we may be in NMI context,
> > after it was interrupted holding this lock, and it will return true which
> > will use the protected area even though the lock should avoid it?
>
> from include/linux/spinlock_api_up.h:
> | static __always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
> | __cond_acquires(true, lock)
> | {
> | __LOCK(lock);
> | return 1;
> | }
>
> on UP a spin_trylock() always succeeds.
>
Right, I got that part, I was wondering the scenarios in which would that
be an issue.
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v8 01/11] KVM: arm64: Serialize userspace MDCR_EL2 access
From: Akihiko Odaki @ 2026-07-13 21:31 UTC (permalink / raw)
To: Oliver Upton
Cc: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, Shuah Khan,
Yury Norov, Rasmus Villemoes, linux-arm-kernel, kvmarm,
linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <alSU0ZoIQ3sMLo0p@kernel.org>
On 2026/07/13 16:33, Oliver Upton wrote:
> Hi,
>
> On Fri, Jul 10, 2026 at 08:14:55PM +0900, Akihiko Odaki wrote:
>> kvm_arm_set_nr_counters() updates MDCR_EL2.HPMN for every vCPU while
>> holding kvm->arch.config_lock. However, KVM_SET_ONE_REG currently writes
>> MDCR_EL2 through the generic sysreg path without taking the same lock.
>> Concurrent PMU configuration and register restore can therefore race and
>> lose updates to unrelated MDCR_EL2 bits.
>
> Ugh, we should just stop updating MDCR_EL2.HPMN altogether. Since this
> overwrites the previous value (rather than clamping it) we could discard
> a legal value set by userspace.
>
> From the UAPI POV all we need to do is ensure the reset value is sane.
> The documentation says that system registers are reset to their warm
> reset values when KVM_ARM_VCPU_INIT is called. Which in this would mean
> HPMN is reset to the number of implemented counters at the time of the
> ioctl.
>
> If userspace changes the number of counters afterwards, that's their
> problem.
One wrinkle is that KVM_ARM_VCPU_PMU_V3_SET_PMU and
KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS can only be used after
KVM_ARM_VCPU_INIT. Thus, either change necessarily occurs after the
initial MDCR_EL2.HPMN reset value has been established. Userspace can
issue KVM_ARM_VCPU_INIT again to reset HPMN from the new counter count.
This is awkward, but reflects the ordering imposed by the current UAPI.
On real hardware, the counter count is fixed before the CPU is reset,
whereas the UAPI configures it after the initial vCPU reset.
Reinitializing the vCPU is at least consistent with the documented warm
reset semantics.
I'll update the next version to stop rewriting MDCR_EL2.HPMN after vCPU
initialization. This also removes the need to serialize userspace
MDCR_EL2 access or reject HPMN values.
Regards,
Akihiko Odaki
>
>> Add explicit userspace accessors for MDCR_EL2. Serialize them with
>> config_lock so whole-register userspace writes cannot race with HPMN
>> rewrites, reject HPMN values above the configured PMU counter count, and
>> request a PMU reload when HPME changes to match guest trap behavior.
>>
>> Fixes: c8823e51b534 ("KVM: arm64: Fix MDCR_EL2.HPMN reset value")
>> Closes: https://sashiko.dev/#/patchset/20260706-hybrid-v8-0-de459617b59d%40rsg.ci.i.u-tokyo.ac.jp?part=6
>> Assisted-by: Codex:gpt-5.5
>> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
>> ---
>> arch/arm64/kvm/sys_regs.c | 39 ++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index d217530359ba..2b2ea33159e9 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -2949,6 +2949,42 @@ static bool access_mdcr(struct kvm_vcpu *vcpu,
>> return true;
>> }
>>
>> +static int get_mdcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
>> + u64 *val)
>> +{
>> + struct kvm *kvm = vcpu->kvm;
>> +
>> + guard(mutex)(&kvm->arch.config_lock);
>
> Hrm... I would strongly prefer that we *not* take the config_lock for
> this register since there's no way for userspace to avoid lock
> contention. ID registers are special and documented as VM-scoped, so an
> aware VMM could potentially set these once (avoiding the lock).
>
>> + *val = __vcpu_sys_reg(vcpu, MDCR_EL2);
>> +
>> + return 0;
>> +}
>> +
>> +static int set_mdcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
>> + u64 val)
>> +{
>> + struct kvm *kvm = vcpu->kvm;
>> + u64 old, hpmn = FIELD_GET(MDCR_EL2_HPMN, val);
>> +
>> + guard(mutex)(&kvm->arch.config_lock);
>> +
>> + if (hpmn > vcpu->kvm->arch.nr_pmu_counters)
>> + return -EINVAL;
>
> KVM allows userspace to write whatever it wants right now, we can't
> start rejecting values that were previously valid. The architecture also
> allows anything to be written to the field, just that unimplemented
> values have UNKNOWN behavior.
>
> Thanks,
> Oliver
^ permalink raw reply
* Re: [PATCH v4 3/4] swap: apply new pw_queue_on() interface
From: Leonardo Bras @ 2026-07-13 21:28 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Leonardo Bras, Jonathan Corbet, Shuah Khan, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
Nathan Chancellor, Nicolas Schier, Miguel Ojeda,
Thomas Weißschuh, Thomas Gleixner, Douglas Anderson,
Gary Guo, Christian Brauner, Pasha Tatashin, Coiby Xu,
Masahiro Yamada, Frederic Weisbecker, linux-doc, linux-kernel,
linux-mm, linux-rt-devel, Marcelo Tosatti
In-Reply-To: <20260713073158.CHjwei-N@linutronix.de>
On Mon, Jul 13, 2026 at 09:31:58AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-07-12 18:43:48 [-0300], Leonardo Bras wrote:
> > > I thought that this improved since commit
> > > ff042f4a9b050 ("mm: lru_cache_disable: replace work queue synchronization with synchronize_rcu")
> > >
> > > Did it get worse or was it not entirely gone?
> > >
> >
> > I worked in this patchset majorly after that commit date, and it was still
> > an issue up to last time Marcelo tested. Not sure of the impact of above
> > commit, but I suppose it may have brought some improvements without fully
> > fixing it.
>
> It would be good to know what is still missing and maybe it can be
> addressed without introducing this remote locking.
>
I get the point, but the main idea is to make this as proof of concept of
the mechanism, that can use to solve the latency introduced by IPIs from
per-cpu workqueues.
I remember discussing all those examples with Marcelo in the past, and IIRC
to solve this we would either have to use per-cpu spinlocks, which is
undesired in terms of performance on !RT, or skip remote operations in
isolated cpus, which may have weird behaviors, or disable caches in
isolated cpus which is terrible for performance there.
In any case, the main goal is to get something generic enough to deal with
most cases, not an individual solution.
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v4 0/4] Introduce Per-CPU Work helpers (was QPW)
From: Leonardo Bras @ 2026-07-13 21:17 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Leonardo Bras, Jonathan Corbet, Shuah Khan, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Thomas Gleixner, Feng Tang, Dapeng Mi, Kees Cook,
Marco Elver, Jakub Kicinski, Li RongQing, Eric Biggers,
Paul E. McKenney, Nathan Chancellor, Miguel Ojeda, Nicolas Schier,
Thomas Weißschuh, Douglas Anderson, Gary Guo,
Christian Brauner, Pasha Tatashin, Masahiro Yamada, Coiby Xu,
Frederic Weisbecker, linux-doc, linux-kernel, linux-mm,
linux-rt-devel
In-Reply-To: <20260713080723.XOTiibfG@linutronix.de>
On Mon, Jul 13, 2026 at 10:07:23AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-07-12 17:32:49 [-0300], Leonardo Bras wrote:
> > > > The idea:
> > > > Currently with PREEMPT_RT=y, local_locks() become per-cpu spinlocks.
> >
> > Hi Sebastian, thank you for reviewing!
> > (Sorry for the delay)
> >
> > > It does not become a _spin_lock because it does not spin. It sleeps.
> >
> > Right, it's a per-cpu mutex.
> > My point is that it's a full lock, and we could use it instead of doing the
> > whole scheduling thing, since we are already paying the 'atomic overhead'
> > to get the lock here.
>
> The whole lock is a spinlock_t. There is also raw_spinlock_t and
> bit_spin_lock(). All three are considered spinlocks.
>
> > > > In this case, instead of scheduling work on a remote cpu, it should
> > > > be safe to grab that remote cpu's per-cpu spinlock and run the required
> > > > work locally. That major cost, which is un/locking in every local function,
> > > > already happens in PREEMPT_RT.
> > >
> > > We did have this before but only in the RT tree. It was a bit messy from
> > > the naming because it started with local_ but then it was a remote CPU.
> >
> > Had the same naming issue here. This idea was initially a expansion to
> > local_lock() mechanism, about the same way you were planning in the past.
> >
> > > The main issue was the different code path which led to a few deadlocks
> > > back then.
> > > By the time local_lock_t went upstream, the cross-CPU locking was
> > > removed. As far as I remember, the cross-CPU user which did schedule
> > > work on a remote CPU and annoyed NOHZ folks were replaced.
> >
> > I understand this could be a big issue if used in a generic way.
> >
> > What I am proposing here a mechanism that standardizes those
> > local_lock()+IPI strategies based on how they are done today, so we are
> > only explected to get 'remote-cpu' pwlocks in the 'IPI replacement'
> > operations.
> >
> > The idea is pwlock_local* in every local function, and pwlock*(,cpu) in
> > operations that can be remote.
> >
> > Maybe being used in a more constrained way, it has less chance of being an
> > issue. Also, the whole idea is to improve CPU isolation numbers by
> > reducing IPIs, so maybe NOHZ people will be happier with that :)
>
> I get that part. The local_lock_t part is cheap on !RT and becomes a
> full lock on RT. While the lock details change the overall expectation
> remain the same. With this change it is possible to acquire the lock
> cross-CPU but this depends on the config/ setup. This might not be easy
> in terms of testing and maintenance.
> The more potential users you have, the better it might become in terms
> of a selling argument. If you have just (say) two users it might be
> simpler to address just those.
>
IIRC there are multiple users of this mechanism around the kernel. I
remember picking the first three (swap, slub and memcontrol) as examples of
how to use pwlocks (QPW at the time). With the concept proven, I could then
proceed to work with other potential users to replace it. (We ended up
dropping memcontrol in the process)
The main idea is to replace as many potential users as possible to reduce
as much as possible the amount of IPIs in isolated cpus, and allow Linux
to run workloads which require much lower latency.
This idea came as a general solution to a bunch of latency violations
Marcelo and I were coming across.
Thanks!
Leo
^ permalink raw reply
* RE: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device passthrough
From: Dan Williams (nvidia) @ 2026-07-13 21:14 UTC (permalink / raw)
To: Manish Honap, Alex Williamson
Cc: djbw@kernel.org, jgg@ziepe.ca, jic23@kernel.org,
dave.jiang@intel.com, Ankit Agrawal,
alejandro.lucero-palau@amd.com, alison.schofield@intel.com,
dave@stgolabs.net, dmatlack@google.com, gourry@gourry.net,
ira.weiny@intel.com, Neo Jia, Krishnakant Jaju, Vikram Sethi,
Zhi Wang, kvm@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, Manish Honap
In-Reply-To: <IA1PR12MB9030E175587B09CEA7A4D90FBDFA2@IA1PR12MB9030.namprd12.prod.outlook.com>
Manish Honap wrote:
> > -----Original Message-----
> > From: Alex Williamson <alex@shazbot.org>
> > Sent: 11 July 2026 03:53
> > To: Manish Honap <mhonap@nvidia.com>
> > Cc: djbw@kernel.org; jgg@ziepe.ca; jic23@kernel.org;
> > dave.jiang@intel.com; Ankit Agrawal <ankita@nvidia.com>;
> > alejandro.lucero-palau@amd.com; alison.schofield@intel.com;
> > dave@stgolabs.net; dmatlack@google.com; gourry@gourry.net;
> > ira.weiny@intel.com; Neo Jia <cjia@nvidia.com>; Krishnakant Jaju
> > <kjaju@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>; Zhi Wang
> > <zhiw@nvidia.com>; kvm@vger.kernel.org; linux-cxl@vger.kernel.org;
> > linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> > kselftest@vger.kernel.org; alex@shazbot.org
> > Subject: Re: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device
> > passthrough
> >
[..]
> >
> > On Thu, 25 Jun 2026 22:24:01 +0530
> > <mhonap@nvidia.com> wrote:
> > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > index 5de618a3a5ee..3707d53c4de5 100644
> > > --- a/include/uapi/linux/vfio.h
> > > +++ b/include/uapi/linux/vfio.h
> > > @@ -215,6 +215,7 @@ struct vfio_device_info {
> > > #define VFIO_DEVICE_FLAGS_FSL_MC (1 << 6) /* vfio-fsl-mc device */
> > > #define VFIO_DEVICE_FLAGS_CAPS (1 << 7) /* Info supports
> > caps */
> > > #define VFIO_DEVICE_FLAGS_CDX (1 << 8) /* vfio-cdx
> > device */
> > > +#define VFIO_DEVICE_FLAGS_CXL (1 << 9) /* vfio-cxl
> > Type-2 device */
> >
> > Would we define a different flag for type-1/3 if we ever found a need to
> > expose them through vfio?
>
> Yes. The current flag is named VFIO_DEVICE_FLAGS_CXL and refers to
> Type-2 specifically. If Type-1 or Type-3 support is added later, a
> separate flag (or a VFIO_DEVICE_INFO_CAP sub-type field) would
> distinguish them. I can rename it VFIO_DEVICE_FLAGS_CXL_TYPE2 now if
> that is preferable; please advise.
The CXL specification itself has deprecated the "Type" names because
they are ambiguous. For example, you can have a "Type-3" device that
supports "device memory (HDM-DB)", Type-2 is a superset of Type-1 in
many cases, etc.
This flag will never be able to capture a coherent / standard set of
device capabilities. It can really only be a plain "CXL" flag with
an implementation that is ready for the superset of capabilities:
CXL.cache, HDM-H (host-only memory expansion), HDM-D (legacy device
memory), HDM-DB (device memory via device cache management
back-invalidate).
I think the HDM-{H,D,DB} difference are not relevant to VFIO, it is all
just CXL HDM.
The capabilities that may need a different VFIO implementation model are
interleaved devices and maybe dynamic capacity devices, but that is not
a type designation.
[..]
> > Does that leave this device level capability describing the device as
> > type-2 (by existence), with only a flags field to declare HDM as
> > firmware committed, for future compatibility should we support non-fw
> > committed? Thanks,
> >
> > Alex
>
> Yes, I will shape the v4 in this direction. The device-level CAP_CXL
> shrinks to "this is a CXL device" (by existence) plus a flags field whose
> only defined bit today is HOST_FIRMWARE_COMMITTED, leaving
> room for a future non-fw-committed mode. Everything else moves to region
> caps. Thanks for this suggestion.
How can VFIO discern if the HDM is host firwmare committed? If
devm_cxl_probe_mem() grows to auto-activate unmapped capacity rather
than finds firmware committed decoders, can VFIO even tell the
difference?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox