* Re: [PATCH v2 0/2] vsprintf: add upper case to %p[mM] et alia
From: Petr Mladek @ 2026-06-12 9:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jiri Kosina, Daniel J. Ogorchock, Tamir Duberstein, linux-doc,
linux-kernel, linux-input, Steven Rostedt, Rasmus Villemoes,
Sergey Senozhatsky, Jonathan Corbet, Shuah Khan,
Benjamin Tissoires, Andrew Morton
In-Reply-To: <20260603104351.152085-1-andriy.shevchenko@linux.intel.com>
On Wed 2026-06-03 12:34:01, Andy Shevchenko wrote:
> The first patch induced by Sashiko rightfully rises a concern on
> potential ABI breakage. To avoid that and allow the user (patch 2)
> to be converted to use unified output introduce %p[mM][...]U for
> printing in upper case. Tests are included and passed.
>
> Changelog v2:
> - added first patch (Sashiko)
>
> Andy Shevchenko (2):
> vsprintf: Add upper case flavour to %p[mM]
> HID: nintendo: Use %pM format specifier for MAC addresses
For the whole series:
Reviewed-by: Petr Mladek <pmladek@suse.com>
I am going to queue it via printk tree.
Best Regards,
Petr
PS: I am sorry for "late" review. My queue is quite long
at the moment...
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
From: Krzysztof Kozlowski @ 2026-06-12 8:53 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, Conor Dooley
In-Reply-To: <20260612030304.5165-2-zmzhu0630@163.com>
On Fri, Jun 12, 2026 at 11:03:02AM +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.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
>
Do not add blank lines between tags. I recommend to use b4 to handle
this - it would solve your problems, including the missing tag in
previous version.
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> .../bindings/hwmon/pmbus/silergy,sq24860.yaml | 74 +++++++++++++++++++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
> new file mode 100644
> index 000000000000..03ef82c11e1a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id: http://devicetree.org/schemas/hwmon/pmbus/silergy,sq24860.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Silergy SQ24860 eFuse
> +
> +maintainers:
> + - Ziming Zhu <ziming.zhu@silergycorp.com>
> +
> +description:
> + The Silergy SQ24860 is an integrated, high-current circuit protection and
> + power management device with PMBus interface.
> +
> +properties:
> + compatible:
> + const: silergy,sq24860
> +
> + reg:
> + maxItems: 1
> +
> + silergy,rimon-micro-ohms:
Isn't this just shunt-resistor-micro-ohms? IOW, didn't you just describe
the shunt?
> + description:
> + Micro-ohms value of the resistance installed between the IMON pin and
> + the ground reference.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 09/16] riscv: Add Zic64b to cpufeature and hwprobe
From: Conor Dooley @ 2026-06-12 8:41 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt,
Qingwei Hu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-9-3f01a2449488@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]
On Thu, Jun 11, 2026 at 04:12:46PM -0400, Guodong Xu wrote:
> From: Qingwei Hu <qingwei.hu@bytedance.com>
>
> Zic64b mandates 64-byte naturally aligned cache blocks and is a
> mandatory extension of the RVA22 and RVA23 profiles. Allocate a
> RISCV_ISA_EXT_ZIC64B id, parse "zic64b" from the ISA string with a
> validate callback that requires each cbom/cbop/cboz cache block size to
> be 64 bytes when it is present, and export it through hwprobe.
>
> Link: https://lists.riscv.org/g/tech-unprivileged/topic/question_about_zic64b_and/119631059
> Signed-off-by: Qingwei Hu <qingwei.hu@bytedance.com>
> Co-developed-by: Guodong Xu <docular.xu@gmail.com>
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
> +static int riscv_ext_zic64b_validate(const struct riscv_isa_ext_data *data,
> + const unsigned long *isa_bitmap)
> +{
> + /*
> + * Zic64b mandates 64-byte naturally aligned cache blocks; cross-check the
> + * cbom/cbop/cboz block-size (when declared) device-tree properties to
> + * avoid inconsistency.
> + */
> + if ((riscv_cbom_block_size && riscv_cbom_block_size != 64) ||
> + (riscv_cbop_block_size && riscv_cbop_block_size != 64) ||
> + (riscv_cboz_block_size && riscv_cboz_block_size != 64)) {
> + pr_err("Zic64b detected in ISA string, disabling as a CBO block size is not 64 bytes\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
I'm inclined to object to this, but we don't have validation on ACPI
stuff to be able to mandate that people fill in the rhct entries.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net-next v7 1/5] net: add dev->bql flag to allow BQL sysfs for IFF_NO_QUEUE devices
From: hawk @ 2026-06-12 8:35 UTC (permalink / raw)
To: netdev
Cc: kernel-team, simon.schippers, Jesper Dangaard Brouer,
Jonas Köppeler, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Kuniyuki Iwashima, Stanislav Fomichev,
Christian Brauner, Frederic Weisbecker, Yajun Deng, linux-doc,
linux-kernel
In-Reply-To: <20260612083530.1650245-1-hawk@kernel.org>
From: Jesper Dangaard Brouer <hawk@kernel.org>
Virtual devices with IFF_NO_QUEUE or lltx are excluded from BQL sysfs
by netdev_uses_bql(), since they traditionally lack real hardware
queues. However, some virtual devices like veth implement a real
ptr_ring FIFO with NAPI processing and benefit from BQL to limit
in-flight bytes and reduce latency.
Add a per-device 'bql' bitfield boolean in the priv_flags_slow section
of struct net_device. When set, it overrides the IFF_NO_QUEUE/lltx
exclusion and exposes BQL sysfs entries (/sys/class/net/<dev>/queues/
tx-<n>/byte_queue_limits/). The flag is still gated on CONFIG_BQL.
This allows drivers that use BQL despite being IFF_NO_QUEUE to opt in
to sysfs visibility for monitoring and debugging.
Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org>
Tested-by: Jonas Köppeler <j.koeppeler@tu-berlin.de>
---
Documentation/networking/net_cachelines/net_device.rst | 1 +
include/linux/netdevice.h | 2 ++
net/core/net-sysfs.c | 8 +++++++-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/net_cachelines/net_device.rst b/Documentation/networking/net_cachelines/net_device.rst
index eb2e6851c6f6..a65d48b6ecc1 100644
--- a/Documentation/networking/net_cachelines/net_device.rst
+++ b/Documentation/networking/net_cachelines/net_device.rst
@@ -169,6 +169,7 @@ unsigned_long:1 see_all_hwtstamp_requests
unsigned_long:1 change_proto_down
unsigned_long:1 netns_immutable
unsigned_long:1 fcoe_mtu
+unsigned_long:1 bql netdev_uses_bql(net-sysfs.c)
struct list_head net_notifier_list
struct macsec_ops* macsec_ops
struct udp_tunnel_nic_info* udp_tunnel_nic_info
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 7f4f0837c09f..f699fded20b4 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2079,6 +2079,7 @@ enum netdev_reg_state {
* @change_proto_down: device supports setting carrier via IFLA_PROTO_DOWN
* @netns_immutable: interface can't change network namespaces
* @fcoe_mtu: device supports maximum FCoE MTU, 2158 bytes
+ * @bql: device uses BQL (DQL sysfs) despite having IFF_NO_QUEUE
*
* @net_notifier_list: List of per-net netdev notifier block
* that follow this device when it is moved
@@ -2495,6 +2496,7 @@ struct net_device {
unsigned long change_proto_down:1;
unsigned long netns_immutable:1;
unsigned long fcoe_mtu:1;
+ unsigned long bql:1;
struct list_head net_notifier_list;
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 0e71c9ed41e8..3cb470b0f17d 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1939,10 +1939,16 @@ static const struct kobj_type netdev_queue_ktype = {
static bool netdev_uses_bql(const struct net_device *dev)
{
+ if (!IS_ENABLED(CONFIG_BQL))
+ return false;
+
+ if (dev->bql)
+ return true;
+
if (dev->lltx || (dev->priv_flags & IFF_NO_QUEUE))
return false;
- return IS_ENABLED(CONFIG_BQL);
+ return true;
}
static int netdev_queue_add_kobject(struct net_device *dev, int index)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 3/4] PCI: endpoint: Add support for DOE initialization and setup in EPC core
From: Aksh Garg @ 2026-06-12 8:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260611191252.GA499821@bhelgaas>
On 12/06/26 00:42, Bjorn Helgaas wrote:
> On Wed, Jun 10, 2026 at 03:32:55PM +0530, Aksh Garg wrote:
>> Add pci_epc_init_capabilities() in EPC core driver to initialize and
>> setup the capabilities supported by the EPC driver. This calls
>> pci_epc_doe_setup() to setup the DOE framework for an endpoint controller,
>> which discovers the DOE capabilities (extended capability ID 0x2E), and
>> registers each discovered DOE mailbox for all the functions in the
>> endpoint controller.
>>
>> Add pci_epc_deinit_capabilities() in EPC core driver for cleanup of the
>> resources used by the capabilities of the EPC driver. This calls
>> pci_ep_doe_destroy() to destroy all DOE mailboxes and free associated
>> resources.
>>
>> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> Signed-off-by: Aksh Garg <a-garg7@ti.com>
>> ---
>> +/**
>> + * pci_epc_doe_setup() - Discover and setup DOE mailboxes for all functions
>> + * @epc: the EPC device on which DOE mailboxes has to be setup
>> + *
>> + * Discover DOE (Data Object Exchange) capabilities for all physical functions
>> + * in the endpoint controller and register DOE mailboxes.
>> + *
>> + * Returns: 0 on success, -errno on failure
>> + */
>> +static int pci_epc_doe_setup(struct pci_epc *epc)
>> +{
>> + u8 func_no, vfunc_no = 0;
>> + u16 cap_offset;
>> + int ret;
>> +
>> + if (!epc->ops || !epc->ops->find_ext_capability)
>> + return -EINVAL;
>
Hi Bjorn,
Thank you for your feedback comments. I will work on them and post v6
series incorporating the changes.
> I don't see anything that sets pci_epc_ops.find_ext_capability in this
> series, so this looks currently unused and untestable, so likely not
> mergeable as-is. What's the plan for users of this?
>
Currently there is no EPC driver upstream which supports DOE yet.
However, I am working on a platform which supports DOE (support for
which would be added soon). Mani pointed out that if EPC driver support
for the same is guaranteed to be added soon, the APIs can be merged
first.
For the demonstration purpose, he asked to show how an EPC driver is
expected to use the API as a snippet in the cover letter itself.
I will add a code snippet in the cover letter, which sets
pci_epc_ops.find_ext_capability as well, if that is acceptable.
Regards,
Aksh Garg
>> + /* Discover DOE capabilities for all functions */
>> + for (func_no = 0; func_no < epc->max_functions; func_no++) {
>> + mutex_lock(&epc->lock);
>> + cap_offset = epc->ops->find_ext_capability(epc, func_no,
>> + vfunc_no, 0,
>> + PCI_EXT_CAP_ID_DOE);
>> + mutex_unlock(&epc->lock);
>> +
>> + while (cap_offset) {
>> + /* Register this DOE mailbox */
>> + ret = pci_ep_doe_add_mailbox(epc, func_no, cap_offset);
>> + if (ret) {
>> + dev_warn(&epc->dev,
>> + "[pf%d:offset %x] failed to add DOE mailbox\n",
>> + func_no, cap_offset);
>> + }
>> +
>> + mutex_lock(&epc->lock);
>> + cap_offset = epc->ops->find_ext_capability(epc, func_no,
>> + vfunc_no, cap_offset,
>> + PCI_EXT_CAP_ID_DOE);
>> + mutex_unlock(&epc->lock);
>> + }
>> + }
>> +
>> + dev_dbg(&epc->dev, "DOE mailboxes setup complete\n");
>> + return 0;
>> +}
>> +
^ permalink raw reply
* Re: [PATCH v4 08/16] dt-bindings: riscv: Add Zic64b extension description
From: Conor Dooley @ 2026-06-12 8:23 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-8-3f01a2449488@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4032 bytes --]
On Thu, Jun 11, 2026 at 04:12:45PM -0400, Guodong Xu wrote:
> Zic64b mandates that cache blocks are 64 bytes in size and naturally
> aligned in the address space. It is a mandatory extension of both the
> RVA22 (U64/S64) and RVA23 (U64/S64) profiles, ratified with RISC-V
> Profiles Version 1.0.
>
> Document it so it can be described in the riscv,isa-extensions property,
> alongside the related Zicbom/Zicbop/Zicboz cache-block extensions. Since
> Zic64b fixes the cache block size at 64 bytes, also add a schema check
^^
Not that it matters, but there's an extra space here.
> requiring any present cbom/cbop/cboz block size to be 64.
>
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
> ---
> v4: Insert zic64b at its sorted position (before zicbom).
> Update the commit message.
> v3: New patch.
> ---
> .../devicetree/bindings/riscv/extensions.yaml | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index 5ffc40d599c02..1c24999beb59e 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -494,6 +494,12 @@ properties:
> in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
> riscv-isa-manual.
>
> + - const: zic64b
> + description:
> + The standard Zic64b extension for 64-byte naturally aligned cache
> + blocks, as ratified in RISC-V Profiles Version 1.0, with commit
> + b1d806605f87 ("Updated to ratified state.")
> +
> - const: zicbom
> description:
> The standard Zicbom extension for base cache management operations as
> @@ -1142,6 +1148,20 @@ allOf:
> not:
> contains:
> const: zilsd
> + # Zic64b mandates 64-byte naturally aligned cache blocks
> + - if:
> + properties:
> + riscv,isa-extensions:
> + contains:
> + const: zic64b
> + then:
> + properties:
> + riscv,cbom-block-size:
> + const: 64
> + riscv,cbop-block-size:
> + const: 64
> + riscv,cboz-block-size:
> + const: 64
I think we also need to have
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 1c24999beb59e..bbd442cfbd904 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -1162,6 +1162,32 @@ allOf:
const: 64
riscv,cboz-block-size:
const: 64
+ # All three Zicbo* extensions require their block size property as there's no
+ # default.
+ - if:
+ properties:
+ riscv,isa-extensions:
+ contains:
+ const: zicbom
+ then:
+ required:
+ - riscv,cbom-block-size
+ - if:
+ properties:
+ riscv,isa-extensions:
+ contains:
+ const: zicbop
+ then:
+ required:
+ - riscv,cbop-block-size
+ - if:
+ properties:
+ riscv,isa-extensions:
+ contains:
+ const: zicboz
+ then:
+ required:
+ - riscv,cboz-block-size
additionalProperties: true
...
because I don't think there's a warning generated at present* if someone
does "zicbom" + "zic64b" and doesn't have a riscv,cbom-block-size property,
only if they have one and it isn't 64. I think the former is a bigger
problem than the latter.
Probably needs to be an additional patch, because it has value whether
or not we permit zic64b.
pwbot: cr
Cheers,
Conor.
*: the kernel will warn at runtime, but nothing in dtbs_check etc.
>
> additionalProperties: true
> ...
>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* Re: [PATCH 12/15] accel/qda: Add FastRPC invocation support
From: Dmitry Baryshkov @ 2026-06-12 8:21 UTC (permalink / raw)
To: Ekansh Gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <b22703d3-03f2-4835-9eee-c3d1fa50a5ce@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 03:08:17PM +0530, Ekansh Gupta wrote:
> On 08-06-2026 02:44, Dmitry Baryshkov wrote:
> > On Thu, Jun 04, 2026 at 10:39:14AM +0530, Ekansh Gupta wrote:
> >> On 20-05-2026 19:26, Dmitry Baryshkov wrote:
> >>> On Tue, May 19, 2026 at 11:46:02AM +0530, Ekansh Gupta via B4 Relay wrote:
> >>>> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> >>>>
> >>>> Implement the FastRPC remote procedure call path, allowing user-space
> >>>> to invoke methods on the DSP via DRM_IOCTL_QDA_REMOTE_INVOKE.
> >>>>
> >>>> qda_fastrpc.c / qda_fastrpc.h
> >>>> Implements the FastRPC protocol layer: argument marshalling
> >>>> (qda_fastrpc_invoke_pack), response unmarshalling
> >>>> (qda_fastrpc_invoke_unpack), and invocation context lifecycle
> >>>> management. Each invocation allocates a fastrpc_invoke_context
> >>>> which tracks buffer descriptors, GEM objects, and the completion
> >>>> used to synchronise with the DSP response.
> >>>>
> >>>> Buffer arguments are handled in three ways:
> >>>> - DMA-BUF fd: imported via PRIME, IOMMU-mapped dma_addr used
> >>>> - Direct (inline): copied into the GEM-backed message buffer
> >>>> - DMA handle: fd forwarded to DSP, physical page descriptor computed
> >>>
> >>> No. This needs to go away. The QDA should support only one way to pass
> >>> data - via the GEM buffers. Everything else should be handled by the
> >>> shim layer, etc.
> >> each FD passed here is a GEM buffer. The reason to pass fd is that there
> >> are some APIs on DSP side which takes fd as an argument and the user
> >> might use the same on their skel implementation. So in this case the
> >> remote call will take fd to DSP and the skel implementation will use the
> >> FD.>
> >
> > Then handle it all on the userspace side. In the end, bad library API is
> > not a reason to complicate kernel API and kernel driver.
> The problem is that the user passes the fd as an argument to the remote
> call which the fastrpc library cannot decrypt. So basically the user can
> allocate some fd buffer(say with FD1) and then call some remote method
> passing FD1 as an int argument to call HAP_mmap on the same at DSP side,
> this int argument cannot be differentiated by fastrpc library as
> FD/non-FD argument.
How does it make the difference _now_? I hope it doesn't accept u64
value, bruteforcing if it is an FD, address or something else.
> >
> >>>> +#define FASTRPC_SCALARS(method, in, out) \
> >>>> + FASTRPC_BUILD_SCALARS(0, method, in, out, 0, 0)
> >>>> +
> >>>> +/**
> >>>> + * struct fastrpc_buf_overlap - Buffer overlap tracking structure
> >>>> + *
> >>>> + * Tracks overlapping buffer regions to optimise memory mapping and avoid
> >>>> + * redundant mappings of the same physical memory.
> >>>
> >>> WHat for? Even if this is a valid optimization, implement it as a
> >>> subsequent patch. The first goal should be very simple - get GEM buffers
> >>> from the app, pass them to the DSP, read the results.
> >> yes, this implementation is mimicking the existing fastrpc design where
> >> non-FD buffers are also supported. I am currently evaluating the
> >> maintainance of such buffers from userspace side and trying to
> >> understand the impacts of the same. I am planning to bring it as a
> >> future enhancement if there is no regression.>
> >
> > Other way around. Drop it for now and bring it back if it has any
> > positive impact.
> We did evaluation and don't see userspace side handling being feasible
> for non-FD buffers, I'll try to summarize the current design and the
> problem:
>
> Currently a remote call can take up to 255 arguments and in many cases
> the user passes the buffers as non-FD arguments which is then copied to
> meta data and sent to DSP. Before copy there is an operation to identify
> if the buffers are overlapped so that it can be maintained efficiently.
>
> DSP understands this based on offset and maps it accordingly, so for
> multiple small sized arguments, there is a possibility that a single
> page is used. Now if we allocate GEM buffers for each of these small
> arguments, it would lead to creation of multiple pages(can go up to 255)
> and all these pages then are required to be mapped onto DSP which could
> also lead to DSP address space exhaustion. So the limitation is too many
> pages and that DSP cannot handling this as efficiently as overlapped
> copy buffers.>
We started to discuss it during the call. Pretty much like you use a
single page (or single buffer) for small buffers in the kernel, your
userspace should be able to create the same single-BO-multiple-data
argument and then pass it to the kernel.
I think, you are mixing several different problems into a single bucket.
One is how to pass and map data buffers to the DSP, the other one is
how to pass arguments via the uAPI.
I think, for the second question we have an answer. Each argument is
located in a buffer at a certain offset provided by the userspace. All
the buffers are identified by the GEM handles. It should not matter for
the kernel driver if the buffer has been allocated from the QDA device
or if it was imported from another DMA-BUF provider. It should not
matter (again, for the kernel), if the user wants to pass all arguments
in a single BO or if each argument is a separate BO. The kernel must
collect GEM handles used by the call, make sure that they are mapped to
the DSP address space, covert them to the addresses for the DSP side and
then pass those addresses to the DSP. All the overlapping calculations,
packing, strategy belong to the userspace.
> >>>> + /** @handle: Handle of the remote method being invoked */
> >>>> + u32 handle;
> >>>> + /** @crc: Pointer to CRC values for data integrity checking */
> >>>> + u32 *crc;
> >>>
> >>> Add it later. It's unused. Drop all unused fields.
> >> ack.>
> >>>> + /** @fdlist: Pointer to array of DMA-BUF file descriptors */
> >>>> + u64 *fdlist;
> >>>
> >>> Why do you need DMA-BUFs in the invocation context? They all should be
> >>> GEM buffers.
> >> the reason is that the users are dependent on FDs as they can import
> >> buffers allocated from anywhere and there are DSP APIs which takes fd as
> >> an argument, so they might end up using the same in there skel
> >> implementation.>
> >
> > No, DSP API can't take FD, they don't quite cross the OS and IOMMU
> > boundary. It's the userspace library API. Which might be improved,
> > rewritten, implemented underneath, etc. For the kernel side please,
> > pass _only_ GEM handles + offsets.
> Yes, but with the current DSP design, DSP APIs take FD just because of
> client/user design. On fastrpc, users could bring FD from any source,
> register it with fastrpc and pass it on to DSP.
The users can bring FD from any source, import it to the QDA's GEM and
then receive the handle.
> The major problem is
> what I mentioned above, where the user application passes the FD as an
> integer argument and the fastrpc library not able to identify if that
> int is an fd or some other data.>
Please provide an example: the API and the ways to pass the data via the
FD or 'other data'. Explain, how _currently_ it is handled.
But, anyway, a bad userspace design is not a reason to complicate uAPI.
Library API is not written in stone, there are SOVERSIONs, wrappers and
all other ways to provide phase out, deprecation and backwards
compatibility. The uAPI, on the other hand, is written in stone.
> >>>> + /** @pkt_size: Total payload size in bytes */
> >>>> + u64 pkt_size;
> >>>> + /** @aligned_pkt_size: Page-aligned payload size for GEM allocation */
> >>>> + u64 aligned_pkt_size;
> >>>> + /** @list: Array of invoke buffer descriptors */
> >>>> + struct fastrpc_invoke_buf *list;
> >>>> + /** @pages: Array of physical page descriptors for all arguments */
> >>>> + struct fastrpc_phy_page *pages;
> >>>> + /** @input_pages: Array of physical page descriptors for input buffers */
> >>>> + struct fastrpc_phy_page *input_pages;
> >>>
> >>> I think you are trying to bring all the complexity from the old driver
> >>> with no added benefit. Please don't. Use the existing memory manager.
> >>> Let it handle all the gory details. If someting is not there, we should
> >>> consider extending GEM instead.
> >> I'm not changing the metadata format as the DSP might not understand the
> >> messages if we modify it.
> >
> > Well, it's up to you to know if DSP will understand the message or not.
> > The probability ("might not") is not suitable here. Anyway, let's get
> > rid of the various data formats first, then maybe some of the items will
> > go away on their own.
> ack>
> >> Also, the fd is still being used because of
> >> the client dependency on it. I'll check if there is any other logic that
> >> needs alteration here.>
> >
> > If the client keeps on passing FD to the library calls, you can map
> > FD to GEM handles in the library code.
> I hope the int argument part mentioned above answers this.>
NO. You are still telling me that you allow users to shove random data
to the kernel and then make the kernel decipher what kind of data it
received. This is a very bad interface. Fix it.
> >>>> +
> >>>> +static int fastrpc_context_get_id(struct fastrpc_invoke_context *ctx, struct qda_dev *qdev)
> >>>> +{
> >>>> + int ret;
> >>>> + u32 id;
> >>>> +
> >>>> + if (!qdev)
> >>>> + return -EINVAL;
> >>>> +
> >>>> + ret = xa_alloc(&qdev->ctx_xa, &id, ctx, xa_limit_32b, GFP_KERNEL);
> >>>> + if (ret)
> >>>> + return ret;
> >>>> +
> >>>> + ctx->ctxid = id << 4;
> >>>
> >>> Why is it being shifted?
> >> this is to accomodate PD type>
> >
> > Not really an answer.
> Okay, let me bring the ctxid layout that DSP expects:
>
> [11:4] = CCCCCCCC (context ID)
> [3:0] = PPPP (PD type)
>
> Based on this PD type, DSP will decide where to queue the message.
And what does it mean?
> >
> >>>> + return 0;
> >>>> +}
> >>>> +
> >>>
> >>
> >
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 07/16] riscv: Add B to hwcap and hwprobe
From: Conor Dooley @ 2026-06-12 8:12 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt,
Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-7-3f01a2449488@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
On Thu, Jun 11, 2026 at 04:12:44PM -0400, Guodong Xu wrote:
> From: Andrew Jones <andrew.jones@oss.qualcomm.com>
>
> Add B to hwcap and ensure when B is present that Zba, Zbb, and Zbs
> are all set. Also expose B via hwprobe (RISCV_HWPROBE_EXT_B in
> RISCV_HWPROBE_KEY_IMA_EXT_1) so that userspace can probe B directly,
> mirroring the F/D/C/V pattern where each is reported via both hwcap
> and hwprobe.
>
> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> [Add B to hwprobe]
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 06/16] riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobe
From: Conor Dooley @ 2026-06-12 8:10 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt,
Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-6-3f01a2449488@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]
On Thu, Jun 11, 2026 at 04:12:43PM -0400, Guodong Xu wrote:
> From: Andrew Jones <andrew.jones@oss.qualcomm.com>
>
> Add Ziccamoa, Ziccif, and Za64rs to riscv_isa_ext[] so they can be
> parsed from devicetree/ACPI ISA strings. Ziccrse is already present
> in cpufeature; this patch only adds its hwprobe exposure.
>
> Expose all four extensions via hwprobe through new bits in
> RISCV_HWPROBE_KEY_IMA_EXT_1 (RISCV_HWPROBE_EXT_ZICCAMOA, _ZICCIF,
> _ZICCRSE, _ZA64RS), so userspace can probe each of these
> RVA23U64-mandatory extensions individually.
>
> Rationale for the validation dependencies added for Ziccamoa and Za64rs:
>
> 1) Ziccamoa depends on Zaamo. The RVA23 profile prose was updated
> post-ratification to spell out the Zaamo reference: commit
> 2b218613752d in riscv/riscv-profiles ("Improve description of
> Ziccamoa (#224)") reworded the rva23-profile.adoc (and other profiles
> that include Ziccamoa) text from "must support all atomics in A" to
> "must support all atomics in the Zaamo extension" [1].
>
> 2) Za64rs depends on Zalrsc. The unprivileged ISA manual src/zars.adoc,
> integrated in commit ebe06adc22cd ("Integrate profiles as Volume III
> (#2771)"), defines Za64rs as: "The Za64rs extension requires that the
> reservation sets used by the instructions in the Zalrsc extension be
> contiguous, naturally aligned, and at most 64 bytes in size" [2].
I think I made the point on either an earlier version of this, or a
similar thread, that the point of the validate callback stuff is to make
sure that the kernel is correctly configured to use the extension in
question or an extension it depends on. It's not the kernel's job to
make sure that the firmware has not reported having an extension without
one that it depends on (at least it is not in devicetree land, and I can
only assume that ACPI is by and large the same.
ziccamoa and za64rs don't depend on kernel configuration and neither do
zaamo and zalrsc, so these validate callbacks should be removed.
Cheers,
Conor.
> +static int riscv_ext_zaamo_depends(const struct riscv_isa_ext_data *data,
> + const unsigned long *isa_bitmap)
> +{
> + if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZAAMO))
> + return 0;
> +
> + return -EPROBE_DEFER;
> +}
> +
> +static int riscv_ext_zalrsc_depends(const struct riscv_isa_ext_data *data,
> + const unsigned long *isa_bitmap)
> +{
> + if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZALRSC))
> + return 0;
> +
> + return -EPROBE_DEFER;
> +}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 01/16] dt-bindings: riscv: sort multi-letter Z extensions alphanumerically
From: Conor Dooley @ 2026-06-12 8:02 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-1-3f01a2449488@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
On Thu, Jun 11, 2026 at 04:12:38PM -0400, Guodong Xu wrote:
> The multi-letter extension enum is documented as being sorted
> alphanumerically (see the "multi-letter extensions, sorted
> alphanumerically" comment), but several Z entries have drifted out of
> order.
>
> Reorder the affected entries so the multi-letter Z list is sorted
> alphanumerically again.
>
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: na
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [Question] 5.posting.rst use To: or Cc:
From: Manuel Ebner @ 2026-06-12 8:01 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
Hi,
so every time I send a mail to lists or maintainers I have to choose: To:
or Cc:. I did look for an answer in the Documentation but couldn't find
one.
I think if there is an answer then it could be added to 5.posting.rst .
Thanks
Manuel
^ permalink raw reply
* Re: [RFC PATCH v2 02/14] kcov: fix INIT_TRACK race in kcov_dataflow
From: Alexander Potapenko @ 2026-06-12 8:00 UTC (permalink / raw)
To: Yunseong Kim
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, sashiko-bot
In-Reply-To: <5fa7a528-a4c5-4fdb-9a17-1b0992e955b3@est.tech>
On Fri, Jun 12, 2026 at 9:25 AM Yunseong Kim <yunseong.kim@est.tech> wrote:
>
> Hi Alexander,
>
> > On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
> >>
> >> [snip...]
> >> Reported-by: sashiko-bot <sashiko-bot@kernel.org>
> >> Closes: https://sashiko.dev/#/patchset/20260603-kcov-dataflow-next-20260603-v2-0-fee0939de2c4%40est.tech
> >> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
> >
> > Can we please avoid this?
> > kcov_dataflow.c is being introduced in the same series, there is no
> > need to send a buggy commit and a follow-up fix - just squash the two
> > together and note the changes after Signed-off-by: separated by a
> > triple dash.
>
> Thank you for your guide. I'll remove it in the next patch set.
Also please make sure to update the patch version. It's really hard to
distinguish between "[RFC PATCH v2 n/6]" and "[RFC PATCH v2 m/14]"
when both series pop up in the inbox.
^ permalink raw reply
* Re: [PATCH v5 0/4] PCI: Add DOE support for endpoint
From: Aksh Garg @ 2026-06-12 7:58 UTC (permalink / raw)
To: Frank Li
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <aise1tIyTj4WLU89@lizhi-Precision-Tower-5810>
On 12/06/26 02:17, Frank Li wrote:
> On Wed, Jun 10, 2026 at 03:32:52PM +0530, Aksh Garg wrote:
>> This patch series introduces the framework for supporting the Data
>> Object Exchange (DOE) feature for PCIe endpoint devices. Please refer
>> to the documentation added in patch 4 for details on the feature and
>> implementation architecture.
>>
>> The implementation provides a common framework for all PCIe endpoint
>> controllers, not specific to any particular SoC vendor.
>>
Hi Frank,
>
> General question, does DOE generate irq when received msg for HOST? I have
> not related irq handle code.
>
The EPC hardware is expected to raise IRQ when it receives DOE signals
from the host. The example IRQ code handler have been provided below.
When the response DOE is ready for the host, the signal_task_complete()
in pci-ep-doe.c invokes completion callback function, through which the
EPC driver handles to send the response back to the host using the DOE
mailbox.
> Any program to test it? such as pci_endpoint_test, need at least one real
> user to use it.
>
Currently there is no EPC driver upstream which support DOE yet.
However, you can refer to the conversation at [1] where the plan to add
user for this framework has been discussed.
Regards,
Aksh Garg
> Frank
>
>> The changes since v1 are documented in the respective patch descriptions.
>>
>> v4: https://lore.kernel.org/all/20260522052434.802034-1-a-garg7@ti.com/
>> v3: https://lore.kernel.org/all/20260427051725.223704-1-a-garg7@ti.com/
>> v2: https://lore.kernel.org/all/20260401073022.215805-1-a-garg7@ti.com/
>> v1 (RFC): https://lore.kernel.org/all/20260213123603.420941-1-a-garg7@ti.com/
>>
>> Below is a code demonstration showing the integration of DOE-EP APIs with
>> EPC drivers.
>>
>> Note: The provided code is just to show how an EPC driver is expected to
>> utilize the pci_ep_doe_process_request() and pci_ep_doe_abort() APIs,
>> and might not cover all the corner cases. The below implementation
>> also expects the EPC hardware to have some memory buffer to store the
>> data from(for) write_mailbox(read_mailbox) DOE capability registers.
>>
>> ============================================================================
>>
>> /* ========== DOE Completion Callback (invoked by DOE-EP core) ========== */
>>
>> static void doe_completion_cb(struct pci_epc *epc, u8 func_no, u16 cap_offset,
>> int status, u16 vendor, u8 type,
>> void *response_pl, size_t response_pl_sz)
>> {
>> struct epc_driver *drv = epc_get_drvdata(epc);
>> u32 *response = (u32 *)response_pl;
>> u32 header1, header2;
>> int payload_dw, i;
>>
>> if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
>> /* Aborted: do not send response */
>> goto free;
>> }
>>
>> if (status < 0) {
>> /* Error: set ERROR bit in DOE Status register */
>> writel(1 << DOE_STATUS_ERROR,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> goto free;
>> }
>>
>> /* Success: write DOE headers first, then response to the read memory */
>>
>> /* Header 1: Vendor ID (bits 15:0) | Type (bits 23:16) */
>> header1 = (type << 16) | vendor;
>> writel(header1, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>>
>> /* Header 2: Length in DW (including 2 DW of headers + payload) */
>> payload_dw = DIV_ROUND_UP(response_pl_sz, sizeof(u32));
>> header2 = 2 + payload_dw; /* 2 header DWs + payload */
>> writel(header2, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>>
>> /* Set READY bit to signal response ready */
>> writel(1 << DOE_STATUS_READY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> /* Write response payload DWORDs to Read memory */
>> for (i = 0; i < payload_dw; i++)
>> writel(response[i],
>> drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>>
>> /* Wait for the memory to empty before clearing the READY bit */
>> while (!RD_MEMORY_EMPTY()) {/* wait */}
>>
>> writel(0 << DOE_STATUS_READY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> free:
>> /* unset BUSY bit */
>> writel(0 << DOE_STATUS_BUSY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> kfree(response_pl);
>> }
>>
>> /* ========== DOE Interrupt Handler (triggered on GO bit from root complex) ========== */
>>
>> static irqreturn_t doe_interrupt_handler(int irq, void *priv)
>> {
>> struct epc_driver *drv = priv;
>> u16 cap_offset = extract_cap_offset_from_irq(irq);
>> u8 func_no = extract_func_from_irq(irq);
>> u32 header1, header2, length_dw, *request;
>> u16 vendor;
>> u8 type;
>> int i, ret;
>>
>> /* Read first header DWORD: Vendor ID (bits 15:0) | Type (bits 23:16) */
>> header1 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
>> vendor = header1 & 0xFFFF;
>> type = (header1 >> 16) & 0xFF;
>>
>> /* Read second header DWORD: Length in DW (includes 2 DW of headers) */
>> header2 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
>> length_dw = header2 & 0x3FFFF; /* Bits 17:0 */
>>
>> if (!length_dw)
>> length_dw = PCI_DOE_MAX_LENGTH;
>>
>> length_dw -= 2; /* Subtract 2 DW of headers to get payload length */
>> /* Allocate buffer for complete request (headers + payload) */
>> request = kzalloc(length_dw * sizeof(u32), GFP_ATOMIC);
>> if (!request) {
>> writel(1 << DOE_STATUS_ERROR,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> return IRQ_HANDLED;
>> }
>>
>> /* Read remaining payload DWORDs from Write memory */
>> for (i = 0; i < length_dw; i++) {
>> while (WR_MEMORY_EMPTY()) { /* wait */ }
>> request[i] = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
>> }
>>
>> mutex_lock(&lock);
>> /* Check the ABORT bit, if set then return */
>> if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
>> kfree(request);
>> mutex_unlock(&lock);
>> return IRQ_HANDLED;
>> }
>>
>> /* Set BUSY bit */
>> writel(1 << DOE_STATUS_BUSY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> mutex_unlock(&lock);
>>
>> /* Hand off to DOE-EP core for asynchronous processing */
>> ret = pci_ep_doe_process_request(drv->epc, func_no, cap_offset,
>> vendor, type, (void *)request,
>> length_dw * sizeof(u32),
>> doe_completion_cb);
>> if (ret) {
>> writel(1 << DOE_STATUS_ERROR,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> kfree(request);
>> }
>>
>> return IRQ_HANDLED;
>> }
>>
>> /* ========== Abort Handler (triggered on ABORT bit from root complex) ========== */
>>
>> static irqreturn_t doe_abort_handler(int irq, void *priv)
>> {
>> struct epc_driver *drv = priv;
>> u16 cap_offset = extract_cap_offset_from_irq(irq);
>> u8 func_no = extract_func_from_irq(irq);
>>
>> mutex_lock(&lock);
>>
>> /* call abort API only if BUSY bit set (pci_ep_doe_process_request() called) */
>> if (readl(drv->base + PF_DOE_STATUS_REG(func_no, cap_offset)) & DOE_STATUS_BUSY)
>> pci_ep_doe_abort(drv->epc, func_no, cap_offset);
>>
>> mutex_unlock(&lock);
>>
>> /* Discard Write memory contents */
>> writel(DOE_WR_MEMORY_CTRL_DISCARD,
>> drv->base + PF_DOE_WR_MEMORY_CTRL_REG(func_no, cap_offset));
>>
>> /* Clear status bits */
>> writel((0 << DOE_STATUS_ERROR) | (0 << DOE_STATUS_READY),
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> return IRQ_HANDLED;
>> }
>>
>> ====================================================================================
>>
>> Aksh Garg (4):
>> PCI/DOE: Move common definitions to the header file
>> PCI: endpoint: Add DOE mailbox support for endpoint functions
>> PCI: endpoint: Add support for DOE initialization and setup in EPC
>> core
>> Documentation: PCI: Add documentation for DOE endpoint support
>>
>> Documentation/PCI/endpoint/index.rst | 1 +
>> .../PCI/endpoint/pci-endpoint-doe.rst | 333 ++++++++++
>> drivers/pci/doe.c | 11 -
>> drivers/pci/endpoint/Kconfig | 14 +
>> drivers/pci/endpoint/Makefile | 1 +
>> drivers/pci/endpoint/pci-ep-doe.c | 594 ++++++++++++++++++
>> drivers/pci/endpoint/pci-epc-core.c | 104 +++
>> drivers/pci/pci.h | 48 ++
>> include/linux/pci-doe.h | 8 +
>> include/linux/pci-epc.h | 9 +
>> 10 files changed, 1112 insertions(+), 11 deletions(-)
>> create mode 100644 Documentation/PCI/endpoint/pci-endpoint-doe.rst
>> create mode 100644 drivers/pci/endpoint/pci-ep-doe.c
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [RFC PATCH v2 1/6] kcov: add per-task dataflow tracking for function arguments/return values
From: Yunseong Kim @ 2026-06-12 7:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, Dmitry Vyukov, Andrey Konovalov, Andrew Morton,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Nicolas Schier, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Jonathan Corbet, Shuah Khan,
linux-kernel, kasan-dev, llvm, linux-kbuild, rust-for-linux,
workflows, linux-doc, Yunseong Kim
In-Reply-To: <20260604084115.GZ3126523@noisy.programming.kicks-ass.net>
Hi Peter,
> On Wed, Jun 03, 2026 at 07:43:28PM +0200, Yunseong Kim wrote:
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index e2f976c3301b..abd1a94589aa 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -2261,6 +2261,28 @@ config KCOV_SELFTEST
>> On test failure, causes the kernel to panic. Recommended to be
>> enabled, ensuring critical functionality works as intended.
>>
>> +
>
> ^ This line...
>
>> +config KCOV_DATAFLOW_ARGS
>> + bool "Enable KCOV dataflow: function argument capture"
>> + depends on KCOV
>> + depends on $(cc-option,-fsanitize-coverage=dataflow-args)
>> + help
>> + Captures function arguments at entry via /sys/kernel/debug/kcov_dataflow.
>> + Struct pointer arguments are auto-expanded using compiler DebugInfo
>> + metadata, recording individual field values at runtime.
>> + Enable per-module with: KCOV_DATAFLOW_file.o := y in the Makefile.
>> + Requires clang with -fsanitize-coverage=dataflow-args support.
>> +
>> +config KCOV_DATAFLOW_RET
>> + bool "Enable KCOV dataflow: return value capture"
>> + depends on KCOV
>> + depends on $(cc-option,-fsanitize-coverage=dataflow-ret)
>> + help
>> + Captures function return values via /sys/kernel/debug/kcov_dataflow.
>> + Struct pointer returns are auto-expanded using compiler DebugInfo
>> + metadata, recording individual field values at runtime.
>> + Enable per-module with: KCOV_DATAFLOW_file.o := y in the Makefile.
>> + Requires clang with -fsanitize-coverage=dataflow-ret support.
>
> Probably wants to be here...
Thank you for code review. I updated at v2 patch.
>
>> config DEBUG_AID_FOR_SYZBOT
>> bool "Additional debug code for syzbot"
>> default n
>>
>> --
>> 2.43.0
>>
Best regards,
Yunseong
^ permalink raw reply
* [mic:next 15/15] htmldocs: Documentation/userspace-api/landlock.rst:768: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
From: kernel test robot @ 2026-06-12 7:52 UTC (permalink / raw)
To: Matthieu Buffet; +Cc: oe-kbuild-all, Mickaël Salaün , linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git next
head: a6f0a6f5377fae42a8028f63c89d544c68f24b60
commit: a6f0a6f5377fae42a8028f63c89d544c68f24b60 [15/15] landlock: Add documentation for UDP support
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260612/202606120923.1nYYlfdb-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606120923.1nYYlfdb-lkp@intel.com/
All warnings (new ones prefixed by >>):
Scope flags
~~~~~~~~~~~ [docutils]
>> Documentation/userspace-api/landlock.rst:768: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
>> Documentation/userspace-api/landlock.rst:768: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
Documentation/userspace-api/landlock:596: ./include/uapi/linux/landlock.h:40: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:596: ./include/uapi/linux/landlock.h:45: ERROR: Unknown target name: "network flags". [docutils]
Documentation/userspace-api/landlock:596: ./include/uapi/linux/landlock.h:50: ERROR: Unknown target name: "scope flags". [docutils]
Documentation/userspace-api/landlock:596: ./include/uapi/linux/landlock.h:24: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:605: ./include/uapi/linux/landlock.h:168: ERROR: Unknown target name: "filesystem flags". [docutils]
vim +768 Documentation/userspace-api/landlock.rst
767
> 768 Starting with the Landlock ABI version 10, it is possible to restrict
769 setting the local port of UDP sockets with the
770 ``LANDLOCK_ACCESS_NET_BIND_UDP`` right. This includes restricting the
771 ability to trigger autobind of an ephemeral port by the kernel by e.g.
772 sending a first datagram or setting the remote peer of a socket.
773 The ``LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP`` right controls setting the
774 remote port of UDP sockets (via :manpage:`connect(2)), and sending
775 datagrams to an explicit remote port (ignoring any destination set on
776 UDP sockets, via e.g. :manpage:`sendto(2)).
777
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [RFC PATCH v2 1/6] kcov: add per-task dataflow tracking for function arguments/return values
From: Yunseong Kim @ 2026-06-12 7:52 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Dmitry Vyukov,
Andrey Konovalov, Andrew Morton, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Nicolas Schier,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Jonathan Corbet, Shuah Khan, linux-kernel,
kasan-dev, llvm, linux-kbuild, rust-for-linux, workflows,
linux-doc, Yunseong Kim
In-Reply-To: <CAG_fn=UMJJz+3zipowaC4uTvcbC0gvXbBRaF0UUJ_1AW+oWNGA@mail.gmail.com>
Hi Alexander,
>> - Per-task buffer: task->kcov_df_area with atomic xadd reservation
>
> I don't understand this line...
>
>> - Recursion-safe: notrace __no_sanitize_coverage noinline
>> - ERR_PTR aware: skips struct expansion for error pointers
>
> ... and this.
I updated this text at v2 patch.
>>
>> The callbacks (__sanitizer_cov_trace_args/ret) are inserted by the
>> compiler when -fsanitize-coverage=dataflow-args,dataflow-ret is used.
>> The Kconfig options depend on cc-option to verify compiler support.
>>
>> Buffer format (TLV records, all u64):
>> area[0]: atomic word count
>> [pos+0]: type_and_seq (0xE=entry, 0xF=return in upper 4 bits)
>> [pos+1]: PC
>> [pos+2]: meta (arg_idx | arg_size | ptr)
>> [pos+3..N]: field values read via copy_from_kernel_nofault()
>>
>> This is completely independent from legacy /sys/kernel/debug/kcov.
>> Existing users (syzkaller, oss-fuzz) are unaffected.
>
> Does oss-fuzz even use kcov?
Also, I removed this text at v2 patch. I mistakenly confused it with another
usage of KCOV with a other fuzzer.
https://security.googleblog.com/2024/06/hacking-for-defenders-approaches-to.html
>>
>> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
>> ---
>> include/linux/sched.h | 8 ++
>> kernel/kcov.c | 291 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> lib/Kconfig.debug | 22 ++++
>> 3 files changed, 321 insertions(+)
>>
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index c4433c185ad8..03be4b495f70 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1533,6 +1533,14 @@ struct task_struct {
>> /* KCOV sequence number: */
>> int kcov_sequence;
>>
>> + /* KCOV dataflow per-task sequence counter for TLV records: */
>> + u32 kcov_dataflow_seq;
>> +
>> + /* KCOV dataflow: separate buffer for trace-args/trace-ret */
>> + unsigned int kcov_df_size;
>> + void *kcov_df_area;
>> + bool kcov_df_enabled;
>> +
>> /* Collect coverage from softirq context: */
>> unsigned int kcov_softirq;
>> #endif
>> diff --git a/kernel/kcov.c b/kernel/kcov.c
>> index 1df373fb562b..d3c9c0efe961 100644
>> --- a/kernel/kcov.c
>> +++ b/kernel/kcov.c
>> @@ -353,6 +353,288 @@ void notrace __sanitizer_cov_trace_switch(kcov_u64 val, void *arg)
>> EXPORT_SYMBOL(__sanitizer_cov_trace_switch);
>> #endif /* ifdef CONFIG_KCOV_ENABLE_COMPARISONS */
>>
>> +#if defined(CONFIG_KCOV_DATAFLOW_ARGS) || defined(CONFIG_KCOV_DATAFLOW_RET)
>> +/*
>> + * KCOV Dataflow: /sys/kernel/debug/kcov_dataflow
>> + *
>> + * Completely separate from legacy /sys/kernel/debug/kcov.
>
> Since this code is completely separate, could it be put into a separate file?
> I think kcov.c is too big already.
Thank you again for your guide, I updated it at v2.
>> + * Own buffer, own ioctl, own mmap. No printk — buffer only.
>
> Can you please not use these long dashes in C code?
I removed all a the v2.
>> +/*
>> + * Core write function — no printk, no locks, just atomic buffer write.
>
> I think it's okay to omit what this function is not doing.
>
>
>> +
>> + /* Atomic reservation */
>> + pos = 1 + xadd((unsigned long *)&area[0], record_len);
>> + if (unlikely(pos + record_len > max_pos)) {
>> + xadd((unsigned long *)&area[0], -(long)record_len);
>> + return;
>> + }
>
> Have you tried compiling this code on ARM64?
> I am pretty sure they don't have xadd(), so it won't work.
> But why do we need an atomic increment here at all? write_comp_data()
> performs the same job, and does not need it.
> Or am I missing something?
Thank you again for pointing out. After updating to the READ_ONCE/WRITE_ONCE
atomic pattern, Testing results based on v2 on arm64 for the Rust for Linux
kernel module(eight_struct_args_rust) are as follows:
do_el0_svc({0xffffffffffffff9c, 0xffffffffffffff9c, 0xffffffff, 0x0, 0x0, 0x0})
invoke_syscall({0xffffffffffffff9c, 0xffffffffffffff9c, 0x38, 0x0, 0x0, 0x0}, 0x38)
__arm64_sys_openat({0xffffffffffffff9c, 0xffffffffffffff9c, 0x38, 0x0, 0x0, 0x0})
ksys_write(0xffff9a031231, 0x1)
fdget_pos(0x4)
0xffff000004421cc0 = fdget_pos()
0x0 = vfs_write()
vfs_write(0xffff9a031231, 0x1, 0x0)
0x0 = _RNvCsdfZGIOKgjaD_22eight_struct_args_rust13write_handler [eight_struct_args_rust]()
_RNvCsdfZGIOKgjaD_22eight_struct_args_rust13write_handler [eight_struct_args_rust](0xffff9a031231, 0x1, 0x0)
rsf_1 [eight_struct_args_rust](0x11)
0x11 = rsf_1 [eight_struct_args_rust]()
rsf_2 [eight_struct_args_rust](0x11, {0x11, 0x22})
0x33 = rsf_2 [eight_struct_args_rust]()
rsf_4 [eight_struct_args_rust](0x11, {0x11, 0x22}, {0x11, 0x22, 0x33}, {0x11, 0x22, 0x33, 0x44})
0xaa = rsf_4 [eight_struct_args_rust]()
...
Latest test results from Github CI:
https://github.com/yskzalloc/kcov-dataflow/actions/runs/27397351811/job/80967927283
Best regards,
Yunseong
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] Add standard stats for HSR/PRP
From: MD Danish Anwar @ 2026-06-12 7:39 UTC (permalink / raw)
To: Andrew Lunn, Felix Maurer
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Meghana Malladi, Jacob Keller, David Carlier,
Vadim Fedorenko, Kevin Hao, Markus Elfring, Hangbin Liu,
Fernando Fernandez Mancera, Jan Vaclav, netdev, linux-doc,
linux-kernel, linux-arm-kernel, Luka Gejak
In-Reply-To: <e8965004-f286-4589-a834-309ccaa1d575@lunn.ch>
Hi Andrew,
On 11/06/26 9:20 pm, Andrew Lunn wrote:
> On Thu, Jun 11, 2026 at 03:20:32PM +0530, MD Danish Anwar wrote:
>> 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]
>
> That is ideally the wrong way around. Offloading it used to accelerate
> what Linux can already do in software. Statistics should be part of
> this, you first define software statistics, and then get the hardware
> to report those.
On v2 of the series Felix commented saying I should go ahead with the
hardware stats first and he can later implement for software only
interfaces [1]. This is the reason I went ahead with this. Initially
this series was not standardizing the stats of HSR/PPR interfaces, it
was only meant for dumping those stats for ICSSG via ethtool -S.
Felix and Jakub commented saying I should standardize these stats.
Hi Felix, When can you implement the same for software only interfaces?
If we can't add support for hardware interfaces before software only
interfaces, then what should be the next steps?
[1]
https://lore.kernel.org/all/ag87pBZfOyccPZTc@thinkpad/#:~:text=(no%20need%20to%20implement%20it%20for%20the%20software%2Donly%20interfaces%0Ain%20this%20patch%20series%2C%20I%20can%20do%20that%20afterwards%20as%20well)
>
> So please get the software statistics merged first.
>
> Andrew
--
Thanks and Regards,
Danish
^ permalink raw reply
* Re: [RFC PATCH v2 0/6] kcov: per-task dataflow extraction at kernel function boundaries
From: Peter Zijlstra @ 2026-06-12 7:38 UTC (permalink / raw)
To: Yunseong Kim
Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, Dmitry Vyukov, Andrey Konovalov, Andrew Morton,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Nicolas Schier, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Jonathan Corbet, Shuah Khan,
linux-kernel, kasan-dev, llvm, linux-kbuild, rust-for-linux,
workflows, linux-doc, Yunseong Kim
In-Reply-To: <513c68a8-e530-4461-a8e5-36e5d3d5858f@est.tech>
On Fri, Jun 12, 2026 at 09:37:40AM +0200, Yunseong Kim wrote:
> Hi Peter,
>
> > On Wed, Jun 03, 2026 at 07:43:27PM +0200, Yunseong Kim wrote:
> >> CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL instruments every function in the
> >> kernel.
> >
> > Well, I would hope it would very much not instrument noinstr functions.
>
> Thank you for your guidance. I updated the default
> CONFIG_KCOV_DATAFLOW_NO_INLINE to n.
That's not really the point. The compiler extension *must* respect
noinstr. If there it no function attribute to suppress this kcov stuff,
then its an absolute non-starter.
^ permalink raw reply
* Re: [RFC PATCH v2 0/6] kcov: per-task dataflow extraction at kernel function boundaries
From: Yunseong Kim @ 2026-06-12 7:37 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, Dmitry Vyukov, Andrey Konovalov, Andrew Morton,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Nicolas Schier, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Jonathan Corbet, Shuah Khan,
linux-kernel, kasan-dev, llvm, linux-kbuild, rust-for-linux,
workflows, linux-doc, Yunseong Kim
In-Reply-To: <20260604084026.GY3126523@noisy.programming.kicks-ass.net>
Hi Peter,
> On Wed, Jun 03, 2026 at 07:43:27PM +0200, Yunseong Kim wrote:
>> CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL instruments every function in the
>> kernel.
>
> Well, I would hope it would very much not instrument noinstr functions.
Thank you for your guidance. I updated the default
CONFIG_KCOV_DATAFLOW_NO_INLINE to n.
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 01/14] kcov: add per-task dataflow tracking for function arguments/return values
From: Alexander Potapenko @ 2026-06-12 7:34 UTC (permalink / raw)
To: Yunseong Kim
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun
In-Reply-To: <20260611-b4-kcov-dataflow-v2-v2-1-0a261da3987c@est.tech>
On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>
> Add a new tracking mechanism that captures function arguments/return
> values at instrumented function boundaries via submitted as an LLVM
> RFC SanitizerCoverage callbacks:
>
> __sanitizer_cov_trace_args
> __sanitizer_cov_trace_ret
>
> This requires a custom LLVM/Clang build with the trace-args/ret passes:
>
> LLVM RFC:
>
> https://discourse.llvm.org/t/rfc-sanitizercoverage-add-fsanitize-coverage-trace-args-trace-ret/91026
>
> LLVM PR:
>
> https://github.com/llvm/llvm-project/pull/201410
>
> Clone and build toolchain:
>
> git clone --recursive --depth 1 --shallow-submodules \
> --jobs `nproc` https://github.com/yskzalloc/kcov-dataflow.git
> cd kcov-dataflow
>
> cd llvm-project
> cmake -S llvm -B build -G Ninja \
> -DCMAKE_BUILD_TYPE=Release \
> -DCMAKE_C_COMPILER=clang \
> -DCMAKE_CXX_COMPILER=clang++ \
> -DLLVM_ENABLE_LLD=ON \
> -DLLVM_ENABLE_PROJECTS="clang;lld" \
> -DLLVM_TARGETS_TO_BUILD="X86;AArch64"
> ninja -C build
> cd ..
>
> Build and boot kernel (using virtme-ng):
>
> export PATH=$PWD/llvm-project/build/bin:$PATH
> cd linux
> vng --build \
> --configitem CONFIG_KCOV=y \
> --configitem CONFIG_KCOV_DATAFLOW_ARGS=y \
> --configitem CONFIG_KCOV_DATAFLOW_RET=y \
> --configitem CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL=y \
> --configitem CONFIG_DEBUG_INFO=y \
> --configitem CONFIG_RUST=y # for rust module kselftest
> LLVM=1 CC=clang
>
> Core implementation in kernel/kcov_dataflow.c (separating from kcov.c
> as Alexander's request):
> - Per-task lock-free ring buffer via debugfs kcov_dataflow device
> - READ_ONCE/WRITE_ONCE atomic pattern (tested on arm64)
> - copy_from_kernel_nofault() for safe struct field reads
> - in_task() guard rejects interrupt context
> - Bit-31 recursion guard prevents INSTRUMENT_ALL re-entry
>
> Build system (scripts/Makefile.kcov, scripts/Makefile.lib):
> - CFLAGS_KCOV_DATAFLOW: -fsanitize-coverage=trace-args,trace-ret
> - RUSTFLAGS_KCOV_DATAFLOW: -Cllvm-args=-sanitizer-coverage-trace-args/ret
> - Per-file opt-in: KCOV_DATAFLOW_file.o := y
> - Respects KCOV_INSTRUMENT := n for noinstr exclusion
> - CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL for whole-kernel
>
> Kconfig (lib/Kconfig.debug):
> - CONFIG_KCOV_DATAFLOW_ARGS / CONFIG_KCOV_DATAFLOW_RET
> - Depends on CONFIG_KCOV and CONFIG_DEBUG_INFO
> - CONFIG_KCOV_DATAFLOW_NO_INLINE (default n)
> - CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL
>
> Also fix rust/kernel/str.rs unused import (flags::* -> flags::GFP_KERNEL)
> which newer rustc (1.98-nightly) rejects as a hard error.
>
> Rust support requires rustc built against the custom LLVM with
> trace-args/ret passes compiled in:
>
> https://github.com/yskzalloc/rust
>
> Link: https://github.com/yskzalloc/kcov-dataflow/
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Nicolas Schier <nsc@kernel.org>
> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
> ---
> include/linux/sched.h | 10 ++
> kernel/Makefile | 3 +
> kernel/kcov.c | 2 +
> kernel/kcov_dataflow.c | 324 +++++++++++++++++++++++++++++++++++++++++++++++++
I think the total size of kcov_dataflow.c doesn't justify splitting it
in multiple patches.
^ permalink raw reply
* Re: [RFC PATCH v2 04/14] kcov: reject enable on multiple dataflow fds simultaneously
From: Alexander Potapenko @ 2026-06-12 7:32 UTC (permalink / raw)
To: Yunseong Kim
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, sashiko-bot
In-Reply-To: <20260611-b4-kcov-dataflow-v2-v2-4-0a261da3987c@est.tech>
On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>
> A task could enable tracing on multiple kcov_dataflow file descriptors,
> corrupting the internal tracking state when one is subsequently closed.
>
> Check current->kcov_df_enabled before allowing KCOV_DF_ENABLE and
> return -EBUSY if already active. This matches kcov's check of
> t->kcov != NULL in the KCOV_ENABLE path.
>
> Reported-by: sashiko-bot <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260603-kcov-dataflow-next-20260603-v2-0-fee0939de2c4%40est.tech
> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
> ---
> kernel/kcov_dataflow.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/kcov_dataflow.c b/kernel/kcov_dataflow.c
> index 5248293280d5..27587b8ceeab 100644
> --- a/kernel/kcov_dataflow.c
> +++ b/kernel/kcov_dataflow.c
Please merge this patch into the one introducing kcov_dataflow.c
^ permalink raw reply
* Re: [RFC PATCH v2 0/6] kcov: per-task dataflow extraction at kernel function boundaries
From: Yunseong Kim @ 2026-06-12 7:33 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Dmitry Vyukov,
Andrey Konovalov, Andrew Morton, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Nicolas Schier,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Jonathan Corbet, Shuah Khan, linux-kernel,
kasan-dev, llvm, linux-kbuild, rust-for-linux, workflows,
linux-doc, Yunseong Kim
In-Reply-To: <CAG_fn=W1++qPJWQk1+4MtRfe6n1iUKF2O5pddnqKGwSq85CuqA@mail.gmail.com>
Hi Alexander,
> On Wed, Jun 3, 2026 at 7:43 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>
>> Introduces a new KCOV exetened feature that captures function arguments and
>> return values at kernel function boundaries, enabling per-process visibility
>> into runtime dataflow.
>
> Some high-level comments:
> - Make sure your code can run on every platform supported by kcov (namely ARM64)
> - Check out Sashiko findings:
> https://sashiko.dev/#/patchset/20260603-kcov-dataflow-next-20260603-v2-0-fee0939de2c4%40est.tech,
I handled those parts that seemed problematic from sashiko's review.
> at least some of them seem to make sense
> - Please consolidate changes to the same file into a single patch
> - There seem to be two tools (one in C and one in Python) with
> overlapping functionality, can you keep only one?
I revised this part in v2.
> - The test modules seem to be used only in manual testing. Can you
> convert them to kselftests or remove them?
Thanks again for yout guide, I've updated it to v2.
> - At this point, long dashes in the kernel codebase are quite rare,
> and I don't see a reason to add more.
I checked that the v2 series patchset was removed, using long dashes.
Best regards,
Yunseong
^ permalink raw reply
* Re: [RFC PATCH v2 03/14] kcov: add barriers to recursion guard in kcov_df_write
From: Alexander Potapenko @ 2026-06-12 7:30 UTC (permalink / raw)
To: Yunseong Kim
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun
In-Reply-To: <20260611-b4-kcov-dataflow-v2-v2-3-0a261da3987c@est.tech>
On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>
> The recursion guard (bit-31 of kcov_df_seq) prevents reentry when
> copy_from_kernel_nofault() or other called functions are instrumented
> with INSTRUMENT_ALL. Without compiler barriers, the guard set/clear
> can be reordered relative to the function body, making the protection
> ineffective under optimization.
>
> Add barrier() after setting the guard and before clearing it, ensuring
> the compiler does not move instrumented operations outside the guarded
> region.
>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
> ---
> kernel/kcov_dataflow.c | 2 ++
Please merge this patch into the one introducing kcov_dataflow.c
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kcov_dataflow.c b/kernel/kcov_dataflow.c
> index df7e8bf70bfa..5248293280d5 100644
> --- a/kernel/kcov_dataflow.c
> +++ b/kernel/kcov_dataflow.c
> @@ -86,6 +86,7 @@ kcov_df_write(u64 type_marker, u64 pc, u64 meta, void *ptr,
> if (t->kcov_df_seq & (1U << 31))
> return;
> t->kcov_df_seq |= (1U << 31);
> + barrier();
Please make sure barriers have comments explaining which barriers they
pair with (see kernel/kcov.c)
^ permalink raw reply
* Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback
From: YoungJun Park @ 2026-06-12 7:27 UTC (permalink / raw)
To: Shakeel Butt
Cc: Yosry Ahmed, Hao Jia, Johannes Weiner, mhocko, tj, mkoutny,
roman.gushchin, Nhat Pham, akpm, chengming.zhou, muchun.song,
cgroups, linux-mm, linux-kernel, linux-doc, Hao Jia, chrisl,
kasong, baoquan.he
In-Reply-To: <aisEWnb3pzmVC4dl@linux.dev>
On Thu, Jun 11, 2026 at 12:12:40PM -0700, Shakeel Butt wrote:
> On Thu, Jun 11, 2026 at 05:45:04PM +0000, Yosry Ahmed wrote:
> > On Tue, Jun 09, 2026 at 01:19:13PM +0900, YoungJun Park wrote:
> > > On Mon, Jun 08, 2026 at 03:27:07PM -0700, Yosry Ahmed wrote:
> > >
> > > +Chris +Kairui +Baoquan
> > >
> > > Hello
> > >
> > > Thanks for inviting me to the discussion, Shakeel.
> > >
> > > > > > > Youngjun is working on swap tiers. At the moment he is more interested in
> > > > > > > allowing a specific swap device to a memcg or not. I can imagine in future there
> > > > > > > will be use-cases where there will be a need to demote data on higher tier swap
> > > > > > > to lower tier swap. What would be the appropriate interface?
> > >
> > > Speaking of my work on swap tiers, I recently submitted a patch and am
> > > currently considering memcg integration:
> > > https://lore.kernel.org/linux-mm/20260527062247.3440692-1-youngjun.park@lge.com/
> > >
> > > The future use-cases imagined above seem to align with this
> > > direction. (BTW, I am currently waiting for reviews/feedback from the memcg
> > > folks on this patch. Any reviews would be highly appreciated!)
> > >
> > > We could potentially assign a target tier
> > > for writeback within the existing memory.zswap.writeback interface.
> > >
> > > For instance, '0' could mean disabled, while non-zero values could represent
> > > specific tiers, which would maintain backward compatibility with the current
> > > version. Alternatively, if zswap is treated as the default top tier,
> > > the `memory.swap.tiers` interface could potentially replace `memory.zswap.writeback`.
> > >
> > > Furthermore, this could be expanded so that each swap tier can demote data
> > > user-triggered demotion between swap tiers.
> > >
> > > Based on the current patch's ideas combined with my swap tiers concept:
> > >
> > > Assuming a hierarchy like:
> > > zswap -> tier1 (SSD swap) -> tier2 (HDD swap) -> tier3 (Network swap)
> > >
> > > We could configure the active tiers via a setting like `memory.swap.tiers`
> > > (tier2 enabled, tier3 enabled).
> > >
> > > For example, the concept of `echo "100M zswap_writeback_only > memory.reclaim"`
> > > could be extended. A user could run `echo "100M tier2 > memory.reclaim"`
> > > to explicitly trigger demotion from tier2 to tier3.
> > > (BTW, if we combine these features, my personal preference for the keyword
> > > format would be `<size> <demote_prefix><tier_name>`. I think it would be
> > > better to explicitly indicate that it is a swap demotion by using a specific
> > > prefix followed by the tier name.
> > > Or make demote prefix another key is also possible)
> >
> > I am not sure if proactive demotion between swap tiers would be driven
> > by memory.reclaim, I am guessing a new interface might be more suitable.
> > But yes, you are right that it's very possible that
> > 'zswap_writeback_only' with memory.reclaim will become obsolete once
> > swap tiering matures and starts supporting things like proactive
> > demotion.
> >
> > Part of me wants to wait until the swap tiering interfaces are figured
> > out so that we don't end up with redundant interfaces, but I also don't
> > want to hold Hao's work since it doesn't directly depend on swap
> > tiering.
> However I would need zswap folks (Yosry & Nhat) help in figuring out swap tiers
> interfaces. Zswap is the current top tier swap usage in real world. I want
> zswap users to eaily (and hopefully transparently) migrate to swap tiers.
> > Shakeel, how do you want to handle this? I think there's a few options:
> >
> > 1. Add zswap_writeback_only now, and when we have swap tiering demotion
> > it becomes a redundant interface, like memory.zswap.writeback -- or
> > maybe we try to deprecate both of them at that point. It's difficult to
> > remove interfaces tho, but maybe easier to stop supporting
> > zswap_writeback_only.
> >
> > 2. Add zswap_writeback_only behind an experimental config option, to
> > unblock development but have a line of sight to dropping support once we
> > have a swap tiering interface.
> >
> > 3. Wait until we figure out the swap tiering interfaces and then add
> > the proactive zswap writeback as part of it.
> >
> > WDYT?
>
> Is Hao's work needed for some followup work/development? The earliest Hao's
> work can is 7.3, so if we aim to figure out swap tiering interfaces in next
> couple of weeks then option 3 is the way to go. If swap tiers take more time
> then we can discuss other options as well.
> However I would need zswap folks (Yosry & Nhat) help in figuring out swap tiers
> interfaces. Zswap is the current top tier swap usage in real world. I want
> zswap users to eaily (and hopefully transparently) migrate to swap tiers.
I am looking forward to the discussion on this interface!
To help boost the discussion and progress, I would like to share a few of my thoughts.
We could either introduce a new interface to trigger demotion/promotion,
or we could reuse the existing one (using tier just internally)
Based on the memcg interface currently proposed in swap_tier
(memory.swap.tiers, memory.swap.tiers.effective), I think it aligns well
with the current direction. It provides a foundation for selectively
targeting devices in tier order.
To summarize the discussions so far, the following points align well.
- Per-cgroup swap control, as I suggested.
- Proactive zswap writeback (Hao's usecase)
- Swap device target demotion(if it wants selective, then it is more better), as you mentioned:
https://lore.kernel.org/linux-mm/aicZ-5GX9De3MAU7@linux.dev/
- Virtual Swap on/off in the future, as Nhat mentioned:
https://lore.kernel.org/linux-mm/20260528212955.1912856-1-nphamcs@gmail.com/
- The memory.zswap.writeback alternative (no hierarchy model conflict)
- zswap is first swap tier.
- Promotion. (Also better for selectve usage)
- tier based swap policy (e.g round-robin...)
To accelerate this work, I believe we should reach a consensus and
merge the currently proposed swap_tier interface :)
If the above approach is difficult, I would like to suggest an
alternative for progress with the memcg interfaces removed:
1) We could make zswap the first tier and create
a use case where memory.zswap.writeback internally is handled by tier logic.
2) Or simply merge the swap_tier infrastructure itself first.
This would allow the swap_tier infrastructure to be merged and discussed
more easily.
If it takes longer to adopt swap_tier anyway, by doing so we progress next step
as a experimental feature.
- Apply per-cgroup swap as an experimental (debugfs) feature.
- Apply Hao's use case experimentally or as it is as Yosry suggested.
(future migration to swap tier)
How do you think?
(FYI: My emails to kernel.org are failing due to internal server issues.)
Thank you
Youngjun Park
^ permalink raw reply
* Re: [RFC PATCH v2 02/14] kcov: fix INIT_TRACK race in kcov_dataflow
From: Yunseong Kim @ 2026-06-12 7:25 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Andrey Konovalov,
Dmitry Vyukov, Andrew Morton, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor, Nicolas Schier,
Nick Desaulniers, Bill Wendling, Justin Stitt, Kees Cook,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Jonathan Corbet, Shuah Khan, linux-kernel, kasan-dev,
rust-for-linux, linux-kbuild, llvm, linux-mm, linux-kselftest,
workflows, linux-doc, Yeoreum Yun, sashiko-bot
In-Reply-To: <CAG_fn=V1+_xLgCZgdLnT7Y-muRO0CXkrNKkC8AzrqzWoL4eR8w@mail.gmail.com>
Hi Alexander,
> On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
>>
>> [snip...]
>> Reported-by: sashiko-bot <sashiko-bot@kernel.org>
>> Closes: https://sashiko.dev/#/patchset/20260603-kcov-dataflow-next-20260603-v2-0-fee0939de2c4%40est.tech
>> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
>
> Can we please avoid this?
> kcov_dataflow.c is being introduced in the same series, there is no
> need to send a buggy commit and a follow-up fix - just squash the two
> together and note the changes after Signed-off-by: separated by a
> triple dash.
Thank you for your guide. I'll remove it in the next patch set.
Best regards,
Yunseong
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox