* [PATCH mm-unstable v17 01/14] mm/khugepaged: generalize hugepage_vma_revalidate for mTHP support
From: Nico Pache @ 2026-05-11 18:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-mm, linux-trace-kernel
Cc: aarcange, akpm, anshuman.khandual, apopple, baohua, baolin.wang,
byungchul, catalin.marinas, cl, corbet, dave.hansen, david,
dev.jain, gourry, hannes, hughd, jack, jackmanb, jannh, jglisse,
joshua.hahnjy, kas, lance.yang, liam, ljs, mathieu.desnoyers,
matthew.brost, mhiramat, mhocko, npache, peterx, pfalcato,
rakie.kim, raquini, rdunlap, richard.weiyang, rientjes, rostedt,
rppt, ryan.roberts, shivankg, sunnanyong, surenb,
thomas.hellstrom, tiwai, usamaarif642, vbabka, vishal.moola,
wangkefeng.wang, will, willy, yang, ying.huang, ziy, zokeefe,
Usama Arif
In-Reply-To: <20260511185817.686831-1-npache@redhat.com>
For khugepaged to support different mTHP orders, we must generalize this
to check if the PMD is not shared by another VMA and that the order is
enabled.
No functional change in this patch. Also correct a comment about the
functionality of the revalidation and fix a double space issues.
Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
Reviewed-by: Lance Yang <lance.yang@linux.dev>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Zi Yan <ziy@nvidia.com>
Acked-by: Usama Arif <usama.arif@linux.dev>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Co-developed-by: Dev Jain <dev.jain@arm.com>
Signed-off-by: Dev Jain <dev.jain@arm.com>
Signed-off-by: Nico Pache <npache@redhat.com>
---
mm/khugepaged.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 28a843f30b32..979885694351 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -902,12 +902,13 @@ static int collapse_find_target_node(struct collapse_control *cc)
/*
* If mmap_lock temporarily dropped, revalidate vma
- * before taking mmap_lock.
+ * after taking the mmap_lock again.
* Returns enum scan_result value.
*/
static enum scan_result hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address,
- bool expect_anon, struct vm_area_struct **vmap, struct collapse_control *cc)
+ bool expect_anon, struct vm_area_struct **vmap,
+ struct collapse_control *cc, unsigned int order)
{
struct vm_area_struct *vma;
enum tva_type type = cc->is_khugepaged ? TVA_KHUGEPAGED :
@@ -920,15 +921,16 @@ static enum scan_result hugepage_vma_revalidate(struct mm_struct *mm, unsigned l
if (!vma)
return SCAN_VMA_NULL;
+ /* Always check the PMD order to ensure its not shared by another VMA */
if (!thp_vma_suitable_order(vma, address, PMD_ORDER))
return SCAN_ADDRESS_RANGE;
- if (!thp_vma_allowable_order(vma, vma->vm_flags, type, PMD_ORDER))
+ if (!thp_vma_allowable_orders(vma, vma->vm_flags, type, BIT(order)))
return SCAN_VMA_CHECK;
/*
* Anon VMA expected, the address may be unmapped then
* remapped to file after khugepaged reaquired the mmap_lock.
*
- * thp_vma_allowable_order may return true for qualified file
+ * thp_vma_allowable_orders may return true for qualified file
* vmas.
*/
if (expect_anon && (!(*vmap)->anon_vma || !vma_is_anonymous(*vmap)))
@@ -1121,7 +1123,8 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
goto out_nolock;
mmap_read_lock(mm);
- result = hugepage_vma_revalidate(mm, address, true, &vma, cc);
+ result = hugepage_vma_revalidate(mm, address, true, &vma, cc,
+ HPAGE_PMD_ORDER);
if (result != SCAN_SUCCEED) {
mmap_read_unlock(mm);
goto out_nolock;
@@ -1155,7 +1158,8 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
* mmap_lock.
*/
mmap_write_lock(mm);
- result = hugepage_vma_revalidate(mm, address, true, &vma, cc);
+ result = hugepage_vma_revalidate(mm, address, true, &vma, cc,
+ HPAGE_PMD_ORDER);
if (result != SCAN_SUCCEED)
goto out_up_write;
/* check if the pmd is still valid */
@@ -2858,8 +2862,8 @@ int madvise_collapse(struct vm_area_struct *vma, unsigned long start,
mmap_unlocked = false;
*lock_dropped = true;
result = hugepage_vma_revalidate(mm, addr, false, &vma,
- cc);
- if (result != SCAN_SUCCEED) {
+ cc, HPAGE_PMD_ORDER);
+ if (result != SCAN_SUCCEED) {
last_fail = result;
goto out_nolock;
}
--
2.54.0
^ permalink raw reply related
* [PATCH mm-unstable v17 00/14] khugepaged: mTHP support
From: Nico Pache @ 2026-05-11 18:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-mm, linux-trace-kernel
Cc: aarcange, akpm, anshuman.khandual, apopple, baohua, baolin.wang,
byungchul, catalin.marinas, cl, corbet, dave.hansen, david,
dev.jain, gourry, hannes, hughd, jack, jackmanb, jannh, jglisse,
joshua.hahnjy, kas, lance.yang, liam, ljs, mathieu.desnoyers,
matthew.brost, mhiramat, mhocko, npache, peterx, pfalcato,
rakie.kim, raquini, rdunlap, richard.weiyang, rientjes, rostedt,
rppt, ryan.roberts, shivankg, sunnanyong, surenb,
thomas.hellstrom, tiwai, usamaarif642, vbabka, vishal.moola,
wangkefeng.wang, will, willy, yang, ying.huang, ziy, zokeefe
The following series provides khugepaged with the capability to collapse
anonymous memory regions to mTHPs.
To achieve this we generalize the khugepaged functions to no longer depend
on PMD_ORDER. Then during the PMD scan, we use a bitmap to track individual
pages that are occupied (!none/zero). After the PMD scan is done, we use
the bitmap to find the optimal mTHP sizes for the PMD range. The
restriction on max_ptes_none is removed during the scan, to make sure we
account for the whole PMD range in the bitmap. When no mTHP size is
enabled, the legacy behavior of khugepaged is maintained.
We currently only support max_ptes_none values of 0 or HPAGE_PMD_NR - 1
(ie 511). If any other value is specified, the kernel will emit a warning
and no mTHP collapse will be attempted. If a mTHP collapse is attempted,
but contains swapped out, or shared pages, we don't perform the collapse.
It is now also possible to collapse to mTHPs without requiring the PMD THP
size to be enabled. These limitations are to prevent collapse "creep"
behavior. This prevents constantly promoting mTHPs to the next available
size, which would occur because a collapse introduces more non-zero pages
that would satisfy the promotion condition on subsequent scans.
Patch 1-2: Generalize hugepage_vma_revalidate and alloc_charge_folio
for arbitrary orders.
Patch 3: Rework max_ptes_* handling into helper functions
Patch 4: Generalize __collapse_huge_page_* for mTHP support
Patch 5: Require collapse_huge_page to enter/exit with the lock dropped
Patch 6: Generalize collapse_huge_page for mTHP collapse
Patch 7: Skip collapsing mTHP to smaller orders
Patch 8-9: Add per-order mTHP statistics and tracepoints
Patch 10: Introduce collapse_allowable_orders helper function
Patch 11-13: Introduce bitmap and mTHP collapse support, fully enabled
Patch 14: Documentation
Testing:
- Built for x86_64, aarch64, ppc64le, and s390x
- ran all arches on test suites provided by the kernel-tests project
- internal testing suites: functional testing and performance testing
- selftests mm
- I created a test script that I used to push khugepaged to its limits
while monitoring a number of stats and tracepoints. The code is
available here[1] (Run in legacy mode for these changes and set mthp
sizes to inherit)
The summary from my testings was that there was no significant
regression noticed through this test. In some cases my changes had
better collapse latencies, and was able to scan more pages in the same
amount of time/work, but for the most part the results were consistent.
- redis testing. I did some testing with these changes along with my defer
changes (see followup [2] post for more details). We've decided to get
the mTHP changes merged first before attempting the defer series.
- some basic testing on 64k page size.
- lots of general use.
V17 Changes:
- Added Acks/RB
- New patch(5): split the mmap_read_unlock() locking contract change out of
"generalize collapse_huge_page" into its own patch; add a comment
documenting the enter/exit-with-lock-dropped contract (Usama, David)
- [patch 03] Add const to max_ptes_none/shared/swap variables; improve the
three helper docstrings; replace the paragraphs with inline comments;
note that sysctl values are now snapshotted once per scan (Usama, David)
- [patch 04] Add SCAN_INVALID_PTES_NONE result code and return it instead
of SCAN_FAIL when collapse_max_ptes_none() returns -EINVAL (Usama);
snapshot khugepaged_max_ptes_none into a local variable to fix race on
the two comparisons (Usama); clean up mTHP docstring paragraphs into
inline comments; fix commit message wording (David)
- [patch 06] Remove /* PMD collapse */ and /* mTHP collapse */ comments
(David); move const declarations to top of variable list (David); add
comment explaining that map_anon_folio_pte_nopf() calls set_ptes under
pmd_ptl and is safe because PMD is expected to be none (Usama)
- [patch 08] Shorten sysfs counter documentation for
collapse_exceed_swap/shared_pte to concise one-liners; trim
collapse_exceed_none_pte description; fix "dont" → "do not" (David)
- [patch 10] Keep vm_flags parameter in khugepaged_enter_vma() and
collapse_allowable_orders() rather than dropping it and reading
vma->vm_flags internally; pass vm_flags explicitly at all three
collapse_allowable_orders() call sites (David, sashskio)
- [patch 11] Fix MTHP_STACK_SIZE: was exponential (~128); correct formula
is (height + 1) for a DFS on a binary tree rewrite comment to explain
the DFS sizing (sashskio)
- [patch 12] Replace SCAN_PAGE_LRU with SCAN_PAGE_LAZYFREE in the
"goto next_order" early-bail cases; non-LRU page failures cannot be
recovered at any order and belong in the default (return) path
- [patch 13] Use tva_flags == TVA_KHUGEPAGED (strict equality) instead of
tva_flags & TVA_KHUGEPAGED; flatten nested if into single condition;
retain vm_flags parameter; pass vm_flags to collapse_allowable_orders()
V16: https://lore.kernel.org/all/20260419185750.260784-1-npache@redhat.com
V15: https://lore.kernel.org/all/20260226031741.230674-1-npache@redhat.com
V14: https://lore.kernel.org/all/20260122192841.128719-1-npache@redhat.com
V13: https://lore.kernel.org/all/20251201174627.23295-1-npache@redhat.com
V12: https://lore.kernel.org/all/20251022183717.70829-1-npache@redhat.com
V11: https://lore.kernel.org/all/20250912032810.197475-1-npache@redhat.com
V10: https://lore.kernel.org/all/20250819134205.622806-1-npache@redhat.com
V9 : https://lore.kernel.org/all/20250714003207.113275-1-npache@redhat.com
V8 : https://lore.kernel.org/all/20250702055742.102808-1-npache@redhat.com
V7 : https://lore.kernel.org/all/20250515032226.128900-1-npache@redhat.com
V6 : https://lore.kernel.org/all/20250515030312.125567-1-npache@redhat.com
V5 : https://lore.kernel.org/all/20250428181218.85925-1-npache@redhat.com
V4 : https://lore.kernel.org/all/20250417000238.74567-1-npache@redhat.com
V3 : https://lore.kernel.org/all/20250414220557.35388-1-npache@redhat.com
V2 : https://lore.kernel.org/all/20250211003028.213461-1-npache@redhat.com
V1 : https://lore.kernel.org/all/20250108233128.14484-1-npache@redhat.com
Baolin Wang (1):
mm/khugepaged: run khugepaged for all orders
Dev Jain (1):
mm/khugepaged: generalize alloc_charge_folio()
Nico Pache (12):
mm/khugepaged: generalize hugepage_vma_revalidate for mTHP support
mm/khugepaged: rework max_ptes_* handling with helper functions
mm/khugepaged: generalize __collapse_huge_page_* for mTHP support
mm/khugepaged: require collapse_huge_page to enter/exit with the lock
dropped
mm/khugepaged: generalize collapse_huge_page for mTHP collapse
mm/khugepaged: skip collapsing mTHP to smaller orders
mm/khugepaged: add per-order mTHP collapse failure statistics
mm/khugepaged: improve tracepoints for mTHP orders
mm/khugepaged: introduce collapse_allowable_orders helper function
mm/khugepaged: Introduce mTHP collapse support
mm/khugepaged: avoid unnecessary mTHP collapse attempts
Documentation: mm: update the admin guide for mTHP collapse
Documentation/admin-guide/mm/transhuge.rst | 71 ++-
include/linux/huge_mm.h | 5 +
include/trace/events/huge_memory.h | 37 +-
mm/huge_memory.c | 11 +
mm/khugepaged.c | 625 ++++++++++++++++-----
5 files changed, 579 insertions(+), 170 deletions(-)
base-commit: e9dd96806dbc2d50a66770b6a86962bd5d601153
--
2.54.0
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Jonathan Corbet @ 2026-05-11 18:39 UTC (permalink / raw)
To: Willy Tarreau, Greg KH
Cc: Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <agIZ8zeg3m0xE3yL@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
>>
>> Looks great, thank you!
>>
>> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> Want me to take it through one of my trees now to get it to Linus this
>> week, or should it go through the documentation tree? Either is fine
>> with me.
>
> Yes, please take it as usual, it's simpler for me and it will likely
> allow it to be published ealier, which ultimately should help us
> faster ;-)
I can ship stuff Linusward quickly too... :) But it's fine if Greg
takes it, of course.
jon
^ permalink raw reply
* RE: [RFC net-next 0/4] devlink: Add boot-time defaults
From: Parav Pandit @ 2026-05-11 18:21 UTC (permalink / raw)
To: Mark Bloch, Jiri Pirko, Jakub Kicinski
Cc: Eric Dumazet, Paolo Abeni, Andrew Lunn, David S. Miller,
Jonathan Corbet, Shuah Khan, Simon Horman, Saeed Mahameed,
Leon Romanovsky, Tariq Toukan, Andrew Morton,
Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Christian Brauner, Petr Mladek, Peter Zijlstra (Intel),
Thomas Gleixner, Pawan Gupta, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, NBU-Contact-Li Rongqing (EXTERNAL),
Paul E. McKenney, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <580a774b-ba9e-4523-b43a-476f75dd5b12@nvidia.com>
> From: Mark Bloch <mbloch@nvidia.com>
> Sent: 10 May 2026 06:02 PM
>
[..]
> > I look at it from the perspective that from some CX generation,
> > switchdev mode should be default. So that is a device-based decision.
> > I believe as such it can optionally be permanenty configured (nv config)
> > on older device. Why not?
>
Because sometimes switchdev_inactive is needed and sometimes not.
Such knob is not device decision.
If it is placed in the device, orchestration needs to yet use additional vendor tool to configure in the device.
And that theoretical tool cannot even run yet because driver is not yet loaded.
That sort of defeats the purpose.
> This is a deployment policy decision, not a permanent property of the card.
+1
> The same adapter can be used in a regular host/RDMA setup or in a
> switchdev/offload setup. If we store this in NVM, that Linux switchdev policy
> follows the device across hosts, kernels and use cases, and can surprise the
> next deployment that just expects a normal NIC.
>
> I'll send another RFC v2 with support limited to:
> devlink=[...]:esw:mode:{ switchdev | switchdev_inactive | legacy }
> and let's see where we land with that.
>
This looks elegant to me as well covering all eswitch modes and still sw is in control.
^ permalink raw reply
* [PATCH net-next v2 9/9] Documentation: networking: add OPEN Alliance 10BASE-T1x MAC-PHY serial interface
From: Selvamani Rajagopal @ 2026-05-11 18:19 UTC (permalink / raw)
To: Piergiorgio Beruto, parthiban.veerasooran@microchip.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Added an API to support setting vendor specific MMS and
new APIs introduced to support hardware timestamp.
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
---
Documentation/networking/oa-tc6-framework.rst | 26 +++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/Documentation/networking/oa-tc6-framework.rst b/Documentation/networking/oa-tc6-framework.rst
index fe2aabde9..b0c220a54 100644
--- a/Documentation/networking/oa-tc6-framework.rst
+++ b/Documentation/networking/oa-tc6-framework.rst
@@ -153,6 +153,9 @@ OPEN Alliance TC6 Framework
- Forwards the received Ethernet frame from 10Base-T1x MAC-PHY to n/w
subsystem.
+- Update hardware timestamp in skb, when indicated by one of the three
+ timestamp capture registers through TSC fields of the header.
+
Data Transaction
~~~~~~~~~~~~~~~~
@@ -495,3 +498,26 @@ the MAC-PHY.
Zero align receive frame feature can be enabled to align all receive ethernet
frames data to start at the beginning of any receive data chunk payload with a
start word offset (SWO) of zero.
+
+.. c:function:: int oa_tc6_hwtstamp_ioctl(struct oa_tc6 *tc6, \
+ struct ifreq *rq, int cmd)
+Legacy ioctl interface for supporting hardware timestmp.
+
+frames data to start at the beginning of any receive data chunk payload with a
+
+.. c:function:: int oa_tc6_hwtstamp_set(struct oa_tc6 *tc6, \
+ struct kernel_hwtstamp_config *cfg)
+
+Interface to set hardware timestmp configuration through ndo_hwtstamp_set.
+This API is used by legacy ioctl interface as well.
+
+.. c:function:: void oa_tc6_hwtstamp_get(struct oa_tc6 *tc6, \
+ struct kernel_hwtstamp_config *cfg)
+
+Interface to get the hardware timestmp configuration through ndo_hwtstamp_get.
+This API is used by legacy ioctl interface as well.
+
+.. c:function:: void oa_tc6_set_vend1_mms(struct oa_tc6 *tc6, int mms)
+
+Interfaces that gives a vendor, an ability to map VEND1 MDIO device number to
+vendor specific MMS (Memory Map Selector)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Andrew Lunn @ 2026-05-11 18:18 UTC (permalink / raw)
To: Mathieu Poirier
Cc: tanmay.shah, Arnaud POULIQUEN, Beleswar Prasad Padhi,
Shenwei Wang, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Frank Li, Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Bartosz Golaszewski
In-Reply-To: <CANLsYkz8HpM_8eS7DjN_jmYs4T7P9xY0jYmdiAx5WO=_1zvFpQ@mail.gmail.com>
> Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
> GPIO controller. The remaining issue it about the best way to work
> out source and destination addresses between Linux and the remote
> processor. I'm running out of time for today but I'll return to this
> thread with a final analysis by the end of the week.
How many of the participants here will be in Minneapolis next week for
the Embedded Linux Conference? There is even a talk about this:
https://osselcna2026.sched.com/event/2JQpx/building-virtual-drivers-with-rpmsg-key-design-principles-challenges-trade-offs-beleswar-prasad-padhi-texas-instruments?iframe=yes&w=100%&sidebar=yes&bg=no
Maybe we can get together and decide on the final design after the
session.
Andrew
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-11 18:09 UTC (permalink / raw)
To: Michal Hocko
Cc: Breno Leitao, Andrew Morton, corbet, skhan, linux-doc,
linux-kernel, linux-kselftest, gregkh, akinobu.mita,
live-patching
In-Reply-To: <agINlnNN4ubZgyiN@tiehlicka>
On Mon, May 11, 2026 at 07:10:46PM +0200, Michal Hocko wrote:
>On Mon 11-05-26 12:45:36, Sasha Levin wrote:
>> Could you describe an existing infrastructure I can use here?
>
>I think it would help to CC maintainers of subsystems that provide
>kernel modification functionality. They will surely have a better
>insight than me.
>
>> Let's look at
>> this recent "Copy Fail" thing as an example.
>>
>> I can obviously build my own kernel and enroll my own key, but 99.9% of our
>> users won't be doing that.
>> Livepatching, or manually building a module that just injects a kprobe is out
>> of the question as we previously agreed.
>
>Onless I am mistaken you can enroll your own key through MOK. But you
>are right that this is an additional step. But the real question is
>whether this is a major road block for users of this specific feature.
The roadblock here is that then I need to start owning the kernel package: I
need to pull updates, rebuild, reinstall, etc. I lose the support I might be
getting from the distro vendor.
I see "users of this particular feature" as the other 99.9% of folks who don't
build their own kernel, who follow security updates from their distro vendor
and could apply the simple workaround that those vendors could now provide.
>> systemtap falls into the same bucket as building my own module.
>>
>> BPF doesn't help because bpf_override_return() requires the target to be on the
>> same within_error_injection_list() whitelist as fault injection, and the CVE
>> targets never are. Some of our fleet doesn't even have BPF enabled either, but
>> that's the smaller objection.
>>
>> I can't use fault injection because:
>>
>> a. It's almost never built in production/distro kernels, and I suspect this
>> won't change.
>> b. The functions I need are not whitelisted.
>> c. Even if (a) and (b) were addressed, fault injection would still need a
>> securityfs front-end, a cmdline parser, a module-unload notifier, a taint flag,
>> and audit on engage and disengage. By the time those land in fail_function and
>> tie into/refactor the fault injection code, the net diff is bigger than this
>> proposal.
>
>I cannot comment on fault injection imeplementation details of course
>but I have to say that the whitelist nature is something that makes its
>use very limited. Maybe this is a good opportunity to change the
>approach.
Possibly, but IMO the bigger hurdle is the refactoring we'll need to do so
seperate fail_function out of the fault injection umbrella.
One approach would be to abstract the kprobe logic out of fail_function into a
common lib that killswitch could also use, but from a brief look the benefit
will be minimal.
>> In my case I can remove the module, but not if I run a distro that shipped with
>> CONFIG_CRYPTO_USER_API_AEAD=y (like RHEL/SUSE).
>
>If you look at copy fail[2], IIRC algif_aead, esp[46] and rxrcp are all
>modules that could be blacklisted.
On some distros sure, on some others, not:
https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/raw/main/redhat/configs/common/generic/CONFIG_CRYPTO_USER_API_AEAD
Even if it is a module, what if I can't just unload it because I have something
that actually uses it?
Look at the ESP issue for example. I can mitigate it by simply doing:
echo "engage xfrm4_udp_encap_rcv 0" > /sys/kernel/security/killswitch/control
echo "engage xfrm6_udp_encap_rcv 0" > /sys/kernel/security/killswitch/control
which only kills ESP encapsulated in UDP. The remaining functionality will keep
working just fine.
>> I can use "initcall_blacklist=" hack and reboot, but as things stand today,
>> I'll need to be rebooting few times a day.
>
>with your just disable some functions in the kernel you might need to
>reboot even more. But more seriously...
>
>> Even if I'm okay with rebooting that often (and I really really would prefer
>> not to), this doesn't solve the issues of a larger fleet of servers that can't
>> just reboot that often.
>>
>> What am I missing?
>
>For one, you are missing more maintainers of code modification infrastructures.
Happy to add more, but I don't want to be too spammy. I'll add in the
livepatching ML and the fault injection maintainer (I couldn't find a list).
Please add any other folks/lists who you think might want to contribute to this
discussion.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-11 18:03 UTC (permalink / raw)
To: Greg KH
Cc: Leon Romanovsky, Jonathan Corbet, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <2026051124-afar-renewal-795c@gregkh>
On Mon, May 11, 2026 at 07:28:57PM +0200, Greg KH wrote:
> On Sat, May 09, 2026 at 11:47:54AM +0200, Willy Tarreau wrote:
> > The use of automated tools to find bugs in random locations of the kernel
> > induces a raise of security reports even if most of them should just be
> > reported as regular bugs. This patch is an attempt at drawing a line
> > between what qualifies as a security bug and what does not, hoping to
> > improve the situation and ease decision on the reporter's side.
> >
> > It defers the enumeration to a new file, threat-model.rst, that tries
> > to enumerate various classes of issues that are and are not security
> > bugs. This should permit to more easily update this file for various
> > subsystem-specific rules without having to revisit the security bug
> > reporting guide.
> >
> > Cc: Greg KH <gregkh@linuxfoundation.org>
> > Cc: Leon Romanovsky <leon@kernel.org>
> > Suggested-by: Leon Romanovsky <leon@kernel.org>
> > Suggested-by: Greg KH <gregkh@linuxfoundation.org>
> > Reviewed-by: Leon Romanovsky <leon@kernel.org>
> > Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/index.rst | 1 +
> > Documentation/process/security-bugs.rst | 38 +++-
> > Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++
> > 3 files changed, 274 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/process/threat-model.rst
>
> Looks great, thank you!
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Want me to take it through one of my trees now to get it to Linus this
> week, or should it go through the documentation tree? Either is fine
> with me.
Yes, please take it as usual, it's simpler for me and it will likely
allow it to be published ealier, which ultimately should help us
faster ;-)
Thanks!
Willy
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Mathieu Poirier @ 2026-05-11 17:58 UTC (permalink / raw)
To: tanmay.shah
Cc: Arnaud POULIQUEN, Beleswar Prasad Padhi, Shenwei Wang,
Andrew Lunn, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Frank Li, Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Bartosz Golaszewski
In-Reply-To: <08c815f5-ccbe-404a-95a1-a549aac8a55d@amd.com>
On Mon, 11 May 2026 at 10:47, Shah, Tanmay <tanmays@amd.com> wrote:
>
>
>
> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
> >
> >
> > On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
> >> Hi Tanmay,
> >>
> >> On 5/4/26 21:19, Shah, Tanmay wrote:
> >>>
> >>> Hello all,
> >>>
> >>> I have started reviewing this work as well.
> >>> Thanks Shenwei for this work.
> >>>
> >>> I have gone through only the current revision, and would like to provide
> >>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
> >>> Also, have some bindings related question.
> >>>
> >>> Please see below:
> >>>
> >>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
> >>>>
> >>>>
> >>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> >>>>> Hello Arnaud,
> >>>>>
> >>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
> >>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi Mathieu,
> >>>>>>>>
> >>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> >>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
> >>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
> >>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
> >>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
> >>>>>>>>>>> padhi@ti.com>; Linus
> >>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
> >>>>>>>>>>> <brgl@kernel.org>; Jonathan
> >>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
> >>>>>>>>>>> Krzysztof Kozlowski
> >>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
> >>>>>>>>>>> Andersson
> >>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> >>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
> >>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
> >>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
> >>>>>>>>>>> kernel@vger.kernel.org;
> >>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> >>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> >>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> >>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
> >>>>>>>>>>> linux-imx <linux-
> >>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> >>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
> >>>>>>>>>>> rpmsg GPIO driver
> >>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
> >>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
> >>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
> >>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
> >>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> >>>>>>>>>>>>> Jonathan
> >>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
> >>>>>>>>>>>>> Krzysztof
> >>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> >>>>>>>>>>>>> <conor+dt@kernel.org>;
> >>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> >>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>;
> >>>>>>>>>>>>> Sascha
> >>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
> >>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> >>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> >>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> >>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> >>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
> >>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
> >>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
> >>>>>>>>>>>>> <brgl@bgdev.pl>
> >>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
> >>>>>>>>>>>>> rpmsg
> >>>>>>>>>>>>> GPIO driver
> >>>>>>>>>>>>>>> struct virtio_gpio_response {
> >>>>>>>>>>>>>>> __u8 status;
> >>>>>>>>>>>>>>> __u8 value;
> >>>>>>>>>>>>>>> };
> >>>>>>>>>>>>>> It is the same message format. Please see the message
> >>>>>>>>>>>>>> definition
> >>>>>>>>>>>>> (GET_DIRECTION) below:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
> >>>>>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> >>>>>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
> >>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
> >>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
> >>>>>>>>>>>>> message format.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Some changes to the message format are necessary.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
> >>>>>>>>>>>> requests and
> >>>>>>>>>>> replies, and a second one for events.
> >>>>>>>>>>>> In contrast, rpmsg provides only a single communication
> >>>>>>>>>>>> channel, so a
> >>>>>>>>>>>> type field is required to distinguish between different kinds
> >>>>>>>>>>>> of messages.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Since rpmsg replies and events share the same message format,
> >>>>>>>>>>>> an additional
> >>>>>>>>>>> line is introduced to handle both cases.
> >>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
> >>>>>>>>>>>> field is added to
> >>>>>>>>>>> uniquely identify the target controller.
> >>>>>>>>>>>
> >>>>>>>>>>> I have commented on this before - RPMSG is already providing
> >>>>>>>>>>> multiplexing
> >>>>>>>>>>> capability by way of endpoints. There is no need for a port
> >>>>>>>>>>> field. One endpoint,
> >>>>>>>>>>> one GPIO controller.
> >>>>>>>>>>>
> >>>>>>>>>> You still need a way to let the remote side know which port the
> >>>>>>>>>> endpoint maps to, either
> >>>>>>>>>> by embedding the port information in the message (the current
> >>>>>>>>>> way), or by sending it
> >>>>>>>>>> separately.
> >>>>>>>>>>
> >>>>>>>>> An endpoint is created with every namespace request. There
> >>>>>>>>> should be
> >>>>>>>>> one namespace request for every GPIO controller, which yields a
> >>>>>>>>> unique
> >>>>>>>>> endpoint for each controller and eliminates the need for an extra
> >>>>>>>>> field to identify them.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Right, but this can still be done by just having one namespace
> >>>>>>>> request.
> >>>>>>>> We can create new endpoints bound to an existing namespace/
> >>>>>>>> channel by
> >>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
> >>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
> >>>>>>>> b73d-228295daaeec@ti.com/
> >>>>>>>>
> >>>>>>>
> >>>>>>> I will look at your suggestion (i.e link above) later this week or
> >>>>>>> next week.
> >>>>>>>
> >>>>>>>> My mental model looks like this for the complete picture:
> >>>>>>>>
> >>>>>>>> 1. namespace/channel#1 = rpmsg-io
> >>>>>>>> a. ept1 -> gpio-controller@1
> >>>>>>>> b. ept2 -> gpio-controller@2
> >>>>>>>>
> >>>
> >>> If my understanding of what gpio-controller is right, than this won't
> >>> work. We need one rpmsg channel per gpio-controller, and in most cases
> >>> there will be only one GPIO-controller on the remote side. If there are
> >>> multiple or multiple instances of same controller, than we need separate
> >>> channel name for that controller just like we would have separate device
> >>> on the Linux.
> >>
> >> As done in ehe rpmsg_tty driver it could be instantiated several times with
> >> the same channel/service name. This would imply a specific rpmsg to
> >> retreive
> >> the gpio controller index from the remote side.
> >>>
> >>>>>>>
> >>>>>>> I've asked for one endpoint per GPIO controller since the very
> >>>>>>> beginning. I don't yet have a strong opinion on whether to use one
> >>>>>>> namespace request per GPIO controller or a single request that spins
> >>>>>>> off multiple endpoints. I'll have to look at your link and
> >>>>>>> reflect on
> >>>>>>> that. Regardless of how we proceed on that front, multiplexing needs
> >>>>>>> to happen at the endpoint level rather than the packet level.
> >>>>>>> This is
> >>>>>>> the only way this work can move forward.
> >>>>>>>
> >>>>>>
> >>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
> >>>>>> created with every namespace request.”
> >>>>>>
> >>>>>> If the endpoint is created only on the Linux side, how do we match
> >>>>>> the Linux endpoint address with the local port field on the remote
> >>>>>> side?
> >>>>>
> >>>>>
> >>>>> Simply by sending a message to the remote containing the newly created
> >>>>> endpoint and the port idx. Note that is this done just one time, after
> >>>>> this
> >>>>> Linux need not have the port field in the message everytime its sending
> >>>>> a message.
> >>>>>
> >>>>>>
> >>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
> >>>>>> [addr], where [addr] corresponds to the GPIO controller address in
> >>>>>> the DT. This would:
> >>>>>
> >>>>>
> >>>>> You will face the same problem in this case also that you asked above:
> >>>>> "how do we match the Linux endpoint address with the local port field
> >>>>> on the remote side?"
> >>>>
> >>>> Sorry I probably introduced confusion here
> >>>> my sentence should be;
> >>>> With a multi-namespace approach, the namespace could be rpmsg-io-
> >>>> [port],
> >>>> where [port] corresponds to the GPIO controller port in the DT.
> >>>>
> >>>>
> >>>> For instance:
> >>>>
> >>>> rpmsg {
> >>>> rpmsg-io {
> >>>> #address-cells = <1>;
> >>>> #size-cells = <0>;
> >>>>
> >>>> gpio@25 {
> >>>> compatible = "rpmsg-gpio";
> >>>> reg = <25>;
> >>>> gpio-controller;
> >>>> #gpio-cells = <2>;
> >>>> #interrupt-cells = <2>;
> >>>> interrupt-controller;
> >>>> };
> >>>>
> >>>> gpio@32 {
> >>>> compatible = "rpmsg-gpio";
> >>>> reg = <32>;
> >>>> gpio-controller;
> >>>> #gpio-cells = <2>;
> >>>> #interrupt-cells = <2>;
> >>>> interrupt-controller;
> >>>> };
> >>>> };
> >>>> };
> >>>>
> >>>> rpmsg-io-25 would match with gpio@25
> >>>> rpmsg-io-32 would match with gpio@32
> >>>>
> >>>
> >>> The problem with this approach is, we will endup creating way too many
> >>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
> >>> many GPIOs can be handled by remote from memory perspective. At
> >>> somepoint we might just run-out of number ept & channels created by the
> >>> remote. As of now, open-amp library supports 128 epts I think.
> >>
> >> Right, I proposed a solution in my previous answer to Beleswar who has
> >> the same concern.
> >>
> >>>
> >>>>
> >>>>>
> >>>>> Because the endpoint that is created on a namespace request is also
> >>>>> dynamic in nature. How will the remote know which endpoint addr
> >>>>> Linux allocated for a namespace that it announced?
> >>>>>
> >>>>> As an example/PoC, I created a firmware example which announces
> >>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
> >>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
> >>>>> see it created 2 different addresses (0x400 and 0x401) for each of
> >>>>> the name service request from the same firmware:
> >>>>>
> >>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
> >>>>> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel
> >>>>> ti.ipc4.ping-pong addr 0xd
> >>>>> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
> >>>>> addr 0xe
> >>>>> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
> >>>>> formed from src = 0x400 to dst = 0xe
> >>>>> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
> >>>>> new channel: 0x401 -> 0xd!
> >>>>>
> >>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
> >>>>> Back to same problem. Simple solution is to reply to remote with the
> >>>>> created ept addr and the index.
> >>>>
> >>>> That why I would like to suggest to use the name service field to
> >>>> identify the port/controller, instead of the endpoint address.
> >>>>>
> >>>>>>
> >>>>>> - match the RPMsg probe with the DT,
> >>>>>
> >>>>>
> >>>>> We can probe from all controllers with a single name service
> >>>>> announcement too.
> >>>>>
> >>>>>> - provide a simple mapping between the port and the endpoint on both
> >>>>>> sides,
> >>>>>
> >>>>>
> >>>>> We are trying to get rid of this mapping from Linux side to adapt
> >>>>> the gpio-virtio design.
> >>>>>
> >>>>>> - allow multiple endpoints on the remote side,
> >>>>>
> >>>>>
> >>>>> We can support this as well with single nameservice model.
> >>>>> There is no limitation. Remote has to send a message with
> >>>>> its newly created ept that's all.
> >>>>>
> >>>>>> - provide a simple discovery mechanism for remote capabilities.
> >>>>>
> >>>>>
> >>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
> >>>>>
> >>>>> Feel free to let me know if you have concerns with any of the
> >>>>> suggestions!
> >>>>
> >>>> My only concern, whatever the solution, is that we find a smart
> >>>> solution to associate the correct endpoint with the correct GPIO
> >>>> port/controller defined in the DT.
> >>>>
> >>>> I may have misunderstood your solution. Could you please help me
> >>>> understand your proposal by explaining how you would handle three
> >>>> GPIO ports defined in the DT, considering that the endpoint
> >>>> addresses on the Linux side can be random?
> >>>> If I assume there is a unique endpoint on the remote side,
> >>>> I do not understand how you can match, on the firmware side,
> >>>> the Linux endpoint address to the GPIO port.
> >>>>
> >>>> Thanks and Regards,Arnaud
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Beleswar
> >>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Arnaud
> >>>>>>
> >>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
> >>>>>>>> a. ept1 -> i2c@1
> >>>>>>>> b. ept2 -> i2c@2
> >>>>>>>> c. ept3 -> i2c@3
> >>>>>>>>
> >>>>>>>> etc...
> >>>>>>>>
> >>>
> >>> Just want to clear-up few terms before I jump to the solution:
> >>>
> >>> **RPMsg channel/device**:
> >>> - These are devices announced by the remote processor, and created by
> >>> linux. They are created at: /sys/bus/rpmsg/devices
> >>> - The channel format: <name>.<src ept>.<dst ept>
> >>>
> >>> **RPMsg endpoint**:
> >>> - Endpoint is differnt than channel. Single channel can have multiple
> >>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
> >>>
> >>> To create endpoint device, we have rpmsg_create_ept API, which takes
> >>> channel information as input, which has src-ept, dst-ept.
> >>>
> >>> Following is proposed solution:
> >>>
> >>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
> >>> pin/port).
> >>> - In our case that would be, single rpmsg-io node. (That makes me
> >>> question if bindings are correct or not).
> >>>
> >>> 2) Assign GPIO number as src ept.
> >>>
> >>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
> >>> endpoint.
> >>>
> >>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
> >>> add 1024 offset to the GPIO number:
> >>>
> >>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
> >>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
> >>>
> >>> Now on the remote side, there is single channel and only single-endpoint
> >>> is needed that is mapped to the rpmsg-io channel callback.
> >>>
> >>> That callback will receive all the payloads from the Linux, which will
> >>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
> >>
> >>
> >> Interesting approach. I also tried to find a similar solution.
> >>
> >> The question here is: how can we guarantee continuous addresses? Given
> >> the static and dynamic allocation of endpoint addresses that are
> >> implemented, my conclusion was that it is not reliable enough.
> >>
> >> but perhaps I missed something...
> >>
> >>>
> >>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
> >>> on platform specific logic.
> >>>
> >>> This doesn't need PORT information at all. Also it makes sure that
> >>> remote is using only single-endpoint so not much memory is used.
> >>>
> >>> *Example*:
> >>> If only rpmsg-gpio channel is created by the remote side, than following
> >>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
> >>> the rpmsg-io controller:
> >>>
> >>> Linux Remote
> >>>
> >>> rpmsg-channel: rpmsg-gpio.0x400.0x400
> >>>
> >>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
> >>> |
> >>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
> >>> |
> >>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-| 0x400 ept callback.
> >>>
> >>>
> >>> *On remote side*:
> >>>
> >>> ept_0x400_callback(..., int src_ept, ...,)
> >>> {
> >>> int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
> >>> // platform specific logic to convert gpio num to proper pin,
> >>> // just like you would convert gpio num to pin on a linux gpio
> >>> controller.
> >>> }
> >>>
> >>> My question on the binding:
> >>>
> >>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
> >>> can be represented just any other GPIO controller? Please let me know if
> >>> I am missing something. So rpmsg channel/rpmsg device is not created per
> >>> GPIO, but per controller. GPIO number multiplexing should be done with
> >>> rpmsg src ept, that removes the need of having each GPIO as a separate
> >>> node.
> >>>
> >>>
> >>> rpmsg_gpio: rpmsg-gpio@0 {
> >>> compatible = "rpmsg-gpio";
> >>> reg = <0>;
> >>> gpio-controller;
> >>> #gpio-cells = <2>;
> >>> #interrupt-cells = <2>;
> >>> interrupt-controller;
> >>> };
> >>>
> >>> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
> >>>
> >>> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
> >>>
> >>> If the intent to create separate gpio nodes was only for the channel
> >>> creation, then it's not really needed.
> >>>
> >>> [1]
> >>> https://github.com/torvalds/linux/
> >>> blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/
> >>> virtio_rpmsg_bus.c#L136
> >>>
> >>
> >> It is already the case. bindings declare GPIO controllers, not directly
> >> GPIOs in:
> >>
> >> [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
> >> support
> >>
> >> The discussion is around having an unique RPmsg endpoint for all
> >> GPIO controller or one RPmsg endpoint per GPIO controller.
> >>
> >
> > Endpoint where remote side or linux side?
> >
> > If unique endpoint on remote side per gpio controller then it makes sense.
> >
> > Unique endpoint on linux side doesn't make sense. Instead, unique
> > channel per gpio controller makes sense, and each channel will have
> > multiple endpoints on linux side. As I replied to Beleswar on the other
> > email, I will copy past my answer here too:
> >
> >
> > To be more specific:
> >
> > Linux: remote:
> >
> > ch1: rpmsg-gpio.-1.1024 -> gpio-controller@1024
> > - gpio-line ept1
> > - gpio-line ept2 -> They all map to same callback_ept_1024.
> > - gpio-line ept3
> >
> > ch2: rpmsg-gpio.-1.1025 -> gpio-controller@1025
> > - gpio-line ept1
> > - gpio-line ept2 -> They all map to same callback_ept_1025.
> > - gpio-line ept3
> >
>
>
> Hi Mathieu,
>
> So upon more brain storming in this approach I found limitation:
>
> This approach won't work if host OS is any other OS but Linux. For
> example, if the remote OS is zephyr/baremetal using open-amp, then Only
> Linux <-> zephyr combination will work, and we won't be able to re-use
> this approach for zephyr <-> zephyr use case. The concept of rpmsg
> channel/device exist only in the linux kernel implementation. This
> brings another question: Should the protocol we decide work on other use
> cases as well? Or Linux must be the Host OS for this protocol ?
>
Linux and Zephyr are very distinct OS, each with their own subsystems
and characteristics. The design we choose here involves RPMSG and,
inherently, Linux. We can't make decisions based on what may
potentially happen in Zephyr.
>
> I think your & Arnaud's proposed approach of single endpoint per
> gpio-controller on both side makes more sense, as it will work
> regardless of any OS on host or remote side.
>
Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
GPIO controller. The remaining issue it about the best way to work
out source and destination addresses between Linux and the remote
processor. I'm running out of time for today but I'll return to this
thread with a final analysis by the end of the week.
> To be more specific this will look like following:
>
> Host (Linux) Remote (baremetal/RTOS)
>
> rpmsg ch/device 1:
> - rpmsg ept 1 <------> rpmsg ept 1 gpio-controller 0
>
> rpmsg ch/device 2:
> - rpmsg ept 2 <------> rpmsg ept 2 gpio-controller 1
>
>
> The question is, how to decide src ept, and dest ept on both sides?
> I still think it should be static endpoints.
>
> I will get back with more reasoning on that.
>
> > On the remote side, we have to hardcode Which rpmsg controller is mapped
> > to which endpoint.
> >
> >> Or did I misunderstand your questions?
> >>
> >> Thanks,
> >> Arnaud
> >>
> >
> >
> > I gave this patch more time yesterday, and I think the 'reg' property
> > should represent remote endpoint, instead of the gpio-controller index.
> >
> > So in this approach remote implementation is expected to provide
> > hard-coded (static) endpoints for each gpio-controller instance, and
> > that same number should be represented with the 'reg' property.
> >
> > On remote side:
> >
> > #define RPMSG_GPIO_0_CONTROLLER_EPT (RPMSG_RESERVED_ADDRESSES + 1) // 1024
> >
> > ept_1024_callback() {
> >
> > // handle appropriate gpio port ()
> >
> > }
> >
> > On linux side:
> >
> > So new representation of controller:
> >
> > rpmsg_gpio_0: gpio@1024 {
> > compatible = "rpmsg-gpio";
> > reg = <1024>;
> > gpio-controller;
> > #gpio-cells = <2>;
> > #interrupt-cells = <2>;
> > interrupt-controller;
> > };
> >
> > rpmsg_gpio_1: gpio@1025 {
> > compatible = "rpmsg-gpio";
> > reg = <1025>;
> > gpio-controller;
> > #gpio-cells = <2>;
> > #interrupt-cells = <2>;
> > interrupt-controller;
> > };
> >
> > gpios = <&rpmsg_gpio_0 (GPIO NUM or PIN) flags>,
> > <&rpmsg_gpio_1 (GPIO NUM or PIN) flags>;
> >
> > Now in the linux driver:
> >
> > You can easily retrieve destination endpoint when we want to send the
> > command to the gpio controller via device's "reg" property.
> >
> > This approach also provides built-in security as well. Because now
> > gpio-controller instance is hardcoded with the endpoint callback, it
> > can't be modified/addressed without changing the 'reg' property.
> >
> > Just like you wouldn't change device address for the instance of the
> > gpio-controller right?
> >
> > This approach can be easily adapted to all the other rpmsg controllers
> > as well.
> >
> > So, dynamic endpoint allocation doesn't make sense in this case. Dynamic
> > endpoint allocation makes more sense for user-space apps which don't
> > really care about endpoints and only payloads.
> >
> > But, here we are multiplexing device-addresses with endpoints, and so it
> > has to be fixed, and presented via 'reg' property. So, firmware can't
> > change device-address without Linux knowing it.
> >
> > Thanks,
> > Tanmay
> >
> >
> >>
> >>>>>>>> This way device groups are isolated with each channel/namespace, and
> >>>>>>>> instances within each device groups are also respected with specific
> >>>>>>>> endpoints.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Beleswar
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-11 17:53 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, kvm, linux-doc,
linux-kernel, Sean Christopherson, Jim Mattson, Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Raghavendra Rao Ananta, Eric Auger,
Kees Cook, Arnd Bergmann, Nathan Chancellor, linux-arm-kernel,
kvmarm, linux-kselftest
In-Reply-To: <baff82ca-6321-4b16-aa61-b2d6d60b6535@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]
On Mon, 2026-05-11 at 18:56 +0200, Paolo Bonzini wrote:
> On 5/11/26 18:38, David Woodhouse wrote:
> > Not *everything* is in CPUID; one recent exception that comes to mind
> > is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the
> > existing behaviour of older kernels — even when that behaviour doesn't
> > make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would
> > *advertise* the feature, but not actually *implement* it. Nevertheless,
> > that remains the default behaviour of future kernels unless userspace
> > explicitly opts in to fully enable (or disable) the feature.
> >
> > But this documentation update isn't even asking for that compatible-by-
> > default behaviour, even though that is the right thing to do. It's only
> > asking that it be *possible* to reinstate the old behaviour, for
> > userspace that *knows* about the change and explicitly wants to go back
> > to the old way to remain compatible.
>
> Yep, these are the "quirks"---if it's too early for Arm to commit to
> that, I guess it's fine.
>
> However, independent of this patch which I (obviously) believe is a good
> idea, I'd like to understand how far it is, assuming 1) no quirks 2)
> same CPU host.
It generally works out on arm64, although it's obviously a lot more
work than x86 which makes an effort to get this stuff right.
When we upgrade the kernel we do a lot of in-guest testing to find the
stuff that "broke", like cache reporting:
https://lore.kernel.org/all/254ca48a67779ccf9b9f60e2bb5796a305c03f95.camel@infradead.org/
... and the GICD_IIDR thing which I reposted today:
https://lore.kernel.org/all/20260511113558.3325004-2-dwmw2@infradead.org/
Those are the ones I came up against recently because someone had just
*reverted* the offending commits local in a previous kernel upgrade,
and I'm trying to fix it *properly* this time around and not carry the
reverts forward for ever.
And fix the expectations too, of course. Being told that we shouldn't
*expect* to be able to upgrade and roll back the kernel while remaining
compatible is... not OK.
> By the way, you didn't Cc Marc...
Ah crap, I meant to. Thanks for spotting that!
I must have screwed up when I combined and dedeuplicated the
get_maintainer.pl output with the recipients of the IIDR patch series.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: kvm: update links in the references section of AMD Memory Encryption
From: Liam Merwick @ 2026-05-11 17:46 UTC (permalink / raw)
To: Ninad Naik, pbonzini, corbet, skhan, seanjc, michael.roth,
vannapurve
Cc: kvm, linux-doc, linux-kernel, me, linux-kernel-mentees,
liam.merwick
In-Reply-To: <20260511174302.811918-1-ninadnaik07@gmail.com>
On 11/05/2026 18:43, Ninad Naik wrote:
> Replace non-working links in the reference section with the working ones.
>
> Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
> ---
> Documentation/virt/kvm/x86/amd-memory-encryption.rst | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
> index b2395dd4769d..bd04a908a8db 100644
> --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
> +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
> @@ -656,8 +656,8 @@ References
> See [white-paper]_, [api-spec]_, [amd-apm]_, [kvm-forum]_, and [snp-fw-abi]_
> for more info.
>
> -.. [white-paper] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
> -.. [api-spec] https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
> -.. [amd-apm] https://support.amd.com/TechDocs/24593.pdf (section 15.34)
> +.. [white-paper] https://docs.amd.com/v/u/en-US/memory-encryption-white-paper
> +.. [api-spec] https://docs.amd.com/v/u/en-US/55766_PUB_3.24_SEV_API
> +.. [amd-apm] https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2 (section 15.34)
> .. [kvm-forum] https://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
> -.. [snp-fw-abi] https://www.amd.com/system/files/TechDocs/56860.pdf
> +.. [snp-fw-abi] https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf
^ permalink raw reply
* [PATCH] Documentation: kvm: update links in the references section of AMD Memory Encryption
From: Ninad Naik @ 2026-05-11 17:43 UTC (permalink / raw)
To: pbonzini, corbet, skhan, seanjc, michael.roth, liam.merwick,
vannapurve
Cc: kvm, linux-doc, linux-kernel, me, linux-kernel-mentees,
Ninad Naik
Replace non-working links in the reference section with the working ones.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
---
Documentation/virt/kvm/x86/amd-memory-encryption.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
index b2395dd4769d..bd04a908a8db 100644
--- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
@@ -656,8 +656,8 @@ References
See [white-paper]_, [api-spec]_, [amd-apm]_, [kvm-forum]_, and [snp-fw-abi]_
for more info.
-.. [white-paper] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
-.. [api-spec] https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
-.. [amd-apm] https://support.amd.com/TechDocs/24593.pdf (section 15.34)
+.. [white-paper] https://docs.amd.com/v/u/en-US/memory-encryption-white-paper
+.. [api-spec] https://docs.amd.com/v/u/en-US/55766_PUB_3.24_SEV_API
+.. [amd-apm] https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2 (section 15.34)
.. [kvm-forum] https://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
-.. [snp-fw-abi] https://www.amd.com/system/files/TechDocs/56860.pdf
+.. [snp-fw-abi] https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5 00/13] ima: Introduce staging mechanism
From: Lakshmi Ramasubramanian @ 2026-05-11 17:29 UTC (permalink / raw)
To: steven chen, Roberto Sassu, corbet, skhan, zohar, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, Roberto Sassu
In-Reply-To: <99c30be6-8b0f-486a-890c-cf74c5930726@linux.microsoft.com>
On 5/7/2026 9:47 AM, steven chen wrote:
>>
>> Usage
>> =====
>>
>> The IMA staging mechanism can be enabled from the kernel configuration
>> with the CONFIG_IMA_STAGING option.
>>
>> If it is enabled, IMA duplicates the current measurements interfaces
>> (both binary and ASCII), by adding the _staged file suffix. Both the
>> original and the staging interfaces gain the write permission for the
>> root user and group, but require the process to have CAP_SYS_ADMIN set.
>>
>> The staging mechanism supports two flavors.
>>
>> Staging with prompt
>> ~~~~~~~~~~~~~~~~~~~
>>
>> The current measurements list is moved to a temporary staging area, and
>> staged measurements are deleted upon confirmation.
>>
>> This staging process is achieved with the following steps.
>>
>> 1. echo A > <original interface>: the user requests IMA to stage the
>> entire measurements list;
>> 2. cat <_staged interface>: the user reads the staged measurements;
>> 3. echo D > <_staged interface>: the user requests IMA to delete
>> staged measurements.
>>
>> Staging and deleting
>> ~~~~~~~~~~~~~~~~~~~~
>>
>> N measurements are staged to a temporary staging area, and immediately
>> deleted without further confirmation.
>>
>> This staging process is achieved with the following steps.
>>
>> 1. cat <original interface>: the user reads the current measurements
>> list and determines what the value N for staging should be;
>> 2. echo N > <original interface>: the user requests IMA to delete N
>> measurements from the current measurements list.
>
> This submission proposes two ways for log trimming:
>
> *Flavor 1:* Staging with prompt
> *Flavor 2:* stage and delete N
>
> Functionally, both approaches address the same problem, but *Favour 2
> *is the
> stronger design and should be preferred. There is no good reason to keep
> *Flavor 1.*
>
> From a kernel implementation perspective, *Flavor 2 *is more efficient
> because it
> minimizes the time spent holding the list lock (can’t be shorter). It
> also substantially
> reduces the amount of kernel-side logic, removing nearly half of the
> code required
> by the alternative approach.
>
> From a user-space perspective, *Flavor 2 *results in a much cleaner
> model. It avoids
> the need to track and reconcile both old and staged lists in user space
> as well as
> two lists (cur and staged) in the kernel space, which simplifies log
> trimming logic
> and reduces maintenance overhead. In addition, it preserves the existing
> external
> behavior by not exposing any staged list to user space.
>
> Overall, *Flavor 2 *provides the same functional result with lower
> kernel complexity,
> shorter kernel list lock hold time, and a simpler user-space interface.
> For those
> reasons, it is the preferable approach and *Favour 1* does not appear to
> offer sufficient
> justification to keep both implementations.
>
> Steven
Roberto, Mimi:
I want to add on to the point Steven has brought up.
With "Stage and Delete N" approach, we have the following sequence of
tasks for trimming the IMA log:
1. User mode locks the IMA measurement list through the "write interface".
a. While this prevents any other user mode process from updating the
IMA log, kernel can still add new IMA events to the measurement log
2. User mode reads the TPM Quote and the IMA measurement events and
sends it to the remote attestation service
3. Once the remote service has successfully processed the IMA events,
the user mode determines the number of IMA events "N" to be removed from
the measurement list maintained in the kernel
4. User mode provides the value "N" to the kernel
5. Kernel now determines the point at which to snap the IMA measurement
list using "N" - without holding a lock
6. Then, the kernel lock is held and the list is snapped at the point
determined in the previous step thus keeping the kernel lock time to the
minimum.
7. Now, user mode removes the "write" lock on the IMA measurement list
With the above, we believe "Stage and Delete N" alone is sufficient to
trim IMA log.
-lakshmi
>> .../admin-guide/kernel-parameters.txt | 4 +
>> Documentation/security/IMA-staging.rst | 163 +++++++++
>> Documentation/security/index.rst | 1 +
>> MAINTAINERS | 2 +
>> security/integrity/ima/Kconfig | 16 +
>> security/integrity/ima/ima.h | 32 +-
>> security/integrity/ima/ima_api.c | 2 +-
>> security/integrity/ima/ima_fs.c | 315 ++++++++++++++++--
>> security/integrity/ima/ima_init.c | 5 +
>> security/integrity/ima/ima_kexec.c | 53 ++-
>> security/integrity/ima/ima_queue.c | 283 ++++++++++++++--
>> 11 files changed, 803 insertions(+), 73 deletions(-)
>> create mode 100644 Documentation/security/IMA-staging.rst
>>
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Greg KH @ 2026-05-11 17:28 UTC (permalink / raw)
To: Willy Tarreau
Cc: Leon Romanovsky, Jonathan Corbet, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <20260509094755.2838-3-w@1wt.eu>
On Sat, May 09, 2026 at 11:47:54AM +0200, Willy Tarreau wrote:
> The use of automated tools to find bugs in random locations of the kernel
> induces a raise of security reports even if most of them should just be
> reported as regular bugs. This patch is an attempt at drawing a line
> between what qualifies as a security bug and what does not, hoping to
> improve the situation and ease decision on the reporter's side.
>
> It defers the enumeration to a new file, threat-model.rst, that tries
> to enumerate various classes of issues that are and are not security
> bugs. This should permit to more easily update this file for various
> subsystem-specific rules without having to revisit the security bug
> reporting guide.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Greg KH <gregkh@linuxfoundation.org>
> Reviewed-by: Leon Romanovsky <leon@kernel.org>
> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/index.rst | 1 +
> Documentation/process/security-bugs.rst | 38 +++-
> Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++
> 3 files changed, 274 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/process/threat-model.rst
Looks great, thank you!
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Want me to take it through one of my trees now to get it to Linus this
week, or should it go through the documentation tree? Either is fine
with me.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] killswitch: add per-function short-circuit mitigation primitive
From: Anthony Iliopoulos @ 2026-05-11 17:23 UTC (permalink / raw)
To: Sasha Levin
Cc: Florian Weimer, corbet, akpm, skhan, linux-doc, linux-kernel,
linux-kselftest, gregkh
In-Reply-To: <agG6PnVAFMsb3iiz@laps>
On Mon, May 11, 2026 at 07:15:10AM -0400, Sasha Levin wrote:
> On Mon, May 11, 2026 at 12:33:28PM +0200, Anthony Iliopoulos wrote:
> > On Sat, May 09, 2026 at 08:34:11AM -0400, Sasha Levin wrote:
> > > On Sat, May 09, 2026 at 02:02:24PM +0200, Florian Weimer wrote:
> > > > * Sasha Levin:
> > > >
> > > > > When a kernel (security) issue goes public, fleets stay exposed until a patched
> > > > > kernel is built, distributed, and rebooted into.
> > > > >
> > > > > For many such issues the simplest mitigation is to stop calling the buggy
> > > > > function. Killswitch provides that. An admin writes:
> > > > >
> > > > > echo "engage af_alg_sendmsg -1" \
> > > > > > /sys/kernel/security/killswitch/control
> > > > >
> > > > > After this, af_alg_sendmsg() returns -EPERM on every call without
> > > > > running its body. The mitigation takes effect immediately, and is dropped on
> > > > > the next reboot -- by which point a patched kernel is hopefully in place.
> > > >
> > > > Do you expect this to be safe to enable in kernel lockdown mode (i.e.,
> > > > with typical Secure Boot configurations in distributions)?
> > >
> > > Yes: under lockdown, killswitch has to be configured on the cmdline. Runtime
> > > engage is gated on the new LOCKDOWN_KILLSWITCH reason.
> >
> > Basically this proposal allows for any function to be overridden on a
> > production kernel as long as no lockdown level is enabled, which is quite
> > dangerous.
> >
> > Assuming this is acceptable (which I am not sure it should be), then this
> > is equivalent to the existing error injection code that we already have in
> > the kernel (CONFIG_FAIL_FUNCTION) minus the explicit whitelisting on a per
> > function basis required to permit injection.
>
> The mechanism is the same, but I don't think reusing fail_function works for
> what killswitch is trying to do.
How so? The kprobe handler is essentially the same. Setting the
whitelisting aside, it is currently possible to do:
echo af_alg_sendmsg > /sys/kernel/debug/fail_function/inject
echo 0xffffffffffffffff > /sys/kernel/debug/fail_function/af_alg_sendmsg/retval
echo 100 > /sys/kernel/debug/fail_function/probability
echo -1 > /sys/kernel/debug/fail_function/times
and that will return -EPERM, taint the kernel, and log the stacktrace on
dmesg on every rejected call.
> > Given that this achieves the exact same result, then why don't we consider
> > simply removing the whitelisting restriction from fail_function altogether
> > and use that instead? The only thing missing then would be the boot param
> > parsing and setup.
>
> fail_function lives in debugfs, and on a typical Secure Boot distro debugfs is
> itself blocked by LOCKDOWN_DEBUGFS at integrity level. Dropping the whitelist
> doesn't help when the operator can't write to the file in the first place.
Agreed, for this to work fail_function would also need to parse boot
params similarly.
> Killswitch is in securityfs so that engaging it can be its own lockdown
> decision rather than being lumped in with everything debugfs exposes.
Sure but it makes no difference when a kernel is locked at integrity it
will anyway block either solution, this makes no practical difference.
> Fault injection in general isn't enabled on production kernels - having to
> enable CONFIG_FUNCTION_ERROR_INJECTION will drag in that entire infra into
> kernels that don't need it.
There's very little code that CONFIG_FUNCTION_ERROR_INJECTION brings in
apart from the override_function_with_return trampoline and
lib/error-inject.c which becomes obsolete without the need to whitelist.
Your proposal also depends on FUNCTION_ERROR_INJECTION necessarily.
The only thing that would be missing and not usually compiled in is
CONFIG_FAIL_FUNCTION that just implements the debugfs ops interface
which you are exposing via securityfs instead.
> > This way we'll be removing a few hundred lines of code instead of adding
> > more duplication, while enabling the same functionality.
>
> I'm not even sure there would be hundreds of lines saved here...
I'm talking specifically about whitelisting which would essentially be
useless:
wc -l lib/error-inject.c include/asm-generic/error-injection.h include/linux/error-injection.h
246 lib/error-inject.c
43 include/asm-generic/error-injection.h
28 include/linux/error-injection.h
317 total
plus a hundred or so annotations of ALLOW_ERROR_INJECT and a tiny bit of
image space savings from dropping that whitelist section from the binary.
> The pieces that make killswitch what it is (cmdline parser,
> LOCKDOWN_KILLSWITCH, TAINT_KILLSWITCH, audit on engage and disengage, the
> module-unload notifier, etc) add up to roughly 200 lines that would move into
> fail_function unchanged. I really don't think we'd end up with much of a line
> delta.
All of that apart from the cmdline parser is already present in the
fault/error injection code, directly or indirectly. I can see though the
appeal of having killswitch cleanly separated from anything else, but
perhaps changing the existing code is more approachable.
> That said, the kprobe and override machinery underneath both of these is fair
> game for a shared helper that fail_function and killswitch both build on. We can
> look at extracting that as a follow-up once killswitch lands, but it's a
> separate piece of work from the policy questions in this thread.
Sure, but my point is that if this is acceptable, then it follows that:
- whitelisting becomes irrelevant (even if fail_function remains
separate), since the exact same capability will be exposed via the
killswitch interface for all functions anyway, so why would we need it
to protect error-injection
and subsequently:
- fail_function would become somewhat redundant since the same
functionality would be achieved via the securityfs (or just bpf, which
is already the case).
Regards,
Anthony
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Michal Hocko @ 2026-05-11 17:10 UTC (permalink / raw)
To: Sasha Levin
Cc: Breno Leitao, Andrew Morton, corbet, skhan, linux-doc,
linux-kernel, linux-kselftest, gregkh
In-Reply-To: <agIHsN9tiIHnVTeV@laps>
On Mon 11-05-26 12:45:36, Sasha Levin wrote:
> Could you describe an existing infrastructure I can use here?
I think it would help to CC maintainers of subsystems that provide
kernel modification functionality. They will surely have a better
insight than me.
> Let's look at
> this recent "Copy Fail" thing as an example.
>
> I can obviously build my own kernel and enroll my own key, but 99.9% of our
> users won't be doing that.
> Livepatching, or manually building a module that just injects a kprobe is out
> of the question as we previously agreed.
Onless I am mistaken you can enroll your own key through MOK. But you
are right that this is an additional step. But the real question is
whether this is a major road block for users of this specific feature.
> systemtap falls into the same bucket as building my own module.
>
> BPF doesn't help because bpf_override_return() requires the target to be on the
> same within_error_injection_list() whitelist as fault injection, and the CVE
> targets never are. Some of our fleet doesn't even have BPF enabled either, but
> that's the smaller objection.
>
> I can't use fault injection because:
>
> a. It's almost never built in production/distro kernels, and I suspect this
> won't change.
> b. The functions I need are not whitelisted.
> c. Even if (a) and (b) were addressed, fault injection would still need a
> securityfs front-end, a cmdline parser, a module-unload notifier, a taint flag,
> and audit on engage and disengage. By the time those land in fail_function and
> tie into/refactor the fault injection code, the net diff is bigger than this
> proposal.
I cannot comment on fault injection imeplementation details of course
but I have to say that the whitelist nature is something that makes its
use very limited. Maybe this is a good opportunity to change the
approach.
>
> In my case I can remove the module, but not if I run a distro that shipped with
> CONFIG_CRYPTO_USER_API_AEAD=y (like RHEL/SUSE).
If you look at copy fail[2], IIRC algif_aead, esp[46] and rxrcp are all
modules that could be blacklisted.
> I can use "initcall_blacklist=" hack and reboot, but as things stand today,
> I'll need to be rebooting few times a day.
with your just disable some functions in the kernel you might need to
reboot even more. But more seriously...
> Even if I'm okay with rebooting that often (and I really really would prefer
> not to), this doesn't solve the issues of a larger fleet of servers that can't
> just reboot that often.
>
> What am I missing?
For one, you are missing more maintainers of code modification infrastructures.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH net-next v3 0/8] net: devmem: support devmem with netkit devices
From: Bobby Eshleman @ 2026-05-11 17:01 UTC (permalink / raw)
To: Zhu Yanjun
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi,
Yanteng Si, Dongliang Mu, Michael Chan, Pavan Chebbi,
Joshua Washington, Harshitha Ramamurthy, Saeed Mahameed,
Tariq Toukan, Mark Bloch, Leon Romanovsky, Alexander Duyck,
kernel-team, Daniel Borkmann, Nikolay Aleksandrov, Shuah Khan, dw,
sdf.kernel, mohsin.bashr, willemb, jiang.kun2, xu.xin16,
wang.yaxin, netdev, linux-doc, linux-kernel, linux-rdma, bpf,
linux-kselftest, Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <d7de2f17-af2d-4b6a-be65-f009d78e3d20@linux.dev>
On Sun, May 10, 2026 at 01:33:18PM -0700, Zhu Yanjun wrote:
> 在 2026/5/7 19:27, Bobby Eshleman 写道:
> > This series enables TCP devmem TX through netkit devices.
> >
> > Netkit now supports queue leasing. A physical NIC's RX queue can be
> > leased to a netkit guest interface inside a container namespace. This
> > gives the container a devmem-capable data path on the RX side (bind-rx,
> > etc...). On the TX side, the container process binds to its netkit guest
> > interface and sends traffic that netkit redirects (via BPF or ip
> > forwarding) to the physical NIC for DMA.
> >
> > Two things in the existing devmem TX path prevent this from working:
> >
> > 1. validate_xmit_unreadable_skb() requires dev->netmem_tx before it will
> > forward a dmabuf-backed (unreadable) skb. This protects skbs from
> > landing on devices that don't have the IOMMU mappings for the backing
> > dmabuf or that don't speak netmem. Netkit, however, does not support
> > DMA, doesn't attempt to read unreadable skb pages and so doesn't
> > break netmem (it is pure skb routing and redirection). It is
> > functionally capable of routing unreadable skbs, but there is no way
> > for the TX validation pathway to distinguish between a device that
> > will actually attempt DMA-ing the skb and another device
> > (like netkit) that does not DMA but also does not break
> > netmem.
> >
> > 2. bind_tx_doit uses the bound device as the DMA device. When the user
> > binds devmem TX to the netkit guest, the bind handler attempts to
> > create DMA mappings against netkit, which has no DMA capability and
> > no IOMMU mappings.
> >
> > This series solves these problems as follows:
> >
> > 1. Extend netmem_tx to two bits, assigned to one of three values:
> >
> > NETMEM_TX_NONE - netmem not supported
> > NETMEM_TX_DMA - netmem supported and performs DMA
> > NETMEM_TX_NO_DMA - netmem supported, but does not DMA
> >
> > With these bits, phys devices can set NETMEM_TX_DMA and devices like
> > netkit set NETMEM_TX_NO_DMA. The validation TX path ensures that any
> > DMA-capable netdev exactly matches the bound device, guaranteeing the
> > correct mapping of the bound dmabuf. The validation TX path also
> > allows devices with NETMEM_TX_NO_DMA to pass, knowing these devices
> > will not misuse netmem or run into IOMMU faults. After redirection or
> > routing and the skb finally makes its way through the stack to a
> > physical device's TX path, the above NETMEM_TX_DMA check is performed
> > again to guarantee the device has the appropriate binding/mappings.
> >
> > 2. On TX bind, the bind handler recognizes NETMEM_TX_NO_DMA devices and
> > finds the phys TX device and binds to that instead. For the netkit
> > case, if it has been leased a queue from a DMA-capable device
> > already, then the bind action is performed on the DMA-capable device
> > instead and the dmabuf is mapped correctly.
> >
> > ---
> > Changes in v3:
> > - Fix validate_xmit_unreadable_skb() logic for non-devmem
> > unreadable niovs (should not be dropped) (Sashiko)
> > - Simplify lock handling in bind_tx, no premature release (Jakub)
> > - split NO_DMA changes into separate patch (Jakub)
> > - fixed some pylint issues, one required an additional patch ("selftests:
> > drv-net: make attr _nk_guest_ifname public") to rename a variable from
> > private to public
> > - see per-patch changelist for more detailed changes
> > - Link to v2: https://lore.kernel.org/r/20260504-tcp-dm-netkit-v2-0-56d52ac72fd4@meta.com
> >
> > Changes in v2:
> > - Squash driver conversion patches (2-5) into patch 1 (Jakub)
> > - In validate_xmit_unreadable_skb() to check netmem_tx mode before inspecting
> > frags (Jakub)
> > - Lock bind_dev around netdev_queue_get_dma_dev() when bind_dev != netdev to
> > fix lockdep (Sashiko)
> > - Move require_devmem() into individual test functions so KsftSkipEx goes up to
> > ksft_run() (Sashiko)
> > - Add nk_devmem.py to TEST_PROGS in Makefile (Sashiko)
> > - Link to v1:
> > https://lore.kernel.org/all/20260428-tcp-dm-netkit-v1-0-719280eba4d2@meta.com/
> >
> > Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
> >
> > ---
> > Bobby Eshleman (8):
> > net: convert netmem_tx flag to enum
> > net: netkit: declare NETMEM_TX_NO_DMA mode
> > net: devmem: support TX over NETMEM_TX_NO_DMA devices
>
> I applied this patchset in my local kernel tree and built a new kernel
> image. I loaded this new kernel image in my test environment. It seems that
> all the testcases can pass.
>
> I think that this patchset would not cause any regression problem in my test
> environment.
>
> Zhu Yanjun
Thanks for testing!
Best,
Bobby
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: Paolo Bonzini @ 2026-05-11 16:56 UTC (permalink / raw)
To: David Woodhouse, Jonathan Corbet, Shuah Khan, kvm, linux-doc,
linux-kernel, Sean Christopherson, Jim Mattson, Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Raghavendra Rao Ananta, Eric Auger,
Kees Cook, Arnd Bergmann, Nathan Chancellor, linux-arm-kernel,
kvmarm, linux-kselftest
In-Reply-To: <57bc082f4824d6114d3156744c25986effc29aca.camel@infradead.org>
On 5/11/26 18:38, David Woodhouse wrote:
> Not *everything* is in CPUID; one recent exception that comes to mind
> is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the
> existing behaviour of older kernels — even when that behaviour doesn't
> make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would
> *advertise* the feature, but not actually *implement* it. Nevertheless,
> that remains the default behaviour of future kernels unless userspace
> explicitly opts in to fully enable (or disable) the feature.
>
> But this documentation update isn't even asking for that compatible-by-
> default behaviour, even though that is the right thing to do. It's only
> asking that it be *possible* to reinstate the old behaviour, for
> userspace that *knows* about the change and explicitly wants to go back
> to the old way to remain compatible.
Yep, these are the "quirks"---if it's too early for Arm to commit to
that, I guess it's fine.
However, independent of this patch which I (obviously) believe is a good
idea, I'd like to understand how far it is, assuming 1) no quirks 2)
same CPU host.
By the way, you didn't Cc Marc...
Paolo
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shah, Tanmay @ 2026-05-11 16:47 UTC (permalink / raw)
To: Arnaud POULIQUEN, tanmay.shah, Beleswar Prasad Padhi,
Mathieu Poirier
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <da3b79b7-9dad-48cb-b552-cf6df445899f@amd.com>
On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
>
>
> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>> Hi Tanmay,
>>
>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>
>>> Hello all,
>>>
>>> I have started reviewing this work as well.
>>> Thanks Shenwei for this work.
>>>
>>> I have gone through only the current revision, and would like to provide
>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>>> Also, have some bindings related question.
>>>
>>> Please see below:
>>>
>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>
>>>>
>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>> Hello Arnaud,
>>>>>
>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>> Hello,
>>>>>>
>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>>>
>>>>>>>> Hi Mathieu,
>>>>>>>>
>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>>>> Andersson
>>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>>>> linux-imx <linux-
>>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>;
>>>>>>>>>>>>> Sascha
>>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>> rpmsg
>>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>>> __u8 status;
>>>>>>>>>>>>>>> __u8 value;
>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> It is the same message format. Please see the message
>>>>>>>>>>>>>> definition
>>>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>>>> message format.
>>>>>>>>>>>>>
>>>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>>>
>>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>>>> requests and
>>>>>>>>>>> replies, and a second one for events.
>>>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>>>> channel, so a
>>>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>>>> of messages.
>>>>>>>>>>>>
>>>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>>>> an additional
>>>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>>>> field is added to
>>>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>>>
>>>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>>>> multiplexing
>>>>>>>>>>> capability by way of endpoints. There is no need for a port
>>>>>>>>>>> field. One endpoint,
>>>>>>>>>>> one GPIO controller.
>>>>>>>>>>>
>>>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>>>> endpoint maps to, either
>>>>>>>>>> by embedding the port information in the message (the current
>>>>>>>>>> way), or by sending it
>>>>>>>>>> separately.
>>>>>>>>>>
>>>>>>>>> An endpoint is created with every namespace request. There
>>>>>>>>> should be
>>>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>>>> unique
>>>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>>>> field to identify them.
>>>>>>>>
>>>>>>>>
>>>>>>>> Right, but this can still be done by just having one namespace
>>>>>>>> request.
>>>>>>>> We can create new endpoints bound to an existing namespace/
>>>>>>>> channel by
>>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>>>> b73d-228295daaeec@ti.com/
>>>>>>>>
>>>>>>>
>>>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>>>> next week.
>>>>>>>
>>>>>>>> My mental model looks like this for the complete picture:
>>>>>>>>
>>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>> a. ept1 -> gpio-controller@1
>>>>>>>> b. ept2 -> gpio-controller@2
>>>>>>>>
>>>
>>> If my understanding of what gpio-controller is right, than this won't
>>> work. We need one rpmsg channel per gpio-controller, and in most cases
>>> there will be only one GPIO-controller on the remote side. If there are
>>> multiple or multiple instances of same controller, than we need separate
>>> channel name for that controller just like we would have separate device
>>> on the Linux.
>>
>> As done in ehe rpmsg_tty driver it could be instantiated several times with
>> the same channel/service name. This would imply a specific rpmsg to
>> retreive
>> the gpio controller index from the remote side.
>>>
>>>>>>>
>>>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>>>> beginning. I don't yet have a strong opinion on whether to use one
>>>>>>> namespace request per GPIO controller or a single request that spins
>>>>>>> off multiple endpoints. I'll have to look at your link and
>>>>>>> reflect on
>>>>>>> that. Regardless of how we proceed on that front, multiplexing needs
>>>>>>> to happen at the endpoint level rather than the packet level.
>>>>>>> This is
>>>>>>> the only way this work can move forward.
>>>>>>>
>>>>>>
>>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>>>> created with every namespace request.”
>>>>>>
>>>>>> If the endpoint is created only on the Linux side, how do we match
>>>>>> the Linux endpoint address with the local port field on the remote
>>>>>> side?
>>>>>
>>>>>
>>>>> Simply by sending a message to the remote containing the newly created
>>>>> endpoint and the port idx. Note that is this done just one time, after
>>>>> this
>>>>> Linux need not have the port field in the message everytime its sending
>>>>> a message.
>>>>>
>>>>>>
>>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>>>> the DT. This would:
>>>>>
>>>>>
>>>>> You will face the same problem in this case also that you asked above:
>>>>> "how do we match the Linux endpoint address with the local port field
>>>>> on the remote side?"
>>>>
>>>> Sorry I probably introduced confusion here
>>>> my sentence should be;
>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>> [port],
>>>> where [port] corresponds to the GPIO controller port in the DT.
>>>>
>>>>
>>>> For instance:
>>>>
>>>> rpmsg {
>>>> rpmsg-io {
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>>
>>>> gpio@25 {
>>>> compatible = "rpmsg-gpio";
>>>> reg = <25>;
>>>> gpio-controller;
>>>> #gpio-cells = <2>;
>>>> #interrupt-cells = <2>;
>>>> interrupt-controller;
>>>> };
>>>>
>>>> gpio@32 {
>>>> compatible = "rpmsg-gpio";
>>>> reg = <32>;
>>>> gpio-controller;
>>>> #gpio-cells = <2>;
>>>> #interrupt-cells = <2>;
>>>> interrupt-controller;
>>>> };
>>>> };
>>>> };
>>>>
>>>> rpmsg-io-25 would match with gpio@25
>>>> rpmsg-io-32 would match with gpio@32
>>>>
>>>
>>> The problem with this approach is, we will endup creating way too many
>>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
>>> many GPIOs can be handled by remote from memory perspective. At
>>> somepoint we might just run-out of number ept & channels created by the
>>> remote. As of now, open-amp library supports 128 epts I think.
>>
>> Right, I proposed a solution in my previous answer to Beleswar who has
>> the same concern.
>>
>>>
>>>>
>>>>>
>>>>> Because the endpoint that is created on a namespace request is also
>>>>> dynamic in nature. How will the remote know which endpoint addr
>>>>> Linux allocated for a namespace that it announced?
>>>>>
>>>>> As an example/PoC, I created a firmware example which announces
>>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>>>> the name service request from the same firmware:
>>>>>
>>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>>>> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel
>>>>> ti.ipc4.ping-pong addr 0xd
>>>>> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>>>> addr 0xe
>>>>> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>>>> formed from src = 0x400 to dst = 0xe
>>>>> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>>>> new channel: 0x401 -> 0xd!
>>>>>
>>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>>>> Back to same problem. Simple solution is to reply to remote with the
>>>>> created ept addr and the index.
>>>>
>>>> That why I would like to suggest to use the name service field to
>>>> identify the port/controller, instead of the endpoint address.
>>>>>
>>>>>>
>>>>>> - match the RPMsg probe with the DT,
>>>>>
>>>>>
>>>>> We can probe from all controllers with a single name service
>>>>> announcement too.
>>>>>
>>>>>> - provide a simple mapping between the port and the endpoint on both
>>>>>> sides,
>>>>>
>>>>>
>>>>> We are trying to get rid of this mapping from Linux side to adapt
>>>>> the gpio-virtio design.
>>>>>
>>>>>> - allow multiple endpoints on the remote side,
>>>>>
>>>>>
>>>>> We can support this as well with single nameservice model.
>>>>> There is no limitation. Remote has to send a message with
>>>>> its newly created ept that's all.
>>>>>
>>>>>> - provide a simple discovery mechanism for remote capabilities.
>>>>>
>>>>>
>>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>>>
>>>>> Feel free to let me know if you have concerns with any of the
>>>>> suggestions!
>>>>
>>>> My only concern, whatever the solution, is that we find a smart
>>>> solution to associate the correct endpoint with the correct GPIO
>>>> port/controller defined in the DT.
>>>>
>>>> I may have misunderstood your solution. Could you please help me
>>>> understand your proposal by explaining how you would handle three
>>>> GPIO ports defined in the DT, considering that the endpoint
>>>> addresses on the Linux side can be random?
>>>> If I assume there is a unique endpoint on the remote side,
>>>> I do not understand how you can match, on the firmware side,
>>>> the Linux endpoint address to the GPIO port.
>>>>
>>>> Thanks and Regards,Arnaud
>>>>
>>>>>
>>>>> Thanks,
>>>>> Beleswar
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Arnaud
>>>>>>
>>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>>> a. ept1 -> i2c@1
>>>>>>>> b. ept2 -> i2c@2
>>>>>>>> c. ept3 -> i2c@3
>>>>>>>>
>>>>>>>> etc...
>>>>>>>>
>>>
>>> Just want to clear-up few terms before I jump to the solution:
>>>
>>> **RPMsg channel/device**:
>>> - These are devices announced by the remote processor, and created by
>>> linux. They are created at: /sys/bus/rpmsg/devices
>>> - The channel format: <name>.<src ept>.<dst ept>
>>>
>>> **RPMsg endpoint**:
>>> - Endpoint is differnt than channel. Single channel can have multiple
>>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>>>
>>> To create endpoint device, we have rpmsg_create_ept API, which takes
>>> channel information as input, which has src-ept, dst-ept.
>>>
>>> Following is proposed solution:
>>>
>>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
>>> pin/port).
>>> - In our case that would be, single rpmsg-io node. (That makes me
>>> question if bindings are correct or not).
>>>
>>> 2) Assign GPIO number as src ept.
>>>
>>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
>>> endpoint.
>>>
>>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
>>> add 1024 offset to the GPIO number:
>>>
>>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
>>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>>>
>>> Now on the remote side, there is single channel and only single-endpoint
>>> is needed that is mapped to the rpmsg-io channel callback.
>>>
>>> That callback will receive all the payloads from the Linux, which will
>>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>>
>>
>> Interesting approach. I also tried to find a similar solution.
>>
>> The question here is: how can we guarantee continuous addresses? Given
>> the static and dynamic allocation of endpoint addresses that are
>> implemented, my conclusion was that it is not reliable enough.
>>
>> but perhaps I missed something...
>>
>>>
>>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
>>> on platform specific logic.
>>>
>>> This doesn't need PORT information at all. Also it makes sure that
>>> remote is using only single-endpoint so not much memory is used.
>>>
>>> *Example*:
>>> If only rpmsg-gpio channel is created by the remote side, than following
>>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
>>> the rpmsg-io controller:
>>>
>>> Linux Remote
>>>
>>> rpmsg-channel: rpmsg-gpio.0x400.0x400
>>>
>>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>>> |
>>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>>> |
>>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-| 0x400 ept callback.
>>>
>>>
>>> *On remote side*:
>>>
>>> ept_0x400_callback(..., int src_ept, ...,)
>>> {
>>> int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
>>> // platform specific logic to convert gpio num to proper pin,
>>> // just like you would convert gpio num to pin on a linux gpio
>>> controller.
>>> }
>>>
>>> My question on the binding:
>>>
>>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
>>> can be represented just any other GPIO controller? Please let me know if
>>> I am missing something. So rpmsg channel/rpmsg device is not created per
>>> GPIO, but per controller. GPIO number multiplexing should be done with
>>> rpmsg src ept, that removes the need of having each GPIO as a separate
>>> node.
>>>
>>>
>>> rpmsg_gpio: rpmsg-gpio@0 {
>>> compatible = "rpmsg-gpio";
>>> reg = <0>;
>>> gpio-controller;
>>> #gpio-cells = <2>;
>>> #interrupt-cells = <2>;
>>> interrupt-controller;
>>> };
>>>
>>> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
>>>
>>> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
>>>
>>> If the intent to create separate gpio nodes was only for the channel
>>> creation, then it's not really needed.
>>>
>>> [1]
>>> https://github.com/torvalds/linux/
>>> blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/
>>> virtio_rpmsg_bus.c#L136
>>>
>>
>> It is already the case. bindings declare GPIO controllers, not directly
>> GPIOs in:
>>
>> [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
>> support
>>
>> The discussion is around having an unique RPmsg endpoint for all
>> GPIO controller or one RPmsg endpoint per GPIO controller.
>>
>
> Endpoint where remote side or linux side?
>
> If unique endpoint on remote side per gpio controller then it makes sense.
>
> Unique endpoint on linux side doesn't make sense. Instead, unique
> channel per gpio controller makes sense, and each channel will have
> multiple endpoints on linux side. As I replied to Beleswar on the other
> email, I will copy past my answer here too:
>
>
> To be more specific:
>
> Linux: remote:
>
> ch1: rpmsg-gpio.-1.1024 -> gpio-controller@1024
> - gpio-line ept1
> - gpio-line ept2 -> They all map to same callback_ept_1024.
> - gpio-line ept3
>
> ch2: rpmsg-gpio.-1.1025 -> gpio-controller@1025
> - gpio-line ept1
> - gpio-line ept2 -> They all map to same callback_ept_1025.
> - gpio-line ept3
>
Hi Mathieu,
So upon more brain storming in this approach I found limitation:
This approach won't work if host OS is any other OS but Linux. For
example, if the remote OS is zephyr/baremetal using open-amp, then Only
Linux <-> zephyr combination will work, and we won't be able to re-use
this approach for zephyr <-> zephyr use case. The concept of rpmsg
channel/device exist only in the linux kernel implementation. This
brings another question: Should the protocol we decide work on other use
cases as well? Or Linux must be the Host OS for this protocol ?
I think your & Arnaud's proposed approach of single endpoint per
gpio-controller on both side makes more sense, as it will work
regardless of any OS on host or remote side.
To be more specific this will look like following:
Host (Linux) Remote (baremetal/RTOS)
rpmsg ch/device 1:
- rpmsg ept 1 <------> rpmsg ept 1 gpio-controller 0
rpmsg ch/device 2:
- rpmsg ept 2 <------> rpmsg ept 2 gpio-controller 1
The question is, how to decide src ept, and dest ept on both sides?
I still think it should be static endpoints.
I will get back with more reasoning on that.
> On the remote side, we have to hardcode Which rpmsg controller is mapped
> to which endpoint.
>
>> Or did I misunderstand your questions?
>>
>> Thanks,
>> Arnaud
>>
>
>
> I gave this patch more time yesterday, and I think the 'reg' property
> should represent remote endpoint, instead of the gpio-controller index.
>
> So in this approach remote implementation is expected to provide
> hard-coded (static) endpoints for each gpio-controller instance, and
> that same number should be represented with the 'reg' property.
>
> On remote side:
>
> #define RPMSG_GPIO_0_CONTROLLER_EPT (RPMSG_RESERVED_ADDRESSES + 1) // 1024
>
> ept_1024_callback() {
>
> // handle appropriate gpio port ()
>
> }
>
> On linux side:
>
> So new representation of controller:
>
> rpmsg_gpio_0: gpio@1024 {
> compatible = "rpmsg-gpio";
> reg = <1024>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> interrupt-controller;
> };
>
> rpmsg_gpio_1: gpio@1025 {
> compatible = "rpmsg-gpio";
> reg = <1025>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> interrupt-controller;
> };
>
> gpios = <&rpmsg_gpio_0 (GPIO NUM or PIN) flags>,
> <&rpmsg_gpio_1 (GPIO NUM or PIN) flags>;
>
> Now in the linux driver:
>
> You can easily retrieve destination endpoint when we want to send the
> command to the gpio controller via device's "reg" property.
>
> This approach also provides built-in security as well. Because now
> gpio-controller instance is hardcoded with the endpoint callback, it
> can't be modified/addressed without changing the 'reg' property.
>
> Just like you wouldn't change device address for the instance of the
> gpio-controller right?
>
> This approach can be easily adapted to all the other rpmsg controllers
> as well.
>
> So, dynamic endpoint allocation doesn't make sense in this case. Dynamic
> endpoint allocation makes more sense for user-space apps which don't
> really care about endpoints and only payloads.
>
> But, here we are multiplexing device-addresses with endpoints, and so it
> has to be fixed, and presented via 'reg' property. So, firmware can't
> change device-address without Linux knowing it.
>
> Thanks,
> Tanmay
>
>
>>
>>>>>>>> This way device groups are isolated with each channel/namespace, and
>>>>>>>> instances within each device groups are also respected with specific
>>>>>>>> endpoints.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Beleswar
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-11 16:45 UTC (permalink / raw)
To: Michal Hocko
Cc: Breno Leitao, Andrew Morton, corbet, skhan, linux-doc,
linux-kernel, linux-kselftest, gregkh
In-Reply-To: <agH_bGUTvWm2h5g4@tiehlicka>
On Mon, May 11, 2026 at 06:10:20PM +0200, Michal Hocko wrote:
>On Mon 11-05-26 11:55:41, Sasha Levin wrote:
>> On Mon, May 11, 2026 at 04:25:57PM +0200, Michal Hocko wrote:
>> > On Mon 11-05-26 09:56:30, Sasha Levin wrote:
>> > > On Mon, May 11, 2026 at 03:49:24PM +0200, Michal Hocko wrote:
>> > > > On Mon 11-05-26 09:39:32, Sasha Levin wrote:
>> > > > > On Mon, May 11, 2026 at 03:07:51PM +0200, Michal Hocko wrote:
>> > > > > In a similar way to how they would know if a given livepatch is safe to apply -
>> > > > > ideally it would be communicated by the vendor/distro/kernel team.
>> > > >
>> > > > You have missed my point. KLP takes an extra steps to make sure patching
>> > > > a particular function is safe to modify or to put the change into the
>> > > > effect.
>> > >
>> > > Safety checks like making sure the patched function is on the stack, or did you
>> > > mean something else?
>> >
>> > Yes, exactly what LP infrastructure already provides.
>>
>> But do we actually need it here?
>
>If not then you can simply systemtap or use BPF to inject the code. In
>other words we have several ways how to runtime modify the kernel so
>before yet another interface is provided (with a non-trivial amount of
>code and very limited functionality) you should really start by
>describing why none of the existing one is fitting well.
>
>I do understand your argument that solutions based on loading a module
>might have an additional step to deal with (AFAIK you do not need to
>build your own kernel to deploy your key) is that a brohibitive
>roadblock? We also do have fault injection which is much less convenient
>because of all the existing constraines but can those be elevated?
>
>So nothing really against playing with ideas nad LLMs to generated a
>quick PoC. That is all good but for this to be considered more seriously
>I think we really need to think deeper whether the existing
>infrastructure is really not fitting and if not whether it could be
>changed to cover more usecase like the one you have mentioned here and I
>believe it is something worth thinking about.
Could you describe an existing infrastructure I can use here? Let's look at
this recent "Copy Fail" thing as an example.
I can obviously build my own kernel and enroll my own key, but 99.9% of our
users won't be doing that.
Livepatching, or manually building a module that just injects a kprobe is out
of the question as we previously agreed.
systemtap falls into the same bucket as building my own module.
BPF doesn't help because bpf_override_return() requires the target to be on the
same within_error_injection_list() whitelist as fault injection, and the CVE
targets never are. Some of our fleet doesn't even have BPF enabled either, but
that's the smaller objection.
I can't use fault injection because:
a. It's almost never built in production/distro kernels, and I suspect this
won't change.
b. The functions I need are not whitelisted.
c. Even if (a) and (b) were addressed, fault injection would still need a
securityfs front-end, a cmdline parser, a module-unload notifier, a taint flag,
and audit on engage and disengage. By the time those land in fail_function and
tie into/refactor the fault injection code, the net diff is bigger than this
proposal.
In my case I can remove the module, but not if I run a distro that shipped with
CONFIG_CRYPTO_USER_API_AEAD=y (like RHEL/SUSE).
I can use "initcall_blacklist=" hack and reboot, but as things stand today,
I'll need to be rebooting few times a day.
Even if I'm okay with rebooting that often (and I really really would prefer
not to), this doesn't solve the issues of a larger fleet of servers that can't
just reboot that often.
What am I missing?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-11 16:38 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, kvm, linux-doc,
linux-kernel, Sean Christopherson, Jim Mattson
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Raghavendra Rao Ananta, Eric Auger,
Kees Cook, Arnd Bergmann, Nathan Chancellor, linux-arm-kernel,
kvmarm, linux-kselftest
In-Reply-To: <6afc4b95-3c15-4d71-877d-19b84e91ce05@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]
On Mon, 2026-05-11 at 17:14 +0200, Paolo Bonzini wrote:
> On 5/11/26 10:57, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > Document the expectation that KVM maintains guest-visible compatibility
> > across host kernel upgrades and rollbacks. Specifically:
> >
> > - State saved/restored via KVM ioctls must be sufficient for live
> > migration (and live update) between kernel versions.
> >
> > - Where a new kernel introduces a guest-visible change, it provides a
> > mechanism for userspace to select the previous behaviour.
> >
> > - This allows both forward migration (upgrade) and backward migration
> > (rollback) of guests.
> >
> > These expectations have been implicitly required on x86 but were not
> > explicitly documented. Harmonise the expectations across all of KVM.
>
> One big part of achieving this on x86 is the handling of CPUID. Despite
> all the mess that KVM_SET_CPUID2 is (and sometimes the underlying
> architecture too, as Jim Mattson would certainly agree), KVM is
> generally able to provide a consistent view of its configuration to the
> guest. This doesn't quite extend to compatibility across vendors, but
> it does work across processor generations from either Intel or AMD.
Right. For x86 this is largely covered by CPUID. If you launch a guest
on a new kernel, using the same CPUID bits as an older kernel, then
your guest will mostly not see anything new. And will be migratable to
that older kernel without issue.
Not *everything* is in CPUID; one recent exception that comes to mind
is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the
existing behaviour of older kernels — even when that behaviour doesn't
make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would
*advertise* the feature, but not actually *implement* it. Nevertheless,
that remains the default behaviour of future kernels unless userspace
explicitly opts in to fully enable (or disable) the feature.
But this documentation update isn't even asking for that compatible-by-
default behaviour, even though that is the right thing to do. It's only
asking that it be *possible* to reinstate the old behaviour, for
userspace that *knows* about the change and explicitly wants to go back
to the old way to remain compatible.
And sadly, KVM/arm64 doesn't even meet *that* low bar.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] slab: fix kernel-docs for mm-api
From: Marco Elver @ 2026-05-11 16:34 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Vlastimil Babka (SUSE), Andrew Morton, Nathan Chancellor,
Nicolas Schier, Dennis Zhou, Tejun Heo, Christoph Lameter,
Harry Yoo, Hao Li, David Rientjes, Roman Gushchin, Kees Cook,
Gustavo A. R. Silva, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Alexander Potapenko, Dmitry Vyukov, Nick Desaulniers,
Bill Wendling, Justin Stitt, Miguel Ojeda, linux-kbuild,
linux-kernel, linux-mm, linux-hardening, kasan-dev, llvm,
linux-doc@vger.kernel.org
In-Reply-To: <871pfiw343.fsf@trenco.lwn.net>
On Mon, 11 May 2026 at 14:19, Jonathan Corbet <corbet@lwn.net> wrote:
>
> Marco Elver <elver@google.com> writes:
>
> > How about the below, i.e. adding type decls that only the kernel-doc
> > parser sees? One complication is also DECL_KMALLOC_PARAMS, and adding
> > kernel-doc parser hacks for that looks pretty awful, so this is a lot
> > cleaner.
>
> I'm going to be a while catching up with things, so this is just a first
> take. I strongly suspect that the people who object so strongly to
> documentation markup in general would be less than fully thrilled by the
> addition of this kind of workaround. I'd like to ponder a bit and see
> if I can some up with something better...but again, it won't happen
> right away.
Thanks, Jon.
The technical debt (hacks) that would accumulate in the kernel-doc
parser just for accommodating slab.h might be quite high; slab.h is
rather special, so the "#if 0" solution might be justified. Then
again, if there's a reasonable kernel-doc parser solution, that also
helps in other places, I won't object.
I tested the "#if 0" version and it works as expected. So to move
forward, we could consider it in the short term, and in the longer
term, see what new powers the kernel-doc parser can provide.
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Michal Hocko @ 2026-05-11 16:10 UTC (permalink / raw)
To: Sasha Levin
Cc: Breno Leitao, Andrew Morton, corbet, skhan, linux-doc,
linux-kernel, linux-kselftest, gregkh
In-Reply-To: <agH7_QBPLWKTZucB@laps>
On Mon 11-05-26 11:55:41, Sasha Levin wrote:
> On Mon, May 11, 2026 at 04:25:57PM +0200, Michal Hocko wrote:
> > On Mon 11-05-26 09:56:30, Sasha Levin wrote:
> > > On Mon, May 11, 2026 at 03:49:24PM +0200, Michal Hocko wrote:
> > > > On Mon 11-05-26 09:39:32, Sasha Levin wrote:
> > > > > On Mon, May 11, 2026 at 03:07:51PM +0200, Michal Hocko wrote:
> > > > > In a similar way to how they would know if a given livepatch is safe to apply -
> > > > > ideally it would be communicated by the vendor/distro/kernel team.
> > > >
> > > > You have missed my point. KLP takes an extra steps to make sure patching
> > > > a particular function is safe to modify or to put the change into the
> > > > effect.
> > >
> > > Safety checks like making sure the patched function is on the stack, or did you
> > > mean something else?
> >
> > Yes, exactly what LP infrastructure already provides.
>
> But do we actually need it here?
If not then you can simply systemtap or use BPF to inject the code. In
other words we have several ways how to runtime modify the kernel so
before yet another interface is provided (with a non-trivial amount of
code and very limited functionality) you should really start by
describing why none of the existing one is fitting well.
I do understand your argument that solutions based on loading a module
might have an additional step to deal with (AFAIK you do not need to
build your own kernel to deploy your key) is that a brohibitive
roadblock? We also do have fault injection which is much less convenient
because of all the existing constraines but can those be elevated?
So nothing really against playing with ideas nad LLMs to generated a
quick PoC. That is all good but for this to be considered more seriously
I think we really need to think deeper whether the existing
infrastructure is really not fitting and if not whether it could be
changed to cover more usecase like the one you have mentioned here and I
believe it is something worth thinking about.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH RFC v4 10/10] docs: iio: add documentation for ad9910 driver
From: Rodrigo Alencar @ 2026-05-11 16:01 UTC (permalink / raw)
To: David Lechner, Rodrigo Alencar, rodrigo.alencar, linux-iio,
devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <5bce7868-feca-4c54-a14d-ad4bf4072c29@baylibre.com>
On 26/05/11 10:23AM, David Lechner wrote:
> On 5/11/26 10:02 AM, Rodrigo Alencar wrote:
> > On 26/05/11 09:46AM, David Lechner wrote:
> >> On 5/10/26 4:30 AM, Rodrigo Alencar wrote:
> >>> On 26/05/09 06:42PM, David Lechner wrote:
> >>>> On 5/8/26 12:00 PM, Rodrigo Alencar via B4 Relay wrote:
> >>>>> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >>>>>
> >>>>> Add documentation for the AD9910 DDS IIO driver, which describes channels,
> >>>>> DDS modes, attributes and ABI usage examples.
...
> >>>> And a practical note, they should be "frequencyscale". I don't like that it is
> >>>> harder to read, but it is easier for a machine to parse.
> >>>
> >>> Parsers like the ones in libiio is not having problems with that.
> >>>
> >>>>> +Usage examples
> >>>>> +^^^^^^^^^^^^^^
> >>>>> +
> >>>>> +Set parallel port frequency modulation with a scale of 16 and a 50 MHz
> >>>>> +offset:
> >>>>> +
> >>>>> +.. code-block:: bash
> >>>>> +
> >>>>> + echo 16 > /sys/bus/iio/devices/iio:device0/out_altvoltage113_frequency_scale
> >>>>> + echo 50000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage113_frequency_offset
> >>>>> +
> >>>>> +Digital ramp generator (DRG)
> >>>>> +----------------------------
> >>>>> +
> >>>>> +The DRG produces linear frequency, phase or amplitude sweeps using dedicated
> >>>>> +hardware. It is controlled through three channels: a parent control channel
> >>>>> +(``digital_ramp_generator``) and two child ramp channels
> >>>>> +(``digital_ramp_up``, ``digital_ramp_down``). DRG destination is set when
> >>>>> +ramp attributes are written, i.e. writing to ``frequency`` or ``frequency_roc``
> >>>>> +sets the destination to frequency.
> >>>>
> >>>> Would it be better to say that the destination is set when the the
> >>>> value is non-zero? Otherwise, how would one change the destination
> >>>> once set?
> >>>
> >>> Destination is only one, so you just need to write phase or phase_roc, if you want
> >>> to target phase then. Does that not sound intuitive?
> >>
> >> I was thinking about if you needed to change the configuration.
> >> If you set it to phase, then want to change it to frequency, how
> >> could you do that if 0 is a valid value for phase?
> >>
> >> Also how could you know which is selected by reading back the
> >> values if 0 is a valid value?
> >
> > This is where Jonathan raised some concerns, so it is a good oportunity for you
> > to provide your inputs! Right now, I am returning -EBUSY on read of an attribute
> > where its destination is not selected. As pointed out, the destination selection
> > is happening when writting to the attribute. In the previous patch, Jonathan
> > suggested frequency_active, phase_active and scale_active to track mode priority,
> > and It could be leveraged here for DRG destination selection. I havent gone for
> > that because I was not willing to add that to all the channels given that it is
> > mostly used for debugging, so I added frequency_source, phase_source and
> > amplitude_source to debugfs instead.
>
> The "last write wins" with the others changing to EBUSY makes more sense to
> me now. If the docs said that, I missed it. Otherwise, that would be a helpful
> thing to add to the docs here.
>
> >
> > Destination selection for RAM mode is firmware based at this point.
>
> Seems reasonable.
>
> > Destination selection for Parallel mode is still not clear... could use
> > those *_active attributes or separate channels.
>
> Since there are _offset attributes proposed for parallel input already,
> could we just make it the same where you have to write one of those
> attributes?
Different from the DRG, both RAM and Parallel mode has this extra polar
destination, which targets both amplitude and phase at the same time.
For parallel mode I have the attributes:
- frequency_scale: applied when destination is frequency
- frequency_offset: applied when destination is frequency
- scale_offset: applied when destination is polar
- phase_offset: applied when destination is polar
In parallel mode, there aren't knobs like those for amplitude and phase
destinations. With the *_active thing or similar, polar can be both
phase_active and scale_active enabled at the same time. However, this
would not behave the same way Jonathan suggested, i.e. to be used for
mode priority indication... it would be used for destination configuration
instead.
>
> >
> >>>
> >>> Zero is a valid value to be written.
> >>>
> >>>>
> >
>
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* [PATCH net-next v4 2/2] dpll: zl3073x: report FFO as DPLL vs input reference offset
From: Ivan Vecera @ 2026-05-11 15:58 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Andrew Lunn, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jiri Pirko,
Jonathan Corbet, Leon Romanovsky, Mark Bloch, Michal Schmidt,
Paolo Abeni, Pasi Vaananen, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
In-Reply-To: <20260511155816.99936-1-ivecera@redhat.com>
Replace the per-reference frequency offset measurement (which was
redundant with measured-frequency) with a direct read of the DPLL's
delta frequency offset vs its tracked input reference.
The new implementation uses the dpll_df_offset_x register with
ref_ofst=1 via the dpll_df_read_x semaphore mechanism. This
provides 2^-48 resolution (~3.5 fE) and reports the actual
frequency difference between the DPLL and its active input.
Switch supported_ffo from DPLL_FFO_PORT_RXTX_RATE to
DPLL_FFO_PIN_DEVICE so FFO is reported only in the per-parent
context for the active input pin.
Use atomic64_t for freq_offset to prevent torn reads on 32-bit
architectures between the periodic worker and netlink callbacks.
Rewrite ffo_check to compare the cached df_offset converted to PPT
instead of using the old per-reference measurement. Remove the
ref_ffo_update periodic measurement and the ref ffo field since
they are no longer needed.
Changes v3 -> v4:
- Switch to DPLL_FFO_PIN_DEVICE, remove dpll=NULL guard
- Use atomic64_t for freq_offset (torn read on 32-bit)
Reviewed-by: Petr Oros <poros@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/chan.c | 31 +++++++++++++++++++++++--
drivers/dpll/zl3073x/chan.h | 14 ++++++++++++
drivers/dpll/zl3073x/core.c | 45 -------------------------------------
drivers/dpll/zl3073x/dpll.c | 38 ++++++++++++++-----------------
drivers/dpll/zl3073x/ref.h | 14 ------------
drivers/dpll/zl3073x/regs.h | 15 +++++++++++++
6 files changed, 75 insertions(+), 82 deletions(-)
diff --git a/drivers/dpll/zl3073x/chan.c b/drivers/dpll/zl3073x/chan.c
index 2f48ca2391494..2fe3c3da84bb5 100644
--- a/drivers/dpll/zl3073x/chan.c
+++ b/drivers/dpll/zl3073x/chan.c
@@ -18,6 +18,7 @@
int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index)
{
struct zl3073x_chan *chan = &zldev->chan[index];
+ u64 val;
int rc;
rc = zl3073x_read_u8(zldev, ZL_REG_DPLL_MON_STATUS(index),
@@ -25,8 +26,34 @@ int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index)
if (rc)
return rc;
- return zl3073x_read_u8(zldev, ZL_REG_DPLL_REFSEL_STATUS(index),
- &chan->refsel_status);
+ rc = zl3073x_read_u8(zldev, ZL_REG_DPLL_REFSEL_STATUS(index),
+ &chan->refsel_status);
+ if (rc)
+ return rc;
+
+ /* Read df_offset vs tracked reference */
+ rc = zl3073x_poll_zero_u8(zldev, ZL_REG_DPLL_DF_READ(index),
+ ZL_DPLL_DF_READ_SEM);
+ if (rc)
+ return rc;
+
+ rc = zl3073x_write_u8(zldev, ZL_REG_DPLL_DF_READ(index),
+ ZL_DPLL_DF_READ_SEM | ZL_DPLL_DF_READ_REF_OFST);
+ if (rc)
+ return rc;
+
+ rc = zl3073x_poll_zero_u8(zldev, ZL_REG_DPLL_DF_READ(index),
+ ZL_DPLL_DF_READ_SEM);
+ if (rc)
+ return rc;
+
+ rc = zl3073x_read_u48(zldev, ZL_REG_DPLL_DF_OFFSET(index), &val);
+ if (rc)
+ return rc;
+
+ chan->df_offset = sign_extend64(val, 47);
+
+ return 0;
}
/**
diff --git a/drivers/dpll/zl3073x/chan.h b/drivers/dpll/zl3073x/chan.h
index 481da2133202b..4353809c69122 100644
--- a/drivers/dpll/zl3073x/chan.h
+++ b/drivers/dpll/zl3073x/chan.h
@@ -17,6 +17,7 @@ struct zl3073x_dev;
* @ref_prio: reference priority registers (4 bits per ref, P/N packed)
* @mon_status: monitor status register value
* @refsel_status: reference selection status register value
+ * @df_offset: frequency offset vs tracked reference in 2^-48 steps
*/
struct zl3073x_chan {
struct_group(cfg,
@@ -26,6 +27,7 @@ struct zl3073x_chan {
struct_group(stat,
u8 mon_status;
u8 refsel_status;
+ s64 df_offset;
);
};
@@ -37,6 +39,18 @@ int zl3073x_chan_state_set(struct zl3073x_dev *zldev, u8 index,
int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index);
+/**
+ * zl3073x_chan_df_offset_get - get cached df_offset vs tracked reference
+ * @chan: pointer to channel state
+ *
+ * Return: frequency offset in 2^-48 steps
+ */
+static inline s64
+zl3073x_chan_df_offset_get(const struct zl3073x_chan *chan)
+{
+ return chan->df_offset;
+}
+
/**
* zl3073x_chan_mode_get - get DPLL channel operating mode
* @chan: pointer to channel state
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
index 5f1e70f3e40a0..b3345060490db 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -704,44 +704,6 @@ zl3073x_ref_freq_meas_update(struct zl3073x_dev *zldev)
return 0;
}
-/**
- * zl3073x_ref_ffo_update - update reference fractional frequency offsets
- * @zldev: pointer to zl3073x_dev structure
- *
- * The function asks device to latch the latest measured fractional
- * frequency offset values, reads and stores them into the ref state.
- *
- * Return: 0 on success, <0 on error
- */
-static int
-zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
-{
- int i, rc;
-
- rc = zl3073x_ref_freq_meas_latch(zldev,
- ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
- if (rc)
- return rc;
-
- /* Read DPLL-to-REFx frequency offset measurements */
- for (i = 0; i < ZL3073X_NUM_REFS; i++) {
- s32 value;
-
- /* Read value stored in units of 2^-32 signed */
- rc = zl3073x_read_u32(zldev, ZL_REG_REF_FREQ(i), &value);
- if (rc)
- return rc;
-
- /* Convert to ppt
- * ffo = (10^12 * value) / 2^32
- * ffo = ( 5^12 * value) / 2^20
- */
- zldev->ref[i].ffo = mul_s64_u64_shr(value, 244140625, 20);
- }
-
- return 0;
-}
-
static void
zl3073x_dev_periodic_work(struct kthread_work *work)
{
@@ -776,13 +738,6 @@ zl3073x_dev_periodic_work(struct kthread_work *work)
}
}
- /* Update references' fractional frequency offsets */
- rc = zl3073x_ref_ffo_update(zldev);
- if (rc)
- dev_warn(zldev->dev,
- "Failed to update fractional frequency offsets: %pe\n",
- ERR_PTR(rc));
-
list_for_each_entry(zldpll, &zldev->dplls, list)
zl3073x_dpll_changes_check(zldpll);
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index 05e63661bf074..cff85cdb9d0e5 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/atomic.h>
#include <linux/bits.h>
#include <linux/bitfield.h>
#include <linux/bug.h>
@@ -57,7 +58,7 @@ struct zl3073x_dpll_pin {
s32 phase_gran;
enum dpll_pin_operstate operstate;
s64 phase_offset;
- s64 freq_offset;
+ atomic64_t freq_offset;
u32 measured_freq;
};
@@ -300,7 +301,10 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
{
struct zl3073x_dpll_pin *pin = pin_priv;
- ffo->ffo = pin->freq_offset;
+ if (pin->operstate != DPLL_PIN_OPERSTATE_ACTIVE)
+ return -ENODATA;
+
+ ffo->ffo = atomic64_read(&pin->freq_offset);
return 0;
}
@@ -1275,7 +1279,7 @@ zl3073x_dpll_freq_monitor_set(const struct dpll_device *dpll,
}
static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
- .supported_ffo = BIT(DPLL_FFO_PORT_RXTX_RATE),
+ .supported_ffo = BIT(DPLL_FFO_PIN_DEVICE),
.direction_get = zl3073x_dpll_pin_direction_get,
.esync_get = zl3073x_dpll_input_pin_esync_get,
.esync_set = zl3073x_dpll_input_pin_esync_set,
@@ -1731,37 +1735,29 @@ zl3073x_dpll_pin_phase_offset_check(struct zl3073x_dpll_pin *pin)
}
/**
- * zl3073x_dpll_pin_ffo_check - check for pin fractional frequency offset change
+ * zl3073x_dpll_pin_ffo_check - check for FFO change on active pin
* @pin: pin to check
*
- * Check for the given pin's fractional frequency change.
- *
- * Return: true on fractional frequency offset change, false otherwise
+ * Return: true on change, false otherwise
*/
static bool
zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
{
struct zl3073x_dpll *zldpll = pin->dpll;
struct zl3073x_dev *zldev = zldpll->dev;
- const struct zl3073x_ref *ref;
- u8 ref_id;
+ const struct zl3073x_chan *chan;
s64 ffo;
- /* Get reference monitor status */
- ref_id = zl3073x_input_pin_ref_get(pin->id);
- ref = zl3073x_ref_state_get(zldev, ref_id);
-
- /* Do not report ffo changes if the reference monitor report errors */
- if (!zl3073x_ref_is_status_ok(ref))
+ if (pin->operstate != DPLL_PIN_OPERSTATE_ACTIVE)
return false;
- /* Compare with previous value */
- ffo = zl3073x_ref_ffo_get(ref);
- if (pin->freq_offset != ffo) {
- dev_dbg(zldev->dev, "%s freq offset changed: %lld -> %lld\n",
- pin->label, pin->freq_offset, ffo);
- pin->freq_offset = ffo;
+ chan = zl3073x_chan_state_get(zldpll->dev, zldpll->id);
+ ffo = mul_s64_u64_shr(zl3073x_chan_df_offset_get(chan),
+ 244140625, 36);
+ if (atomic64_xchg(&pin->freq_offset, ffo) != ffo) {
+ dev_dbg(zldev->dev, "%s freq offset changed to: %lld\n",
+ pin->label, ffo);
return true;
}
diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
index 55e80e4f08734..e140ca3ea17dc 100644
--- a/drivers/dpll/zl3073x/ref.h
+++ b/drivers/dpll/zl3073x/ref.h
@@ -22,7 +22,6 @@ struct zl3073x_dev;
* @freq_ratio_n: FEC mode divisor
* @sync_ctrl: reference sync control
* @config: reference config
- * @ffo: current fractional frequency offset
* @meas_freq: measured input frequency in Hz
* @mon_status: reference monitor status
*/
@@ -40,7 +39,6 @@ struct zl3073x_ref {
u8 config;
);
struct_group(stat, /* Status */
- s64 ffo;
u32 meas_freq;
u8 mon_status;
);
@@ -58,18 +56,6 @@ int zl3073x_ref_state_update(struct zl3073x_dev *zldev, u8 index);
int zl3073x_ref_freq_factorize(u32 freq, u16 *base, u16 *mult);
-/**
- * zl3073x_ref_ffo_get - get current fractional frequency offset
- * @ref: pointer to ref state
- *
- * Return: the latest measured fractional frequency offset
- */
-static inline s64
-zl3073x_ref_ffo_get(const struct zl3073x_ref *ref)
-{
- return ref->ffo;
-}
-
/**
* zl3073x_ref_meas_freq_get - get measured input frequency
* @ref: pointer to ref state
diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h
index 8015808bdf548..9578f00095282 100644
--- a/drivers/dpll/zl3073x/regs.h
+++ b/drivers/dpll/zl3073x/regs.h
@@ -164,6 +164,11 @@
#define ZL_DPLL_MODE_REFSEL_MODE_NCO 4
#define ZL_DPLL_MODE_REFSEL_REF GENMASK(7, 4)
+#define ZL_REG_DPLL_DF_READ(_idx) \
+ ZL_REG_IDX(_idx, 5, 0x28, 1, ZL3073X_MAX_CHANNELS, 1)
+#define ZL_DPLL_DF_READ_SEM BIT(4)
+#define ZL_DPLL_DF_READ_REF_OFST BIT(3)
+
#define ZL_REG_DPLL_MEAS_CTRL ZL_REG(5, 0x50, 1)
#define ZL_DPLL_MEAS_CTRL_EN BIT(0)
#define ZL_DPLL_MEAS_CTRL_AVG_FACTOR GENMASK(7, 4)
@@ -176,6 +181,16 @@
#define ZL_REG_DPLL_PHASE_ERR_DATA(_idx) \
ZL_REG_IDX(_idx, 5, 0x55, 6, ZL3073X_MAX_CHANNELS, 6)
+/*******************************
+ * Register Pages 6-7, DPLL Data
+ *******************************/
+
+#define ZL_REG_DPLL_DF_OFFSET_03(_idx) \
+ ZL_REG_IDX(_idx, 6, 0x00, 6, 4, 0x20)
+#define ZL_REG_DPLL_DF_OFFSET_4 ZL_REG(7, 0x00, 6)
+#define ZL_REG_DPLL_DF_OFFSET(_idx) \
+ ((_idx) < 4 ? ZL_REG_DPLL_DF_OFFSET_03(_idx) : ZL_REG_DPLL_DF_OFFSET_4)
+
/***********************************
* Register Page 9, Synth and Output
***********************************/
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox