Linux Documentation
 help / color / mirror / Atom feed
* Re: [PATCH 1/3] dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
From: Krzysztof Kozlowski @ 2026-06-08 10:47 UTC (permalink / raw)
  To: Ziming Zhu
  Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Jonathan Corbet, Shuah Khan, linux-hwmon, devicetree,
	linux-kernel, linux-doc, Ziming Zhu
In-Reply-To: <20260605020450.89638-2-zmzhu0630@163.com>

On Fri, Jun 05, 2026 at 10:04:48AM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
> 
> Add devicetree binding documentation for the Silergy SQ24860 eFuse.
> 
> The device is a PMBus hardware monitoring device which reports voltage,
> current, power, and temperature telemetry. The board-specific IMON
> resistor value is described with silergy,rimon-micro-ohms.

How many versions are you planning to send on the same day?

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v6 06/11] x86/virt/tdx: Optimize tdx_pamt_get/put()
From: Yan Zhao @ 2026-06-08  9:50 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Kiryl Shutsemau, Chao Gao, Edgecombe, Rick P, kvm@vger.kernel.org,
	linux-coco@lists.linux.dev, Huang, Kai, seanjc@google.com,
	mingo@redhat.com, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com, nik.borisov@suse.com,
	linux-doc@vger.kernel.org, hpa@zytor.com, tglx@kernel.org,
	Annapurve, Vishal, bp@alien8.de, kirill.shutemov@linux.intel.com,
	x86@kernel.org
In-Reply-To: <572868d7-4794-4fec-b80f-97d8434d5fb6@intel.com>

On Fri, Jun 05, 2026 at 09:23:21AM -0700, Dave Hansen wrote:
> On 6/5/26 04:42, Kiryl Shutsemau wrote:
> >>> I don't see a reason why we can't keep the scoped_guard() on get side.
> >> One additional reason to drop scoped_guard() is that it mixes cleanup helpers
> >> with goto, which is discouraged. See [*]
> >>
> >>  :Lastly, given that the benefit of cleanup helpers is removal of “goto”, and
> >>  :that the “goto” statement can jump between scopes, the expectation is that
> >>  :usage of “goto” and cleanup helpers is never mixed in the same function.
> > Fair enough.
> > 
> > But it can also be address if we free the PAMT page array with the guard
> > too :P
> 
> How important is this patch? I see "Optimize" but I read "Optional".
This patch reduces the number of global pamt_lock acquisitions.

Reference testing data with/without the optimization:
(collected on my SPR test machine)

Booting/teardown of 1 TD (8 vcpus/8G memory) per iteration:
                |--------------|-------------|------------|
                |    avg (us)  |   max (us)  |   min (us) | 
                |  w/o  |  w/  |  w/o  | w/  | w/o  |  w/ |
----------------|-------|------|-------|-----|------|-----|
__tdx_pamt_get()|   2   |  0   |  578  | 505 |  2   |  0  |
__tdx_pamt_put()|   0   |  0   |  563  | 496 |  0   |  0  |
----------------|--------------|-------------|------------|

Boot/teardown of 5 TDs (each TD: 8 vcpus/8G memory) concurrently:
                |--------------|-------------|------------|
                |    avg (us)  |   max (us)  |   min (us) | 
                |  w/o  |  w/  |  w/o  | w/  | w/o  |  w/ |
----------------|-------|------|-------|-----|------|-----|
__tdx_pamt_get()|  15   |  0   |  1723 | 1386|  2   |  0  |
__tdx_pamt_put()|   0   |  0   |   562 |  733|  0   |  0  |
----------------|--------------|-------------|------------|


> If we're arguing about it, maybe we should just kick it out and focus on
> the more important bits.
DPAMT still works fine without this optimization. The optimization can reduce
the average time spent on the global lock, especially when there's high
contention.

^ permalink raw reply

* Re: [RFC v1 0/9] kho: granular compatibility and header decoupling
From: Mike Rapoport @ 2026-06-08 10:26 UTC (permalink / raw)
  To: Pasha Tatashin
  Cc: Mike Rapoport, linux-kselftest, shuah, akpm, linux-mm, skhan,
	linux-doc, jasonmiu, linux-kernel, corbet, ran.xiaokai, kexec,
	pratyush, graf
In-Reply-To: <aiVp5RlbWRz5VnPB@plex>

On 2026-06-07 13:43:09+00:00, Pasha Tatashin wrote:
> On 06-07 14:58, Mike Rapoport wrote:
> 
> > On Fri, 05 Jun 2026 03:32:26 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > 
> > Hi,
> > 
> > 
> > I'd keep vmalloc where it is, it's more of a memory preservation primitive
> > rather than a data structure of it's own. The data structure it uses is an
> > implementation detail.
> 
> kho vmalloc is absolutely a data structure. KHO core only provides the
> basic handover mechanism (FDT nodes, physical memory ranges). vmalloc
> is a structured representation on top of KHO, and should provide its own
> versioned ABI.

kho_preserve_vmalloc() has the same semantics as kho_preserve_folio().
It's not intended to be used as a data structure. The data structure is
an implementation detail unlike with kho_block and kho_radix_tree that
are intended to be used as data structures and expose clear data
structure APIs.

Yes, vmalloc should have versioning, but that does not mean it must move
to different files.

And, btw, moving KHOSER_PTR() infra along with vmalloc is wrong. It was
my oversight that I didn't insist on using it for most of the
serializeable pointers instead of open coded
virt_to_phys()/phys_to_virt(). We need to fix it.

> If we change any of the vmalloc serialized structures (like kho_vmalloc,
> kho_vmalloc_chunk, or kho_vmalloc_hdr), then vmalloc won't work and
> compatibility will break.
> 
> Core KHO does not need vmalloc; nothing in kexec_handover.c uses it.
> 
> Instead, vmalloc has external customers:
> - memfd (uses it to preserve serialized folio metadata)
> - KHO test suite in lib/test_kho.c (uses it to preserve physical address arrays)

Following this logic, kho_presrve_folio() should be moved out because
it's not used by KHO but has external customers. And radix tree should
forever remain in kexec_handover.c because KHO uses it ;-)

> > Let's minimize the churn where possible for the sake of git blame and
> > backports.
> 
> It is much better to do the right cleanups now while KHO is young. Once more
> subsystems are added, this refactoring will be twice as hard. Modularizing the
> code now guarantees a simpler, safer, and scalable design. Placing each data
> structure in its own file gives us code that is easier to maintain, review, and
> less prone to bugs.

dependencies
> > that justify small headers for each two functions and netiher
> > linux/kexec_handover.h nor linux/kho/abi/kexec_handover.h are that long
> > to start splitting them.
> 
> External users only need to include the headers they actually use. For
> example, LUO shouldn't have to pull vmalloc or radix tree KHO
> declarations, and memfd does not need block.
> 
> From a maintenance point of view, it is much easier to catch ABI
> changes when the file with the appropriate version has been changed,
> and most likely the version of that file should be updated. If a single
> header contains compatibility versions for several different data
> structures, it is easier to miss the correct version update.

No matter in what files the definition lives, someone can forget to
update version and we may miss it during review.

Would be better to spend this time and energy to add kho-specific prompt
to LLM review to catch such issues ;-)
 
> Since we are splitting the source files (like kho_radix.c and
> kho_vmalloc.c), the headers should logically follow the same
> modularity.
 
They could. Doesn't mean they have to.

> > I agree that we should decouple versioning of these components from the
> > global KHO versioning.
> > Can't say I agree with the way you propose to do it.
> > 
> > I don't like that each user of a KHO component should include that
> > component version in its own version string (or whatever it may become
> > later).
> > 
> > It requires ABI headers update each time a user decides to add a new
> > data structure and worse when there is a change to that data structure.
> > It creates coupling of the data structure user with its particular
> > version and just looks ugly IMHO.
> 
> It is actually the opposite.
> 
> If a user adds a new data structure, that new data structure will have
> its own compatibility version. Instead of the current approach where
> the global version string needs to be updated, only the new version
> string would be added.
> 
> Also, if someone updates their code to use the new data structure, their
> compatibility string is going to be updated anyway, as part of using
> the data structure requires including the dependency in their
> compatibility.

Sorry I wasn't clear. I agree that kho_vmalloc, block and radix tree
should have their own versioning rather than rely on global KHO version.

What I don't like in your proposal is mixing versioning of a component
with its dependencies.

I think that versioning should be completely local to each component.
LUO should not care about kho_block "on wire" layout. This should be
encapsulated in kho_block.

> Backward compatibility is not in scope at the moment, but we can make
> the version parsing more granular in the future.
> 
> Instead of a simple strncmp(), we can introduce a standard callback
> interface for data structures. Each data structure implementation would
> implement this interface, and we would pass the parsed version string
> to the data-structure-specific version check.

Backward compatibility will be in scope sooner or later and string
parsing is surely not the way to deal with multiple versions.

How do you suggest to represent support for multiple versions?
"luo-v2;luo-v3;block-v2;block-v3;block-v4"?

> > Or, say, we add support to kmalloc() and use it in kho_block.
> > Then we'd have to add kmalloc() versioning to all kho_block users, right?
> 
> I was thinking about this. Since we don't have examples of data
> structures depending on each other right now, I simply made sure
> there are no duplicates in the compatibility strings.
> 
> If data structures have interdependencies in the future, we can easily
> remove this uniqueness restriction. The users of block will still
> include the block compatibility string (which automatically includes
> kmalloc), and if user also depends on kmalloc, they will include it
> as well.
> 
> > I think the versioning of each component should be handled by ->restore()
> > of that component. If it sees an incompatible version in the preserved
> > data, it returns an error. The versions can be stored e.g. in the base KHO
> > fdt.
> 
> Hm, I think, checking compatibility inside ->restore() of each component may be
> too late in the boot sequence.
>
> By checking the composite compatibility strings upfront (before invoking
> the actual restore/retrieve callbacks), we can guarantee that the entire
> state configuration is fully compatible. If any mismatch is found, we
> can cleanly abort the live update.

If a ->restore() returned an error (for any reason) we anyway need to
reboot, don't we? 

What do we do if memfd discovered incompatibility, but, say hugetlb
global state was already restored?

If you really want to run the compatibility check upfront, we need a
mechanism for that. And that should probably happen even before
kho_mem_init().

> Additionally, keeping the versioning managed via composite strings on the
> serialized data and registered handlers keeps the KHO core completely
> decoupled from individual component ABIs, avoiding the need to bloat the
> base KHO FDT with subsystem-specific versions.

Actually FDT "compatible" handles versioning nicer than composite strings
You can have

	compatible="kho-v4", "vmalloc-v1", "radix-v1", "block-v2";

and check fdt_node_check_compatible("vmalloc-v1") for vmalloc and
fdt_node_check_compatible("block-v2") for block.

And we wouldn't need to reimplement string parsing ;-)

But yeah, I do see value of making components versioning and KHO global
versioning independent. I just don't like composite strings and I don't
like mixing versioning with dependencies.

Since we are moving from FDT for the most things, version should become
a number rather than a string and version compatibility should be
independently verified by each component.
Then dependencies between components will remain at API level rather
than brought into the ABI.

If you think ->restore() is too late for compatibility check, we should
work on a mechanism for upfront compatibility verification.

> > > 5. Adds a KUnit test suite to verify that the composite compatibility
> > 
> > Without "composite compatibility strings" we don't need to care about
> > them "remaining unique and sorted in alphabetical order".
> 
> These are not strict runtime requirements; they are simply there to enforce
> code cleanliness and prevent human errors like accidental duplicates or
> mismatched orders.
> 
> Even with a simple strncmp(), it works perfectly fine as long as the
> strings match exactly. If the uniqueness or sorting constraints are too
> strict, they can easily be removed.
> 
> In the future, we can transition to a more sophisticated version checker
> that parses the composite string into individual subsystem version tokens
> and verifies them one-by-one, rather than relying on a strict literal
> strcmp() string comparison.
> 
> > The need for this test alone is already a red flag ;-)
> 
> I will remove test ;-)

It will not remove the red flags ;-)


^ permalink raw reply

* [PATCH net-next v3 3/3] net: ti: icssg: Add HSR offload statistics support
From: MD Danish Anwar @ 2026-06-08 10:09 UTC (permalink / raw)
  To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Simon Horman, Jonathan Corbet, Shuah Khan, MD Danish Anwar,
	Roger Quadros, Andrew Lunn, Jacob Keller, Meghana Malladi,
	David Carlier, Vadim Fedorenko, Kevin Hao, Himanshu Mittal,
	Hangbin Liu, Markus Elfring, Fernando Fernandez Mancera,
	Jan Vaclav
  Cc: netdev, linux-doc, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608100930.210149-1-danishanwar@ti.com>

Add support for exposing ICSSG HSR statistics through two interfaces:
ethtool and the standard RTM_GETSTATS / IFLA_STATS_LINK_XSTATS path.

Add a standard_stats flag to struct icssg_pa_stats and extend
icssg_all_pa_stats[] with 10 new entries:

  Firmware-specific HSR counters (standard_stats=false, ethtool only):
  - FW_HSR_FWD_CHECK_FAIL_DROP
  - FW_HSR_HE_CHECK_FAIL_DROP
  - FW_HSR_SKIP_HOST_DUP_DISCARD

  IEC 62439-3 LRE counters (standard_stats=true, excluded from ethtool):
  - FW_LRE_CNT_UNIQUE_RX, FW_LRE_CNT_DUPLICATE_RX, FW_LRE_CNT_MULTIPLE_RX
  - FW_LRE_CNT_RX, FW_LRE_CNT_TX, FW_LRE_CNT_OWN_RX
  - FW_LRE_CNT_ERRWRONGLAN

The ethtool get_strings/get_ethtool_stats callbacks skip entries with
standard_stats=true so they do not appear as ethtool counters.
ICSSG_NUM_PA_STANDARD_STATS is introduced and accounted for in
ICSSG_NUM_ETHTOOL_STATS so the sset count stays accurate.
ICSSG_NUM_PA_STATS is updated from 32 to 42.

Implement ndo_has_offload_stats() and ndo_get_offload_stats() in
emac_netdev_ops to expose the IEC 62439-3 LRE counters via the HSR
stack's RTM_GETSTATS / IFLA_STATS_LINK_XSTATS interface. The HSR stack
calls these NDOs on slave A; the callback reads PA stat registers for
both ports (MAC0 = port A, MAC1 = port B) from the shared prueth
instance and fills struct hsr_lre_stats. Port C counters are not
available in ICSSG hardware and remain at ~0ULL.

Export emac_update_hardware_stats() and emac_get_stat_by_name() as
GPL symbols so they can be called from icssg_prueth.c. Also change
emac_get_stat_by_name() return type from int to u64 and make it return
~0ULL on an unknown stat name instead of -EINVAL, consistent with the
hsr_lre_stats sentinel convention.

Add FW_HSR_FWD_CHECK_FAIL_DROP and FW_HSR_HE_CHECK_FAIL_DROP to the
rx_dropped sum in ndo_get_stats64, as these represent frames discarded
by the HSR forwarding logic.

Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
---
 .../ethernet/ti/icssg_prueth.rst              | 19 ++++
 drivers/net/ethernet/ti/icssg/icssg_common.c  |  7 +-
 drivers/net/ethernet/ti/icssg/icssg_ethtool.c | 10 +-
 drivers/net/ethernet/ti/icssg/icssg_prueth.c  | 91 +++++++++++++++++++
 drivers/net/ethernet/ti/icssg/icssg_prueth.h  | 10 +-
 drivers/net/ethernet/ti/icssg/icssg_stats.c   |  6 +-
 drivers/net/ethernet/ti/icssg/icssg_stats.h   | 85 +++++++++--------
 .../net/ethernet/ti/icssg/icssg_switch_map.h  | 10 ++
 8 files changed, 192 insertions(+), 46 deletions(-)

diff --git a/Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst b/Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst
index da21ddf431bbc..faa1fc18a6737 100644
--- a/Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst
+++ b/Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst
@@ -54,3 +54,22 @@ These statistics are as follows,
  - ``FW_HOST_TX_PKT_CNT``: Number of valid packets copied by RTU0 to Tx queues
  - ``FW_HOST_EGRESS_Q_PRE_OVERFLOW``: Host Egress Q (Pre-emptible) Overflow Counter
  - ``FW_HOST_EGRESS_Q_EXP_OVERFLOW``: Host Egress Q (Pre-emptible) Overflow Counter
+ - ``FW_HSR_FWD_CHECK_FAIL_DROP``: Packets dropped on the HSR forwarding path due to failed checks
+ - ``FW_HSR_HE_CHECK_FAIL_DROP``: Packets dropped on the host egress path due to failed checks
+ - ``FW_HSR_SKIP_HOST_DUP_DISCARD``: Frames for which the host duplicate discard check was skipped
+
+HSR/LRE Standard Statistics
+============================
+
+When the ICSSG operates in HSR offload mode the driver exposes the IEC 62439-3
+LRE counters through the standard netlink stats interface.
+
+The following per-port (port A and port B) LRE counters are reported:
+
+ - ``lreCntTx``: Number of HSR/PRP tagged frames sent
+ - ``lreCntRx``: Number of HSR/PRP tagged frames received
+ - ``lreCntUnique``: Number of frames received with no duplicate detected
+ - ``lreCntDuplicate``: Number of frames received for which exactly one duplicate was detected
+ - ``lreCntMultiple``: Number of frames received for which more than one duplicate was detected
+ - ``lreCntOwnRx``: Number of HSR/PRP tagged frames received whose source MAC matches the node's own address
+ - ``lreCntErrWrongLan``: Number of frames received with a wrong LAN identifier (PRP only)
diff --git a/drivers/net/ethernet/ti/icssg/icssg_common.c b/drivers/net/ethernet/ti/icssg/icssg_common.c
index a28a608f9bf4b..1fcb031949535 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_common.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_common.c
@@ -1643,7 +1643,12 @@ void icssg_ndo_get_stats64(struct net_device *ndev,
 			    emac_get_stat_by_name(emac, "FW_INF_DROP_TAGGED") +
 			    emac_get_stat_by_name(emac, "FW_INF_DROP_PRIOTAGGED") +
 			    emac_get_stat_by_name(emac, "FW_INF_DROP_NOTAG") +
-			    emac_get_stat_by_name(emac, "FW_INF_DROP_NOTMEMBER");
+			    emac_get_stat_by_name(emac,
+						  "FW_INF_DROP_NOTMEMBER") +
+			    emac_get_stat_by_name(emac,
+						  "FW_HSR_FWD_CHECK_FAIL_DROP") +
+			    emac_get_stat_by_name(emac,
+						  "FW_HSR_HE_CHECK_FAIL_DROP");
 	stats->tx_errors  = ndev->stats.tx_errors;
 	stats->tx_dropped = ndev->stats.tx_dropped +
 			    emac_get_stat_by_name(emac, "FW_RTU_PKT_DROP") +
diff --git a/drivers/net/ethernet/ti/icssg/icssg_ethtool.c b/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
index b715af21d23ac..7a99c99aab1e8 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
@@ -74,7 +74,9 @@ static int emac_get_sset_count(struct net_device *ndev, int stringset)
 		if (emac->prueth->pa_stats)
 			return ICSSG_NUM_ETHTOOL_STATS;
 		else
-			return ICSSG_NUM_ETHTOOL_STATS - ICSSG_NUM_PA_STATS;
+			return ICSSG_NUM_ETHTOOL_STATS -
+			       (ICSSG_NUM_PA_STATS -
+				ICSSG_NUM_PA_STANDARD_STATS);
 	default:
 		return -EOPNOTSUPP;
 	}
@@ -93,7 +95,8 @@ static void emac_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
 				ethtool_puts(&p, icssg_all_miig_stats[i].name);
 		if (emac->prueth->pa_stats)
 			for (i = 0; i < ARRAY_SIZE(icssg_all_pa_stats); i++)
-				ethtool_puts(&p, icssg_all_pa_stats[i].name);
+				if (!icssg_all_pa_stats[i].standard_stats)
+					ethtool_puts(&p, icssg_all_pa_stats[i].name);
 		break;
 	default:
 		break;
@@ -114,7 +117,8 @@ static void emac_get_ethtool_stats(struct net_device *ndev,
 
 	if (emac->prueth->pa_stats)
 		for (i = 0; i < ARRAY_SIZE(icssg_all_pa_stats); i++)
-			*(data++) = emac->pa_stats[i];
+			if (!icssg_all_pa_stats[i].standard_stats)
+				*(data++) = emac->pa_stats[i];
 }
 
 static int emac_get_ts_info(struct net_device *ndev,
diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.c b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
index 591be5c8056b4..bd390ccf7e450 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
@@ -14,6 +14,7 @@
 #include <linux/etherdevice.h>
 #include <linux/genalloc.h>
 #include <linux/if_hsr.h>
+#include <linux/if_link.h>
 #include <linux/if_vlan.h>
 #include <linux/interrupt.h>
 #include <linux/io-64-nonatomic-hi-lo.h>
@@ -1633,6 +1634,94 @@ int prueth_xsk_wakeup(struct net_device *ndev, u32 qid, u32 flags)
 	return 0;
 }
 
+/**
+ * prueth_ndo_get_offload_stats - Fill standard LRE counters from ICSSG.
+ * @attr_id: Stats attribute ID; only IFLA_STATS_LINK_XSTATS is handled.
+ * @dev:     Slave net_device (port A) whose offload stats are requested.
+ * @sp:      Output pointer; cast to struct hsr_lre_stats *.
+ *
+ * Called by the HSR stack via ndo_get_offload_stats on the slave A device.
+ * Fetches the per-port PA stat register snapshots for port A and port B,
+ * and fills the IEC-62439-3 per-port LRE counters.  Port C (interlink)
+ * counters are not available in ICSSG hardware and remain at ~0ULL.
+ *
+ * Return: 0 on success, -EOPNOTSUPP if the device does not support
+ *         HSR offload statistics for the requested attribute.
+ */
+static int prueth_ndo_get_offload_stats(int attr_id,
+					const struct net_device *dev,
+					void *sp)
+{
+	struct hsr_lre_stats *stats = sp;
+	struct prueth_emac *emac0;
+	struct prueth_emac *emac1;
+	struct prueth_emac *emac = netdev_priv(dev);
+	struct prueth *prueth = emac->prueth;
+
+	if (attr_id != IFLA_STATS_LINK_XSTATS)
+		return -EOPNOTSUPP;
+
+	if (!prueth->is_hsr_offload_mode)
+		return -EOPNOTSUPP;
+
+	emac0 = prueth->emac[PRUETH_MAC0];
+	emac1 = prueth->emac[PRUETH_MAC1];
+
+	if (!prueth->pa_stats)
+		return -EOPNOTSUPP;
+
+	/* Initialise all fields to ~0ULL ("unsupported"); only port A and B
+	 * counters are filled — port C and aggregate counters are not
+	 * available in ICSSG hardware.
+	 */
+	memset(stats, 0xff, sizeof(*stats));
+
+	emac_update_hardware_stats(emac0);
+	stats->cnt_tx_a =
+		emac_get_stat_by_name(emac0, "FW_LRE_CNT_TX");
+	stats->cnt_rx_a =
+		emac_get_stat_by_name(emac0, "FW_LRE_CNT_RX");
+	stats->cnt_unique_a =
+		emac_get_stat_by_name(emac0, "FW_LRE_CNT_UNIQUE_RX");
+	stats->cnt_duplicate_a =
+		emac_get_stat_by_name(emac0, "FW_LRE_CNT_DUPLICATE_RX");
+	stats->cnt_multi_a =
+		emac_get_stat_by_name(emac0, "FW_LRE_CNT_MULTIPLE_RX");
+	stats->cnt_own_rx_a =
+		emac_get_stat_by_name(emac0, "FW_LRE_CNT_OWN_RX");
+	/* lreCntErrWrongLan is PRP only */
+	stats->cnt_err_wrong_lan_a =
+		emac_get_stat_by_name(emac0, "FW_LRE_CNT_ERRWRONGLAN");
+
+	emac_update_hardware_stats(emac1);
+	stats->cnt_tx_b =
+		emac_get_stat_by_name(emac1, "FW_LRE_CNT_TX");
+	stats->cnt_rx_b =
+		emac_get_stat_by_name(emac1, "FW_LRE_CNT_RX");
+	stats->cnt_unique_b =
+		emac_get_stat_by_name(emac1, "FW_LRE_CNT_UNIQUE_RX");
+	stats->cnt_duplicate_b =
+		emac_get_stat_by_name(emac1, "FW_LRE_CNT_DUPLICATE_RX");
+	stats->cnt_multi_b =
+		emac_get_stat_by_name(emac1, "FW_LRE_CNT_MULTIPLE_RX");
+	stats->cnt_own_rx_b =
+		emac_get_stat_by_name(emac1, "FW_LRE_CNT_OWN_RX");
+	stats->cnt_err_wrong_lan_b =
+		emac_get_stat_by_name(emac1, "FW_LRE_CNT_ERRWRONGLAN");
+
+	return 0;
+}
+
+static bool prueth_ndo_has_offload_stats(const struct net_device *dev,
+					 int attr_id)
+{
+	struct prueth_emac *emac = netdev_priv(dev);
+	struct prueth *prueth = emac->prueth;
+
+	return attr_id == IFLA_STATS_LINK_XSTATS &&
+	       prueth->is_hsr_offload_mode && prueth->pa_stats;
+}
+
 static const struct net_device_ops emac_netdev_ops = {
 	.ndo_open = emac_ndo_open,
 	.ndo_stop = emac_ndo_stop,
@@ -1652,6 +1741,8 @@ static const struct net_device_ops emac_netdev_ops = {
 	.ndo_hwtstamp_get = icssg_ndo_get_ts_config,
 	.ndo_hwtstamp_set = icssg_ndo_set_ts_config,
 	.ndo_xsk_wakeup = prueth_xsk_wakeup,
+	.ndo_has_offload_stats = prueth_ndo_has_offload_stats,
+	.ndo_get_offload_stats = prueth_ndo_get_offload_stats,
 };
 
 static int prueth_netdev_init(struct prueth *prueth,
diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.h b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
index df93d15c5b786..d6c221e897924 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
@@ -57,12 +57,14 @@
 
 #define ICSSG_MAX_RFLOWS	8	/* per slice */
 
-#define ICSSG_NUM_PA_STATS	32
+#define ICSSG_NUM_PA_STATS	42
 #define ICSSG_NUM_MIIG_STATS	60
 /* Number of ICSSG related stats */
 #define ICSSG_NUM_STATS (ICSSG_NUM_MIIG_STATS + ICSSG_NUM_PA_STATS)
-#define ICSSG_NUM_STANDARD_STATS 31
-#define ICSSG_NUM_ETHTOOL_STATS (ICSSG_NUM_STATS - ICSSG_NUM_STANDARD_STATS)
+#define ICSSG_NUM_STANDARD_STATS	31
+#define ICSSG_NUM_PA_STANDARD_STATS	7
+#define ICSSG_NUM_ETHTOOL_STATS (ICSSG_NUM_STATS - ICSSG_NUM_STANDARD_STATS - \
+				 ICSSG_NUM_PA_STANDARD_STATS)
 
 #define IEP_DEFAULT_CYCLE_TIME_NS	1000000	/* 1 ms */
 
@@ -458,7 +460,7 @@ int emac_fdb_flow_id_updated(struct prueth_emac *emac);
 
 void icssg_stats_work_handler(struct work_struct *work);
 void emac_update_hardware_stats(struct prueth_emac *emac);
-int emac_get_stat_by_name(struct prueth_emac *emac, char *stat_name);
+u64 emac_get_stat_by_name(struct prueth_emac *emac, char *stat_name);
 
 /* Common functions */
 void prueth_cleanup_rx_chns(struct prueth_emac *emac,
diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.c b/drivers/net/ethernet/ti/icssg/icssg_stats.c
index 7159baa0155cf..9950d0ba899fa 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_stats.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_stats.c
@@ -62,6 +62,7 @@ void emac_update_hardware_stats(struct prueth_emac *emac)
 
 	spin_unlock(&prueth->stats_lock);
 }
+EXPORT_SYMBOL_GPL(emac_update_hardware_stats);
 
 void icssg_stats_work_handler(struct work_struct *work)
 {
@@ -74,7 +75,7 @@ void icssg_stats_work_handler(struct work_struct *work)
 }
 EXPORT_SYMBOL_GPL(icssg_stats_work_handler);
 
-int emac_get_stat_by_name(struct prueth_emac *emac, char *stat_name)
+u64 emac_get_stat_by_name(struct prueth_emac *emac, char *stat_name)
 {
 	int i;
 
@@ -91,5 +92,6 @@ int emac_get_stat_by_name(struct prueth_emac *emac, char *stat_name)
 	}
 
 	netdev_err(emac->ndev, "Invalid stats %s\n", stat_name);
-	return -EINVAL;
+	return ~0ULL;
 }
+EXPORT_SYMBOL_GPL(emac_get_stat_by_name);
diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/net/ethernet/ti/icssg/icssg_stats.h
index 6f4400d8a0f61..373debfb815cc 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
@@ -157,50 +157,63 @@ static const struct icssg_miig_stats icssg_all_miig_stats[] = {
 
 static_assert(ARRAY_SIZE(icssg_all_miig_stats) == ICSSG_NUM_MIIG_STATS);
 
-#define ICSSG_PA_STATS(field)	\
-{				\
-	#field,			\
-	field,			\
+#define ICSSG_PA_STATS(field, stats_type)	\
+{						\
+	#field,					\
+	field,					\
+	stats_type				\
 }
 
 struct icssg_pa_stats {
 	char name[ETH_GSTRING_LEN];
 	u32 offset;
+	bool standard_stats;
 };
 
 static const struct icssg_pa_stats icssg_all_pa_stats[] = {
-	ICSSG_PA_STATS(FW_RTU_PKT_DROP),
-	ICSSG_PA_STATS(FW_Q0_OVERFLOW),
-	ICSSG_PA_STATS(FW_Q1_OVERFLOW),
-	ICSSG_PA_STATS(FW_Q2_OVERFLOW),
-	ICSSG_PA_STATS(FW_Q3_OVERFLOW),
-	ICSSG_PA_STATS(FW_Q4_OVERFLOW),
-	ICSSG_PA_STATS(FW_Q5_OVERFLOW),
-	ICSSG_PA_STATS(FW_Q6_OVERFLOW),
-	ICSSG_PA_STATS(FW_Q7_OVERFLOW),
-	ICSSG_PA_STATS(FW_DROPPED_PKT),
-	ICSSG_PA_STATS(FW_RX_ERROR),
-	ICSSG_PA_STATS(FW_RX_DS_INVALID),
-	ICSSG_PA_STATS(FW_TX_DROPPED_PACKET),
-	ICSSG_PA_STATS(FW_TX_TS_DROPPED_PACKET),
-	ICSSG_PA_STATS(FW_INF_PORT_DISABLED),
-	ICSSG_PA_STATS(FW_INF_SAV),
-	ICSSG_PA_STATS(FW_INF_SA_DL),
-	ICSSG_PA_STATS(FW_INF_PORT_BLOCKED),
-	ICSSG_PA_STATS(FW_INF_DROP_TAGGED),
-	ICSSG_PA_STATS(FW_INF_DROP_PRIOTAGGED),
-	ICSSG_PA_STATS(FW_INF_DROP_NOTAG),
-	ICSSG_PA_STATS(FW_INF_DROP_NOTMEMBER),
-	ICSSG_PA_STATS(FW_RX_EOF_SHORT_FRMERR),
-	ICSSG_PA_STATS(FW_RX_B0_DROP_EARLY_EOF),
-	ICSSG_PA_STATS(FW_TX_JUMBO_FRM_CUTOFF),
-	ICSSG_PA_STATS(FW_RX_EXP_FRAG_Q_DROP),
-	ICSSG_PA_STATS(FW_RX_FIFO_OVERRUN),
-	ICSSG_PA_STATS(FW_CUT_THR_PKT),
-	ICSSG_PA_STATS(FW_HOST_RX_PKT_CNT),
-	ICSSG_PA_STATS(FW_HOST_TX_PKT_CNT),
-	ICSSG_PA_STATS(FW_HOST_EGRESS_Q_PRE_OVERFLOW),
-	ICSSG_PA_STATS(FW_HOST_EGRESS_Q_EXP_OVERFLOW),
+	/* Firmware-specific stats: exposed via ethtool -S only */
+	ICSSG_PA_STATS(FW_RTU_PKT_DROP, false),
+	ICSSG_PA_STATS(FW_Q0_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_Q1_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_Q2_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_Q3_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_Q4_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_Q5_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_Q6_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_Q7_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_DROPPED_PKT, false),
+	ICSSG_PA_STATS(FW_RX_ERROR, false),
+	ICSSG_PA_STATS(FW_RX_DS_INVALID, false),
+	ICSSG_PA_STATS(FW_TX_DROPPED_PACKET, false),
+	ICSSG_PA_STATS(FW_TX_TS_DROPPED_PACKET, false),
+	ICSSG_PA_STATS(FW_INF_PORT_DISABLED, false),
+	ICSSG_PA_STATS(FW_INF_SAV, false),
+	ICSSG_PA_STATS(FW_INF_SA_DL, false),
+	ICSSG_PA_STATS(FW_INF_PORT_BLOCKED, false),
+	ICSSG_PA_STATS(FW_INF_DROP_TAGGED, false),
+	ICSSG_PA_STATS(FW_INF_DROP_PRIOTAGGED, false),
+	ICSSG_PA_STATS(FW_INF_DROP_NOTAG, false),
+	ICSSG_PA_STATS(FW_INF_DROP_NOTMEMBER, false),
+	ICSSG_PA_STATS(FW_RX_EOF_SHORT_FRMERR, false),
+	ICSSG_PA_STATS(FW_RX_B0_DROP_EARLY_EOF, false),
+	ICSSG_PA_STATS(FW_TX_JUMBO_FRM_CUTOFF, false),
+	ICSSG_PA_STATS(FW_RX_EXP_FRAG_Q_DROP, false),
+	ICSSG_PA_STATS(FW_RX_FIFO_OVERRUN, false),
+	ICSSG_PA_STATS(FW_CUT_THR_PKT, false),
+	ICSSG_PA_STATS(FW_HOST_RX_PKT_CNT, false),
+	ICSSG_PA_STATS(FW_HOST_TX_PKT_CNT, false),
+	ICSSG_PA_STATS(FW_HOST_EGRESS_Q_PRE_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_HOST_EGRESS_Q_EXP_OVERFLOW, false),
+	ICSSG_PA_STATS(FW_HSR_FWD_CHECK_FAIL_DROP, false),
+	ICSSG_PA_STATS(FW_HSR_HE_CHECK_FAIL_DROP, false),
+	ICSSG_PA_STATS(FW_HSR_SKIP_HOST_DUP_DISCARD, false),
+	ICSSG_PA_STATS(FW_LRE_CNT_UNIQUE_RX, true),
+	ICSSG_PA_STATS(FW_LRE_CNT_DUPLICATE_RX, true),
+	ICSSG_PA_STATS(FW_LRE_CNT_MULTIPLE_RX, true),
+	ICSSG_PA_STATS(FW_LRE_CNT_RX, true),
+	ICSSG_PA_STATS(FW_LRE_CNT_TX, true),
+	ICSSG_PA_STATS(FW_LRE_CNT_OWN_RX, true),
+	ICSSG_PA_STATS(FW_LRE_CNT_ERRWRONGLAN, true),
 };
 
 static_assert(ARRAY_SIZE(icssg_all_pa_stats) == ICSSG_NUM_PA_STATS);
diff --git a/drivers/net/ethernet/ti/icssg/icssg_switch_map.h b/drivers/net/ethernet/ti/icssg/icssg_switch_map.h
index 7e053b8af3ece..556facb33e0ce 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_switch_map.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_switch_map.h
@@ -266,5 +266,15 @@
 #define FW_HOST_TX_PKT_CNT		0x0250
 #define FW_HOST_EGRESS_Q_PRE_OVERFLOW	0x0258
 #define FW_HOST_EGRESS_Q_EXP_OVERFLOW	0x0260
+#define FW_HSR_FWD_CHECK_FAIL_DROP		0x0500
+#define FW_HSR_HE_CHECK_FAIL_DROP		0x0508
+#define FW_HSR_SKIP_HOST_DUP_DISCARD		0x0510
+#define FW_LRE_CNT_UNIQUE_RX			0x0518
+#define FW_LRE_CNT_DUPLICATE_RX			0x0520
+#define FW_LRE_CNT_MULTIPLE_RX			0x0528
+#define FW_LRE_CNT_RX				0x0530
+#define FW_LRE_CNT_TX				0x0538
+#define FW_LRE_CNT_OWN_RX			0x0540
+#define FW_LRE_CNT_ERRWRONGLAN			0x0548
 
 #endif /* __NET_TI_ICSSG_SWITCH_MAP_H  */
-- 
2.34.1


^ permalink raw reply related

* [PATCH net-next v3 2/3] net: ti: icssg: Add static_assert to guard stat array counts
From: MD Danish Anwar @ 2026-06-08 10:09 UTC (permalink / raw)
  To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Simon Horman, Jonathan Corbet, Shuah Khan, MD Danish Anwar,
	Roger Quadros, Andrew Lunn, Jacob Keller, Meghana Malladi,
	David Carlier, Vadim Fedorenko, Kevin Hao, Himanshu Mittal,
	Hangbin Liu, Markus Elfring, Fernando Fernandez Mancera,
	Jan Vaclav
  Cc: netdev, linux-doc, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608100930.210149-1-danishanwar@ti.com>

Place static_assert() immediately after each of icssg_all_miig_stats[]
and icssg_all_pa_stats[] in icssg_stats.h to verify at build time that
ICSSG_NUM_MIIG_STATS and ICSSG_NUM_PA_STATS stay in sync with the
actual array sizes. This turns a silent miscount into a build error
should either the constant or the array be updated independently.

Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
---
 drivers/net/ethernet/ti/icssg/icssg_stats.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/net/ethernet/ti/icssg/icssg_stats.h
index 5ec0b38e0c67d..6f4400d8a0f61 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
@@ -155,6 +155,8 @@ static const struct icssg_miig_stats icssg_all_miig_stats[] = {
 	ICSSG_MIIG_STATS(tx_bytes, true),
 };
 
+static_assert(ARRAY_SIZE(icssg_all_miig_stats) == ICSSG_NUM_MIIG_STATS);
+
 #define ICSSG_PA_STATS(field)	\
 {				\
 	#field,			\
@@ -201,4 +203,6 @@ static const struct icssg_pa_stats icssg_all_pa_stats[] = {
 	ICSSG_PA_STATS(FW_HOST_EGRESS_Q_EXP_OVERFLOW),
 };
 
+static_assert(ARRAY_SIZE(icssg_all_pa_stats) == ICSSG_NUM_PA_STATS);
+
 #endif /* __NET_TI_ICSSG_STATS_H */
-- 
2.34.1


^ permalink raw reply related

* [PATCH net-next v3 1/3] net: hsr: Add standard LRE stats via RTM_GETSTATS / IFLA_STATS_LINK_XSTATS
From: MD Danish Anwar @ 2026-06-08 10:09 UTC (permalink / raw)
  To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Simon Horman, Jonathan Corbet, Shuah Khan, MD Danish Anwar,
	Roger Quadros, Andrew Lunn, Jacob Keller, Meghana Malladi,
	David Carlier, Vadim Fedorenko, Kevin Hao, Himanshu Mittal,
	Hangbin Liu, Markus Elfring, Fernando Fernandez Mancera,
	Jan Vaclav
  Cc: netdev, linux-doc, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608100930.210149-1-danishanwar@ti.com>

Per the IEC-62439-3 specification the Link Redundancy Entity (LRE)
maintains a well-defined set of counters applicable to both software
and offloaded HSR/PRP implementations. Define these counters as
individual netlink attributes inside a LINK_XSTATS_TYPE_HSR nest,
following the approach used by bridge and bond with IFLA_STATS_LINK_XSTATS.

The full IEC-62439-3 MIB counter set is represented, with per-port (A,
B, C) granularity where applicable:

  lreCntTx{A,B,C}          - sent HSR/PRP tagged frames per port
  lreCntRx{A,B,C}          - received HSR/PRP tagged frames per port
  lreCntErrWrongLan{A,B,C} - received frames with wrong LAN ID (PRP)
  lreCntErrors{A,B,C}      - received frames with errors per port
  lreCntUnique{A,B,C}       - frames received without duplicate
  lreCntDuplicate{A,B,C}    - frames received with exactly one duplicate
  lreCntMulti{A,B,C}        - frames received with more than one duplicate
  lreCntOwnRx{A,B}          - own-address frames received (HSR only)

Each counter is encoded as its own HSR_XSTATS_* u64 netlink attribute.
Unsupported counters are initialised to ~0ULL by the kernel and omitted
from the netlink reply; user-space must treat an absent attribute as
"not available".

The UAPI attribute enum (HSR_XSTATS_*) is added to hsr_netlink.h.
LINK_XSTATS_TYPE_HSR is added to the LINK_XSTATS_TYPE_* enum in both
include/uapi/linux/if_link.h and tools/include/uapi/linux/if_link.h.

A kernel-internal struct hsr_lre_stats (in linux/if_hsr.h) is provided
for offload drivers to fill via ndo_get_offload_stats. Unsupported
fields must be left at the ~0ULL value initialised by the HSR layer
before calling the NDO.

The HSR stack calls ndo_get_offload_stats(IFLA_STATS_LINK_XSTATS) on
slave A to collect offload counters.

Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
---
 include/linux/if_hsr.h             |  48 +++++++++++
 include/uapi/linux/hsr_netlink.h   |  56 ++++++++++++
 include/uapi/linux/if_link.h       |   1 +
 net/hsr/hsr_netlink.c              | 132 +++++++++++++++++++++++++++--
 tools/include/uapi/linux/if_link.h |   1 +
 5 files changed, 230 insertions(+), 8 deletions(-)

diff --git a/include/linux/if_hsr.h b/include/linux/if_hsr.h
index f4cf2dd36d193..b8c20f0906194 100644
--- a/include/linux/if_hsr.h
+++ b/include/linux/if_hsr.h
@@ -38,6 +38,54 @@ struct hsr_tag {
 
 #define HSR_HLEN	6
 
+/**
+ * struct hsr_lre_stats - Kernel-internal IEC-62439-3 LRE counter set.
+ *
+ * This is the buffer type written by ndo_get_offload_stats() when called
+ * with attr_id == IFLA_STATS_LINK_XSTATS on an HSR slave device.  Each
+ * field maps to one HSR_XSTATS_* netlink attribute.  Fields that the
+ * offload driver does not support must be left at the initialised value of
+ * ~0ULL; the HSR layer will skip those when building the netlink reply.
+ *
+ * Per-port suffix: _a = port A (slave 1 / LAN-A),
+ *                  _b = port B (slave 2 / LAN-B),
+ *                  _c = interlink / application interface.
+ *
+ * @cnt_tx_a: lreCntTxA - sent HSR/PRP tagged frames on port A.
+ * @cnt_tx_b: lreCntTxB - sent HSR/PRP tagged frames on port B.
+ * @cnt_tx_c: lreCntTxC - sent HSR/PRP tagged frames on port C.
+ * @cnt_rx_a: lreCntRxA - received HSR/PRP tagged frames on port A.
+ * @cnt_rx_b: lreCntRxB - received HSR/PRP tagged frames on port B.
+ * @cnt_rx_c: lreCntRxC - received HSR/PRP tagged frames on port C.
+ * @cnt_err_wrong_lan_a: lreCntErrWrongLanA - wrong LAN ID frames on port A.
+ * @cnt_err_wrong_lan_b: lreCntErrWrongLanB - wrong LAN ID frames on port B.
+ * @cnt_err_wrong_lan_c: lreCntErrWrongLanC - wrong LAN ID frames on port C.
+ * @cnt_errors_a: lreCntErrorsA - received frames with errors on port A.
+ * @cnt_errors_b: lreCntErrorsB - received frames with errors on port B.
+ * @cnt_errors_c: lreCntErrorsC - received frames with errors on port C.
+ * @cnt_unique_a: lreCntUniqueA - frames received without duplicate on port A.
+ * @cnt_unique_b: lreCntUniqueB - frames received without duplicate on port B.
+ * @cnt_unique_c: lreCntUniqueC - frames received without duplicate on port C.
+ * @cnt_duplicate_a: lreCntDuplicateA - frames with one duplicate on port A.
+ * @cnt_duplicate_b: lreCntDuplicateB - frames with one duplicate on port B.
+ * @cnt_duplicate_c: lreCntDuplicateC - frames with one duplicate on port C.
+ * @cnt_multi_a: lreCntMultiA - frames with more than one duplicate on port A.
+ * @cnt_multi_b: lreCntMultiB - frames with more than one duplicate on port B.
+ * @cnt_multi_c: lreCntMultiC - frames with more than one duplicate on port C.
+ * @cnt_own_rx_a: lreCntOwnRxA - own-address frames received on port A.
+ * @cnt_own_rx_b: lreCntOwnRxB - own-address frames received on port B.
+ */
+struct hsr_lre_stats {
+	u64 cnt_tx_a, cnt_tx_b, cnt_tx_c;
+	u64 cnt_rx_a, cnt_rx_b, cnt_rx_c;
+	u64 cnt_err_wrong_lan_a, cnt_err_wrong_lan_b, cnt_err_wrong_lan_c;
+	u64 cnt_errors_a, cnt_errors_b, cnt_errors_c;
+	u64 cnt_unique_a, cnt_unique_b, cnt_unique_c;
+	u64 cnt_duplicate_a, cnt_duplicate_b, cnt_duplicate_c;
+	u64 cnt_multi_a, cnt_multi_b, cnt_multi_c;
+	u64 cnt_own_rx_a, cnt_own_rx_b;
+};
+
 #if IS_ENABLED(CONFIG_HSR)
 extern bool is_hsr_master(struct net_device *dev);
 extern int hsr_get_version(struct net_device *dev, enum hsr_version *ver);
diff --git a/include/uapi/linux/hsr_netlink.h b/include/uapi/linux/hsr_netlink.h
index d540ea9bbef4b..c414a2bb93b79 100644
--- a/include/uapi/linux/hsr_netlink.h
+++ b/include/uapi/linux/hsr_netlink.h
@@ -48,4 +48,60 @@ enum {
 };
 #define HSR_C_MAX (__HSR_C_MAX - 1)
 
+/* HSR/PRP LRE extended statistics attributes.
+ * Reported inside LINK_XSTATS_TYPE_HSR (RTM_GETSTATS / ip stats show).
+ * Counter definitions follow IEC-62439-3 MIB naming.
+ *
+ * All counters are __u64.  Unsupported counters are omitted from the
+ * netlink reply; user-space must treat an absent attribute as "not available".
+ *
+ * Per-port suffix: _A = port A (slave 1), _B = port B (slave 2),
+ *                  _C = interlink / application interface.
+ */
+enum {
+	/* Sent HSR/PRP tagged frames per port */
+	HSR_XSTATS_CNT_TX_A = 1,
+	HSR_XSTATS_CNT_TX_B,
+	HSR_XSTATS_CNT_TX_C,
+
+	/* Received HSR/PRP tagged frames per port */
+	HSR_XSTATS_CNT_RX_A,
+	HSR_XSTATS_CNT_RX_B,
+	HSR_XSTATS_CNT_RX_C,
+
+	/* Received frames with wrong LAN ID (PRP only) per port */
+	HSR_XSTATS_CNT_ERR_WRONG_LAN_A,
+	HSR_XSTATS_CNT_ERR_WRONG_LAN_B,
+	HSR_XSTATS_CNT_ERR_WRONG_LAN_C,
+
+	/* Received frames with errors per port */
+	HSR_XSTATS_CNT_ERRORS_A,
+	HSR_XSTATS_CNT_ERRORS_B,
+	HSR_XSTATS_CNT_ERRORS_C,
+
+	/* Frames received with no duplicate per port */
+	HSR_XSTATS_CNT_UNIQUE_A,
+	HSR_XSTATS_CNT_UNIQUE_B,
+	HSR_XSTATS_CNT_UNIQUE_C,
+
+	/* Frames received with exactly one duplicate per port */
+	HSR_XSTATS_CNT_DUPLICATE_A,
+	HSR_XSTATS_CNT_DUPLICATE_B,
+	HSR_XSTATS_CNT_DUPLICATE_C,
+
+	/* Frames received with more than one duplicate per port */
+	HSR_XSTATS_CNT_MULTI_A,
+	HSR_XSTATS_CNT_MULTI_B,
+	HSR_XSTATS_CNT_MULTI_C,
+
+	/* Frames received matching this node's own address (HSR only) */
+	HSR_XSTATS_CNT_OWN_RX_A,
+	HSR_XSTATS_CNT_OWN_RX_B,
+
+	HSR_XSTATS_PAD,
+	__HSR_XSTATS_MAX,
+};
+
+#define HSR_XSTATS_MAX (__HSR_XSTATS_MAX - 1)
+
 #endif /* __UAPI_HSR_NETLINK_H */
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 79ce4bc24cba6..3dcd51e64f29d 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -1905,6 +1905,7 @@ enum {
 	LINK_XSTATS_TYPE_UNSPEC,
 	LINK_XSTATS_TYPE_BRIDGE,
 	LINK_XSTATS_TYPE_BOND,
+	LINK_XSTATS_TYPE_HSR,
 	__LINK_XSTATS_TYPE_MAX
 };
 #define LINK_XSTATS_TYPE_MAX (__LINK_XSTATS_TYPE_MAX - 1)
diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c
index db0b0af7a6920..9455f65868ca2 100644
--- a/net/hsr/hsr_netlink.c
+++ b/net/hsr/hsr_netlink.c
@@ -11,6 +11,8 @@
 #include <linux/kernel.h>
 #include <net/rtnetlink.h>
 #include <net/genetlink.h>
+#include <uapi/linux/if_link.h>
+#include <uapi/linux/hsr_netlink.h>
 #include "hsr_main.h"
 #include "hsr_device.h"
 #include "hsr_framereg.h"
@@ -189,15 +191,129 @@ static int hsr_fill_info(struct sk_buff *skb, const struct net_device *dev)
 	return -EMSGSIZE;
 }
 
+/*
+ * Number of real HSR_XSTATS_* u64 counter attributes.
+ * Real counters run from HSR_XSTATS_CNT_TX_A(1) through
+ * HSR_XSTATS_CNT_OWN_RX_B(25); HSR_XSTATS_PAD is not a counter.
+ */
+#define HSR_XSTATS_CNT_ATTRS (HSR_XSTATS_PAD - 1)
+
+static size_t hsr_get_linkxstats_size(const struct net_device *dev, int attr)
+{
+	if (attr != IFLA_STATS_LINK_XSTATS)
+		return 0;
+
+	/* Nest header (LINK_XSTATS_TYPE_HSR) + one u64 nla per counter */
+	return nla_total_size(0) +
+	       HSR_XSTATS_CNT_ATTRS * nla_total_size_64bit(sizeof(u64));
+}
+
+/* Put a u64 counter attribute; skip if value is ~0ULL (unsupported). */
+static int hsr_put_stat(struct sk_buff *skb, int attr_id, u64 val)
+{
+	if (val == ~0ULL)
+		return 0;
+	return nla_put_u64_64bit(skb, attr_id, val, HSR_XSTATS_PAD);
+}
+
+static int hsr_fill_linkxstats(struct sk_buff *skb,
+			       const struct net_device *dev,
+			       int *prividx, int attr)
+{
+	struct hsr_lre_stats stats;
+	struct hsr_port *port;
+	struct hsr_priv *hsr = netdev_priv(dev);
+	struct nlattr *nest;
+	int s_prividx = *prividx;
+	int err;
+
+	if (attr != IFLA_STATS_LINK_XSTATS)
+		return 0;
+
+	*prividx = 0;
+
+	nest = nla_nest_start_noflag(skb, LINK_XSTATS_TYPE_HSR);
+	if (!nest)
+		return -EMSGSIZE;
+
+	/* Initialise all counters to ~0ULL ("unsupported") */
+	memset(&stats, 0xff, sizeof(stats));
+
+	/* Ask the offload driver (if any) via ndo_get_offload_stats on slave A.
+	 * Guard with ndo_has_offload_stats so we only call drivers that
+	 * explicitly declare support for IFLA_STATS_LINK_XSTATS, avoiding
+	 * spurious -EINVAL from drivers that implement the NDO for a different
+	 * attr_id (e.g. IFLA_OFFLOAD_XSTATS_CPU_HIT).
+	 */
+	port = hsr_port_get_hsr(hsr, HSR_PT_SLAVE_A);
+	if (port) {
+		const struct net_device_ops *ops = port->dev->netdev_ops;
+
+		if (ops->ndo_has_offload_stats &&
+		    ops->ndo_has_offload_stats(port->dev,
+					       IFLA_STATS_LINK_XSTATS) &&
+		    ops->ndo_get_offload_stats) {
+			err = ops->ndo_get_offload_stats(IFLA_STATS_LINK_XSTATS,
+							 port->dev, &stats);
+			if (err && err != -EOPNOTSUPP) {
+				nla_nest_cancel(skb, nest);
+				return err;
+			}
+		}
+	}
+
+#define PUT_STAT(attr, field) \
+	do { \
+		if (HSR_XSTATS_##attr < s_prividx) \
+			break; \
+		if (hsr_put_stat(skb, HSR_XSTATS_##attr, stats.field)) { \
+			*prividx = HSR_XSTATS_##attr; \
+			nla_nest_end(skb, nest); \
+			return -EMSGSIZE; \
+		} \
+	} while (0)
+
+	PUT_STAT(CNT_TX_A,		cnt_tx_a);
+	PUT_STAT(CNT_TX_B,		cnt_tx_b);
+	PUT_STAT(CNT_TX_C,		cnt_tx_c);
+	PUT_STAT(CNT_RX_A,		cnt_rx_a);
+	PUT_STAT(CNT_RX_B,		cnt_rx_b);
+	PUT_STAT(CNT_RX_C,		cnt_rx_c);
+	PUT_STAT(CNT_ERR_WRONG_LAN_A,	cnt_err_wrong_lan_a);
+	PUT_STAT(CNT_ERR_WRONG_LAN_B,	cnt_err_wrong_lan_b);
+	PUT_STAT(CNT_ERR_WRONG_LAN_C,	cnt_err_wrong_lan_c);
+	PUT_STAT(CNT_ERRORS_A,		cnt_errors_a);
+	PUT_STAT(CNT_ERRORS_B,		cnt_errors_b);
+	PUT_STAT(CNT_ERRORS_C,		cnt_errors_c);
+	PUT_STAT(CNT_UNIQUE_A,		cnt_unique_a);
+	PUT_STAT(CNT_UNIQUE_B,		cnt_unique_b);
+	PUT_STAT(CNT_UNIQUE_C,		cnt_unique_c);
+	PUT_STAT(CNT_DUPLICATE_A,	cnt_duplicate_a);
+	PUT_STAT(CNT_DUPLICATE_B,	cnt_duplicate_b);
+	PUT_STAT(CNT_DUPLICATE_C,	cnt_duplicate_c);
+	PUT_STAT(CNT_MULTI_A,		cnt_multi_a);
+	PUT_STAT(CNT_MULTI_B,		cnt_multi_b);
+	PUT_STAT(CNT_MULTI_C,		cnt_multi_c);
+	PUT_STAT(CNT_OWN_RX_A,		cnt_own_rx_a);
+	PUT_STAT(CNT_OWN_RX_B,		cnt_own_rx_b);
+
+#undef PUT_STAT
+
+	nla_nest_end(skb, nest);
+	return 0;
+}
+
 static struct rtnl_link_ops hsr_link_ops __read_mostly = {
-	.kind		= "hsr",
-	.maxtype	= IFLA_HSR_MAX,
-	.policy		= hsr_policy,
-	.priv_size	= sizeof(struct hsr_priv),
-	.setup		= hsr_dev_setup,
-	.newlink	= hsr_newlink,
-	.dellink	= hsr_dellink,
-	.fill_info	= hsr_fill_info,
+	.kind			= "hsr",
+	.maxtype		= IFLA_HSR_MAX,
+	.policy			= hsr_policy,
+	.priv_size		= sizeof(struct hsr_priv),
+	.setup			= hsr_dev_setup,
+	.newlink		= hsr_newlink,
+	.dellink		= hsr_dellink,
+	.fill_info		= hsr_fill_info,
+	.get_linkxstats_size	= hsr_get_linkxstats_size,
+	.fill_linkxstats	= hsr_fill_linkxstats,
 };
 
 /* attribute policy */
diff --git a/tools/include/uapi/linux/if_link.h b/tools/include/uapi/linux/if_link.h
index 7e46ca4cd31bb..13f122996d01a 100644
--- a/tools/include/uapi/linux/if_link.h
+++ b/tools/include/uapi/linux/if_link.h
@@ -1844,6 +1844,7 @@ enum {
 	LINK_XSTATS_TYPE_UNSPEC,
 	LINK_XSTATS_TYPE_BRIDGE,
 	LINK_XSTATS_TYPE_BOND,
+	LINK_XSTATS_TYPE_HSR,
 	__LINK_XSTATS_TYPE_MAX
 };
 #define LINK_XSTATS_TYPE_MAX (__LINK_XSTATS_TYPE_MAX - 1)
-- 
2.34.1


^ permalink raw reply related

* [PATCH net-next v3 0/3] Add standard stats for HSR/PRP
From: MD Danish Anwar @ 2026-06-08 10:09 UTC (permalink / raw)
  To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Simon Horman, Jonathan Corbet, Shuah Khan, MD Danish Anwar,
	Roger Quadros, Andrew Lunn, Jacob Keller, Meghana Malladi,
	David Carlier, Vadim Fedorenko, Kevin Hao, Himanshu Mittal,
	Hangbin Liu, Markus Elfring, Fernando Fernandez Mancera,
	Jan Vaclav
  Cc: netdev, linux-doc, linux-kernel, linux-arm-kernel, Felix Maurer,
	Luka Gejak

Add standard stats for HSR / PRP. This series was initially adding HSR/PRP
related stats for ICSSG driver. Based on maintainers' comments on v2 I am
now adding support to dump standard stats for HSR/PRP.

The drivers which support offload can populate these standard stats.

This series only implements offloaded stats. For software-only interfaces
Felix Maurer had said he will do it later [1]

v2 https://lore.kernel.org/all/20260514075605.850674-1-danishanwar@ti.com/
[1] https://lore.kernel.org/all/ag87pBZfOyccPZTc@thinkpad/

Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Felix Maurer <fmaurer@redhat.com>
Cc: Luka Gejak <luka.gejak@linux.dev>

MD Danish Anwar (3):
  net: hsr: Add standard LRE stats via RTM_GETSTATS /
    IFLA_STATS_LINK_XSTATS
  net: ti: icssg: Add static_assert to guard stat array counts
  net: ti: icssg: Add HSR offload statistics support

 .../ethernet/ti/icssg_prueth.rst              |  19 +++
 drivers/net/ethernet/ti/icssg/icssg_common.c  |   7 +-
 drivers/net/ethernet/ti/icssg/icssg_ethtool.c |  10 +-
 drivers/net/ethernet/ti/icssg/icssg_prueth.c  |  91 ++++++++++++
 drivers/net/ethernet/ti/icssg/icssg_prueth.h  |  10 +-
 drivers/net/ethernet/ti/icssg/icssg_stats.c   |   6 +-
 drivers/net/ethernet/ti/icssg/icssg_stats.h   |  89 +++++++-----
 .../net/ethernet/ti/icssg/icssg_switch_map.h  |  10 ++
 include/linux/if_hsr.h                        |  48 +++++++
 include/uapi/linux/hsr_netlink.h              |  56 ++++++++
 include/uapi/linux/if_link.h                  |   1 +
 net/hsr/hsr_netlink.c                         | 132 ++++++++++++++++--
 tools/include/uapi/linux/if_link.h            |   1 +
 13 files changed, 426 insertions(+), 54 deletions(-)


base-commit: 4aacf509e537a711fa71bca9f234e5eb6968850e
-- 
2.34.1


^ permalink raw reply

* Re: [PATCH v6 06/11] x86/virt/tdx: Optimize tdx_pamt_get/put()
From: Kiryl Shutsemau @ 2026-06-08  9:14 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Chao Gao, Edgecombe, Rick P, kvm@vger.kernel.org,
	linux-coco@lists.linux.dev, Huang, Kai, Zhao, Yan Y,
	seanjc@google.com, mingo@redhat.com, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com, nik.borisov@suse.com,
	linux-doc@vger.kernel.org, hpa@zytor.com, tglx@kernel.org,
	Annapurve, Vishal, bp@alien8.de, kirill.shutemov@linux.intel.com,
	x86@kernel.org
In-Reply-To: <572868d7-4794-4fec-b80f-97d8434d5fb6@intel.com>

On Fri, Jun 05, 2026 at 09:23:21AM -0700, Dave Hansen wrote:
> On 6/5/26 04:42, Kiryl Shutsemau wrote:
> >>> I don't see a reason why we can't keep the scoped_guard() on get side.
> >> One additional reason to drop scoped_guard() is that it mixes cleanup helpers
> >> with goto, which is discouraged. See [*]
> >>
> >>  :Lastly, given that the benefit of cleanup helpers is removal of “goto”, and
> >>  :that the “goto” statement can jump between scopes, the expectation is that
> >>  :usage of “goto” and cleanup helpers is never mixed in the same function.
> > Fair enough.
> > 
> > But it can also be address if we free the PAMT page array with the guard
> > too :P
> 
> How important is this patch? I see "Optimize" but I read "Optional".
> 
> If we're arguing about it, maybe we should just kick it out and focus on
> the more important bits.

I don't think it is optional for anything outside of test setup.

Without the optimization, we have all KVM memory allocations serialized
on a single spinlock. And we do alloc_pamt_array()/free_pamt_array() all
the time too.

And since the lock is global, it is an easy DoS attack vector: one guest
can do a shared->private->shared conversion loop and make every guest on
the host suffer.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

^ permalink raw reply

* Re: [PATCH v7 10/42] KVM: guest_memfd: Ensure pages are not in use before conversion
From: Vlastimil Babka (SUSE) @ 2026-06-08  8:55 UTC (permalink / raw)
  To: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
	david, ira.weiny, jmattson, jthoughton, michael.roth, oupton,
	pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
	steven.price, tabba, willy, wyihan, yan.y.zhao, forkloop,
	pratyush, suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
	Sean Christopherson, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
	Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
	Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
	Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
	Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
	Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe
  Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
	linux-mm, linux-coco
In-Reply-To: <20260522-gmem-inplace-conversion-v7-10-2f0fae496530@google.com>

On 5/23/26 02:17, Ackerley Tng via B4 Relay wrote:
> From: Ackerley Tng <ackerleytng@google.com>
> 
> When converting memory to private in guest_memfd, it is necessary to ensure
> that the pages are not currently being accessed by any other part of the
> kernel or userspace to avoid any current user writing to guest private
> memory.
> 
> guest_memfd checks for unexpected refcounts to determine whether a page is
> still in use. The only expected refcounts after unmapping the range
> requested for conversion are those that are held by guest_memfd itself.

Is it sufficient to only check, and not also freeze the refcount? (i.e.
using folio_ref_freeze()), because without freezing, anything (e.g.
compaction's pfn-based scanner) could do a speculative folio_try_get() and
the checked refcount becomes stale.

Might be ok if we know that no such speculative increment can result in
actually touching the page contents, and the extra refcount and something
inspecting the struct folio won't interfere with anything else. Then it
could be just a comment mentioning why it's safe.

IIRC the compaction's scanning can result in a migration here so it's
probably ok?

> Update the kvm_memory_attributes2 structure to include an error_offset
> field. This allows KVM to report the exact offset where a conversion
> failed to userspace. If the safety check fails, return -EAGAIN and copy
> the error_offset back to userspace so that it can potentially retry the
> operation or handle the failure gracefully.
> 
> Suggested-by: David Hildenbrand <david@kernel.org>
> Co-developed-by: Vishal Annapurve <vannapurve@google.com>
> Signed-off-by: Vishal Annapurve <vannapurve@google.com>
> Reviewed-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
>  include/uapi/linux/kvm.h |  3 ++-
>  virt/kvm/guest_memfd.c   | 68 ++++++++++++++++++++++++++++++++++++++++++++----
>  2 files changed, 65 insertions(+), 6 deletions(-)
> 
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index e6bbf68a83813..0b55258573d3d 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1658,7 +1658,8 @@ struct kvm_memory_attributes2 {
>  	__u64 size;
>  	__u64 attributes;
>  	__u64 flags;
> -	__u64 reserved[12];
> +	__u64 error_offset;
> +	__u64 reserved[11];
>  };
>  
>  #define KVM_MEMORY_ATTRIBUTE_PRIVATE           (1ULL << 3)
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 426917d22a2b6..2767992955752 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -572,9 +572,45 @@ static int kvm_gmem_mas_preallocate(struct ma_state *mas, u64 attributes,
>  	return mas_preallocate(mas, xa_mk_value(attributes), GFP_KERNEL);
>  }
>  
> +static bool kvm_gmem_is_safe_for_conversion(struct inode *inode, pgoff_t start,
> +					    size_t nr_pages, pgoff_t *err_index)
> +{
> +	struct address_space *mapping = inode->i_mapping;
> +	const int filemap_get_folios_refcount = 1;
> +	pgoff_t last = start + nr_pages - 1;
> +	struct folio_batch fbatch;
> +	bool safe = true;
> +	pgoff_t next;
> +	int i;
> +
> +	folio_batch_init(&fbatch);
> +
> +	next = start;
> +	while (safe && filemap_get_folios(mapping, &next, last, &fbatch)) {
> +
> +		for (i = 0; i < folio_batch_count(&fbatch); ++i) {
> +			struct folio *folio = fbatch.folios[i];
> +
> +			if (folio_ref_count(folio) !=
> +			    folio_nr_pages(folio) + filemap_get_folios_refcount) {
> +				safe = false;
> +				*err_index = max(start, folio->index);
> +				break;
> +			}
> +		}
> +
> +		folio_batch_release(&fbatch);
> +		cond_resched();
> +	}
> +
> +	return safe;
> +}
> +
>  static int __kvm_gmem_set_attributes(struct inode *inode, pgoff_t start,
> -				     size_t nr_pages, uint64_t attrs)
> +				     size_t nr_pages, uint64_t attrs,
> +				     pgoff_t *err_index)
>  {
> +	bool to_private = attrs & KVM_MEMORY_ATTRIBUTE_PRIVATE;
>  	struct address_space *mapping = inode->i_mapping;
>  	struct gmem_inode *gi = GMEM_I(inode);
>  	pgoff_t end = start + nr_pages;
> @@ -588,8 +624,21 @@ static int __kvm_gmem_set_attributes(struct inode *inode, pgoff_t start,
>  
>  	mas_init(&mas, mt, start);
>  	r = kvm_gmem_mas_preallocate(&mas, attrs, start, nr_pages);
> -	if (r)
> +	if (r) {
> +		*err_index = start;
>  		goto out;
> +	}
> +
> +	if (to_private) {
> +		unmap_mapping_pages(mapping, start, nr_pages, false);
> +
> +		if (!kvm_gmem_is_safe_for_conversion(inode, start, nr_pages,
> +						     err_index)) {
> +			mas_destroy(&mas);
> +			r = -EAGAIN;
> +			goto out;
> +		}
> +	}
>  
>  	/*
>  	 * From this point on guest_memfd has performed necessary
> @@ -609,9 +658,10 @@ static long kvm_gmem_set_attributes(struct file *file, void __user *argp)
>  	struct gmem_file *f = file->private_data;
>  	struct inode *inode = file_inode(file);
>  	struct kvm_memory_attributes2 attrs;
> +	pgoff_t err_index;
>  	size_t nr_pages;
>  	pgoff_t index;
> -	int i;
> +	int i, r;
>  
>  	if (copy_from_user(&attrs, argp, sizeof(attrs)))
>  		return -EFAULT;
> @@ -635,8 +685,16 @@ static long kvm_gmem_set_attributes(struct file *file, void __user *argp)
>  
>  	nr_pages = attrs.size >> PAGE_SHIFT;
>  	index = attrs.offset >> PAGE_SHIFT;
> -	return __kvm_gmem_set_attributes(inode, index, nr_pages,
> -					 attrs.attributes);
> +	r = __kvm_gmem_set_attributes(inode, index, nr_pages, attrs.attributes,
> +				      &err_index);
> +	if (r) {
> +		attrs.error_offset = ((uint64_t)err_index) << PAGE_SHIFT;
> +
> +		if (copy_to_user(argp, &attrs, sizeof(attrs)))
> +			return -EFAULT;
> +	}
> +
> +	return r;
>  }
>  
>  static long kvm_gmem_ioctl(struct file *file, unsigned int ioctl,
> 


^ permalink raw reply

* Re: [PATCH v16 08/10] powerpc/kexec_file: Use crash_exclude_core_ranges() helper
From: Breno Leitao @ 2026-06-08  8:48 UTC (permalink / raw)
  To: Jinjie Ruan
  Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
	mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
	dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
	pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
	dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
	coxu, Liam.Howlett, ryan.roberts, osandov, jbohac, cfsworks,
	tangyouling, sourabhjain, ritesh.list, adityag, liaoyuanhong,
	seanjc, fuqiang.wang, ardb, chenjiahao16, guoren, x86, linux-doc,
	linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
	linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-9-ruanjinjie@huawei.com>

On Mon, Jun 08, 2026 at 03:34:57PM +0800, Jinjie Ruan wrote:
> The crash memory exclude of crashk_res and crashk_cma memory on powerpc
> are almost identical to the generic crash_exclude_core_ranges().
> 
> By introducing the architecture-specific arch_crash_exclude_mem_range()
> function with a default implementation of crash_exclude_mem_range(),
> and using crash_exclude_mem_range_guarded as powerpc's separate
> implementation, the generic crash_exclude_core_ranges() helper function
> can be reused.
> 
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Acked-by: Baoquan He <bhe@redhat.com>
> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>

Acked-by: Breno leitao <leitao@debian.org>

^ permalink raw reply

* Re: [PATCH v7 14/42] KVM: guest_memfd: Handle lru_add fbatch refcounts during conversion safety check
From: Vlastimil Babka (SUSE) @ 2026-06-08  8:45 UTC (permalink / raw)
  To: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
	david, ira.weiny, jmattson, jthoughton, michael.roth, oupton,
	pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
	steven.price, tabba, willy, wyihan, yan.y.zhao, forkloop,
	pratyush, suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
	Sean Christopherson, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
	Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
	Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
	Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
	Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
	Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe
  Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
	linux-mm, linux-coco
In-Reply-To: <20260522-gmem-inplace-conversion-v7-14-2f0fae496530@google.com>

On 5/23/26 02:17, Ackerley Tng via B4 Relay wrote:
> From: Ackerley Tng <ackerleytng@google.com>
> 
> When checking if a guest_memfd folio is safe for conversion, its refcount
> is examined. A folio may be present in a per-CPU lru_add fbatch, which
> temporarily increases its refcount. This can lead to a false positive,
> incorrectly indicating that the folio is in use and preventing the
> conversion, even if it is otherwise safe. The conversion process might not
> be on the same CPU that holds the folio in its fbatch, making a simple
> per-CPU check insufficient.
> 
> To address this, drain all CPUs' lru_add fbatches if an unexpectedly high
> refcount is encountered during the safety check. This is performed at most
> once per conversion request. Draining only if the folio in question may be
> lru cached.
> 
> guest_memfd folios are unevictable, so they can only reside in the lru_add
> fbatch. If the folio's refcount is still unsafe after draining, then the
> conversion is truly deemed unsafe.
> 
> Reviewed-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>

Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>


^ permalink raw reply

* Re: [PATCH v3 4/6] alloc_tag: add accuracy based filtering to ioctl
From: Hao Ge @ 2026-06-08  8:24 UTC (permalink / raw)
  To: Abhishek Bapat
  Cc: Shuah Khan, Jonathan Corbet, linux-doc, linux-kernel, linux-mm,
	Sourav Panda, Suren Baghdasaryan, Andrew Morton, Kent Overstreet
In-Reply-To: <1ec17313-cd2b-4389-a05d-998757af30b3@linux.dev>


On 2026/6/8 14:22, Hao Ge wrote:
> Hi Abhishek
>
>
> On 2026/6/6 07:36, Abhishek Bapat wrote:
>> Extend the allocinfo filtering mechanism to allow users to filter tags
>> based on their accuracy.
>>
>> Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
>> ---
>>   include/uapi/linux/alloc_tag.h | 3 +++
>>   lib/alloc_tag.c                | 8 ++++++++
>>   2 files changed, 11 insertions(+)
>>
>> diff --git a/include/uapi/linux/alloc_tag.h 
>> b/include/uapi/linux/alloc_tag.h
>> index 0e648192df4d..42445bdb11c5 100644
>> --- a/include/uapi/linux/alloc_tag.h
>> +++ b/include/uapi/linux/alloc_tag.h
>> @@ -20,6 +20,7 @@ struct allocinfo_tag {
>>       char function[ALLOCINFO_STR_SIZE];
>>       char filename[ALLOCINFO_STR_SIZE];
>>       __u64 lineno;
>> +    __u64 inaccurate;
>
>
> I was wondering if it would make sense to define inaccurate as a flags 
> field
>
> (e.g. __u64 flags with ALLOCINFO_TAG_F_INACCURATE (1 <<0)),
>
> so that only bit 0 is used today and the upper bits are reserved for 
> future use,
>
> aligning with current kernel codebase.
>
> This design also allows for better extensibility if we need to
>
> add new flags for any reason in the future.
>
> We also need to add flag validity checks if we go this route.
>
And I've reviewed the issue reported by Sashiko, and I think it's valid.

When we expand the allocinfo_tag_data structure

struct allocinfo_tag_data{

     char modname[64];

     char function[64];

     char filename[64];

     __u64 lineno;

     __u64 inaccurate;

     __u64 bytes;

     __u64 calls;

     __u8 accurate;
   /* padding */

}

I think user space may see two fields related to inaccuracy.

How do you like these modifications?


diff --git a/include/uapi/linux/alloc_tag.h b/include/uapi/linux/alloc_tag.h
--- a/include/uapi/linux/alloc_tag.h
+++ b/include/uapi/linux/alloc_tag.h
@@ -20,7 +20,6 @@ struct allocinfo_tag {
      char function[ALLOCINFO_STR_SIZE];
      char filename[ALLOCINFO_STR_SIZE];
      __u64 lineno;
-    __u64 inaccurate;
  };

  /* The alignment ensures 32-bit compatible interfaces are not broken */
@@ -40,7 +39,7 @@ enum {
      ALLOCINFO_FILTER_FUNCTION,
      ALLOCINFO_FILTER_FILENAME,
      ALLOCINFO_FILTER_LINENO,
-    ALLOCINFO_FILTER_INACCURATE,
+    ALLOCINFO_FILTER_FLAGS,
      ALLOCINFO_FILTER_MIN_SIZE,
      ALLOCINFO_FILTER_MAX_SIZE,
      __ALLOCINFO_FILTER_LAST = ALLOCINFO_FILTER_MAX_SIZE
@@ -50,16 +49,20 @@ enum {
  #define ALLOCINFO_FILTER_MASK_FUNCTION        (1 << 
ALLOCINFO_FILTER_FUNCTION)
  #define ALLOCINFO_FILTER_MASK_FILENAME        (1 << 
ALLOCINFO_FILTER_FILENAME)
  #define ALLOCINFO_FILTER_MASK_LINENO        (1 << ALLOCINFO_FILTER_LINENO)
-#define ALLOCINFO_FILTER_MASK_INACCURATE    (1 << 
ALLOCINFO_FILTER_INACCURATE)
+#define ALLOCINFO_FILTER_MASK_FLAGS        (1 << ALLOCINFO_FILTER_FLAGS)
  #define ALLOCINFO_FILTER_MASK_MIN_SIZE        (1 << 
ALLOCINFO_FILTER_MIN_SIZE)
  #define ALLOCINFO_FILTER_MASK_MAX_SIZE        (1 << 
ALLOCINFO_FILTER_MAX_SIZE)

  #define ALLOCINFO_FILTER_MASKS \
      ((1 << (__ALLOCINFO_FILTER_LAST + 1)) - 1)

+#define ALLOCINFO_FILTER_F_INACCURATE    (1ULL << 0)
+#define ALLOCINFO_FILTER_FLAGS_ALL ALLOCINFO_FILTER_F_INACCURATE
+
  struct allocinfo_filter {
      __u64 mask; /* bitmask of the filter fields used */
      struct allocinfo_tag fields;
+    __u64 flags; /* bitmask of ALLOCINFO_FILTER_F_* */
      __u64 min_size;
      __u64 max_size;
  };
diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
--- a/lib/alloc_tag.c
+++ b/lib/alloc_tag.c
@@ -249,8 +249,6 @@ static bool matches_filter(struct codetag *ct, 
struct allocinfo_filter *filter,
                 struct alloc_tag_counters *counters,
                 bool *fetched_counters)
  {
-    bool inaccurate;
-
      if (!filter || !filter->mask)
          return true;

@@ -277,10 +275,11 @@ static bool matches_filter(struct codetag *ct, 
struct allocinfo_filter *filter,
          ct->lineno != filter->fields.lineno)
          return false;

-    if (filter->mask & ALLOCINFO_FILTER_MASK_INACCURATE) {
-        inaccurate = !!(ct->flags & CODETAG_FLAG_INACCURATE);
-        if (inaccurate != !!(filter->fields.inaccurate))
-            return false;
+    if (filter->mask & ALLOCINFO_FILTER_MASK_FLAGS) {
+        if (filter->flags & ALLOCINFO_FILTER_F_INACCURATE) {
+            if (!(ct->flags & CODETAG_FLAG_INACCURATE))
+                return false;
+        }
      }

      if (filter->mask & (ALLOCINFO_FILTER_MASK_MIN_SIZE | 
ALLOCINFO_FILTER_MASK_MAX_SIZE)) {
@@ -318,6 +317,10 @@ static int allocinfo_ioctl_get_at(struct seq_file 
*m, void __user *arg)
      if (params.filter.mask & ~ALLOCINFO_FILTER_MASKS)
          return -EINVAL;

+    if ((params.filter.mask & ALLOCINFO_FILTER_MASK_FLAGS) &&
+        (params.filter.flags & ~ALLOCINFO_FILTER_FLAGS_ALL))
+        return -EINVAL;
+
      if ((params.filter.mask & ALLOCINFO_FILTER_MASK_MIN_SIZE) &&
          (params.filter.mask & ALLOCINFO_FILTER_MASK_MAX_SIZE) &&
          params.filter.min_size > params.filter.max_size)


Thanks

Best Regards

Hao


>
> Thanks
>
> Best Regards
>
> Hao
>
>
>>   };
>>     /* The alignment ensures 32-bit compatible interfaces are not 
>> broken */
>> @@ -39,6 +40,7 @@ enum {
>>       ALLOCINFO_FILTER_FUNCTION,
>>       ALLOCINFO_FILTER_FILENAME,
>>       ALLOCINFO_FILTER_LINENO,
>> +    ALLOCINFO_FILTER_INACCURATE,
>>       ALLOCINFO_FILTER_MIN_SIZE,
>>       ALLOCINFO_FILTER_MAX_SIZE,
>>       __ALLOCINFO_FILTER_LAST = ALLOCINFO_FILTER_MAX_SIZE
>> @@ -48,6 +50,7 @@ enum {
>>   #define ALLOCINFO_FILTER_MASK_FUNCTION        (1 << 
>> ALLOCINFO_FILTER_FUNCTION)
>>   #define ALLOCINFO_FILTER_MASK_FILENAME        (1 << 
>> ALLOCINFO_FILTER_FILENAME)
>>   #define ALLOCINFO_FILTER_MASK_LINENO        (1 << 
>> ALLOCINFO_FILTER_LINENO)
>> +#define ALLOCINFO_FILTER_MASK_INACCURATE    (1 << 
>> ALLOCINFO_FILTER_INACCURATE)
>>   #define ALLOCINFO_FILTER_MASK_MIN_SIZE        (1 << 
>> ALLOCINFO_FILTER_MIN_SIZE)
>>   #define ALLOCINFO_FILTER_MASK_MAX_SIZE        (1 << 
>> ALLOCINFO_FILTER_MAX_SIZE)
>>   diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
>> index ddc6946f56ab..cbcd12c4ef9c 100644
>> --- a/lib/alloc_tag.c
>> +++ b/lib/alloc_tag.c
>> @@ -249,6 +249,8 @@ static bool matches_filter(struct codetag *ct, 
>> struct allocinfo_filter *filter,
>>                  struct alloc_tag_counters *counters,
>>                  bool *fetched_counters)
>>   {
>> +    bool inaccurate;
>> +
>>       if (!filter || !filter->mask)
>>           return true;
>>   @@ -275,6 +277,12 @@ static bool matches_filter(struct codetag *ct, 
>> struct allocinfo_filter *filter,
>>           ct->lineno != filter->fields.lineno)
>>           return false;
>>   +    if (filter->mask & ALLOCINFO_FILTER_MASK_INACCURATE) {
>> +        inaccurate = !!(ct->flags & CODETAG_FLAG_INACCURATE);
>> +        if (inaccurate != !!(filter->fields.inaccurate))
>> +            return false;
>> +    }
>> +
>>       if (filter->mask & (ALLOCINFO_FILTER_MASK_MIN_SIZE | 
>> ALLOCINFO_FILTER_MASK_MAX_SIZE)) {
>>           if (!*fetched_counters) {
>>               *counters = allocinfo_prefetch_counters(ct);

^ permalink raw reply

* Re: [PATCH v16 07/10] LoongArch: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-08  8:23 UTC (permalink / raw)
  To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
	mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
	dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
	pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
	dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
	leitao, coxu, Liam.Howlett, ryan.roberts, osandov, jbohac,
	cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
	liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
	x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
	linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-8-ruanjinjie@huawei.com>



On 6/8/2026 3:34 PM, Jinjie Ruan wrote:
> Use the newly introduced crash_prepare_headers() function to replace
> the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
> memory in the crash core, which reduce code duplication.
> 
> Only the following two architecture functions need to be implemented:
> - arch_get_system_nr_ranges(). Use for_each_mem_range to traverse
>   and pre-count the max number of memory ranges.
> 
> - arch_crash_populate_cmem(). Use for_each_mem_range to traverse
>   and collect the memory ranges and fills them into cmem.
> 
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: WANG Xuerui <kernel@xen0n.name>
> Cc: Youling Tang <tangyouling@kylinos.cn>
> Cc: Baoquan He <bhe@redhat.com>
> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Acked-by: Baoquan He <bhe@redhat.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
>  arch/loongarch/kernel/machine_kexec_file.c | 40 +++++++---------------
>  1 file changed, 12 insertions(+), 28 deletions(-)


The below AI reported TOCTOU bug is an existing artifact and completely
unrelated to the rework here. Therefore, we will skip fixing it in this
series to avoid unnecessary noise.

Link:
https://lore.kernel.org/all/20260608075258.0F6D91F00893@smtp.kernel.org/

> 
> diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
> index 5584b798ba46..5412aa9f3568 100644
> --- a/arch/loongarch/kernel/machine_kexec_file.c
> +++ b/arch/loongarch/kernel/machine_kexec_file.c
> @@ -56,46 +56,30 @@ static void cmdline_add_initrd(struct kimage *image, unsigned long *cmdline_tmpl
>  }
>  
>  #ifdef CONFIG_CRASH_DUMP
> -
> -static int prepare_elf_headers(void **addr, unsigned long *sz)
> +unsigned int arch_get_system_nr_ranges(void)
>  {
> -	int ret, nr_ranges;
> -	uint64_t i;
> +	int nr_ranges = 2; /* for exclusion of crashkernel region */
>  	phys_addr_t start, end;
> -	struct crash_mem *cmem;
> +	uint64_t i;
>  
> -	nr_ranges = 2; /* for exclusion of crashkernel region */
>  	for_each_mem_range(i, &start, &end)
>  		nr_ranges++;
>  
> -	cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> -	if (!cmem)
> -		return -ENOMEM;
> +	return nr_ranges;
> +}
> +
> +int arch_crash_populate_cmem(struct crash_mem *cmem)
> +{
> +	phys_addr_t start, end;
> +	uint64_t i;
>  
> -	cmem->max_nr_ranges = nr_ranges;
> -	cmem->nr_ranges = 0;
>  	for_each_mem_range(i, &start, &end) {
>  		cmem->ranges[cmem->nr_ranges].start = start;
>  		cmem->ranges[cmem->nr_ranges].end = end - 1;
>  		cmem->nr_ranges++;
>  	}
>  
> -	/* Exclude crashkernel region */
> -	ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> -	if (ret < 0)
> -		goto out;
> -
> -	if (crashk_low_res.end) {
> -		ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
> -		if (ret < 0)
> -			goto out;
> -	}
> -
> -	ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> -
> -out:
> -	kfree(cmem);
> -	return ret;
> +	return 0;
>  }
>  
>  /*
> @@ -163,7 +147,7 @@ int load_other_segments(struct kimage *image,
>  		void *headers;
>  		unsigned long headers_sz;
>  
> -		ret = prepare_elf_headers(&headers, &headers_sz);
> +		ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
>  		if (ret < 0) {
>  			pr_err("Preparing elf core header failed\n");
>  			goto out_err;


^ permalink raw reply

* Re: [PATCH v16 05/10] x86: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-08  8:21 UTC (permalink / raw)
  To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
	mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
	dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
	pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
	dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
	leitao, coxu, Liam.Howlett, ryan.roberts, osandov, jbohac,
	cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
	liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
	x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
	linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-6-ruanjinjie@huawei.com>



On 6/8/2026 3:34 PM, Jinjie Ruan wrote:
> Use the newly introduced crash_prepare_headers() function to replace
> the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
> memory in the crash core, which reduce code duplication.
> 
> Only the following three architecture functions need to be implemented:
> - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
>   to pre-count the max number of memory ranges.
> 
> - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
>   to collect the memory ranges and fills them into cmem.
> 
> - arch_crash_exclude_ranges(). Exclude the low 1M for x86.
> 
> By the way, remove the unused "nr_mem_ranges" in
> arch_crash_handle_hotplug_event().

The below AI reported TOCTOU bug is an existing artifact and completely
unrelated to the reowork here. Therefore, we will skip fixing it in this
series to avoid unnecessary noise.

Link:
https://lore.kernel.org/all/20260608074748.58E8E1F00893@smtp.kernel.org/

> 
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Acked-by: Baoquan He <bhe@redhat.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
>  arch/x86/kernel/crash.c | 89 +++++------------------------------------
>  1 file changed, 11 insertions(+), 78 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index cd796818d94d..cb2ce7acfec4 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -153,16 +153,8 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
>  	return 0;
>  }
>  
> -/* Gather all the required information to prepare elf headers for ram regions */
> -static struct crash_mem *fill_up_crash_elf_data(void)
> +unsigned int arch_get_system_nr_ranges(void)
>  {
> -	unsigned int nr_ranges = 0;
> -	struct crash_mem *cmem;
> -
> -	walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> -	if (!nr_ranges)
> -		return NULL;
> -
>  	/*
>  	 * Exclusion of crash region, crashk_low_res and/or crashk_cma_ranges
>  	 * may cause range splits. So add extra slots here.
> @@ -177,49 +169,16 @@ static struct crash_mem *fill_up_crash_elf_data(void)
>  	 * But in order to lest the low 1M could be changed in the future,
>  	 * (e.g. [start, 1M]), add a extra slot.
>  	 */
> -	nr_ranges += 3 + crashk_cma_cnt;
> -	cmem = vzalloc(struct_size(cmem, ranges, nr_ranges));
> -	if (!cmem)
> -		return NULL;
> -
> -	cmem->max_nr_ranges = nr_ranges;
> +	unsigned int nr_ranges = 3 + crashk_cma_cnt;
>  
> -	return cmem;
> +	walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> +	return nr_ranges;
>  }
>  
> -/*
> - * Look for any unwanted ranges between mstart, mend and remove them. This
> - * might lead to split and split ranges are put in cmem->ranges[] array
> - */
> -static int elf_header_exclude_ranges(struct crash_mem *cmem)
> +int arch_crash_exclude_ranges(struct crash_mem *cmem)
>  {
> -	int ret = 0;
> -	int i;
> -
>  	/* Exclude the low 1M because it is always reserved */
> -	ret = crash_exclude_mem_range(cmem, 0, SZ_1M - 1);
> -	if (ret)
> -		return ret;
> -
> -	/* Exclude crashkernel region */
> -	ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> -	if (ret)
> -		return ret;
> -
> -	if (crashk_low_res.end)
> -		ret = crash_exclude_mem_range(cmem, crashk_low_res.start,
> -					      crashk_low_res.end);
> -	if (ret)
> -		return ret;
> -
> -	for (i = 0; i < crashk_cma_cnt; ++i) {
> -		ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
> -					      crashk_cma_ranges[i].end);
> -		if (ret)
> -			return ret;
> -	}
> -
> -	return 0;
> +	return crash_exclude_mem_range(cmem, 0, SZ_1M - 1);
>  }
>  
>  static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
> @@ -233,35 +192,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
>  	return 0;
>  }
>  
> -/* Prepare elf headers. Return addr and size */
> -static int prepare_elf_headers(void **addr, unsigned long *sz,
> -			       unsigned long *nr_mem_ranges)
> +int arch_crash_populate_cmem(struct crash_mem *cmem)
>  {
> -	struct crash_mem *cmem;
> -	int ret;
> -
> -	cmem = fill_up_crash_elf_data();
> -	if (!cmem)
> -		return -ENOMEM;
> -
> -	ret = walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
> -	if (ret)
> -		goto out;
> -
> -	/* Exclude unwanted mem ranges */
> -	ret = elf_header_exclude_ranges(cmem);
> -	if (ret)
> -		goto out;
> -
> -	/* Return the computed number of memory ranges, for hotplug usage */
> -	*nr_mem_ranges = cmem->nr_ranges;
> -
> -	/* By default prepare 64bit headers */
> -	ret = crash_prepare_elf64_headers(cmem, IS_ENABLED(CONFIG_X86_64), addr, sz);
> -
> -out:
> -	vfree(cmem);
> -	return ret;
> +	return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
>  }
>  #endif
>  
> @@ -419,7 +352,8 @@ int crash_load_segments(struct kimage *image)
>  				  .buf_max = ULONG_MAX, .top_down = false };
>  
>  	/* Prepare elf headers and add a segment */
> -	ret = prepare_elf_headers(&kbuf.buffer, &kbuf.bufsz, &pnum);
> +	ret = crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &kbuf.buffer,
> +				    &kbuf.bufsz, &pnum);
>  	if (ret)
>  		return ret;
>  
> @@ -512,7 +446,6 @@ unsigned int arch_crash_get_elfcorehdr_size(void)
>  void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
>  {
>  	void *elfbuf = NULL, *old_elfcorehdr;
> -	unsigned long nr_mem_ranges;
>  	unsigned long mem, memsz;
>  	unsigned long elfsz = 0;
>  
> @@ -530,7 +463,7 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
>  	 * Create the new elfcorehdr reflecting the changes to CPU and/or
>  	 * memory resources.
>  	 */
> -	if (prepare_elf_headers(&elfbuf, &elfsz, &nr_mem_ranges)) {
> +	if (crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &elfbuf, &elfsz, NULL)) {
>  		pr_err("unable to create new elfcorehdr");
>  		goto out;
>  	}


^ permalink raw reply

* RE: [PATCH 01/11] net: wwan: t9xx: Add PCIe core
From: Wu. JackBB (GSM) @ 2026-06-08  8:16 UTC (permalink / raw)
  To: Jagielski, Jedrzej, Loic Poulain, Sergey Ryazanov, Johannes Berg,
	Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng,
	Matthias Brugger, AngeloGioacchino Del Regno, Simon Horman,
	Jonathan Corbet, Shuah Khan
  Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <bfecf94780ad458b91a26d18d832cdd1@compal.com>

> > > Sent: Friday, May 29, 2026 12:32 PM
> > >
> > > > +
> > >
> > > please also take a look on sashiko notes, there is some number of them
> >
> > Hi Jagielski,
> >
> > Thank you for your review. We have fixed some issues and are still
> > discussing others with MediaTek. All of them will be addressed in V2.
> >
> > Regarding sashiko notes, how should I handle them if discussion is needed? I
> > cannot find sashiko's email address, and its website does not have a reply
> > option.
> >
>
> I guess discussion is needed when any of the reviewers directly refers
> to any of the notes posted by sashiko.
>
> If any of the notes was not directly pointed out by anybody please just
> check which of sashiko notes are valid and fix them respectively
> if needed.
>
>
> > For example:
> > https://sashiko.dev/#/patchset/20260529-t9xx_driver_v1-v1-0-bdbfe2c01e57%40compal.com?part=2
> >
> > Q1: The commit message mentions implementing TX and RX services, but the
> > patch primarily adds empty structures and boilerplate code. Is the patch
> > missing the actual TX/RX implementation described here?
> >
> > Reply:
> > We plan to update the commit message. Would the following be acceptable?
>
> I believe if you want to check if sashiko has no any longer problems with it
> you
> need to send v2 and check that way, unless im not aware of something
>
> >
> > Add the control plane transaction layer framework for the t9xx
> > WWAN driver, including configuration options, device structure
> > definitions, and initialization/cleanup functions.
> >
> > The actual TX/RX service implementations that use this framework
> > are introduced in subsequent patches.
> >
> >
> > Thanks.

Hi Jagielski,

Thank you for the clarification. It makes perfect sense now.

Regarding the sashiko notes, there are a few that we believe are false
positives or do not require modifications based on our hardware design.
Since nobody has directly pointed them out, we will address only the
valid ones and leave the rest unchanged for V2.

As for the V2 submission timing, I am still waiting for feedback from the
WWAN maintainers/reviewers, specifically:
- Loic Poulain <loic.poulain@oss.qualcomm.com>
- Sergey Ryazanov <ryazanov.s.a@gmail.com>
- Johannes Berg <johannes@sipsolutions.net>

Should I wait until I receive comments from all of them before spinning V2,
or is it acceptable to send V2 once the current feedback has been addressed?

Thanks,
Jack


================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================

^ permalink raw reply

* Re: [PATCH v16 06/10] riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-08  8:08 UTC (permalink / raw)
  To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
	mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
	dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
	pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
	dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
	leitao, coxu, Liam.Howlett, ryan.roberts, osandov, jbohac,
	cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
	liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
	x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
	linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-7-ruanjinjie@huawei.com>



On 6/8/2026 3:34 PM, Jinjie Ruan wrote:
> Use the newly introduced crash_prepare_headers() function to replace
> the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
> memory in the crash core, which reduce code duplication.
> 
> Only the following two architecture functions need to be implemented:
> - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
>   to pre-counts the max number of memory ranges.
> 
> - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
>   to collects the memory ranges and fills them into cmem.


The below AI reported TOCTOU bug is an existing artifact and completely
unrelated to the core CMA implementation introduced here. Therefore, we
will skip fixing it in this series to avoid unnecessary noise.

Link:
https://lore.kernel.org/all/20260608075420.8C5871F00893@smtp.kernel.org/

> 
> Cc: Paul Walmsley <pjw@kernel.org>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Albert Ou <aou@eecs.berkeley.edu>
> Cc: Alexandre Ghiti <alex@ghiti.fr>
> Cc: Guo Ren <guoren@kernel.org>
> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Acked-by: Baoquan He <bhe@redhat.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
>  arch/riscv/kernel/machine_kexec_file.c | 47 +++++++-------------------
>  1 file changed, 12 insertions(+), 35 deletions(-)
> 
> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 3f7766057cac..439cbc50dfa6 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
> @@ -44,6 +44,15 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
>  	return 0;
>  }
>  
> +unsigned int arch_get_system_nr_ranges(void)
> +{
> +	unsigned int nr_ranges = 2; /* For exclusion of crashkernel region */
> +
> +	walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> +
> +	return nr_ranges;
> +}
> +
>  static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
>  {
>  	struct crash_mem *cmem = arg;
> @@ -55,41 +64,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
>  	return 0;
>  }
>  
> -static int prepare_elf_headers(void **addr, unsigned long *sz)
> +int arch_crash_populate_cmem(struct crash_mem *cmem)
>  {
> -	struct crash_mem *cmem;
> -	unsigned int nr_ranges;
> -	int ret;
> -
> -	nr_ranges = 2; /* For exclusion of crashkernel region */
> -	walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> -
> -	cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> -	if (!cmem)
> -		return -ENOMEM;
> -
> -	cmem->max_nr_ranges = nr_ranges;
> -	cmem->nr_ranges = 0;
> -	ret = walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
> -	if (ret)
> -		goto out;
> -
> -	/* Exclude crashkernel region */
> -	ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> -	if (ret)
> -		goto out;
> -
> -	if (crashk_low_res.end) {
> -		ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
> -		if (ret)
> -			goto out;
> -	}
> -
> -	ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> -
> -out:
> -	kfree(cmem);
> -	return ret;
> +	return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
>  }
>  
>  static char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
> @@ -281,7 +258,7 @@ int load_extra_segments(struct kimage *image, unsigned long kernel_start,
>  	if (image->type == KEXEC_TYPE_CRASH) {
>  		void *headers;
>  		unsigned long headers_sz;
> -		ret = prepare_elf_headers(&headers, &headers_sz);
> +		ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
>  		if (ret) {
>  			pr_err("Preparing elf core header failed\n");
>  			goto out;


^ permalink raw reply

* Re: [PATCH v16 04/10] arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-08  8:07 UTC (permalink / raw)
  To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
	mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
	dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
	pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
	dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
	leitao, coxu, Liam.Howlett, ryan.roberts, osandov, jbohac,
	cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
	liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
	x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
	linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-5-ruanjinjie@huawei.com>


The below AI reported TOCTOU bug is an existing artifact and completely
unrelated to the core CMA implementation introduced here. Therefore, we
will skip fixing it in this series to avoid unnecessary noise.

Link:
https://lore.kernel.org/all/20260608075628.039FC1F00893@smtp.kernel.org/

On 6/8/2026 3:34 PM, Jinjie Ruan wrote:
> Use the newly introduced crash_prepare_headers() function to replace
> the existing prepare_elf_headers(), allocate cmem and exclude crash
> kernel memory in the crash core, which reduce code duplication.
> 
> Only the following two architecture functions need to be implemented:
> - arch_get_system_nr_ranges(). Use for_each_mem_range() to traverse
>   and pre-count the max number of memory ranges.
> 
> - arch_crash_populate_cmem(). Use for_each_mem_range to traverse
>   and collect the memory ranges and fills them into cmem.
> 
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Acked-by: Baoquan He <bhe@redhat.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
>  arch/arm64/kernel/machine_kexec_file.c | 40 ++++++++------------------
>  1 file changed, 12 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index e31fabed378a..b019b31df48c 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -40,46 +40,30 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
>  }
>  
>  #ifdef CONFIG_CRASH_DUMP
> -static int prepare_elf_headers(void **addr, unsigned long *sz)
> +unsigned int arch_get_system_nr_ranges(void)
>  {
> -	struct crash_mem *cmem;
> -	unsigned int nr_ranges;
> -	int ret;
> -	u64 i;
> +	unsigned int nr_ranges = 2; /* for exclusion of crashkernel region */
>  	phys_addr_t start, end;
> +	u64 i;
>  
> -	nr_ranges = 2; /* for exclusion of crashkernel region */
>  	for_each_mem_range(i, &start, &end)
>  		nr_ranges++;
>  
> -	cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> -	if (!cmem)
> -		return -ENOMEM;
> +	return nr_ranges;
> +}
> +
> +int arch_crash_populate_cmem(struct crash_mem *cmem)
> +{
> +	phys_addr_t start, end;
> +	u64 i;
>  
> -	cmem->max_nr_ranges = nr_ranges;
> -	cmem->nr_ranges = 0;
>  	for_each_mem_range(i, &start, &end) {
>  		cmem->ranges[cmem->nr_ranges].start = start;
>  		cmem->ranges[cmem->nr_ranges].end = end - 1;
>  		cmem->nr_ranges++;
>  	}
>  
> -	/* Exclude crashkernel region */
> -	ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> -	if (ret)
> -		goto out;
> -
> -	if (crashk_low_res.end) {
> -		ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
> -		if (ret)
> -			goto out;
> -	}
> -
> -	ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> -
> -out:
> -	kfree(cmem);
> -	return ret;
> +	return 0;
>  }
>  #endif
>  
> @@ -109,7 +93,7 @@ int load_other_segments(struct kimage *image,
>  	void *headers;
>  	unsigned long headers_sz;
>  	if (image->type == KEXEC_TYPE_CRASH) {
> -		ret = prepare_elf_headers(&headers, &headers_sz);
> +		ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
>  		if (ret) {
>  			pr_err("Preparing elf core header failed\n");
>  			goto out_err;


^ permalink raw reply

* Re: [PATCH v16 01/10] riscv: kexec_file: Fix crashk_low_res not exclude bug
From: Jinjie Ruan @ 2026-06-08  8:05 UTC (permalink / raw)
  To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
	mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
	dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
	pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
	dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
	leitao, coxu, Liam.Howlett, ryan.roberts, osandov, jbohac,
	cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
	liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
	x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
	linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-2-ruanjinjie@huawei.com>



On 6/8/2026 3:34 PM, Jinjie Ruan wrote:
> As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
> and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for
> crashkres_low.") for arm64, while implementing crashkernel=X,[high,low],
> riscv should have excluded the "crashk_low_res" reserved ranges from
> the crash kernel memory to prevent them from being exported through
> /proc/vmcore, and the exclusion would need an extra crash_mem range.
> 
> Just simply tested on qemu with crashkernel=4G with kexec in [1] mentioned
> in [2]. And the second kernel can be started normally.
> 
> 	# dmesg | grep crash
> 	[    0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB)
> 	[    0.000000] crashkernel reserved: 0x000000017fe00000 - 0x000000027fe00000 (4096 MB)
> 
> Cc: Guo Ren <guoren@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> [1]: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
> [2]: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/
> Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]")
> Reviewed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>


The below AI reported TOCTOU bug is an existing artifact and completely
unrelated to this fix here. Therefore, we will skip fixing it in this
series to avoid unnecessary noise.

Link:
https://lore.kernel.org/all/20260608074809.EE4201F00893@smtp.kernel.org/

> ---
>  arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 54e2d9552e93..3f7766057cac 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
> @@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>  	unsigned int nr_ranges;
>  	int ret;
>  
> -	nr_ranges = 1; /* For exclusion of crashkernel region */
> +	nr_ranges = 2; /* For exclusion of crashkernel region */
>  	walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
>  
>  	cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> @@ -76,8 +76,16 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>  
>  	/* Exclude crashkernel region */
>  	ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> -	if (!ret)
> -		ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> +	if (ret)
> +		goto out;
> +
> +	if (crashk_low_res.end) {
> +		ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
> +		if (ret)
> +			goto out;
> +	}
> +
> +	ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>  
>  out:
>  	kfree(cmem);


^ permalink raw reply

* Re: [PATCH v2] docs/mm/slab: document cache isolation with SLAB_NO_MERGE
From: Mohammed EL Kadiri @ 2026-06-08  7:56 UTC (permalink / raw)
  To: Vlastimil Babka (SUSE)
  Cc: Jonathan Corbet, Andrew Morton, Vlastimil Babka, Matthew Wilcox,
	David Hildenbrand, Lorenzo Stoakes, Kees Cook, linux-mm,
	linux-doc, linux-hardening, linux-kernel
In-Reply-To: <7906bad7-4e64-40c0-a724-f55ac44e12ab@kernel.org>

Hi Vlastimil, Vishal,

Thank you both for the honest feedback.

Vlastimil, understood, I will drop this patch. I can send a small
patch adding a comment above the SLAB_NO_MERGE define if that would
be useful. Otherwise I will focus on code contributions going
forward, written and reviewed manually. Appreciate the guidance.

I will follow Vishal's feedback and send new iterations as separate
threads going forward.

Thanks,
Mohammed

^ permalink raw reply

* Re: [PATCH net-next v4 15/16] dt-bindings: net: add onsemi's S2500
From: Krzysztof Kozlowski @ 2026-06-08  7:53 UTC (permalink / raw)
  To: Selvamani Rajagopal
  Cc: Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit, Russell King,
	David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Andrew Lunn, Parthiban Veerasooran, Richard Cochran, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Simon Horman, Jonathan Corbet,
	Shuah Khan, netdev, linux-kernel, devicetree, linux-doc,
	Jerry Ray
In-Reply-To: <20260605-s2500-mac-phy-support-v4-15-de0fbc13c6d8@onsemi.com>

On Fri, Jun 05, 2026 at 10:42:46PM -0700, Selvamani Rajagopal wrote:
> Add YAML device tree binding for the onsemi S2500 IEEE 802.3cg
> compliant Ethernet transceiver device.
> 
> We use IRQF_TRIGGER_FALLING, though OPEN Alliance 10BASE-T1x
> Serial Interface specification calls for IRQF_TRIGGER_LOW.

Ah, and keep correct order of patches.

Please organize the patch documenting the compatible (DT bindings)
before the patch using that compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH net-next v4 15/16] dt-bindings: net: add onsemi's S2500
From: Krzysztof Kozlowski @ 2026-06-08  7:52 UTC (permalink / raw)
  To: Selvamani Rajagopal
  Cc: Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit, Russell King,
	David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Andrew Lunn, Parthiban Veerasooran, Richard Cochran, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Simon Horman, Jonathan Corbet,
	Shuah Khan, netdev, linux-kernel, devicetree, linux-doc,
	Jerry Ray
In-Reply-To: <20260605-s2500-mac-phy-support-v4-15-de0fbc13c6d8@onsemi.com>

On Fri, Jun 05, 2026 at 10:42:46PM -0700, Selvamani Rajagopal wrote:
> Add YAML device tree binding for the onsemi S2500 IEEE 802.3cg

s/YAML//

> compliant Ethernet transceiver device.
> 
> We use IRQF_TRIGGER_FALLING, though OPEN Alliance 10BASE-T1x
> Serial Interface specification calls for IRQF_TRIGGER_LOW.
> 
> This is to match IRQF_TRIGGER_FALLING used by OA TC6 framework code.
> This bug fix requires changes to the stable branch. At that time,
> this will be changed to IRQF_TRIGGER_LOW.
> 
> Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH mm-unstable v19 14/14] Documentation: mm: update the admin guide for mTHP collapse
From: Lance Yang @ 2026-06-08  7:41 UTC (permalink / raw)
  To: npache
  Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
	akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
	catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
	hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
	lance.yang, liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
	mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
	richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
	sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
	vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
	zokeefe, bagasdotme
In-Reply-To: <20260605161422.213817-15-npache@redhat.com>


On Fri, Jun 05, 2026 at 10:14:21AM -0600, Nico Pache wrote:
>Now that we can collapse to mTHPs lets update the admin guide to
>reflect these changes and provide proper guidance on how to utilize it.
>
>Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
>Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
>Signed-off-by: Nico Pache <npache@redhat.com>
>---

Reviewed-by: Lance Yang <lance.yang@linux.dev>

^ permalink raw reply

* RE: [PATCH 01/11] net: wwan: t9xx: Add PCIe core
From: Jagielski, Jedrzej @ 2026-06-08  7:40 UTC (permalink / raw)
  To: Wu. JackBB (GSM), Loic Poulain, Sergey Ryazanov, Johannes Berg,
	Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng,
	Matthias Brugger, AngeloGioacchino Del Regno, Simon Horman,
	Jonathan Corbet, Shuah Khan
  Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <c9e80369a7ec449a814cd85269f1135e@compal.com>

From: Wu. JackBB (GSM) <JackBB_Wu@compal.com> 
Sent: Thursday, June 4, 2026 8:43 AM

>> Sent: Friday, May 29, 2026 12:32 PM
>>
>> > +
>>
>> please also take a look on sashiko notes, there is some number of them
>
>Hi Jagielski,
>
>  Thank you for your review. We have fixed some issues and are still discussing others with MediaTek. All of them will be addressed in V2.
>
>  Regarding sashiko notes, how should I handle them if discussion is needed? I cannot find sashiko's email address, and its website does not have a reply option.
>

I guess discussion is needed when any of the reviewers directly refers
to any of the notes posted by sashiko.

If any of the notes was not directly pointed out by anybody please just
check which of sashiko notes are valid and fix them respectively
if needed.


>For example:
>  https://sashiko.dev/#/patchset/20260529-t9xx_driver_v1-v1-0-bdbfe2c01e57%40compal.com?part=2
>
>  Q1:
>  The commit message mentions implementing TX and RX services, but the patch primarily adds empty structures and boilerplate code. Is the patch missing the actual TX/RX implementation described here?
>
>  Reply:
>  We plan to update the commit message. Would the following be acceptable?

I believe if you want to check if sashiko has no any longer problems with it you
need to send v2 and check that way, unless im not aware of something

>
>    Add the control plane transaction layer framework for the t9xx
>    WWAN driver, including configuration options, device structure
>    definitions, and initialization/cleanup functions.
>
>    The actual TX/RX service implementations that use this framework
>    are introduced in subsequent patches.
>
>
>Thanks.

^ permalink raw reply

* Re: [PATCH v2] docs/mm/slab: document cache isolation with SLAB_NO_MERGE
From: Vlastimil Babka (SUSE) @ 2026-06-08  7:39 UTC (permalink / raw)
  To: Mohammed EL Kadiri, Jonathan Corbet, Andrew Morton
  Cc: Vlastimil Babka, Matthew Wilcox, David Hildenbrand,
	Lorenzo Stoakes, Kees Cook, linux-mm, linux-doc, linux-hardening,
	linux-kernel
In-Reply-To: <20260607070645.9559-1-med08elkadiri@gmail.com>

On 6/7/26 09:06, Mohammed EL Kadiri wrote:
> Add documentation to slab.rst explaining when and how to use
> SLAB_NO_MERGE to protect security-critical slab caches from
> cross-cache heap exploitation.
> 
> The document covers:
> - When to use SLAB_NO_MERGE and what it communicates
> - How to verify merge status on a running system
> - Tradeoffs (memory cost vs performance)
> - Relationship to CONFIG_RANDOM_KMALLOC_CACHES, SLAB_TYPESAFE_BY_RCU,
>   and the slab_nomerge boot parameter
> 
> Assisted-by: Claude:claude-opus-4.6
> Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
> ---
> Changes in v2 (per Jonathan Corbet and Matthew Wilcox feedback):
> - Add content to existing slab.rst instead of creating new file
> - Fix markup: use plain function() without additional formatting
> - Use slab terminology consistently, not SLUB
> - Remove How merging works section (implementation internals)
> - Remove cross-cache attack class section (redundant)
> - Remove Bounded allocation volume criteria
> - Rephrase unmergeability guidance per Matthew Wilcox suggestion
> - Add Assisted-by tag per coding-assistants.rst
>  Documentation/mm/slab.rst | 60 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 60 insertions(+)
> 
> diff --git a/Documentation/mm/slab.rst b/Documentation/mm/slab.rst
> index 2bcc58ada302..c485bd257c44 100644
> --- a/Documentation/mm/slab.rst
> +++ b/Documentation/mm/slab.rst
> @@ -4,6 +4,66 @@
>  Slab Allocation
>  ===============
>  
> +Cache isolation with SLAB_NO_MERGE
> +===================================
> +
> +The slab allocator merges caches with compatible size, alignment, and flags
> +to reduce memory fragmentation. While this improves memory efficiency, it
> +allows objects of different types to share the same slab. This enables
> +cross-cache heap exploitation, where a use-after-free in one object type can
> +be leveraged to corrupt an unrelated type.
> +
> +SLAB_NO_MERGE prevents a cache from being merged, ensuring it receives a
> +dedicated slab. A freed slot in an isolated cache can only be reallocated as
> +the same object type.
> +
> +When to use SLAB_NO_MERGE
> +--------------------------
> +
> +SLAB_NO_MERGE should be considered for caches holding security-critical
> +objects whose corruption leads directly to privilege escalation, such as
> +credentials, cryptographic keys, or capability sets.
> +
> +It is harmless to specify SLAB_NO_MERGE even if the cache is already
> +unmergeable for other reasons (e.g., it has a constructor or a non-zero
> +usersize). The flag communicates intent and ensures the cache remains
> +isolated if those other properties change in the future.
> +
> +Verifying merge status
> +-----------------------
> +
> +To check whether a cache is merged on a running system::
> +
> +    # Check how many other caches share its slab
> +    cat /sys/kernel/slab/<cache_name>/aliases
> +
> +    # aliases > 0 means other types share this cache's slab
> +
> +Tradeoffs
> +----------
> +
> +**Memory**: Isolated caches may have partially-filled slabs that cannot be
> +used by other types. The overhead is typically a few extra pages.
> +
> +**Performance**: Zero impact on kmem_cache_alloc() and kmem_cache_free().
> +The only effect is at boot when the cache is created.
> +
> +Relationship to other mitigations
> +----------------------------------
> +
> +CONFIG_RANDOM_KMALLOC_CACHES creates multiple copies of each kmalloc size
> +class and randomly assigns allocations among them. It only affects kmalloc()
> +users and does not affect named caches created with kmem_cache_create().
> +
> +SLAB_TYPESAFE_BY_RCU delays freeing the slab by an RCU grace period. It
> +does not delay object slot reuse and does not prevent cross-cache merging.
> +It solves a different problem: safe lockless access to freed-and-reallocated
> +objects of the same type.
> +
> +The slab_nomerge boot parameter disables merging for all caches globally.
> +SLAB_NO_MERGE provides the same protection selectively for individual caches
> +without the global memory cost.

Matthew already pointed out in v1 that these last 2 are unnecessary.

I think this is approach unproductive, sorry. IIUC a newcomer to the
community, with help of a LLM (I however appreciate the openness about it,
with Assisted-by: tag), but multiple senior people have to provide input to
hopefully make it into an acceptable shape. This SLAB_NO_MERGE flag isn't
that crucial to go through all of this. We could just add a comment about
security use cases to the comment above #define SLAB_NO_MERGE and that's it.

So please considers other ways of getting involved in the community (which
is otherwise welcome), as this is not a great one. Thanks.

> +
>  Functions and structures
>  ========================
>  


^ permalink raw reply

* Re: [PATCH mm-unstable v19 12/14] mm/khugepaged: avoid unnecessary mTHP collapse attempts
From: Lance Yang @ 2026-06-08  7:36 UTC (permalink / raw)
  To: npache
  Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
	akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
	catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
	hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
	lance.yang, liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
	mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
	richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
	sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
	vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
	zokeefe, usama.arif
In-Reply-To: <20260605161422.213817-13-npache@redhat.com>


On Fri, Jun 05, 2026 at 10:14:19AM -0600, Nico Pache wrote:
>There are cases where, if an attempted collapse fails, all subsequent
>orders are guaranteed to also fail. Avoid these collapse attempts by
>bailing out early.
>
>Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
>Acked-by: Usama Arif <usama.arif@linux.dev>
>Acked-by: David Hildenbrand (Arm) <david@kernel.org>
>Signed-off-by: Nico Pache <npache@redhat.com>
>---

Reviewed-by: Lance Yang <lance.yang@linux.dev>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox