* [PATCH v2] docs/zh_CN: fix CONFIG_CONPAT typo for CONFIG_COMPAT
From: Ethan Nelson-Moore @ 2026-06-13 18:37 UTC (permalink / raw)
To: Dongliang Mu, Shuah Khan, Kees Cook, Ethan Nelson-Moore,
linux-doc
Cc: Alex Shi, Yanteng Si, Jonathan Corbet
The Simplified Chinese translation of security/self-protection.rst
contains a typo CONFIG_CONPAT for CONFIG_COMPAT. Fix it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Changes in v2: remove unnecessary information from commit message
Documentation/translations/zh_CN/security/self-protection.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/translations/zh_CN/security/self-protection.rst b/Documentation/translations/zh_CN/security/self-protection.rst
index 93de9cee5c1a..ad96bb4a4995 100644
--- a/Documentation/translations/zh_CN/security/self-protection.rst
+++ b/Documentation/translations/zh_CN/security/self-protection.rst
@@ -97,7 +97,7 @@ ARCH_OPTIONAL_KERNEL_RWX时的默认设置。
--------------------
对于64位系统，一种消除许多系统调用最简单的方法是构建时不启用
-CONFIG_CONPAT。然而，这种情况通常不可行。
+CONFIG_COMPAT。然而，这种情况通常不可行。
“seccomp”系统为用户空间提供了一种可选功能，提供了一种减少可供
运行中进程使用内核入口点数量的方法。这限制了可以访问内核代码
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v2 3/3] docs: net: fix minor issues with strparser docs
From: Jakub Kicinski @ 2026-06-13 16:58 UTC (permalink / raw)
To: davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, linux-doc,
john.fastabend, sd, jiri, Jakub Kicinski, skhan
In-Reply-To: <20260613165846.2913092-1-kuba@kernel.org>
Not sure if anyone would read this doc, but the API has evolved
since it was written. Update to:
- show the int return type for strp_init()
- refer to strp_data_ready(), not the old strp_tcp_data_ready() name
- direct users to strp_msg(skb) for strparser metadata instead of
treating skb->cb as struct strp_msg directly
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: corbet@lwn.net
CC: skhan@linuxfoundation.org
CC: linux-doc@vger.kernel.org
---
Documentation/networking/strparser.rst | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/networking/strparser.rst b/Documentation/networking/strparser.rst
index 8dc6bb04c710..372106b61e65 100644
--- a/Documentation/networking/strparser.rst
+++ b/Documentation/networking/strparser.rst
@@ -40,8 +40,8 @@ Functions
::
- strp_init(struct strparser *strp, struct sock *sk,
- const struct strp_callbacks *cb)
+ int strp_init(struct strparser *strp, struct sock *sk,
+ const struct strp_callbacks *cb)
Called to initialize a stream parser. strp is a struct of type
strparser that is allocated by the upper layer. sk is the TCP
@@ -95,7 +95,7 @@ Functions
void strp_data_ready(struct strparser *strp);
- The upper layer calls strp_tcp_data_ready when data is ready on
+ The upper layer calls strp_data_ready when data is ready on
the lower socket for strparser to process. This should be called
from a data_ready callback that is set on the socket. Note that
maximum messages size is the limit of the receive socket
@@ -123,9 +123,9 @@ Callbacks
should parse the sk_buff as containing the headers for the
next application layer message in the stream.
- The skb->cb in the input skb is a struct strp_msg. Only
- the offset field is relevant in parse_msg and gives the offset
- where the message starts in the skb.
+ The strparser metadata in the input skb can be accessed with
+ strp_msg(skb). Only the offset field is relevant in parse_msg and
+ gives the offset where the message starts in the skb.
The return values of this function are:
@@ -176,11 +176,11 @@ Callbacks
received in rcv_msg (see strp_pause above). This callback
must be set.
- The skb->cb in the input skb is a struct strp_msg. This
- struct contains two fields: offset and full_len. Offset is
- where the message starts in the skb, and full_len is the
- the length of the message. skb->len - offset may be greater
- than full_len since strparser does not trim the skb.
+ The strparser metadata in the input skb can be accessed with
+ strp_msg(skb). This struct contains two fields: offset and full_len.
+ Offset is where the message starts in the skb, and full_len is
+ the length of the message. skb->len - offset may be greater than
+ full_len since strparser does not trim the skb.
::
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v2 2/3] docs: net: fix minor issues with devlink docs
From: Jakub Kicinski @ 2026-06-13 16:58 UTC (permalink / raw)
To: davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, linux-doc,
john.fastabend, sd, jiri, Jakub Kicinski, skhan
In-Reply-To: <20260613165846.2913092-1-kuba@kernel.org>
Update devlink documentation to match current code:
- describe health reporter defaults (it's currently under "callbacks"),
best-effort auto-dump, and port-scoped reporters
- fix generic parameter names and values
- fix nested devlink setup wording and registration ordering
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: jiri@resnulli.us
CC: corbet@lwn.net
CC: skhan@linuxfoundation.org
CC: linux-doc@vger.kernel.org
---
Documentation/networking/devlink/devlink-health.rst | 12 ++++++++----
Documentation/networking/devlink/devlink-params.rst | 2 +-
Documentation/networking/devlink/devlink-port.rst | 5 ++++-
Documentation/networking/devlink/devlink-trap.rst | 8 +++++---
Documentation/networking/devlink/index.rst | 10 +++++-----
5 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/Documentation/networking/devlink/devlink-health.rst b/Documentation/networking/devlink/devlink-health.rst
index 4d10536377ab..bedac58a2f36 100644
--- a/Documentation/networking/devlink/devlink-health.rst
+++ b/Documentation/networking/devlink/devlink-health.rst
@@ -33,7 +33,9 @@ asynchronously. All health reports handling is done by ``devlink``.
* Recovery procedures
* Diagnostics procedures
* Object dump procedures
- * Out Of Box initial parameters
+
+Drivers also provide default values for generic reporter parameters when
+creating a health reporter.
Different parts of the driver can register different types of health reporters
with different handlers.
@@ -45,8 +47,9 @@ Actions
* A log is being send to the kernel trace events buffer
* Health status and statistics are being updated for the reporter instance
- * Object dump is being taken and saved at the reporter instance (as long as
- auto-dump is set and there is no other dump which is already stored)
+ * Object dump is being taken and saved at the reporter instance. This is
+ best effort and skipped when recovery is aborted, auto-dump is disabled,
+ no dump callback is registered, or a dump is already stored.
* Auto recovery attempt is being done. Depends on:
- Auto-recovery configuration
@@ -75,7 +78,8 @@ User Interface
==============
User can access/change each reporter's parameters and driver specific callbacks
-via ``devlink``, e.g per error type (per health reporter):
+via ``devlink``, e.g. per error type (per health reporter). Reporters may be
+registered for the whole devlink instance or for a specific devlink port.
* Configure reporter's generic parameters (like: disable/enable auto recovery)
* Invoke recovery procedure
diff --git a/Documentation/networking/devlink/devlink-params.rst b/Documentation/networking/devlink/devlink-params.rst
index ea17756dcda6..ca19ee3e63c8 100644
--- a/Documentation/networking/devlink/devlink-params.rst
+++ b/Documentation/networking/devlink/devlink-params.rst
@@ -122,7 +122,7 @@ own name.
* - ``enable_iwarp``
- Boolean
- Enable handling of iWARP traffic in the device.
- * - ``internal_err_reset``
+ * - ``internal_error_reset``
- Boolean
- When enabled, the device driver will reset the device on internal
errors.
diff --git a/Documentation/networking/devlink/devlink-port.rst b/Documentation/networking/devlink/devlink-port.rst
index 5e397798a402..9374ebe70f48 100644
--- a/Documentation/networking/devlink/devlink-port.rst
+++ b/Documentation/networking/devlink/devlink-port.rst
@@ -38,7 +38,7 @@ Devlink port flavours are described below.
- This indicates an eswitch port representing a port of PCI
subfunction (SF).
* - ``DEVLINK_PORT_FLAVOUR_VIRTUAL``
- - This indicates a virtual port for the PCI virtual function.
+ - Any virtual port facing the user.
Devlink port can have a different type based on the link layer described below.
@@ -134,6 +134,9 @@ Users may also set the IPsec crypto capability of the function using
Users may also set the IPsec packet capability of the function using
`devlink port function set ipsec_packet` command.
+The ``migratable`` attribute may be set only on ports with
+``DEVLINK_PORT_FLAVOUR_PCI_VF``.
+
Users may also set the maximum IO event queues of the function
using `devlink port function set max_io_eqs` command.
diff --git a/Documentation/networking/devlink/devlink-trap.rst b/Documentation/networking/devlink/devlink-trap.rst
index 5885e21e2212..ac5bf9337198 100644
--- a/Documentation/networking/devlink/devlink-trap.rst
+++ b/Documentation/networking/devlink/devlink-trap.rst
@@ -516,9 +516,11 @@ Generic Packet Trap Groups
Generic packet trap groups are used to aggregate logically related packet
traps. These groups allow the user to batch operations such as setting the trap
-action of all member traps. In addition, ``devlink-trap`` can report aggregated
-per-group packets and bytes statistics, in case per-trap statistics are too
-narrow. The description of these groups must be added to the following table:
+action of all member drop traps whose action may legally change. Exception and
+control traps remain unchanged. In addition, ``devlink-trap`` can report
+aggregated per-group packets and bytes statistics, in case per-trap statistics
+are too narrow. The description of these groups must be added to the following
+table:
.. list-table:: List of Generic Packet Trap Groups
:widths: 10 90
diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst
index f7ba7dcf477d..32f70879ddd0 100644
--- a/Documentation/networking/devlink/index.rst
+++ b/Documentation/networking/devlink/index.rst
@@ -13,8 +13,8 @@ new APIs prefixed by ``devl_*``. The older APIs handle all the locking
in devlink core, but don't allow registration of most sub-objects once
the main devlink object is itself registered. The newer ``devl_*`` APIs assume
the devlink instance lock is already held. Drivers can take the instance
-lock by calling ``devl_lock()``. It is also held all callbacks of devlink
-netlink commands.
+lock by calling ``devl_lock()``. It is also held across all callbacks of
+devlink netlink commands.
Drivers are encouraged to use the devlink instance lock for their own needs.
@@ -33,11 +33,11 @@ devlink instances created underneath. In that case, drivers should make
lock of both nested and parent instances at the same time, devlink
instance lock of the parent instance should be taken first, only then
instance lock of the nested instance could be taken.
- - Driver should use object-specific helpers to setup the
- nested relationship:
+ - Driver should use object-specific helpers to setup the nested relationship
+ before registering the nested devlink instance:
- ``devl_nested_devlink_set()`` - called to setup devlink -> nested
- devlink relationship (could be user for multiple nested instances.
+ devlink relationship (could be used for multiple nested instances).
- ``devl_port_fn_devlink_set()`` - called to setup port function ->
nested devlink relationship.
- ``devlink_linecard_nested_dl_set()`` - called to setup linecard ->
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v2 1/3] docs: net: tls-offload: document tls_dev_del, tls_dev_resync, and rekey
From: Jakub Kicinski @ 2026-06-13 16:58 UTC (permalink / raw)
To: davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, linux-doc,
john.fastabend, sd, jiri, Jakub Kicinski, skhan
In-Reply-To: <20260613165846.2913092-1-kuba@kernel.org>
Fill in some gaps in the TLS offload doc:
- describe the tls_dev_del and tls_dev_resync callbacks
- add a mention of rekeying being out of scope for now
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
v2:
- add mentions of the callback in resync text
- Stack -> The stack
v1: https://lore.kernel.org/20260609201224.1191391-1-kuba@kernel.org
CC: john.fastabend@gmail.com
CC: sd@queasysnail.net
CC: corbet@lwn.net
CC: skhan@linuxfoundation.org
CC: linux-doc@vger.kernel.org
---
Documentation/networking/tls-offload.rst | 45 ++++++++++++++++++++----
1 file changed, 38 insertions(+), 7 deletions(-)
diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst
index 25ee8d9f12c9..e5802bcd4d22 100644
--- a/Documentation/networking/tls-offload.rst
+++ b/Documentation/networking/tls-offload.rst
@@ -99,6 +99,29 @@ at the end of kernel structures (see :c:member:`driver_state` members
in ``include/net/tls.h``) to avoid additional allocations and pointer
dereferences.
+When the offloaded connection is destroyed the core calls
+the :c:member:`tls_dev_del` callback so the driver can release per-direction
+state:
+
+.. code-block:: c
+
+ void (*tls_dev_del)(struct net_device *netdev,
+ struct tls_context *ctx,
+ enum tls_offload_ctx_dir direction);
+
+``tls_dev_del`` is mandatory whenever ``tls_dev_add`` is provided.
+
+The third TLS device callback is :c:member:`tls_dev_resync`, called by the core
+to synchronize the TCP stream with the record boundaries:
+
+.. code-block:: c
+
+ int (*tls_dev_resync)(struct net_device *netdev,
+ struct sock *sk, u32 seq, u8 *rcd_sn,
+ enum tls_offload_ctx_dir direction);
+
+See the `Resync handling`_ section for details.
+
TX
--
@@ -250,9 +273,9 @@ sequence number (as it will be updated from a different context).
bool tls_offload_tx_resync_pending(struct sock *sk)
Next time ``ktls`` pushes a record it will first send its TCP sequence number
-and TLS record number to the driver. Stack will also make sure that
-the new record will start on a segment boundary (like it does when
-the connection is initially added).
+and TLS record number to the driver via the ``tls_dev_resync`` callback.
+The stack will also make sure that the new record will start on a segment
+boundary (like it does when the connection is initially added).
RX
--
@@ -344,9 +367,10 @@ all TLS record headers that have been logged since the resync request
started.
The kernel confirms the guessed location was correct and tells the device
-the record sequence number. Meanwhile, the device had been parsing
-and counting all records since the just-confirmed one, it adds the number
-of records it had seen to the record number provided by the kernel.
+the record sequence number via the ``tls_dev_resync`` callback. Meanwhile,
+the device had been parsing and counting all records since the just-confirmed
+one, it adds the number of records it had seen to the record number provided
+by the kernel.
At this point the device is in sync and can resume decryption at next
segment boundary.
@@ -370,12 +394,19 @@ schedules resynchronization after it has received two completely encrypted
records.
The stack waits for the socket to drain and informs the device about
-the next expected record number and its TCP sequence number. If the
+the next expected record number and its TCP sequence number via the
+``tls_dev_resync`` callback. If the
records continue to be received fully encrypted stack retries the
synchronization with an exponential back off (first after 2 encrypted
records, then after 4 records, after 8, after 16... up until every
128 records).
+Rekey
+=====
+
+Offload does not currently support TLS 1.3, therefore key rotation
+is not a concern for offloaded connections at this point.
+
Error handling
==============
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v2 0/3] docs: net: more adjustments to docs
From: Jakub Kicinski @ 2026-06-13 16:58 UTC (permalink / raw)
To: davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, linux-doc,
john.fastabend, sd, jiri, Jakub Kicinski
A few small updates to the docs.
This is trying to prepare docs for getting fed directly
into AI reviews.
v2:
- fixes in the tls offload patch
- add the strparser patch in place of the already applied XDP md one
v1: https://lore.kernel.org/20260609201224.1191391-1-kuba@kernel.org
Jakub Kicinski (3):
docs: net: tls-offload: document tls_dev_del, tls_dev_resync, and
rekey
docs: net: fix minor issues with devlink docs
docs: net: fix minor issues with strparser docs
.../networking/devlink/devlink-health.rst | 12 +++--
.../networking/devlink/devlink-params.rst | 2 +-
.../networking/devlink/devlink-port.rst | 5 ++-
.../networking/devlink/devlink-trap.rst | 8 ++--
Documentation/networking/devlink/index.rst | 10 ++---
Documentation/networking/strparser.rst | 22 ++++-----
Documentation/networking/tls-offload.rst | 45 ++++++++++++++++---
7 files changed, 72 insertions(+), 32 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
From: Yan Zhu @ 2026-06-13 15:08 UTC (permalink / raw)
To: Fan Wu
Cc: alexs, si.yanteng, corbet, mic, dzm91, skhan, gnoack, linux-doc,
linux-security-module
In-Reply-To: <CAKtyLkE3unhxMsH1LpqvjHQoKVgz1tcTsZWUxNHs+R6v2amf6w@mail.gmail.com>
On 6/13/2026 10:54 AM, Fan Wu wrote:
> On Fri, Jun 12, 2026 at 8:59 AM Yan Zhu <zhuyan2015@qq.com> wrote:
>>
>> Translate Documentation/admin-guide/LSM/ipe.rst into Chinese.
>>
>> Update the translation through commit d7ba853c0e47
>> ("ipe: Update documentation for script enforcement")
>>
>> Assisted-by: Claude:deepseek-4-pro
>> Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
>> ---
>
> Have you tried to refine the AI translation? IMO some are really bad translated.
I have double-checked it several times and manually corrected the
formatting and the accuracy of the translation.
>
> Also how does the doc translation project work? I do notice there is
> another IPE design doc translation,
> https://docs.kernel.org/next/translations/zh_CN/security/ipe.html
> which has a wrong "original link".>
> -Fan
The documents in the "admin-guide" directory are intended for both
administrators and users, focusing on usage; the documents in the
"security" directory are targeted at developers, emphasizing design and
development.
--
Thanks
Yan Zhu
^ permalink raw reply
* Re: [PATCH v3] kconfig: add optional warnings for changed input values
From: Julian Braha @ 2026-06-13 12:48 UTC (permalink / raw)
To: Pengpeng Hou, Masahiro Yamada, Nathan Chancellor, Nicolas Schier
Cc: Jonathan Corbet, linux-kbuild, linux-doc, linux-kernel
In-Reply-To: <20260611060000.23858-1-pengpeng@iscas.ac.cn>
On 6/11/26 07:00, Pengpeng Hou wrote:
> When reading .config input, Kconfig stores user-provided values first
> and then resolves the final value after applying dependencies, ranges,
> and other constraints.
>
> If the final value differs from the user input, Kconfig already tracks
> that state internally, but it does not provide a focused diagnostic to
> show which explicit inputs were adjusted. This is particularly confusing
> for requested values that get forced down by unmet dependencies or
> clamped by ranges.
Hi Pengpeng,
This change would be a huge QoL improvement for me, thank you. When I
generate config files with external tooling, I need to do this check
manually.
It would also be helpful if config options that are removed from .config
would be printed, since there are config options that are only defined
in certain architectures.
Tested-by: Julian Braha <julianbraha@gmail.com>
^ permalink raw reply
* [cris:scmi_telemetry_unified_fs_V4 29/34] htmldocs: Documentation/filesystems/stlmfs.rst:238: WARNING: Title underline too short.
From: kernel test robot @ 2026-06-13 12:40 UTC (permalink / raw)
To: Cristian Marussi; +Cc: oe-kbuild-all, linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/cris/linux.git scmi_telemetry_unified_fs_V4
head: ed28087005811783e972fe7a788446936878932f
commit: c4f3df624c05557c708df87efde36b341fabff01 [29/34] fs/stlmfs: Document alternative topological view
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/20260613/202606131440.jdW5ZTeF-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/202606131440.jdW5ZTeF-lkp@intel.com/
All warnings (new ones prefixed by >>):
----------- [docutils]
WARNING: ./include/linux/virtio.h:188 struct member 'map' not described in 'virtio_device'
WARNING: ./include/linux/virtio.h:188 struct member 'vmap' not described in 'virtio_device'
WARNING: ./include/linux/netfs.h:764 function parameter 'ictx' not described in 'netfs_resize_file'
WARNING: ./include/linux/netfs.h:764 function parameter 'ictx' not described in 'netfs_resize_file'
>> Documentation/filesystems/stlmfs.rst:238: WARNING: Title underline too short.
vim +238 Documentation/filesystems/stlmfs.rst
225
226 scmi_tlm_0/groups/0/
227 |-- available_update_intervals_ms
228 |-- composing_des
229 |-- control
230 |-- current_update_interval_ms
231 |-- des_bulk_read
232 |-- des_single_sample_read
233 |-- enable
234 |-- intervals_discrete
235 `-- tstamp_enable
236
237 by-components/
> 238 -----------
239
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next v4 13/13] net: ethernet: adi: Add a driver for the ADIN1140 MACPHY
From: Paolo Abeni @ 2026-06-13 9:26 UTC (permalink / raw)
To: ciprian.regus
Cc: parthiban.veerasooran, andrew+netdev, davem, edumazet, kuba,
pabeni, horms, corbet, skhan, andrew, hkallweit1, linux, robh,
krzk+dt, conor+dt, netdev, linux-kernel, linux-doc, devicetree
In-Reply-To: <20260609-adin1140-driver-v4-13-0753e28ee004@analog.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://netdev-ai.bots.linux.dev/sashiko/
---
net: ethernet: adi: Add a driver for the ADIN1140 MACPHY
This patch adds a driver for the ADIN1140 10BASE-T1S MAC-PHY which talks
to the host over SPI using the OA TC6 protocol. It introduces a custom
mii_bus to work around two hardware issues, and exposes both rtnl link
stats and ethtool MAC stats from periodically polled hardware counters.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 50f795dfa880..c3cab8f7b9ef 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1858,6 +1858,14 @@ S: Supported
> W: https://ez.analog.com/linux-software-drivers
> F: drivers/dma/dma-axi-dmac.c
>
> +ANALOG DEVICES INC ETHERNET DRIVERS
> +M: Ciprian Regus <ciprian.regus@analog.com>
> +L: netdev@vger.kernel.org
> +S: Maintained
> +W: https://ez.analog.com/linux-software-drivers
> +F: Documentation/devicetree/bindings/net/adi,ad3306.yaml
> +F: drivers/net/ethernet/adi/adin1140.c
[Medium]
The MAINTAINERS entry references
Documentation/devicetree/bindings/net/adi,ad3306.yaml, but that file is
not added by this patch and does not appear elsewhere in the tree.
The driver also introduces two new of compatibles:
{ .compatible = "adi,ad3306" },
{ .compatible = "adi,adin1140" },
with no YAML schema. Should the binding document be added in this same
series so that the F: line resolves and dt_binding_check can validate
the new compatibles?
> diff --git a/drivers/net/ethernet/adi/adin1140.c b/drivers/net/ethernet/adi/adin1140.c
> new file mode 100644
> index 000000000000..306e5de6faa5
> --- /dev/null
> +++ b/drivers/net/ethernet/adi/adin1140.c
[ ... ]
> +static int adin1140_mac_filter_set(struct adin1140_priv *priv,
> + const u8 *addr, const u8 *mask,
> + u8 slot)
> +{
> + u32 reg_address;
> + u32 val;
> + int ret;
> +
> + if (slot >= ADIN1140_MAC_FILT_MAX_SLOT)
> + return -ENOSPC;
> +
> + reg_address = ADIN1140_MAC_ADDR_FILT_UPR_REG + 2 * slot;
> +
> + ret = oa_tc6_write_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + reg_address,
> + get_unaligned_be16(&addr[0]) |
> + ADIN1140_MAC_ADDR_FILT_APPLY2PORT1 |
> + ADIN1140_MAC_ADDR_FILT_TO_HOST);
> + if (ret)
> + return ret;
> +
> + reg_address = ADIN1140_MAC_ADDR_FILT_LWR_REG + 2 * slot;
> + ret = oa_tc6_write_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + reg_address,
> + get_unaligned_be32(&addr[2]));
> + if (ret)
> + return ret;
> +
> + /* Only the first 2 destination MAC filter slots support masking.
> + * For the other entries, the destination address in the received
> + * frame must match exactly.
> + */
> + if (slot >= ADIN1140_MAC_FILT_MASK_LIMIT)
> + return 0;
> +
> + val = get_unaligned_be16(&mask[0]);
> + reg_address = ADIN1140_MAC_ADDR_MASK_UPR_REG + (2 * slot);
> +
> + ret = oa_tc6_write_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + reg_address, val);
> + if (ret)
> + return ret;
> +
> + val = get_unaligned_be32(&mask[2]);
> + reg_address = ADIN1140_MAC_ADDR_MASK_LWR_REG + (2 * slot);
> +
> + return oa_tc6_write_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + reg_address, val);
> +}
[Medium]
adin1140_mac_filter_set() performs up to four sequential
oa_tc6_write_register_mms() calls (filter upper, filter lower, mask
upper, mask lower) and returns at the first error without rolling back
the writes that already succeeded.
If the upper-half write of a new MAC succeeds and the lower-half write
fails, the slot is left programmed with (new high | old low). Callers
treat this as single-shot:
ret = adin1140_mac_filter_set(priv, address->sa_data, mask,
ADIN1140_MAC_FILT_UC_SLOT);
if (ret)
return ret;
eth_commit_mac_addr_change(netdev, addr);
so adin1140_set_mac_address() leaves netdev->dev_addr at the old value
while the hardware filter now matches a third, hybrid address. The same
applies to adin1140_rx_mode_work() which just returns on the first
error and leaves the dynamic filter table inconsistent with
netdev->uc/mc.
Should this function stage the writes (or perform a rollback / clear of
the affected slot) so a partial failure cannot leave the hardware
filter in a state that does not match the driver's view?
[ ... ]
> +static void adin1140_rx_mode_work(struct work_struct *work)
> +{
> + struct adin1140_priv *priv = container_of(work, struct adin1140_priv,
> + rx_mode_work);
> + struct netdev_hw_addr *ha;
> + bool all_multi, promisc;
> + u8 mask[ETH_ALEN];
> + u8 start, end;
> + u32 mac_addrs;
> + u8 slot, i;
> + int ret;
> +
> + /* The ADIN1140 has 16 dest MAC address filter slots:
> + * 0 - reserved for all multicast filter.
> + * 1 - reserved for broadcast filter.
> + * 2 - reserved for the device's own unicast MAC.
> + * 3 -> 15 - available for other unicast/multicast filters.
> + */
> +
> + mac_addrs = netdev_uc_count(priv->netdev) +
> + netdev_mc_count(priv->netdev);
> +
> + if (priv->netdev->flags & IFF_PROMISC) {
> + promisc = true;
> + all_multi = false;
> + } else if (priv->netdev->flags & IFF_ALLMULTI) {
> + promisc = false;
> + all_multi = true;
> + } else if (mac_addrs <= ADIN1140_MAC_FILT_AVAIL) {
> + promisc = false;
> + all_multi = false;
> +
> + slot = ADIN1140_MAC_FILT_UC_SLOT + 1;
> + memset(mask, 0xFF, ETH_ALEN);
> +
> + netdev_for_each_uc_addr(ha, priv->netdev) {
> + ret = adin1140_mac_filter_set(priv, ha->addr, mask,
> + slot);
> + if (ret)
> + return;
> +
> + slot++;
> + }
> +
> + netdev_for_each_mc_addr(ha, priv->netdev) {
> + ret = adin1140_mac_filter_set(priv, ha->addr, mask,
> + slot);
> + if (ret)
> + return;
> +
> + slot++;
> + }
> +
> + for (i = slot; i < ADIN1140_MAC_FILT_MAX_SLOT; i++) {
> + ret = adin1140_mac_filter_clear(priv, i);
> + if (ret)
> + return;
> + }
> +
> + } else {
> + /* The filter table is full. Enable promisc mode. */
> + promisc = true;
> + all_multi = false;
> +
> + start = ADIN1140_MAC_FILT_UC_SLOT + 1;
> + end = ADIN1140_MAC_FILT_MAX_SLOT;
> + for (i = start; i < end; i++) {
> + ret = adin1140_mac_filter_clear(priv, i);
> + if (ret)
> + return;
> + }
> + }
> +
> + ret = adin1140_promiscuous_mode(priv, promisc);
> + if (ret)
> + return;
> +
> + adin1140_filter_all_multicast(priv, all_multi);
> +}
[High]
This work iterates priv->netdev->uc and ->mc with no synchronization:
netdev_for_each_uc_addr(ha, priv->netdev) {
ret = adin1140_mac_filter_set(priv, ha->addr, mask, slot);
...
}
netdev_for_each_mc_addr(ha, priv->netdev) {
...
}
netdev_for_each_uc_addr() and netdev_for_each_mc_addr() expand to
plain list_for_each_entry() over dev->uc.list / dev->mc.list. Callers
are required to hold netif_addr_lock_bh() (or rtnl) because dev_uc_add
/ dev_uc_del / dev_mc_add / dev_mc_del can mutate those lists from
user-space ip address/maddr changes.
Inside the loop ha->addr is then handed to adin1140_mac_filter_set(),
which performs SPI register writes that can sleep, so taking
netif_addr_lock_bh() across the iteration is not directly viable.
Can this race with a concurrent dev_uc_del() / dev_mc_del() and
dereference freed list entries (or skip / duplicate filter slots)?
Other ethernet drivers that need to issue sleeping ops while syncing
the address lists use __dev_uc_sync() / __dev_mc_sync() which copy
state under netif_addr_lock; would that pattern be more appropriate
here?
[Medium]
In the IFF_PROMISC and IFF_ALLMULTI branches, slots 3..15 are not
cleared:
if (priv->netdev->flags & IFF_PROMISC) {
promisc = true;
all_multi = false;
} else if (priv->netdev->flags & IFF_ALLMULTI) {
promisc = false;
all_multi = true;
} else if (mac_addrs <= ADIN1140_MAC_FILT_AVAIL) {
...
for (i = slot; i < ADIN1140_MAC_FILT_MAX_SLOT; i++) {
ret = adin1140_mac_filter_clear(priv, i);
...
}
} else {
...
for (i = start; i < end; i++) {
ret = adin1140_mac_filter_clear(priv, i);
...
}
}
If a previous invocation populated slots 3..N with extra unicast or
multicast filters and the user then enables IFF_ALLMULTI, those
previously installed unicast filters remain active in hardware
(carrying APPLY2PORT1 | TO_HOST). Should the IFF_ALLMULTI path also
clear slots 3..15 so traffic for addresses no longer in netdev->uc/mc
is not still forwarded to the host?
[ ... ]
> +static void adin1140_stats_work(struct work_struct *work)
> +{
> + struct delayed_work *dwork = to_delayed_work(work);
> + u64 stat_buff[ADIN1140_STATS_CNT] = {};
> + struct adin1140_priv *priv;
> + u32 reg_val;
> + int ret;
> + u32 i;
> +
> + priv = container_of(dwork, struct adin1140_priv, stats_work);
> +
> + for (i = 0; i < ARRAY_SIZE(adin1140_stat_regs); i++) {
> + ret = oa_tc6_read_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + adin1140_stat_regs[i],
> + ®_val);
> + if (ret)
> + break;
> +
> + stat_buff[i] = reg_val;
> + }
> +
> + scoped_guard(spinlock, &priv->stat_lock)
> + memcpy(&priv->stats, stat_buff, sizeof(priv->stats));
> +
> + schedule_delayed_work(dwork, ADIN1140_STATS_CHECK_DELAY);
> +}
[Medium]
stat_buff is zero-initialized and the loop break on a read error is
followed unconditionally by:
scoped_guard(spinlock, &priv->stat_lock)
memcpy(&priv->stats, stat_buff, sizeof(priv->stats));
If oa_tc6_read_register_mms() fails partway through, every entry from
the failing index onwards is still zero, and that all-zero tail is
copied over the previously valid u64 counters. Since priv->stats[] is
read directly by adin1140_ndo_get_stats64(),
adin1140_get_eth_mac_stats() and adin1140_get_ethtool_stats(), a
single transient SPI/TC6 hiccup makes the rtnl_link_stats64 and
ethtool_eth_mac_stats counters drop to zero before climbing again.
Should the memcpy be skipped on error, or should partial updates be
merged into priv->stats[] only for the indices that were read
successfully?
[Medium]
The hardware counters at MMS1 0xA1..0xBA are read into u32 reg_val and
then stored as-is into the u64 stat_buff[i]:
ret = oa_tc6_read_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
adin1140_stat_regs[i],
®_val);
...
stat_buff[i] = reg_val;
priv->stats[] feeds rtnl_link_stats64 and ethtool_eth_mac_stats, both
of which document monotonic u64 counters. On 32-bit hardware register
wrap (0xFFFFFFFF -> 0) the user-visible u64 value will go backwards,
and with a 3-second poll interval a fast counter (e.g.
FramesReceivedOK on a busy 10BASE-T1S segment) can wrap entirely
between samples. Should the driver compute deltas with 32-bit wrap
handling and accumulate them into a software u64 counter rather than
overwriting?
[ ... ]
> +static void adin1140_get_ethtool_stats(struct net_device *netdev,
> + struct ethtool_stats *stats, u64 *data)
> +{
> + struct adin1140_priv *priv = netdev_priv(netdev);
> + u32 i;
> +
> + scoped_guard(spinlock, &priv->stat_lock) {
> + for (i = 0; i < ARRAY_SIZE(adin1140_stats); i++)
> + data[i] = priv->stats[adin1140_stats[i].idx];
> + }
> +}
> +
> +static void adin1140_get_ethtool_strings(struct net_device *netdev, u32 sset,
> + u8 *p)
> +{
> + u32 i;
> +
> + switch (sset) {
> + case ETH_SS_STATS:
> + for (i = 0; i < ARRAY_SIZE(adin1140_stats); i++)
> + ethtool_puts(&p, adin1140_stats[i].name);
> +
> + break;
> + }
> +}
[Medium]
The driver implements both .ndo_get_stats64 and .get_eth_mac_stats,
yet adin1140_stats[] adds private ethtool -S strings whose values are
already exposed (or trivially derivable) through those standard uAPIs:
{.name = "rx_unicast_frames", .idx = rx_uc_frames},
{.name = "rx_preamble_errors", .idx = rx_preamble_errors},
{.name = "rx_ifg_errors", .idx = rx_ifg_errors},
{.name = "rx_addr_filter_dropped", .idx = rx_addr_filter_dropped},
{.name = "tx_unicast_frames", .idx = tx_uc_frames},
rx_addr_filter_dropped is already aggregated into
rtnl_link_stats64.rx_dropped by this same driver:
storage->rx_dropped = priv->stats[rx_fifo_full_dropped] +
priv->stats[rx_addr_filter_dropped];
rx_unicast_frames and tx_unicast_frames are derivable from
ethtool_eth_mac_stats (FramesReceivedOK minus broadcast minus
multicast, and the Xmitted equivalents) which are populated in
__adin1140_eth_mac_stats.
Per Documentation/networking/statistics.rst, should these counters be
left out of ethtool -S since standard uAPIs already cover them?
--
This is an AI-generated review.
^ permalink raw reply
* [cris:scmi_telemetry_unified_fs_V4 23/34] htmldocs: Documentation/filesystems/stlmfs.rst: WARNING: document isn't included in any toctree [toc.not_included]
From: kernel test robot @ 2026-06-13 8:46 UTC (permalink / raw)
To: Cristian Marussi; +Cc: oe-kbuild-all, linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/cris/linux.git scmi_telemetry_unified_fs_V4
head: ed28087005811783e972fe7a788446936878932f
commit: a4696bbff34cf8e311ab878fc616567844b576ee [23/34] fs/stlmfs: Document ARM SCMI Telemetry filesystem
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/20260613/202606131001.iJbU6AyB-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/202606131001.iJbU6AyB-lkp@intel.com/
All warnings (new ones prefixed by >>):
Documentation/userspace-api/landlock:550: ./include/uapi/linux/landlock.h:45: ERROR: Unknown target name: "network flags". [docutils]
Documentation/userspace-api/landlock:550: ./include/uapi/linux/landlock.h:50: ERROR: Unknown target name: "scope flags". [docutils]
Documentation/userspace-api/landlock:550: ./include/uapi/linux/landlock.h:24: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:559: ./include/uapi/linux/landlock.h:168: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:559: ./include/uapi/linux/landlock.h:191: ERROR: Unknown target name: "network flags". [docutils]
>> Documentation/filesystems/stlmfs.rst: WARNING: document isn't included in any toctree [toc.not_included]
WARNING: Documentation/ABI/testing/stlmfs not found
Documentation/networking/skbuff:36: ./include/linux/skbuff.h:181: WARNING: Failed to create a cross reference. A title or caption not found: 'crc' [ref.ref]
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [RFC PATCH 0/5] mm/slub: preserve previous object lifetime
From: Harry Yoo @ 2026-06-13 6:01 UTC (permalink / raw)
To: Vlastimil Babka (SUSE), Pengpeng Hou, Andrew Morton, linux-mm
Cc: Hao Li, Christoph Lameter, David Rientjes, Roman Gushchin,
David Hildenbrand, Lorenzo Stoakes, liam, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jonathan Corbet, Shuah Khan,
linux-doc, linux-kernel
In-Reply-To: <55b1b674-6487-4585-8a0d-919373e66d3a@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]
On 6/12/26 2:28 AM, Vlastimil Babka (SUSE) wrote:
> On 6/11/26 08:39, Pengpeng Hou wrote:
>> SLAB_STORE_USER currently stores one allocation track and one free track
>> for an object. This is useful, but it loses part of the previous lifetime
>> when the object is reused: the new allocation overwrites the allocation
>> track, and a later stale free can overwrite the free track.
>>
>> For free-after-reuse bugs, the report can therefore contain the victim
>> allocation and the stale free, while the earlier alloc/free pair that
>> explains where the stale pointer came from is no longer available.
>>
>> This RFC adds an opt-in SLUB debug option to keep one previous completed
>> object lifetime. The option is disabled by default, is not part of the
>> default debug flags, and only takes effect when user tracking is already
>> enabled:
>
> Sounds useful!
>
>> This is sent as RFC because the user-visible interface and the cost/benefit
>> tradeoff should be agreed on before this becomes a normal patch series.
>> In particular, feedback would be useful on:
>>
>> - whether a separate H option is preferable to extending U directly
>
> I think before we converted U to stackdepot, the memory overhead of the
> stacks was higher than U+H with stackdepot. So I think it would be
> acceptable to extend directly. If a user is willing to pay the current U
> overhead to debug something in production, the addition of U+H shouldn't
> make it suddenly unacceptable.
Agreed on extending U directly rather than having a separate option.
>> - whether H should require U, as implemented here, or imply U
>> - whether the extra per-object metadata is useful enough for this debug path
>
> One could think of scenarios where even longer object history would be
> needed to find the culprit. But adding one extra lifetime probably has the
> biggest impact.
Heh, I was actually wondering if it would make sense to have e.g.) a
hash table (per cache) where each bucket can store N "extra" lifetime
history of objects with the same key, with each element storing
stackdepot handles and the object address :P
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/5] mm/slub: preserve previous object lifetime
From: Harry Yoo @ 2026-06-13 5:42 UTC (permalink / raw)
To: Vlastimil Babka (SUSE), Pengpeng Hou, Andrew Morton, linux-mm
Cc: Hao Li, Christoph Lameter, David Rientjes, Roman Gushchin,
David Hildenbrand, Lorenzo Stoakes, liam, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jonathan Corbet, Shuah Khan,
linux-doc, linux-kernel
In-Reply-To: <8c5d67d1-e4b0-4cb2-9336-875f4f2ca96b@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2850 bytes --]
On 6/12/26 2:13 AM, Vlastimil Babka (SUSE) wrote:
> On 6/11/26 09:19, Harry Yoo wrote:
>> Hi Pengpeng,
>>
>> On 6/11/26 3:39 PM, Pengpeng Hou wrote:
>>> SLAB_STORE_USER currently stores one allocation track and one free track
>>> for an object. This is useful, but it loses part of the previous lifetime
>>> when the object is reused: the new allocation overwrites the allocation
>>> track, and a later stale free can overwrite the free track.
>>
>> I'm not sure what you meant by "stale free", UAF is accessing object
>> that are freed. What makes the free "stale"?
>
> I'm guessing it means 'second/duplicated free" of the previous owner.
Okay, it wasn't clear in the cover letter but now assuming the same...
> Accesses (UAF) perhaps may not happen by that owner, or if they happen after
> he object is reallocated, they are not recognized as such.
Right.
User A User B
=======================================================================
allocates an object
frees the object
allocates the object
frees the object again
(poison the object)
overwrites the object
(not detected until freed)
frees the object, UAF detected!
By the time it detects a UAF, free trace is from user A (of the second
free) (since we perform consistency checks before updating free trace),
alloc trace is from user B.
So the only thing we know about user A is the stack trace of double free
but no original alloc/free traces of user A.
>> In general, I don't think slab_debug=UP is the right tool to debug
>> use-after-frees, because slab will never know _when_ the object was
>> overwritten. It can only tell that somebody has overwritten freed
>> objects by checking if the object content is POISON_FREE or POISON_END.
>
> It could give more information about double frees like this, however.
Right.
>> KASAN is a better tool to debug use-after-frees, because it can
>> tell you which kernel code is accessing memory it shouldn't. (It also
>> quarantines slab objects to avoid immediately reusing the object for
>> better coverage).
>>
>> So I have to ask, "Why not use KASAN instead?" before enhancing
>> slab_debug (neither is intended for production anyway).
>
> From my distro experience, it's very useful to tell a user to just enable
> slub_debug for a specific cache with the existing kernel, with some but not
> prohibitive overhead. And with some luck it gives you enough information to
> find the root cause too. So in that sense it can be used in production.
Right.
> KASAN is indeed superior wrt catching issues, but almost never applicable in
> such environment. It would need a rebuilt kernel and the overhead is much
> higher. So it's a tradeoff.
Right and not all users reporting bugs are willying to do that...
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: Randy Dunlap @ 2026-06-13 5:35 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc
Cc: sudeep.holla, james.quinlan, f.fainelli, vincent.guittot,
etienne.carriere, peng.fan, michal.simek, d-gole, jic23,
elif.topuz, lukasz.luba, philip.radford, brauner,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team
In-Reply-To: <20260612223802.1337232-1-cristian.marussi@arm.com>
On 6/12/26 3:37 PM, Cristian Marussi wrote:
> Hi all,
>
> --------------------------------------------------------------------------------
> [TLDR Summary]
> This series introduces a new SCMI driver which uses a new Telemetry FS to expose
> and configure SCMI Telemetry Data Events retrieved from the platform SCMI FW
> at runtime. The patches carrying the new STLMFS Filesystem support are tagged
> with 'stlmfs'.
> --------------------------------------------------------------------------------
> ---
> - moved from SysFS/chardev to a full fledged FS
> - added support for SCMI Telemetry BLK timestamps
>
'make htmldocs' with all documentation patches applied says:
WARNING: linext-2026-0610/Documentation/ABI/testing/stlmfs:5: tag 'contact' is invalid
Rationale: This filesystem provides access to SCMI telemetry data and
WARNING: linext-2026-0610/Documentation/ABI/testing/stlmfs:21: tag 'contact' is invalid
Concurrency: The telemetry configuration exposed through this filesystem is
Documentation/ABI/testing/stlmfs:55: ERROR: Unexpected indentation. [docutils]
Documentation/ABI/testing/stlmfs:69: ERROR: Unexpected indentation. [docutils]
Documentation/ABI/testing/stlmfs:282: ERROR: Unexpected indentation. [docutils]
WARNING: linext-2026-0610/Documentation/ABI/testing/stlmfs:39: abi_sys_fs_arm_telemetry_tlm_n doesn't have a description
linext-2026-0610/Documentation/filesystems/stlmfs.rst:255: WARNING: Title underline too short.
by-components/
----------- [docutils]
linext-2026-0610/Documentation/filesystems/stlmfs.rst: WARNING: document isn't included in any toctree [toc.not_included]
Please correct these and run 'make htmldocs' to verify that they are fixed.
>
> Thanks,
> Cristian
>
> [0]: https://developer.arm.com/documentation/den0056/f/?lang=en
> [1]: https://lore.kernel.org/arm-scmi/20250620192813.2463367-1-cristian.marussi@arm.com/
> [2]: https://git.kernel.org/pub/scm/linux/kernel/git/cris/linux.git/log/?h=scmi_telemetry_unified_fs_V4
>
> Cristian Marussi (31):
> firmware: arm_scmi: Add new SCMIv4.0 error codes definitions
> firmware: arm_scmi: Reduce the scope of protocols mutex
> firmware: arm_scmi: Allow registration of unknown-size events/reports
> firmware: arm_scmi: Allow protocols to register for notifications
> uapi: Add ARM SCMI definitions
> dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
> include: trace: Add Telemetry trace events
> firmware: arm_scmi: Add basic Telemetry support
> firmware: arm_scmi: Add support to parse SHMTIs areas
> firmware: arm_scmi: Add Telemetry configuration operations
> firmware: arm_scmi: Add Telemetry DataEvent read capabilities
> firmware: arm_scmi: Add support for Telemetry reset
> firmware: arm_scmi: Add Telemetry notification support
> firmware: arm_scmi: Add support for boot-on Telemetry
> firmware: arm_scmi: Add Telemetry generation counter
> firmware: arm_scmi: Add common per-protocol debugfs support
> firmware: arm_scmi: Add Telemetry debugfs SHMTI dump support
> firmware: arm_scmi: Add Telemetry debugfs ABI documentation
> firmware: arm_scmi: stlmfs: Add System Telemetry filesystem driver
> fs/stlmfs: Document ARM SCMI Telemetry filesystem
> firmware: arm_scmi: stlmfs: Add basic mount options
> fs/stlmfs: Document ARM SCMI Telemetry FS mount options
> firmware: arm_scmi: stlmfs: Add ioctls support
> fs/stlmfs: Document alternative ioctl based binary interface
> firmware: arm_scmi: stlmfs: Add by-components view
> fs/stlmfs: Document alternative topological view
> firmware: arm_scmi: stlmfs: Add generation file
> [RFC] docs: stlmfs: Document ARM SCMI Telemetry FS ABI
> firmware: arm_scmi: stlmfs: Add lazy population support
> fs/stlmfs: Document lazy mode and related mount option
> [RFC] tools/scmi: Add SCMI Telemetry testing tool
>
> Documentation/ABI/testing/debugfs-scmi | 22 +
> Documentation/ABI/testing/stlmfs | 348 ++
> .../bindings/firmware/arm,scmi.yaml | 8 +
> Documentation/filesystems/stlmfs.rst | 342 ++
> MAINTAINERS | 1 +
> drivers/firmware/arm_scmi/Kconfig | 24 +
> drivers/firmware/arm_scmi/Makefile | 3 +-
> drivers/firmware/arm_scmi/common.h | 10 +
> drivers/firmware/arm_scmi/driver.c | 93 +-
> drivers/firmware/arm_scmi/notify.c | 30 +-
> drivers/firmware/arm_scmi/notify.h | 8 +-
> drivers/firmware/arm_scmi/protocols.h | 13 +
> .../firmware/arm_scmi/scmi_system_telemetry.c | 3146 ++++++++++++++++
> drivers/firmware/arm_scmi/telemetry.c | 3300 +++++++++++++++++
> include/linux/scmi_protocol.h | 203 +-
> include/trace/events/scmi.h | 48 +-
> include/uapi/linux/scmi.h | 289 ++
> tools/testing/scmi/Makefile | 25 +
> tools/testing/scmi/stlm.c | 434 +++
> 19 files changed, 8307 insertions(+), 40 deletions(-)
> create mode 100644 Documentation/ABI/testing/stlmfs
> create mode 100644 Documentation/filesystems/stlmfs.rst
> create mode 100644 drivers/firmware/arm_scmi/scmi_system_telemetry.c
> create mode 100644 drivers/firmware/arm_scmi/telemetry.c
> create mode 100644 include/uapi/linux/scmi.h
> create mode 100644 tools/testing/scmi/Makefile
> create mode 100644 tools/testing/scmi/stlm.c
>
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 28/31] [RFC] docs: stlmfs: Document ARM SCMI Telemetry FS ABI
From: Randy Dunlap @ 2026-06-13 5:30 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc
Cc: sudeep.holla, james.quinlan, f.fainelli, vincent.guittot,
etienne.carriere, peng.fan, michal.simek, d-gole, jic23,
elif.topuz, lukasz.luba, philip.radford, brauner,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team
In-Reply-To: <20260612223802.1337232-29-cristian.marussi@arm.com>
On 6/12/26 3:37 PM, Cristian Marussi wrote:
> Add full ABI dcoumentation for stlmfs under testing/
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> v3 --> v4
> - renamed to by-components
> - updated date/versions
> - changed output of des/0x<NNN>/value to -> <tstamp> <value>
> (removed colon)
> - added Rationale and Concurrency model
> - added generation counter Description
> v2 --> v3
> - complete ABI entries docs
>
> RFC since unsure if place this into stable/ or testing/
> ---
> Documentation/ABI/testing/stlmfs | 348 +++++++++++++++++++++++++++++++
> 1 file changed, 348 insertions(+)
> create mode 100644 Documentation/ABI/testing/stlmfs
>
> diff --git a/Documentation/ABI/testing/stlmfs b/Documentation/ABI/testing/stlmfs
> new file mode 100644
> index 000000000000..826092a4baf4
> --- /dev/null
> +++ b/Documentation/ABI/testing/stlmfs
> @@ -0,0 +1,348 @@
> +What: /sys/fs/arm_telemetry/tlm_<N>/...
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Rationale: This filesystem provides access to SCMI telemetry data and
> + configuration.
> + The interface is required to support:
> + - hierarchical dynamically discovered telemetry objects
> + - bulk data read across multiple sources
> + - representation of complex structured data and their
> + relationship
> + - alternative high-frequency data access (ioctl/mmap)
> + These characteristics exceed the intended use of sysfs, which is
> + designed to represent devices properties with simple attribute
> + based configuration with one value per file: representing
> + telemetry Data Events with devices was deemed an abuse by
> + itself.
> + A dedicated filesystem is therefore used to provide a more
> + suitable abstraction for this class of functionality.
> +
> +Concurrency: The telemetry configuration exposed through this filesystem is
> + global to each SCMI telemetry instance, indentified by the top
identified
> + tlm_<N> directory.
> + Concurrent access from multiple user-space processes is allowed.
> + The kernel does not enforce exclusivity or ownership of the
> + interface.
> + All configuration changes are applied immediately by issuing
> + the related SCMI commands. Writes to different attributes may
> + interleave and no atomicity across multiple files is guaranteed.
> + In case of concurrent writes to the same attribute, the last
> + writer wins.
> + Read operations may observe state that has been already modified
> + and it is stale.
> + Userspace is responsible for coordinating access if stronger
> + consistency or serialization is required and this filesystem
> + provides a generation counter to aid in the detection of sudden
> + configuration changes.
> +
> +What: /sys/fs/arm_telemetry/tlm_<N>/all_des_enable
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Description: A boolean WO entry to enable all the discovered Data Events for
> + SCMI instance <N>.
> +Users: Any userspace telemetry tool
> +
> +What: /sys/fs/arm_telemetry/tlm_<N>/all_tstamp_des_enable
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Description: A boolean WO entry to enable timestamps for all the discovered
> + Data Events for SCMI instance <N>. (when available)
> +Users: Any userspace telemetry tool
> +
> +What: /sys/fs/arm_telemetry/tlm_<N>/available_update_intervals_ms
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Description: A RO entry that returns a space separated list of tuples of
> + values, separated by a coma, each one representing a
> + configurable update interval for SCMI instance <N>.
> + Each tuple describes a possible update interval using the
> + format <secs>,<exp> where the final represented interval is
> + calculated as: <secs> * 10 ^ <exp>
> + An example of list of tuples that can be read from this entry:
> + 3,0 4,-1 75,-2 300,-3 1,1 5,3 222,-7
> +Users: Any userspace telemetry tool
> +
> +What: /sys/fs/arm_telemetry/tlm_<N>/by-components/
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Description: A subdirectory that exposes an alternative topological view of
> + the same set of discovered DEs that can be already found under
> + the des/ branch.
> + This topology subtree is built following this structure:
> + by-components/
> + ├── <COMPO_TYPE_STR>
> + │ ├── <COMPO_ISTANCE_ID>
> + │ │ ├── <DE_UNIT_TYPE_STR>
> + │ │ │ └── <DE_INSTANCE_ID>
> + │ │ │ └── 0x<DE_ID>[<DE_NAME>] -> ../../../../../des/0x<DE_ID>
> +
> + The leaves are actual symlinks to an existing des/0x<DE_ID>
> + subdirectory, while the naming of the subdirectories composing
> + the inner nodes of the subtree are derived from the DataEvent
> + Descriptor in SCMI v4.0 3.12.4.6.
> +Users: Any userspace telemetry tool
> +
> +What: /sys/fs/arm_telemetry/tlm_<N>/control
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Description: An RW entry that can be used to discover, configure and retrieve
> + Telemetry data using the alternative binary interface based on
> + ioctls which is documented in include/uapi/linux/scmi.h
> +Users: Any userspace telemetry tool
> +
> +What: /sys/fs/arm_telemetry/tlm_<N>/current_update_intervals_ms
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Description: An RW entry that can be used to get or set the platform update
> + interval for SCMI instance <N>.
> + On read the returned tuple represents the current update
> + interval using the format <secs>,<exp> where the final
> + represented interval is calculated as: <secs> * 10 ^ <exp>
> + On write the accepted format is the same as on read <secs>,<exp>
> + but, optionally, the second element of the tuple can be omitted
> + and in that case the assumed value for the exponent will default
> + to -3, i.e. milliseconds.
> +Users: Any userspace telemetry tool
> +
> +What: /sys/fs/arm_telemetry/tlm_<N>/de_implementation_version
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Description: A RO entry that returns a string representing the 128bit UUID
> + that uniquely identifies the set of SCMI Telemetry Data Events
> + and their semantic for SCMI instance <N>.
> + This is compliant with the DE_IMPLEMENTATION_REVISION described
> + in SCMI v4.0 Telemetry 3.12.4.3.
> +Users: Any userspace telemetry tool
> +
> +What: /sys/fs/arm_telemetry/tlm_<N>/des_bulk_read
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Description: A RO entry that returns a multi-line string containing all the
> + the DEs enabled for SCMI instance <N>, one-per-line, formatted
> + as: <DE_ID> <TIMESTAMP> <DATA_VALUE>
> + These DEs readings represent the last value updated by the
> + platform following the configured update interval: on the
> + backend they will have been collected transparently in a number
> + of different ways: on-demand SHMTI lookup, notifications,
> + fastchannels. Data consistency is guaranteed by the underlying
> + SCMI synchronization mechanisms.
> + Any disabled or unavailable DE is simply NOT included.
> +Users: Any userspace telemetry tool
> +
> +What: /sys/fs/arm_telemetry/tlm_<N>/des_single_sample_read
> +Date: Nov 2026
> +KernelVersion: 7.3
> +Contact: cristian.marussi@arm.com
> +Description: A RO entry that returns a multi-line string containing all the
> + the DEs enabled for SCMI instance <N>, one-per-line, formmatted
formatted
> + as: <DE_ID> <TIMESTAMP> <DATA_VALUE>
> + These DEs readings are generated by triggering an explicit and
> + immediate platform update using single sample asynchronous
> + collect methods.
> + Any disabled or unavailable DE is simply NOT included.
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 20/31] fs/stlmfs: Document ARM SCMI Telemetry filesystem
From: Randy Dunlap @ 2026-06-13 5:27 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc
Cc: sudeep.holla, james.quinlan, f.fainelli, vincent.guittot,
etienne.carriere, peng.fan, michal.simek, d-gole, jic23,
elif.topuz, lukasz.luba, philip.radford, brauner,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team, Jonathan Corbet, Shuah Khan
In-Reply-To: <20260612223802.1337232-21-cristian.marussi@arm.com>
On 6/12/26 3:37 PM, Cristian Marussi wrote:
> +Design
> +======
> +
> +STLMFS is a pseudo filesystem used to expose ARM SCMI Telemetry data
> +discovered dynamically at run-time via SCMI.
> +
> +Inodes are all dynamically created at mount-time from a dedicated
> +kmem_cache based on the gathered available SCMI Telemetry information.
> +
> +Since inodes represent the discovered Telemetry entities, which in turn are
> +statically defined at the platform level and immutable throughout the same
> +session (boot), allocated inodes are freed only at unmount-time and the
> +user is not allowed to delete or create any kind of file within the STLMFS
> +filesystem after mount has completed.
> +
> +A single instance of STLMFS is created at the filesystem level, using
> +get_tree_single(), given that the same SCMI backend entities will be
> +involved no matter how many times you mount it.
> +
> +STLMFS configurations gets appplied by issuing the related SCMI commands to
get applied
or better:
are applied
> +the backend SCMI platform server: for such reason any configuration applied
> +by this FS interface will survive the unmount or the unload of the module, but
> +not a reboot.
--
~Randy
^ permalink raw reply
* Re: [PATCH v3] mm/mempool: Untangle CONFIG_SLUB_DEBUG_ON abuse and switch to static key
From: Harry Yoo @ 2026-06-13 4:55 UTC (permalink / raw)
To: lirongqing, Jonathan Corbet, Shuah Khan, Vlastimil Babka,
Andrew Morton, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, linux-doc, linux-kernel, linux-mm
Cc: Matthew Wilcox, Usama Arif
In-Reply-To: <20260604110318.2089-1-lirongqing@baidu.com>
[-- Attachment #1.1: Type: text/plain, Size: 1334 bytes --]
On 6/4/26 8:03 PM, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> The mempool subsystem historically wrapped its debugging logic inside an
> merely defines compile-time defaults for SLUB and caused two flaws:
>
> 1. On production kernels where CONFIG_SLUB_DEBUG=y but
> CONFIG_SLUB_DEBUG_ON=n, mempool debugging was completely compiled out
> at compile time.
> 2. On kernels with CONFIG_SLUB_DEBUG_ON=y, mempool debugging stayed active
> even if a user explicitly disabled slub debugging at boot time.
>
> Clean up this mess by removing the #ifdef and switching to a runtime static
> key (mempool_debug_enabled), allowing mempool debugging to be toggled
> cleanly via its own boot parameter.
>
> Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Harry Yoo <harry@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Hao Li <hao.li@linux.dev>
> Cc: Christoph Lameter <cl@gentwo.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Usama Arif <usama.arif@linux.dev>
> ---
Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org>
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
From: Fan Wu @ 2026-06-13 2:54 UTC (permalink / raw)
To: Yan Zhu
Cc: alexs, si.yanteng, corbet, mic, dzm91, skhan, gnoack, linux-doc,
linux-security-module
In-Reply-To: <tencent_DADDE291CA580302EB7BB40B83A552D6F006@qq.com>
On Fri, Jun 12, 2026 at 8:59 AM Yan Zhu <zhuyan2015@qq.com> wrote:
>
> Translate Documentation/admin-guide/LSM/ipe.rst into Chinese.
>
> Update the translation through commit d7ba853c0e47
> ("ipe: Update documentation for script enforcement")
>
> Assisted-by: Claude:deepseek-4-pro
> Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
> ---
Have you tried to refine the AI translation? IMO some are really bad translated.
Also how does the doc translation project work? I do notice there is
another IPE design doc translation,
https://docs.kernel.org/next/translations/zh_CN/security/ipe.html
which has a wrong "original link".
-Fan
^ permalink raw reply
* Re: [PATCH net-next v2] docs: networking: add guidance on what to push via extack
From: patchwork-bot+netdevbpf @ 2026-06-13 1:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, joe,
corbet, skhan, linux-doc
In-Reply-To: <20260611172149.1877704-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 11 Jun 2026 10:21:49 -0700 you wrote:
> Every now and then someone tries to duplicated extack
> messages to dmesg. Document our guidance against this.
> Also indicate that system level faults should continue
> to go to system logs. The high level thinking is to try
> to distinguish between what's important to the user vs
> system admin.
>
> [...]
Here is the summary with links:
- [net-next,v2] docs: networking: add guidance on what to push via extack
https://git.kernel.org/netdev/net-next/c/96fbe161e402
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFC PATCH 2/2] kasan: hw_tags: Add boot option to elide free time poisoning
From: Isaac Manjarres @ 2026-06-13 0:23 UTC (permalink / raw)
To: Dev Jain
Cc: ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will,
catalin.marinas
In-Reply-To: <20260612044425.763060-3-dev.jain@arm.com>
On Fri, Jun 12, 2026 at 04:44:24AM +0000, Dev Jain wrote:
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index fc9169a547662..4fa8abb312faa 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> #ifdef CONFIG_KASAN_GENERIC
> @@ -478,6 +489,16 @@ static inline u8 kasan_random_tag(void) { return 0; }
>
> static inline void kasan_poison(const void *addr, size_t size, u8 value, bool init)
> {
> + if (kasan_tag_only_on_alloc_enabled()) {
> + if ((value != KASAN_SLAB_REDZONE) && (value != KASAN_PAGE_REDZONE)) {
> + if (init)
> + memset((void *)kasan_reset_tag(addr), 0, size);
> + return;
> + }
> + }
> +
> + value |= 0xF0;
> +
I wonder if it would make more sense to have this as:
if (kasan_tag_only_on_alloc_enabled() && (value == KASAN_SLAB_FREE ||
value == KASAN_PAGE_FREE)) {
if (init)
memset((void *)kasan_reset_tag(addr), 0, size);
return;
}
That seems a bit clearer to me as to what it is that you're doing, and
also makes it so that you don't have to do any bit manipulation
on the value when you're filling in the redzones.
Thanks,
Isaac
^ permalink raw reply
* Re: [PATCH v3] mm/mempool: Untangle CONFIG_SLUB_DEBUG_ON abuse and switch to static key
From: SeongJae Park @ 2026-06-13 0:22 UTC (permalink / raw)
To: lirongqing
Cc: SeongJae Park, Jonathan Corbet, Shuah Khan, Vlastimil Babka,
Harry Yoo, Andrew Morton, Hao Li, Christoph Lameter,
David Rientjes, Roman Gushchin, linux-doc, linux-kernel, linux-mm,
Matthew Wilcox, Usama Arif
In-Reply-To: <20260604110318.2089-1-lirongqing@baidu.com>
On Thu, 4 Jun 2026 19:03:18 +0800 lirongqing <lirongqing@baidu.com> wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> The mempool subsystem historically wrapped its debugging logic inside an
> merely defines compile-time defaults for SLUB and caused two flaws:
>
> 1. On production kernels where CONFIG_SLUB_DEBUG=y but
> CONFIG_SLUB_DEBUG_ON=n, mempool debugging was completely compiled out
> at compile time.
> 2. On kernels with CONFIG_SLUB_DEBUG_ON=y, mempool debugging stayed active
> even if a user explicitly disabled slub debugging at boot time.
>
> Clean up this mess by removing the #ifdef and switching to a runtime static
> key (mempool_debug_enabled), allowing mempool debugging to be toggled
> cleanly via its own boot parameter.
Makes sense to me.
>
> Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Harry Yoo <harry@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Hao Li <hao.li@linux.dev>
> Cc: Christoph Lameter <cl@gentwo.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Usama Arif <usama.arif@linux.dev>
Reviewed-by: SeongJae Park <sj@kernel.org>
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Isaac Manjarres @ 2026-06-13 0:16 UTC (permalink / raw)
To: Dev Jain
Cc: ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will,
catalin.marinas
In-Reply-To: <20260612044425.763060-1-dev.jain@arm.com>
On Fri, Jun 12, 2026 at 04:44:22AM +0000, Dev Jain wrote:
> Introduce a boot option to tag only at allocation time of the objects. This
> reduces KASAN MTE overhead, the tradeoff being reduced ability of
> catching bugs.
>
> Now, when a memory object will be freed, it will retain the random tag it
> had at allocation time. This compromises on catching UAF bugs, till the
> time the object is not reallocated, at which point it will have a new
> random tag.
>
> Hence, not catching "use-after-free-before-reallocation" and not catching
> "double-free" will be the compromise for reduced KASAN overhead.
>
> This is an RFC because we are not clear about the performance benefit.
>
> Android folks, please help with testing!
>
> ---
> Applies on Linus master (9716c086c8e8).
>
> Dev Jain (2):
> kasan: hw_tags: Use KASAN_PAGE_REDZONE for vmalloc redzoning
> kasan: hw_tags: Add boot option to elide free time poisoning
>
> Documentation/dev-tools/kasan.rst | 4 +++
> mm/kasan/hw_tags.c | 45 +++++++++++++++++++++++++++++--
> mm/kasan/kasan.h | 23 +++++++++++++++-
> 3 files changed, 69 insertions(+), 3 deletions(-)
>
> --
> 2.43.0
I tested out this series on one of our devices that has MTE support,
and didn't see any functional issues.
One thing I did notice though, and it's independent of this patch, is
that the vmalloc_oob is failing, but that happens even if these patches
aren't present.
Thanks,
Isaac
^ permalink raw reply
* Re: [PATCH] Docs/mm/damon/design: fix a typo in the Address Unit section
From: SeongJae Park @ 2026-06-13 0:08 UTC (permalink / raw)
To: Shardul Deshpande
Cc: SeongJae Park, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jonathan Corbet, Shuah Khan,
damon, linux-mm, linux-doc, linux-kernel
In-Reply-To: <20260612154054.720363-1-iamsharduld@gmail.com>
On Fri, 12 Jun 2026 21:10:54 +0530 Shardul Deshpande <iamsharduld@gmail.com> wrote:
> The "Address Unit" section misspelled the C type that the DAMON core
> layer uses for monitoring target address ranges. Correct it to read
> "unsigned long".
Thank you! I found you sent another patch having this change following
Andrew's comment. So I reviewed there.
[1] https://lore.kernel.org/20260613000715.791-1-sj@kernel.org
Thanks,
SJ
[...]
^ permalink raw reply
* [robh:for-next 42/47] htmldocs: Documentation/devicetree/kernel-api:11: ./drivers/of/base.c:2134: WARNING: Inline emphasis start-string without end-string. [docutils]
From: kernel test robot @ 2026-06-12 23:59 UTC (permalink / raw)
To: Charan Teja Kalla
Cc: oe-kbuild-all, Rob Herring (Arm), Vijayanand Jitta, linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
head: 030e2f5b9260c29ce85c21c004714742fa9f8d55
commit: f71f07bee9b56b94f7828cf3082ea19ec590de36 [42/47] of: Factor arguments passed to of_map_id() into a struct
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/20260613/202606130111.ldC96rqf-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/202606130111.ldC96rqf-lkp@intel.com/
All warnings (new ones prefixed by >>):
int kref_put_mutex (struct kref *kref, void (*release)(struct kref *kref), struct mutex *mutex) __cond_acquires(true# mutex)
------------------------------------------------------------------------------------------------^
Documentation/core-api/kref:328: ./include/linux/kref.h:94: WARNING: Invalid C declaration: Expected end of definition. [error at 92]
int kref_put_lock (struct kref *kref, void (*release)(struct kref *kref), spinlock_t *lock) __cond_acquires(true# lock)
--------------------------------------------------------------------------------------------^
>> Documentation/devicetree/kernel-api:11: ./drivers/of/base.c:2134: WARNING: Inline emphasis start-string without end-string. [docutils]
Documentation/devicetree/kernel-api:11: ./drivers/of/base.c:2260: WARNING: Inline emphasis start-string without end-string. [docutils]
Documentation/driver-api/basics:42: ./kernel/time/time.c:370: WARNING: Duplicate C declaration, also defined at driver-api/basics:436.
Declaration is '.. c:function:: unsigned int jiffies_to_msecs (const unsigned long j)'. [duplicate_declaration.c]
Documentation/driver-api/basics:42: ./kernel/time/time.c:393: WARNING: Duplicate C declaration, also defined at driver-api/basics:453.
Declaration is '.. c:function:: unsigned int jiffies_to_usecs (const unsigned long j)'. [duplicate_declaration.c]
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] kdoc: xforms: ignore special static/inline macros
From: Randy Dunlap @ 2026-06-12 23:44 UTC (permalink / raw)
To: linux-doc
Cc: Randy Dunlap, Jonathan Corbet, Shuah Khan, Mauro Carvalho Chehab,
Harry Wentland, Alex Hung, Ivan Lipski, Dan Wheeler, Alex Deucher,
Christian König, amd-gfx
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c contains 7 (for
now) functions that use STATIC_IFN_KUNIT or INLINE_IFN_KUNIT macros for
function qualifiers (static or not, inline or not).
These cause parse warnings from kernel-doc:
Invalid C declaration: Expected identifier in nested name, got keyword:
struct [error at 29]
STATIC_IFN_KUNIT const struct drm_color_lut * __extract_blob_lut (const
struct drm_property_blob *blob, uint32_t *size)
Handle these in kernel-doc to prevent multiple warnings.
Fixes: 647d1fd04652 ("drm/amd/display: Add KUnit test for color helpers")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
v2: drop an unsubmitted patch so that this one applies with no problem
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: amd-gfx@lists.freedesktop.org
tools/lib/python/kdoc/xforms_lists.py | 2 ++
1 file changed, 2 insertions(+)
--- linext-2026-0610.orig/tools/lib/python/kdoc/xforms_lists.py
+++ linext-2026-0610/tools/lib/python/kdoc/xforms_lists.py
@@ -102,6 +102,8 @@ class CTransforms:
(CMatch("__no_context_analysis"), ""),
(CMatch("__attribute_const__"), ""),
(CMatch("__attribute__"), ""),
+ (CMatch("STATIC_IFN_KUNIT"), ""),
+ (CMatch("INLINE_IFN_KUNIT"), ""),
#
# HACK: this is similar to process_export() hack. It is meant to
^ permalink raw reply
* Re: [PATCH] kdoc: xforms: ignore special static/inline macros
From: Randy Dunlap @ 2026-06-12 23:34 UTC (permalink / raw)
To: Jonathan Corbet, linux-doc
Cc: Shuah Khan, Mauro Carvalho Chehab, Harry Wentland, Alex Hung,
Ivan Lipski, Dan Wheeler, Alex Deucher, Christian König,
amd-gfx
In-Reply-To: <87ldcj5z9i.fsf@trenco.lwn.net>
On 6/12/26 12:34 PM, Jonathan Corbet wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c contains 7 (for
>> now) functions that use STATIC_IFN_KUNIT or INLINE_IFN_KUNIT macros for
>> function qualifiers (static or not, inline or not).
>>
>> These cause parse warnings from kernel-doc:
>> Invalid C declaration: Expected identifier in nested name, got keyword:
>> struct [error at 29]
>> STATIC_IFN_KUNIT const struct drm_color_lut * __extract_blob_lut (const
>> struct drm_property_blob *blob, uint32_t *size)
>>
>> Handle these in kernel-doc to prevent multiple warnings.
>>
>> Fixes: 647d1fd04652 ("drm/amd/display: Add KUnit test for color helpers")
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> ---
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Cc: Shuah Khan <skhan@linuxfoundation.org>
>> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
>> Cc: Harry Wentland <harry.wentland@amd.com>
>> Cc: Alex Hung <alex.hung@amd.com>
>> Cc: Ivan Lipski <ivan.lipski@amd.com>
>> Cc: Dan Wheeler <daniel.wheeler@amd.com>
>> Cc: Alex Deucher <alexander.deucher@amd.com>
>> Cc: Christian König <christian.koenig@amd.com>
>> Cc: amd-gfx@lists.freedesktop.org
>>
>> tools/lib/python/kdoc/xforms_lists.py | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> --- linux-next-20260601.orig/tools/lib/python/kdoc/xforms_lists.py
>> +++ linux-next-20260601/tools/lib/python/kdoc/xforms_lists.py
>> @@ -104,6 +104,8 @@ class CTransforms:
>> (CMatch("__context_unsafe"), ""),
>> (CMatch("__attribute_const__"), ""),
>> (CMatch("__attribute__"), ""),
>> + (CMatch("STATIC_IFN_KUNIT"), ""),
>> + (CMatch("INLINE_IFN_KUNIT"), ""),
>
> So I can't get this one to apply; which tree did you patch here?
Ah. My quilt patches. There is one there that I haven't submitted.
I'll drop it and resubmit the patch.
thanks.
--
~Randy
^ 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