* [PATCH V4 2/2] tools/perf: Use scnprintf in buffer offset calculations
From: Athira Rajeev @ 2026-05-04 15:42 UTC (permalink / raw)
To: acme, jolsa, adrian.hunter, mpetlan, tmricht, maddy, irogers,
namhyung
Cc: linux-perf-users, linuxppc-dev, atrajeev, hbathini, Tejas.Manhas1,
Tanushree.Shah, shivani
In-Reply-To: <20260504154205.21394-1-atrajeev@linux.ibm.com>
Replace snprintf with scnprintf in buffer offset calculations to
ensure the 'used' count will not exceed the "len".
The current logic in perf_pmu__for_each_event uses an unconditional
+ 1 increment to buf_used to account for null terminators. This can
cause a a stack buffer overflow in the subsequent scnprintf call.
When the local stack buffer buf (1024 bytes) is full, buf_used can
reach 1025. This causes the subsequent remaining space calculation
sizeof(buf) - buf_used to underflow.
Use sub_non_neg() to see if space actually existed, and only
increment the offset if remaning space is present.
Changes includes:
- Use sub_non_neg to check if space exists
- Replacing snprintf with scnprintf to ensure the return value
reflects the actual bytes written into the buffer.
- Only increment buf_used by 1 if space exists
- If a parameterized event uses a built-in perf keyword for its
parameter name (eg, config=?), the lexer parses it as a predefined
term token, which sets term->config to NULL. Add check to use
parse_events__term_type_str() if term->config is NULL.
Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
---
Changelog:
v2 -> v3:
- Split the scnprintf related changes in separate patch
- Handle the overflow issues and unconditional increment
wrapped around sub_non_neg addressing review comment from Sashiko
tools/perf/util/pmu.c | 46 ++++++++++++++++++++++++++++++++-----------
1 file changed, 35 insertions(+), 11 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 0b8d58543f17..4b9ade1a4cf9 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -2129,15 +2129,19 @@ static char *format_alias(char *buf, int len, const struct perf_pmu *pmu,
pr_err("Failure to parse '%s' terms '%s': %d\n",
alias->name, alias->terms, ret);
parse_events_terms__exit(&terms);
- snprintf(buf, len, "%.*s/%s/", (int)pmu_name_len, pmu->name, alias->name);
+ scnprintf(buf, len, "%.*s/%s/", (int)pmu_name_len, pmu->name, alias->name);
return buf;
}
- used = snprintf(buf, len, "%.*s/%s", (int)pmu_name_len, pmu->name, alias->name);
+ used = scnprintf(buf, len, "%.*s/%s", (int)pmu_name_len, pmu->name, alias->name);
list_for_each_entry(term, &terms.terms, list) {
+ const char *name = term->config;
+
+ if (!name)
+ name = parse_events__term_type_str(term->type_term);
if (term->type_val == PARSE_EVENTS__TERM_TYPE_STR)
- used += snprintf(buf + used, sub_non_neg(len, used),
- ",%s=%s", term->config,
+ used += scnprintf(buf + used, sub_non_neg(len, used),
+ ",%s=%s", name,
term->val.str);
}
parse_events_terms__exit(&terms);
@@ -2201,6 +2205,7 @@ int perf_pmu__for_each_event(struct perf_pmu *pmu, bool skip_duplicate_pmus,
int ret = 0;
struct hashmap_entry *entry;
size_t bkt;
+ size_t size_rem, len;
if (perf_pmu__is_tracepoint(pmu))
return tp_pmu__for_each_event(pmu, state, cb);
@@ -2234,17 +2239,36 @@ int perf_pmu__for_each_event(struct perf_pmu *pmu, bool skip_duplicate_pmus,
}
buf_used = strlen(buf) + 1;
}
+
info.scale_unit = NULL;
if (strlen(event->unit) || event->scale != 1.0) {
- info.scale_unit = buf + buf_used;
- buf_used += snprintf(buf + buf_used, sizeof(buf) - buf_used,
- "%G%s", event->scale, event->unit) + 1;
+ /* Check the remaining space */
+ size_rem = sub_non_neg(sizeof(buf), buf_used);
+
+ if (size_rem > 0) {
+ info.scale_unit = buf + buf_used;
+ len = scnprintf(buf + buf_used, size_rem, "%G%s",
+ event->scale, event->unit);
+ /*
+ * Increment buf_used by 1 only if
+ * it fits remaining space
+ */
+ buf_used += min(len + 1, size_rem);
+ }
}
info.desc = event->desc;
info.long_desc = event->long_desc;
- info.encoding_desc = buf + buf_used;
- buf_used += snprintf(buf + buf_used, sizeof(buf) - buf_used,
- "%.*s/%s/", (int)pmu_name_len, info.pmu_name, event->terms) + 1;
+ info.encoding_desc = NULL;
+
+ /* Check the remaining space */
+ size_rem = sub_non_neg(sizeof(buf), buf_used);
+ if (size_rem > 0) {
+ info.encoding_desc = buf + buf_used;
+ len = scnprintf(buf + buf_used, size_rem, "%.*s/%s/",
+ (int)pmu_name_len, info.pmu_name, event->terms);
+ buf_used += min(len + 1, size_rem);
+ }
+
info.str = event->terms;
info.topic = event->topic;
info.deprecated = perf_pmu_alias__check_deprecated(pmu, event);
@@ -2254,7 +2278,7 @@ int perf_pmu__for_each_event(struct perf_pmu *pmu, bool skip_duplicate_pmus,
}
if (pmu->selectable) {
info.name = buf;
- snprintf(buf, sizeof(buf), "%s//", pmu->name);
+ scnprintf(buf, sizeof(buf), "%s//", pmu->name);
info.alias = NULL;
info.scale_unit = NULL;
info.desc = NULL;
--
2.47.3
^ permalink raw reply related
* [PATCH net] net: wan: fsl_uhdlc_hdlc: fix dma_rmb usage in hdlc_rx_done
From: Holger Brunck @ 2026-05-04 15:56 UTC (permalink / raw)
To: netdev
Cc: linuxppc-dev, andrew+netdev, chleroy, qiang.zhao, horms,
Holger Brunck
If dma_rmb is used it has to be done after reading bd_status and checking
if R_E_S is zero. Therefore we need to move it into the while loop.
Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
---
drivers/net/wan/fsl_ucc_hdlc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 15bfb78381d4..09081f128a98 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -523,12 +523,12 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
u16 length, howmany = 0;
u8 *bdbuffer;
- dma_rmb();
bd = priv->currx_bd;
bd_status = be16_to_cpu(bd->status);
/* while there are received buffers and BD is full (~R_E) */
while (!((bd_status & (R_E_S)) || (--rx_work_limit < 0))) {
+ dma_rmb();
if (bd_status & (RX_BD_ERRORS)) {
dev->stats.rx_errors++;
@@ -610,7 +610,6 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
bd_status = be16_to_cpu(bd->status);
}
- dma_rmb();
priv->currx_bd = bd;
return howmany;
--
2.47.3
^ permalink raw reply related
* [PATCH net] net: wan: fsl_ucc_hdlc: fix indentation error
From: Holger Brunck @ 2026-05-04 16:07 UTC (permalink / raw)
To: netdev
Cc: linuxppc-dev, andrew+netdev, chleroy, qiang.zhao, horms,
Holger Brunck
Remove the whitespace to fix the indentation.
Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 09081f128a98..adf3863463f5 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -764,7 +764,7 @@ static void uhdlc_memclean(struct ucc_hdlc_private *priv)
qe_muram_free(priv->ucc_pram_offset);
priv->ucc_pram = NULL;
priv->ucc_pram_offset = 0;
- }
+ }
kfree(priv->rx_skbuff);
priv->rx_skbuff = NULL;
--
2.47.3
^ permalink raw reply related
* [PATCH net] net: wan: fsl_ucc_hdlc: free tx_skbuff in uhdlc_memclean
From: Holger Brunck @ 2026-05-04 16:11 UTC (permalink / raw)
To: netdev
Cc: linuxppc-dev, andrew+netdev, chleroy, qiang.zhao, horms,
Holger Brunck
When cleaning up the resources we need to iterate over the
tx_skbuf array to free pending TX messages.
Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
---
drivers/net/wan/fsl_ucc_hdlc.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index adf3863463f5..68f78aeabdc3 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -739,6 +739,8 @@ static int uhdlc_open(struct net_device *dev)
static void uhdlc_memclean(struct ucc_hdlc_private *priv)
{
+ int i;
+
qe_muram_free(ioread16be(&priv->ucc_pram->riptr));
qe_muram_free(ioread16be(&priv->ucc_pram->tiptr));
@@ -769,6 +771,11 @@ static void uhdlc_memclean(struct ucc_hdlc_private *priv)
kfree(priv->rx_skbuff);
priv->rx_skbuff = NULL;
+ for (i = 0; i < TX_BD_RING_LEN) {
+ kfree(priv->tx_skbuff[i]);
+ priv->tx_skbuff[i] = NULL;
+ }
+
kfree(priv->tx_skbuff);
priv->tx_skbuff = NULL;
--
2.47.3
^ permalink raw reply related
* [PATCH net] net: wan: fsl_ucc_hdlc: return NETDEV_TX_OK if skb was freed
From: Holger Brunck @ 2026-05-04 17:44 UTC (permalink / raw)
To: netdev
Cc: linuxppc-dev, andrew+netdev, chleroy, qiang.zhao, horms,
Holger Brunck
If the skb was freed in the ucc_hdlc_tx function and the packet marked
as dropped we need to return NETDEV_TX_OK. Otherwise the above layer
will try to requeue an already freed skb.
Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
---
drivers/net/wan/fsl_ucc_hdlc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 7af558780bdc..6ce539151618 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -360,7 +360,7 @@ static netdev_tx_t ucc_hdlc_tx(struct sk_buff *skb, struct net_device *dev)
dev->stats.tx_dropped++;
dev_kfree_skb(skb);
netdev_err(dev, "No enough space for hdlc head\n");
- return -ENOMEM;
+ return NETDEV_TX_OK;
}
skb_push(skb, HDLC_HEAD_LEN);
@@ -377,7 +377,7 @@ static netdev_tx_t ucc_hdlc_tx(struct sk_buff *skb, struct net_device *dev)
dev->stats.tx_dropped++;
dev_kfree_skb(skb);
netdev_err(dev, "Wrong ppp header\n");
- return -ENOMEM;
+ return NETDEV_TX_OK;
}
dev->stats.tx_bytes += skb->len;
@@ -390,7 +390,7 @@ static netdev_tx_t ucc_hdlc_tx(struct sk_buff *skb, struct net_device *dev)
default:
dev->stats.tx_dropped++;
dev_kfree_skb(skb);
- return -ENOMEM;
+ return NETDEV_TX_OK;
}
netdev_sent_queue(dev, skb->len);
spin_lock_irqsave(&priv->lock, flags);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 0/3] KVM: Fix and clean up kvm_vcpu_map[_readonly]() usages
From: Sean Christopherson @ 2026-05-04 17:59 UTC (permalink / raw)
To: Peter Fang
Cc: David Woodhouse, Paolo Bonzini, Madhavan Srinivasan,
Nicholas Piggin, Fred Griffoul, Yosry Ahmed, Ritesh Harjani,
Michael Ellerman, Christophe Leroy (CS GROUP), Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
kvm, linuxppc-dev, linux-kernel
In-Reply-To: <20260427080554.GD1733452@pedri>
On Mon, Apr 27, 2026, Peter Fang wrote:
> On Fri, Apr 24, 2026 at 11:27:03AM +0100, David Woodhouse wrote:
> >
> > Fred is already removing all the usage of kvm_vcpu_map() in nested VMX¹
> > and nested SVM probably wants the same treatment. And the PowerPC one
> > looks like it could just as easily operate on the userspace address?
> >
> > Could we just kill kvm_vcpu_map() completely?
Yeah, that's probably for the best in the long run.
> Thanks David!
>
> I think I'd need at least input from the maintainers on this but just by
> code inspection, the kvm_vcpu_map() usage in sev.c seems a bit tricky.
> Unmapping doesn't happen until right before switching to the guest, so
> this might fall into the "keep the mapping around for a longer time"
> category [1].
It definitely falls into that category. But that code is also rather gross, i.e.
could use some cleanup no matter what, so I don't think it's a good argument for
keeping kvm_vcpu_map() around.
To avoid a bunch of pointless work and churn, let's hold off on hardening and/or
renaming kvm_vcpu_map() for now. I'll take this v2 as-is; even though taking a
gpa instead of a gfn will conflict with the nVMX series, it's dead simple and a
worthwhile cleanup even if some of the conversions get discarded shortly after.
^ permalink raw reply
* Re: [PATCH] lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code
From: Eric Biggers @ 2026-05-04 18:00 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: linux-crypto, linux-kernel, Ard Biesheuvel, Jason A . Donenfeld,
Herbert Xu, linuxppc-dev, Nicholas Piggin, Michael Ellerman,
Madhavan Srinivasan
In-Reply-To: <111ea924-fef5-441e-9849-83f938c913a7@kernel.org>
On Mon, May 04, 2026 at 03:28:24PM +0200, Christophe Leroy (CS GROUP) wrote:
> Hi Eric,
>
> Le 04/05/2026 à 06:14, Eric Biggers a écrit :
> > Earlier the decision was made to keep this code for a while, despite no
> > other architectures having optimized MD5 code anymore, because of
> > someone using it via AF_ALG via libkcapi-hasher
> > (https://lore.kernel.org/r/f0d771d5-ed70-444c-957a-ad4c16f6c115@csgroup.eu/)
> >
> > However, with AF_ALG itself now being on its way out due to its
> > continuous stream of security vulnerabilities
> > (https://lore.kernel.org/r/20260430011544.31823-1-ebiggers@kernel.org/),
> > it's time to be a bit more forceful with nudging people towards
> > userspace crypto code. It's always been the better solution anyway, and
> > it's much more efficient if properly optimized code is used.
>
> Ok, why not, but what do you propose as an alternative ? Let me explain the
> situation.
>
> We have two versions of boards:
> - One with powerpc MPC885E, which embeds a SECURITY Engine called TALITOS
> for offloading crypto operations
> - One with powerpc MPC866, which doesn't have the security engine.
>
> To use the security engine, our software use the AF_ALG interface (via
> libkcapi).
>
> Our software has to run on both boards, we can't afford two different
> versions of the software and the software shall have no dead code. Therefore
> we rely on the capability of the kernel to do the hash by itself when the
> TALITOS in not available.
>
> The kernel has always been the place where we do board specific stuff, not
> the application. I can't see why the application would have to ask the
> kernel when the Talitos is there and have to do the hashing by itself when
> the Talitos is not there.
>
> I'm really concerned with the optimised MD5 going away now, and I'm also
> wondering what will be the way to splice a file into the kernel and get it's
> MD-5 hash from the TALITOS if AF_ALG goes away in medium-term.
>
> What is the way forward ? I'm open to any suggestion as I really can't see
> where to go for now.
>
> But please don't remove powerpc MD5 before we find an alternative solution.
>
> Thanks
> Christophe
I think I gave the solution in the commit message already, no? Take the
same MD5 code and run it in userspace. It will be even faster than
invoking that code via AF_ALG.
Yes, the selection of software vs "security" engine (if you actually
still need the latter, which in reality you probably don't) would then
occur in userspace. But selecting an implementation in userspace isn't
unusual. It's no different from how different CPU features are handled
in userspace.
Anyway, please don't confuse this patch (which only affects performance)
with full removal of AF_ALG (which would be a hard break, and won't
occur until quite far in the future). This patch is just a nudge in the
right direction, and a cleanup of the kernel's powerpc support to be
aligned with all the other architectures. So I do believe we should
proceed with this patch.
- Eric
^ permalink raw reply
* [PATCH] powerpc/pseries/iommu: Add TCEs for 16GB pages when RAM is pre-mapped
From: Gaurav Batra @ 2026-05-04 20:54 UTC (permalink / raw)
To: maddy; +Cc: linuxppc-dev, ritesh.list, donettom, vaibhav, sbhat, Gaurav Batra
In powerPC, if Dynamic DMA Window is big enough, RAM is pre-mapped. To
determine the size of RAM, a PAPR+ property "ibm,lrdr-capacity" is used.
This OF property dictates what is the max size of RAM an LPAR can have,
including DR added memory.
In PowerPC, 16GB pages can be allocated at machine level and then
assigned to LPARs. These 16GB pages are added to LPAR memory at the time
of boot. The address range for these 16GB pages is above MAX RAM an LPAR
can have (ibm,lrdr-capacity). In the current implementation, these 16GB
pages are being excluded from pre-mapped TCEs. A driver can have DMA
buffers allocated from 16GB pages. This results in platform to raise an
EEH when DMA is attempted on buffers in 16GB memory range.
commit 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly
adds TCEs for pmemory")
Prior to the above patch, memblock_end_of_DRAM() was being used to
determine the MAX memory of an LPAR. This included 16GB pages as well.
The issue with using memblock_end_of_DRAM() is that when pmemory is
converted to RAM via daxctl command, the DDW engine will incorrectly try
to add TCEs for pmemory as well.
Below is the address distribution of RAM, 16GB pages and pmemory for an
LPAR with max memory of 256GB, memory allocated 64GB, 2 16GB pages and
assigned pmemory of 8GB.
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000000000000-0x0000000fffffffff 64G online yes 0-255
0x0000004000000000-0x00000047ffffffff 32G online yes 1024-1151
cat /sys/bus/nd/devices/region0/resource
0x40100000000
cat /sys/bus/nd/devices/region0/size
8589934592
The approach to fix this problem is to revert back the code changes
introduced by the above patch and to stash away the MAX memory of an
LPAR, including 16GB pages, at the LPAR boot time. This value is then
used whenever TCEs are needed to be pre-mapped - enable_DDW() or,
iommu_mem_notifier()
Fixes: 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly adds TCEs for pmemory")
Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
---
arch/powerpc/platforms/pseries/iommu.c | 38 ++++++++++++++++++--------
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 3e1f915fe4f6..e74954b7add6 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -69,6 +69,8 @@ static struct iommu_table *iommu_pseries_alloc_table(int node)
return tbl;
}
+static phys_addr_t pseries_ddw_max_ram;
+
#ifdef CONFIG_IOMMU_API
static struct iommu_table_group_ops spapr_tce_table_group_ops;
#endif
@@ -1285,15 +1287,19 @@ static LIST_HEAD(failed_ddw_pdn_list);
static phys_addr_t ddw_memory_hotplug_max(void)
{
- resource_size_t max_addr;
+ resource_size_t max_addr = memory_hotplug_max();
+ struct device_node *memory;
-#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
- max_addr = hot_add_drconf_memory_max();
-#else
- max_addr = memblock_end_of_DRAM();
-#endif
+ for_each_node_by_type(memory, "memory") {
+ struct resource res;
+
+ if (of_address_to_resource(memory, 0, &res))
+ continue;
- return max_addr;
+ max_addr = max_t(resource_size_t, max_addr, res.end + 1);
+ }
+
+ return max_addr;
}
/*
@@ -1446,7 +1452,7 @@ static struct property *ddw_property_create(const char *propname, u32 liobn, u64
static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn, u64 dma_mask)
{
int len = 0, ret;
- int max_ram_len = order_base_2(ddw_memory_hotplug_max());
+ int max_ram_len = order_base_2(pseries_ddw_max_ram);
struct ddw_query_response query;
struct ddw_create_response create;
int page_shift;
@@ -1668,7 +1674,7 @@ static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn, u64 dma_mas
if (direct_mapping) {
/* DDW maps the whole partition, so enable direct DMA mapping */
- ret = walk_system_ram_range(0, ddw_memory_hotplug_max() >> PAGE_SHIFT,
+ ret = walk_system_ram_range(0, pseries_ddw_max_ram >> PAGE_SHIFT,
win64->value, tce_setrange_multi_pSeriesLP_walk);
if (ret) {
dev_info(&dev->dev, "failed to map DMA window for %pOF: %d\n",
@@ -2423,7 +2429,7 @@ static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
/* This notifier can get called when onlining persistent memory as well.
* TCEs are not pre-mapped for persistent memory. Persistent memory will
- * always be above ddw_memory_hotplug_max()
+ * always be above pseries_ddw_max_ram
*/
switch (action) {
@@ -2431,7 +2437,7 @@ static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
spin_lock(&dma_win_list_lock);
list_for_each_entry(window, &dma_win_list, list) {
if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
- ddw_memory_hotplug_max()) {
+ pseries_ddw_max_ram) {
ret |= tce_setrange_multi_pSeriesLP(arg->start_pfn,
arg->nr_pages, window->prop);
}
@@ -2444,7 +2450,7 @@ static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
spin_lock(&dma_win_list_lock);
list_for_each_entry(window, &dma_win_list, list) {
if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
- ddw_memory_hotplug_max()) {
+ pseries_ddw_max_ram) {
ret |= tce_clearrange_multi_pSeriesLP(arg->start_pfn,
arg->nr_pages, window->prop);
}
@@ -2532,6 +2538,14 @@ void __init iommu_init_early_pSeries(void)
register_memory_notifier(&iommu_mem_nb);
set_pci_dma_ops(&dma_iommu_ops);
+
+ /* During init determine the max memory an LPAR can have and set it. This
+ * will be used for pre-mapping RAM in DDW. memblock_end_of_DRAM() can
+ * change during the running of LPAR - daxctl can add pmemory as
+ * "system-ram". This memory range should not be pre-mapped in DDW since
+ * the address of pmemory can be much higher than the DDW size.
+ */
+ pseries_ddw_max_ram = ddw_memory_hotplug_max();
}
static int __init disable_multitce(char *str)
base-commit: 6d35786de28116ecf78797a62b84e6bf3c45aa5a
--
2.39.3
^ permalink raw reply related
* [powerpc:merge] BUILD SUCCESS d88a1b4ae622420b9ced6bc1d559362f746a6cce
From: kernel test robot @ 2026-05-05 0:08 UTC (permalink / raw)
To: Madhavan Srinivasan; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: d88a1b4ae622420b9ced6bc1d559362f746a6cce Automatic merge of 'fixes' into merge (2026-05-04 17:22)
elapsed time: 730m
configs tested: 302
configs skipped: 44
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260504 gcc-13.4.0
arc randconfig-001-20260505 gcc-8.5.0
arc randconfig-002-20260504 gcc-13.4.0
arc randconfig-002-20260505 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm aspeed_g4_defconfig clang-23
arm defconfig gcc-15.2.0
arm randconfig-001-20260504 gcc-13.4.0
arm randconfig-001-20260505 gcc-8.5.0
arm randconfig-002-20260504 gcc-13.4.0
arm randconfig-002-20260505 gcc-8.5.0
arm randconfig-003-20260504 gcc-13.4.0
arm randconfig-003-20260505 gcc-8.5.0
arm randconfig-004-20260504 gcc-13.4.0
arm randconfig-004-20260505 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260504 gcc-15.2.0
arm64 randconfig-001-20260505 gcc-14.3.0
arm64 randconfig-002-20260504 gcc-15.2.0
arm64 randconfig-003-20260504 gcc-15.2.0
arm64 randconfig-004-20260504 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260504 gcc-15.2.0
csky randconfig-001-20260505 gcc-14.3.0
csky randconfig-002-20260504 gcc-15.2.0
csky randconfig-002-20260505 gcc-14.3.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260504 clang-23
hexagon randconfig-001-20260505 clang-23
hexagon randconfig-001-20260505 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260504 clang-23
hexagon randconfig-002-20260505 clang-23
hexagon randconfig-002-20260505 gcc-11.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260504 gcc-14
i386 buildonly-randconfig-001-20260505 gcc-14
i386 buildonly-randconfig-002 gcc-14
i386 buildonly-randconfig-002-20260504 gcc-14
i386 buildonly-randconfig-002-20260505 gcc-14
i386 buildonly-randconfig-003 gcc-14
i386 buildonly-randconfig-003-20260504 gcc-14
i386 buildonly-randconfig-003-20260505 gcc-14
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260504 gcc-14
i386 buildonly-randconfig-004-20260505 gcc-14
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260504 gcc-14
i386 buildonly-randconfig-005-20260505 gcc-14
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260504 gcc-14
i386 buildonly-randconfig-006-20260505 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260504 clang-20
i386 randconfig-001-20260505 clang-20
i386 randconfig-002 gcc-14
i386 randconfig-002-20260504 clang-20
i386 randconfig-002-20260504 gcc-14
i386 randconfig-002-20260505 clang-20
i386 randconfig-003 gcc-14
i386 randconfig-003-20260504 clang-20
i386 randconfig-003-20260504 gcc-14
i386 randconfig-003-20260505 clang-20
i386 randconfig-004-20260504 clang-20
i386 randconfig-004-20260504 gcc-14
i386 randconfig-004-20260505 clang-20
i386 randconfig-005 gcc-14
i386 randconfig-005-20260504 clang-20
i386 randconfig-005-20260504 gcc-14
i386 randconfig-005-20260505 clang-20
i386 randconfig-006 gcc-14
i386 randconfig-006-20260504 clang-20
i386 randconfig-006-20260505 clang-20
i386 randconfig-007 gcc-14
i386 randconfig-007-20260504 clang-20
i386 randconfig-007-20260505 clang-20
i386 randconfig-011-20260504 clang-20
i386 randconfig-011-20260505 clang-20
i386 randconfig-011-20260505 gcc-14
i386 randconfig-012-20260504 clang-20
i386 randconfig-012-20260505 clang-20
i386 randconfig-013-20260504 clang-20
i386 randconfig-013-20260505 clang-20
i386 randconfig-014-20260504 clang-20
i386 randconfig-014-20260505 clang-20
i386 randconfig-015-20260504 clang-20
i386 randconfig-015-20260505 clang-20
i386 randconfig-015-20260505 gcc-14
i386 randconfig-016-20260504 clang-20
i386 randconfig-016-20260505 clang-20
i386 randconfig-017-20260504 clang-20
i386 randconfig-017-20260505 clang-20
i386 randconfig-017-20260505 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260504 clang-23
loongarch randconfig-001-20260505 clang-23
loongarch randconfig-001-20260505 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260504 clang-23
loongarch randconfig-002-20260505 clang-23
loongarch randconfig-002-20260505 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
m68k defconfig gcc-15.2.0
m68k m5249evb_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips rs90_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 defconfig gcc-15.2.0
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260504 clang-23
nios2 randconfig-001-20260505 clang-23
nios2 randconfig-001-20260505 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260504 clang-23
nios2 randconfig-002-20260505 clang-23
nios2 randconfig-002-20260505 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-11.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260504 gcc-13.4.0
parisc randconfig-001-20260505 gcc-14.3.0
parisc randconfig-002-20260504 gcc-13.4.0
parisc randconfig-002-20260505 gcc-14.3.0
parisc64 defconfig clang-19
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260504 gcc-13.4.0
powerpc randconfig-001-20260505 gcc-14.3.0
powerpc randconfig-002-20260504 gcc-13.4.0
powerpc randconfig-002-20260505 gcc-14.3.0
powerpc tqm8560_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260504 gcc-13.4.0
powerpc64 randconfig-001-20260505 gcc-14.3.0
powerpc64 randconfig-002-20260504 gcc-13.4.0
powerpc64 randconfig-002-20260505 gcc-14.3.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260504 gcc-8.5.0
riscv randconfig-001-20260505 gcc-10.5.0
riscv randconfig-002-20260504 gcc-8.5.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260504 gcc-8.5.0
s390 randconfig-002-20260504 gcc-8.5.0
s390 randconfig-002-20260505 gcc-10.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260504 gcc-8.5.0
sh randconfig-001-20260505 gcc-10.5.0
sh randconfig-002-20260504 gcc-8.5.0
sh randconfig-002-20260505 gcc-10.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260504 gcc-8.5.0
sparc randconfig-001-20260505 gcc-15.2.0
sparc randconfig-002-20260504 gcc-8.5.0
sparc randconfig-002-20260505 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260504 gcc-8.5.0
sparc64 randconfig-001-20260505 gcc-15.2.0
sparc64 randconfig-002-20260504 gcc-8.5.0
sparc64 randconfig-002-20260505 gcc-15.2.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260504 gcc-8.5.0
um randconfig-001-20260505 gcc-15.2.0
um randconfig-002-20260504 gcc-8.5.0
um randconfig-002-20260505 gcc-15.2.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260504 gcc-12
x86_64 buildonly-randconfig-001-20260505 clang-20
x86_64 buildonly-randconfig-002-20260504 gcc-12
x86_64 buildonly-randconfig-002-20260505 clang-20
x86_64 buildonly-randconfig-003-20260504 gcc-12
x86_64 buildonly-randconfig-003-20260505 clang-20
x86_64 buildonly-randconfig-004-20260504 gcc-12
x86_64 buildonly-randconfig-004-20260505 clang-20
x86_64 buildonly-randconfig-005-20260504 gcc-12
x86_64 buildonly-randconfig-005-20260505 clang-20
x86_64 buildonly-randconfig-006-20260504 gcc-12
x86_64 buildonly-randconfig-006-20260505 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260505 clang-20
x86_64 randconfig-002-20260505 clang-20
x86_64 randconfig-003-20260504 gcc-14
x86_64 randconfig-003-20260505 clang-20
x86_64 randconfig-004-20260505 clang-20
x86_64 randconfig-005-20260505 clang-20
x86_64 randconfig-006-20260505 clang-20
x86_64 randconfig-011-20260504 gcc-14
x86_64 randconfig-011-20260505 clang-20
x86_64 randconfig-012-20260504 gcc-14
x86_64 randconfig-012-20260505 clang-20
x86_64 randconfig-013-20260504 gcc-14
x86_64 randconfig-013-20260505 clang-20
x86_64 randconfig-014-20260504 gcc-14
x86_64 randconfig-014-20260505 clang-20
x86_64 randconfig-015-20260505 clang-20
x86_64 randconfig-016-20260505 clang-20
x86_64 randconfig-071-20260504 clang-20
x86_64 randconfig-071-20260505 clang-20
x86_64 randconfig-072-20260504 clang-20
x86_64 randconfig-072-20260505 clang-20
x86_64 randconfig-073-20260504 clang-20
x86_64 randconfig-073-20260505 clang-20
x86_64 randconfig-074-20260504 clang-20
x86_64 randconfig-074-20260505 clang-20
x86_64 randconfig-075-20260504 clang-20
x86_64 randconfig-075-20260505 clang-20
x86_64 randconfig-076-20260504 clang-20
x86_64 randconfig-076-20260505 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa allyesconfig gcc-11.5.0
xtensa randconfig-001-20260504 gcc-8.5.0
xtensa randconfig-001-20260505 gcc-15.2.0
xtensa randconfig-002-20260504 gcc-8.5.0
xtensa randconfig-002-20260505 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_xcvr: Fix event generation for cached controls
From: Mark Brown @ 2026-05-04 13:21 UTC (permalink / raw)
To: Shengjiu Wang, Xiubo Li, Fabio Estevam, Nicolin Chen,
Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Viorel Suman,
Cássio Gabriel
Cc: linux-sound, linuxppc-dev, linux-kernel
In-Reply-To: <20260428-asoc-fsl-xcvr-event-generation-v1-1-f21cf0812c4f@gmail.com>
On Tue, 28 Apr 2026 00:07:08 -0300, Cássio Gabriel wrote:
> ASoC: fsl_xcvr: Fix event generation for cached controls
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1
Thanks!
[1/1] ASoC: fsl_xcvr: Fix event generation for cached controls
https://git.kernel.org/broonie/sound/c/e8446a4a574d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 1/3] ASoC: dapm: Fix widget lookup with snd_soc_dapm_widget_name_cmp()
From: Mark Brown @ 2026-05-05 2:21 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, perex, tiwai, shengjiu.wang, Xiubo.Lee, festevam,
nicoleotsuka, Frank.Li, s.hauer, kernel, shumingf, rander.wang,
pierre-louis.bossart, linux-sound, linux-kernel, linuxppc-dev,
imx, linux-arm-kernel
In-Reply-To: <20260429021252.691263-2-chancel.liu@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
On Wed, Apr 29, 2026 at 11:12:50AM +0900, Chancel Liu wrote:
> Currently dapm_find_widget() manually constructs a prefixed widget name
> based on the provided DAPM context and compares it using strcmp(). This
> happens to work in most cases because callers usually know which DAPM
> context the target widget belongs to and pass in the matching DAPM
> context.
> - if (prefix) {
> - snprintf(prefixed_pin, sizeof(prefixed_pin), "%s %s",
> - prefix, pin);
> - pin_name = prefixed_pin;
> - } else {
> - pin_name = pin;
> - }
>
> for_each_card_widgets(dapm->card, w) {
> - if (!strcmp(w->name, pin_name)) {
> + if (!snd_soc_dapm_widget_name_cmp(w, pin)) {
> if (w->dapm == dapm)
> return w;
> else
This means we can't use the prefix to disambiguate any more -
snd_soc_dapm_widget_name_cmp() will strip the prefix off. We want the
prefix in contexts where the name is specified by the user since the
prefix is there to provide for disambiguation. The prefix addition
logic is a bit weird and I'm not sure it makes sense, but the search
based on the fully specified name we got is something we want.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc/powermac: Remove pmac_low_i2c_{lock,unlock}()
From: Madhavan Srinivasan @ 2026-05-05 3:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <5ee49a18-e6cd-4ab8-8430-e1ef64ec353f@acm.org>
On 4/27/26 10:40 PM, Bart Van Assche wrote:
> On 3/16/26 10:47 AM, Bart Van Assche wrote:
>> Commit a28d3af2a26c ("[PATCH] 2/5 powerpc: Rework PowerMac i2c part 2")
>> removed the last calls to the pmac_low_i2c_{lock,unlock}() functions.
>> Hence, remove these two functions.
>
> It seems like this patch hasn't made it into Linux kernel v7.1-rc1. Has
> it been sent to the right maintainer?
>
my bad, missed it. Will pull it in.
Maddy
> Thanks,
>
> Bart.
>
^ permalink raw reply
* Re: [PATCH net] net: wan: fsl_uhdlc_hdlc: fix dma_rmb usage in hdlc_rx_done
From: Christophe Leroy (CS GROUP) @ 2026-05-05 5:29 UTC (permalink / raw)
To: Holger Brunck, netdev; +Cc: linuxppc-dev, andrew+netdev, qiang.zhao, horms
In-Reply-To: <20260504155642.2216040-1-holger.brunck@hitachienergy.com>
Hi,
Le 04/05/2026 à 17:56, Holger Brunck a écrit :
> If dma_rmb is used it has to be done after reading bd_status and checking
> if R_E_S is zero. Therefore we need to move it into the while loop.
Can you give more details ? Why does dma_rmb() has to be done after
reading bd_status and checking if R_E_S is zero ?
>
> Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
> Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 15bfb78381d4..09081f128a98 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -523,12 +523,12 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
> u16 length, howmany = 0;
> u8 *bdbuffer;
>
> - dma_rmb();
> bd = priv->currx_bd;
> bd_status = be16_to_cpu(bd->status);
>
> /* while there are received buffers and BD is full (~R_E) */
> while (!((bd_status & (R_E_S)) || (--rx_work_limit < 0))) {
> + dma_rmb();
> if (bd_status & (RX_BD_ERRORS)) {
> dev->stats.rx_errors++;
>
> @@ -610,7 +610,6 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
>
> bd_status = be16_to_cpu(bd->status);
> }
> - dma_rmb();
>
> priv->currx_bd = bd;
> return howmany;
^ permalink raw reply
* Re: [PATCH net] net: wan: fsl_ucc_hdlc: fix indentation error
From: Christophe Leroy (CS GROUP) @ 2026-05-05 5:31 UTC (permalink / raw)
To: Holger Brunck, netdev; +Cc: linuxppc-dev, andrew+netdev, qiang.zhao, horms
In-Reply-To: <20260504160734.2217382-1-holger.brunck@hitachienergy.com>
Hi,
Le 04/05/2026 à 18:07, Holger Brunck a écrit :
> Remove the whitespace to fix the indentation.
Do we really need a patch for that ? What's the added value of doing
this change compared to the cost of doing it ?
>
> Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
> Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 09081f128a98..adf3863463f5 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -764,7 +764,7 @@ static void uhdlc_memclean(struct ucc_hdlc_private *priv)
> qe_muram_free(priv->ucc_pram_offset);
> priv->ucc_pram = NULL;
> priv->ucc_pram_offset = 0;
> - }
> + }
>
> kfree(priv->rx_skbuff);
> priv->rx_skbuff = NULL;
^ permalink raw reply
* Re: [PATCH net] net: wan: fsl_ucc_hdlc: free tx_skbuff in uhdlc_memclean
From: Christophe Leroy (CS GROUP) @ 2026-05-05 5:37 UTC (permalink / raw)
To: Holger Brunck, netdev; +Cc: linuxppc-dev, andrew+netdev, qiang.zhao, horms
In-Reply-To: <20260504161145.2217950-1-holger.brunck@hitachienergy.com>
Le 04/05/2026 à 18:11, Holger Brunck a écrit :
> When cleaning up the resources we need to iterate over the
> tx_skbuf array to free pending TX messages.
>
> Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
> Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index adf3863463f5..68f78aeabdc3 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -739,6 +739,8 @@ static int uhdlc_open(struct net_device *dev)
>
> static void uhdlc_memclean(struct ucc_hdlc_private *priv)
> {
> + int i;
> +
> qe_muram_free(ioread16be(&priv->ucc_pram->riptr));
> qe_muram_free(ioread16be(&priv->ucc_pram->tiptr));
>
> @@ -769,6 +771,11 @@ static void uhdlc_memclean(struct ucc_hdlc_private *priv)
> kfree(priv->rx_skbuff);
> priv->rx_skbuff = NULL;
>
> + for (i = 0; i < TX_BD_RING_LEN) {
> + kfree(priv->tx_skbuff[i]);
I don't think you can just kfree() an skb like this.
I think you have to call dev_kfree_skb_any() instead.
Christophe
> + priv->tx_skbuff[i] = NULL;
> + }
> +
> kfree(priv->tx_skbuff);
> priv->tx_skbuff = NULL;
>
^ permalink raw reply
* Re: [PATCH 1/6] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Harsh Prateek Bora @ 2026-05-05 6:44 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Vaibhav Jain, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), kvm, linux-kernel
In-Reply-To: <20260430054906.94431-2-amachhiw@linux.ibm.com>
On 30/04/26 11:19 am, Amit Machhiwal wrote:
> On IBM POWER systems, newer processor generations can operate in
> compatibility modes corresponding to earlier generations. This becomes
> relevant for nested virtualization, where nested KVM guests may need to
> run with a specific processor compatibility level.
>
> Currently, when running a nested KVM guest (L2) inside a Power11 pSeries
> logical partition (L1) booted in Power10 compatibility mode, the guest
> fails to boot while setting 'arch_compat'. This happens because the CPU
> class is derived from the hardware PVR (via mfspr()), which reflects the
> physical processor generation (Power11), rather than the effective
> compatibility mode (Power10).
>
> As a result, userspace may request a Power11 arch_compat for the L2
> guest. However, the L1 partition, running in Power10 compatibility, has
> only negotiated support up to Power10 with the Power Hypervisor (L0).
> When H_SET_STATE is invoked with a Power11 Logical PVR, the hypervisor
> rejects the request, leading to a late guest boot failure:
>
> KVM-NESTEDv2: couldn't set guest wide elements
> [..KVM reg dump..]
>
> This situation should be detected earlier. Rejecting unsupported
> 'arch_compat' values in 'kvmppc_set_arch_compat()' avoids issuing an
> invalid H_SET_STATE hcall and provides a clearer failure mode.
>
> Add a check to reject Power11 'arch_compat' requests when the host is
> running in Power10 compatibility mode, returning -EINVAL early instead
> of deferring the failure to the hypervisor.
>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 61dbeea317f3..948c6b099a29 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -446,7 +446,13 @@ static int kvmppc_set_arch_compat(struct kvm_vcpu *vcpu, u32 arch_compat)
> guest_pcr_bit = PCR_ARCH_300;
> break;
> case PVR_ARCH_31:
> + guest_pcr_bit = PCR_ARCH_31;
> + break;
> case PVR_ARCH_31_P11:
> + if ((PVR_ARCH_31 & cur_cpu_spec->pvr_mask) ==
> + cur_cpu_spec->pvr_value) {
> + return -EINVAL;
> + }
Is it possible to keep the check generic for applicable ISA versions
(ISA 3.1 onwards?) instead of keeping it specific for P11 ?
Also need to add a comment, why it's not applicable for older ISAs.
> guest_pcr_bit = PCR_ARCH_31;
> break;
> default:
^ permalink raw reply
* RE: [PATCH net] net: wan: fsl_uhdlc_hdlc: fix dma_rmb usage in hdlc_rx_done
From: Holger Brunck @ 2026-05-05 8:14 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, andrew+netdev@lunn.ch,
qiang.zhao@nxp.com, horms@kernel.org
In-Reply-To: <d6957853-9d24-4f35-8ea7-ef4376de991e@kernel.org>
>
> Le 04/05/2026 à 17:56, Holger Brunck a écrit :
> > If dma_rmb is used it has to be done after reading bd_status and
> > checking if R_E_S is zero. Therefore we need to move it into the while loop.
>
> Can you give more details ? Why does dma_rmb() has to be done after reading
> bd_status and checking if R_E_S is zero ?
>
when R_E_S is zero in the status of the buffer descriptor it means the buffer is
filled with data from the device. Now the CPU owns the descriptor. Now we
should execute the dma_rmb to be sure that we read the data correctly.
And this we need to redo for each buffer descriptor which is filled with data,
that’s why it must be done within the for loop and not before and after.
This is also consistent with the example in Documentation/memory-barriers.txt
Best regards
Holger
^ permalink raw reply
* RE: [PATCH net] net: wan: fsl_ucc_hdlc: fix indentation error
From: Holger Brunck @ 2026-05-05 8:16 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, andrew+netdev@lunn.ch,
qiang.zhao@nxp.com, horms@kernel.org
In-Reply-To: <e3abfd12-6537-42b1-b35e-c79a06f87172@kernel.org>
>
> Le 04/05/2026 à 18:07, Holger Brunck a écrit :
> > Remove the whitespace to fix the indentation.
>
> Do we really need a patch for that ? What's the added value of doing this change
> compared to the cost of doing it ?
>
no not mandatory needed. I just saw that and thought that also such minor issues
should be fixed. Can be abandoned.
Best regards
Holger
^ permalink raw reply
* Re: [PATCH 2/6] KVM: PPC: Introduce KVM_CAP_PPC_COMPAT_CAPS and KVM_PPC_GET_COMPAT_CAPS
From: Harsh Prateek Bora @ 2026-05-05 8:31 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Vaibhav Jain, Paolo Bonzini, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), kvm, linux-kernel
In-Reply-To: <20260430054906.94431-3-amachhiw@linux.ibm.com>
On 30/04/26 11:19 am, Amit Machhiwal wrote:
> Introduce a new capability and ioctl to expose CPU compatibility modes
> supported by the host processor for nested guests.
>
> Introduce a new KVM capability, KVM_CAP_PPC_COMPAT_CAPS, and a
> corresponding vm ioctl, KVM_PPC_GET_COMPAT_CAPS, to expose processor
> compatibility modes supported by the host.
>
> On IBM POWER systems, newer processor generations (N) can operate in
> compatibility modes corresponding to earlier generations, like (N-1) and
> (N-2). This is particularly relevant for nested virtualization, where
> nested KVM guests may need to run with a specific processor compatibility
> level.
>
> The new ioctl returns a bitmap describing the compatibility modes
> supported by the host in respective bit numbers. This allows userspace
> to select an appropriate compatibility level when configuring nested KVM
> guests.
>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> arch/powerpc/include/uapi/asm/kvm.h | 6 ++++++
> include/uapi/linux/kvm.h | 4 ++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index 077c5437f521..a38dff7a8aea 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -437,6 +437,12 @@ struct kvm_ppc_cpu_char {
> __u64 behaviour_mask; /* valid bits in behaviour */
> };
>
> +/* For KVM_PPC_GET_COMPAT_CAPS */
> +struct kvm_ppc_compat_caps {
> + __u32 flags;
You may either want flags to be __u64, or rearrange to keep variables in
descending order of size or add padding as appropriate.
Also, if we are not using flags with this series, we need to document
comment as /* reserved for future use */
> + __u64 compat_capabilities; /* Capabilities supported by the host */
> +};
> +
> /*
> * Values for character and character_mask.
> * These are identical to the values used by H_GET_CPU_CHARACTERISTICS.
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 6c8afa2047bf..1788a0068662 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -996,6 +996,7 @@ struct kvm_enable_cap {
> #define KVM_CAP_S390_USER_OPEREXEC 246
> #define KVM_CAP_S390_KEYOP 247
> #define KVM_CAP_S390_VSIE_ESAMODE 248
> +#define KVM_CAP_PPC_COMPAT_CAPS 249
>
> struct kvm_irq_routing_irqchip {
> __u32 irqchip;
> @@ -1349,6 +1350,9 @@ struct kvm_s390_keyop {
> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct kvm_device_attr)
> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct kvm_device_attr)
>
> +/* Available with KVM_CAP_PPC_COMPAT_CAPS */
> +#define KVM_PPC_GET_COMPAT_CAPS _IOR(KVMIO, 0xe4, struct kvm_ppc_compat_caps)
> +
This patch can actually be squashed with next patch where the struct,
macros are actually being used.
> /*
> * ioctls for vcpu fds
> */
^ permalink raw reply
* RE: [PATCH net] net: wan: fsl_ucc_hdlc: free tx_skbuff in uhdlc_memclean
From: Holger Brunck @ 2026-05-05 8:33 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, andrew+netdev@lunn.ch,
qiang.zhao@nxp.com, horms@kernel.org
In-Reply-To: <3e1a653b-81bc-4008-8f84-77c823aeef49@kernel.org>
>
> Le 04/05/2026 à 18:11, Holger Brunck a écrit :
> > When cleaning up the resources we need to iterate over the tx_skbuf
> > array to free pending TX messages.
> >
> > Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
> > Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
> > ---
> > drivers/net/wan/fsl_ucc_hdlc.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/net/wan/fsl_ucc_hdlc.c
> > b/drivers/net/wan/fsl_ucc_hdlc.c index adf3863463f5..68f78aeabdc3
> > 100644
> > --- a/drivers/net/wan/fsl_ucc_hdlc.c
> > +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> > @@ -739,6 +739,8 @@ static int uhdlc_open(struct net_device *dev)
> >
> > static void uhdlc_memclean(struct ucc_hdlc_private *priv)
> > {
> > + int i;
> > +
> > qe_muram_free(ioread16be(&priv->ucc_pram->riptr));
> > qe_muram_free(ioread16be(&priv->ucc_pram->tiptr));
> >
> > @@ -769,6 +771,11 @@ static void uhdlc_memclean(struct ucc_hdlc_private
> *priv)
> > kfree(priv->rx_skbuff);
> > priv->rx_skbuff = NULL;
> >
> > + for (i = 0; i < TX_BD_RING_LEN) {
> > + kfree(priv->tx_skbuff[i]);
>
> I don't think you can just kfree() an skb like this.
>
> I think you have to call dev_kfree_skb_any() instead.
>
yes you are right or at least dev_kfree_skb() as the error handling code in
ucc_hdlc_tx does.
Thanks
Holger
^ permalink raw reply
* Re: [PATCH net] net: wan: fsl_uhdlc_hdlc: fix dma_rmb usage in hdlc_rx_done
From: Christophe Leroy (CS GROUP) @ 2026-05-05 8:37 UTC (permalink / raw)
To: Holger Brunck, netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, andrew+netdev@lunn.ch,
qiang.zhao@nxp.com, horms@kernel.org
In-Reply-To: <AM0PR06MB10396920527D0B69CC9D9BDFEF73E2@AM0PR06MB10396.eurprd06.prod.outlook.com>
Le 05/05/2026 à 10:14, Holger Brunck a écrit :
>>
>> Le 04/05/2026 à 17:56, Holger Brunck a écrit :
>>> If dma_rmb is used it has to be done after reading bd_status and
>>> checking if R_E_S is zero. Therefore we need to move it into the while loop.
>>
>> Can you give more details ? Why does dma_rmb() has to be done after reading
>> bd_status and checking if R_E_S is zero ?
>>
>
> when R_E_S is zero in the status of the buffer descriptor it means the buffer is
> filled with data from the device. Now the CPU owns the descriptor. Now we
> should execute the dma_rmb to be sure that we read the data correctly.
> And this we need to redo for each buffer descriptor which is filled with data,
> that’s why it must be done within the for loop and not before and after.
We enter hdlc_rx_done() after an interrupt which triggers scheduling of
ucc_hdlc_poll(). I think dma_rmb() is needed _before_ reading the first
status, otherwise it might read an erroneous status.
Once we are here the interrupt has been cleared so any new buffer will
trigger a new interrupt and call again this function. Therefore I don't
think it is worth the cost of a dma_rmb() inside the loop.
Christophe
^ permalink raw reply
* Re: [PATCH 3/6] KVM: PPC: Wire up KVM_PPC_GET_COMPAT_CAPS ioctl
From: Harsh Prateek Bora @ 2026-05-05 8:46 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Vaibhav Jain, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), kvm, linux-kernel
In-Reply-To: <20260430054906.94431-4-amachhiw@linux.ibm.com>
On 30/04/26 11:19 am, Amit Machhiwal wrote:
> Add handling for KVM_PPC_GET_COMPAT_CAPS in kvm_arch_vm_ioctl() and
> advertise support via KVM_CAP_PPC_COMPAT_CAPS.
>
> The ioctl retrieves host CPU compatibility capabilities via a
> PowerPC-specific backend implementation when available. If the
> capability is not supported, the ioctl returns success with no
> capabilities set, allowing userspace to fall back gracefully.
>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> arch/powerpc/include/asm/kvm_ppc.h | 1 +
> arch/powerpc/kvm/powerpc.c | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index 0953f2daa466..cadfb839e836 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -319,6 +319,7 @@ struct kvmppc_ops {
> bool (*hash_v3_possible)(void);
> int (*create_vm_debugfs)(struct kvm *kvm);
> int (*create_vcpu_debugfs)(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry);
> + int (*get_compat_cpu_ver)(struct kvm_ppc_compat_caps *host_caps);
> };
>
> extern struct kvmppc_ops *kvmppc_hv_ops;
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 00302399fc37..f35017d83d77 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -697,6 +697,12 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> }
> }
> break;
> +#if defined(CONFIG_KVM_BOOK3S_HV_POSSIBLE)
> + case KVM_CAP_PPC_COMPAT_CAPS:
> + if (kvmhv_on_pseries())
What about PowerNV ?
Also, can't we just check if get_compat_cpu_ver is initialized and
return accordingly ?
> + r = 1;
> + break;
> +#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
> default:
> r = 0;
> break;
> @@ -2463,6 +2469,19 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> r = kvm->arch.kvm_ops->svm_off(kvm);
> break;
> }
> + case KVM_PPC_GET_COMPAT_CAPS: {
> + struct kvm_ppc_compat_caps host_caps;
> +
> + memset(&host_caps, 0, sizeof(host_caps));
> + if (!kvm->arch.kvm_ops->get_compat_cpu_ver)
> + goto out;
I guess we want to init r = 0 before returning in this case.
Also prefer break over goto unless really needed.
> +
> + r = kvm->arch.kvm_ops->get_compat_cpu_ver(&host_caps);
> + if (!r && copy_to_user(argp, &host_caps,
> + sizeof(host_caps)))
> + r = -EFAULT;
> + break;
> + }
> default: {
> struct kvm *kvm = filp->private_data;
> r = kvm->arch.kvm_ops->arch_vm_ioctl(filp, ioctl, arg);
^ permalink raw reply
* [PATCH v1 0/6] objtool: Fixup alternate feature relative addresses
From: Sathvika Vasireddy @ 2026-05-05 8:46 UTC (permalink / raw)
To: nathan, nsc, maddy, mpe, npiggin, chleroy, jpoimboe, peterz,
ojeda, masahiroy, lossin, tamird, thomas.weissschuh, rostedt,
ihor.solodrai, thuth, pmladek, aliceryhl, elver, kees, legion,
ardb, yuxuan.zuo, alexghiti, alexandre.chartre, bp, linux-kbuild,
linux-kernel, linuxppc-dev, sv
This patch series implements build-time fixup of alternate feature
relative addresses for powerpc.
Previously, Nicholas Piggin proposed a build-time solution using a
custom PowerPC tool [1], which provided the foundation for this approach.
The current implementation leverages objtool's existing ELF parsing
infrastructure to do the same.
This patchset applies atop powerpc/merge branch.
[1] Original PowerPC tool approach:
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20170521010130.13552-1-npiggin@gmail.com/
Testing:
Build and Boot tested on ppc64le, ppc64be, and ppc32be configs.
Sathvika Vasireddy (6):
objtool/powerpc: Add build-time fixup of alternate feature branch
targets
objtool: Set ELF_F_LAYOUT flag to preserve vmlinux segment layout
objtool: Fix "can't find starting instruction" warnings on vmlinux
objtool/powerpc: Skip jump destination analysis and unnanotated
intra-function call warnings for --ftr-fixup
kbuild: Add objtool integration for PowerPC feature fixups
powerpc: Enable build-time feature fixup processing by default
Makefile | 7 +
arch/powerpc/Kconfig | 3 +
arch/powerpc/Makefile | 5 +
arch/powerpc/include/asm/feature-fixups.h | 2 +-
arch/powerpc/kernel/vmlinux.lds.S | 8 +-
arch/powerpc/lib/feature-fixups.c | 12 -
scripts/Makefile.lib | 4 +-
scripts/Makefile.vmlinux | 11 +-
tools/objtool/arch/powerpc/decode.c | 15 +-
tools/objtool/arch/powerpc/special.c | 451 ++++++++++++++++++++++
tools/objtool/builtin-check.c | 2 +
tools/objtool/check.c | 57 ++-
tools/objtool/elf.c | 4 +
tools/objtool/include/objtool/builtin.h | 1 +
tools/objtool/include/objtool/special.h | 56 +++
tools/objtool/special.c | 29 ++
16 files changed, 637 insertions(+), 30 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v1 2/6] objtool: Set ELF_F_LAYOUT flag to preserve vmlinux segment layout
From: Sathvika Vasireddy @ 2026-05-05 8:46 UTC (permalink / raw)
To: nathan, nsc, maddy, mpe, npiggin, chleroy, jpoimboe, peterz,
ojeda, masahiroy, lossin, tamird, thomas.weissschuh, rostedt,
ihor.solodrai, thuth, pmladek, aliceryhl, elver, kees, legion,
ardb, yuxuan.zuo, alexghiti, alexandre.chartre, bp, linux-kbuild,
linux-kernel, linuxppc-dev, sv
In-Reply-To: <20260505084628.17940-1-sv@linux.ibm.com>
When objtool writes changes back to vmlinux with --ftr-fixup --link,
libelf recalculates the file layout and inserts padding between
sections. This corrupts the ELF segment structure, causing kexec to
fail with:
ELF Note corrupted !
Cannot determine the file type of vmlinux
This happens because libelf's default behavior assumes it can freely
rearrange section offsets when writing, which breaks the carefully
constructed vmlinux layout produced by the linker.
Set ELF_F_LAYOUT after elf_begin() to instruct libelf that the
application is responsible for the file layout. This prevents libelf
from inserting padding or repositioning sections while still allowing
data modifications to be written back.
Signed-off-by: Sathvika Vasireddy <sv@linux.ibm.com>
---
tools/objtool/elf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 2ca2a4e4b92e..8752cec5e818 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -1162,6 +1162,9 @@ struct elf *elf_open_read(const char *name, int flags)
goto err;
}
+ if (opts.ftr_fixup)
+ elf_flagelf(elf->elf, ELF_C_SET, ELF_F_LAYOUT);
+
if (!gelf_getehdr(elf->elf, &elf->ehdr)) {
ERROR_ELF("gelf_getehdr");
goto err;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 3/6] objtool: Fix "can't find starting instruction" warnings on vmlinux
From: Sathvika Vasireddy @ 2026-05-05 8:46 UTC (permalink / raw)
To: nathan, nsc, maddy, mpe, npiggin, chleroy, jpoimboe, peterz,
ojeda, masahiroy, lossin, tamird, thomas.weissschuh, rostedt,
ihor.solodrai, thuth, pmladek, aliceryhl, elver, kees, legion,
ardb, yuxuan.zuo, alexghiti, alexandre.chartre, bp, linux-kbuild,
linux-kernel, linuxppc-dev, sv
In-Reply-To: <20260505084628.17940-1-sv@linux.ibm.com>
Objtool throws a lot of can't find starting instruction warnings
when run on vmlinux with --ftr-fixup option.
These warnings are seen because find_insn() function looks for
instructions at offsets that are relative to the start of the section.
In case of individual object files (.o), there are no can't find
starting instruction warnings seen because the actual offset
associated with an instruction is itself a relative offset since the
sections start at offset 0x0.
However, in case of vmlinux, find_insn() function fails to find
instructions at the actual offset associated with an instruction
since the sections in vmlinux do not start at offset 0x0. Due to
this, find_insn() will look for absolute offset and not the relative
offset. This is resulting in a lot of can't find starting instruction
warnings when objtool is run on vmlinux.
To fix this, pass offset that is relative to the start of the section
to find_insn().
find_insn() is also looking for symbols of size 0. But, objtool does
not store empty STT_NOTYPE symbols in the rbtree. Due to this,
for empty symbols, objtool is throwing can't find starting
instruction warnings. Fix this by ignoring symbols that are of
size 0 since objtool does not add them to the rbtree.
Signed-off-by: Sathvika Vasireddy <sv@linux.ibm.com>
---
tools/objtool/check.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 8cb55fe6e1dc..f3501b149829 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -412,7 +412,7 @@ static int decode_instructions(struct objtool_file *file)
{
struct section *sec;
struct symbol *func;
- unsigned long offset;
+ unsigned long offset, func_off;
struct instruction *insn;
for_each_sec(file->elf, sec) {
@@ -494,17 +494,25 @@ static int decode_instructions(struct objtool_file *file)
if (func->embedded_insn || func->alias != func)
continue;
- if (!find_insn(file, sec, func->offset)) {
+ if (func->len == 0 && is_notype_sym(func))
+ continue;
+
+ func_off = opts.ftr_fixup ?
+ func->offset - sec->sh.sh_addr : func->offset;
+
+ if (!find_insn(file, sec, func_off)) {
ERROR("%s(): can't find starting instruction", func->name);
return -1;
}
- sym_for_each_insn(file, func, insn) {
+ for (insn = find_insn(file, sec, func_off);
+ insn && insn->offset < func_off + func->len;
+ insn = next_insn_same_sec(file, insn)) {
insn->sym = func;
if (is_func_sym(func) &&
insn->type == INSN_ENDBR &&
list_empty(&insn->call_node)) {
- if (insn->offset == func->offset) {
+ if (insn->offset == func_off) {
list_add_tail(&insn->call_node, &file->endbr_list);
file->nr_endbr++;
} else {
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox