* Re: [PATCH v10 19/30] KVM: arm64: Provide assembly for SME register access
From: Mark Rutland @ 2026-05-21 14:51 UTC (permalink / raw)
To: Mark Brown, Oliver Upton, Marc Zyngier
Cc: Joey Gouly, Catalin Marinas, Suzuki K Poulose, Will Deacon,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, Dave Martin,
Fuad Tabba, Ben Horgan, linux-arm-kernel, kvmarm, linux-kernel,
kvm, linux-doc, linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <20260306-kvm-arm64-sme-v10-19-43f7683a0fb7@kernel.org>
On Fri, Mar 06, 2026 at 05:01:11PM +0000, Mark Brown wrote:
> Provide versions of the SME state save and restore functions for the
> hypervisor to allow it to restore ZA and ZT for guests.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/include/asm/kvm_hyp.h | 2 ++
> arch/arm64/kvm/hyp/fpsimd.S | 23 +++++++++++++++++++++++
> 2 files changed, 25 insertions(+)
While this specific instance is simple enough, I don't think we should
continue to duplicate the low level save/restore routines between the
main kernel and KVM hyp code.
I've sent a series that avoids the need for this, and cleans up some
other bits):
https://lore.kernel.org/linux-arm-kernel/20260521132556.584676-1-mark.rutland@arm.com/
Assuming Marc and Oliver are on board, I'd prefer that we do that
cleanup first, and build the KVM SME support atop.
Mark.
>
> diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
> index 0317790dd3b7..9b1354d1122c 100644
> --- a/arch/arm64/include/asm/kvm_hyp.h
> +++ b/arch/arm64/include/asm/kvm_hyp.h
> @@ -116,6 +116,8 @@ void __fpsimd_save_state(struct user_fpsimd_state *fp_regs);
> void __fpsimd_restore_state(struct user_fpsimd_state *fp_regs);
> void __sve_save_state(void *sve_pffr, u32 *fpsr, int save_ffr);
> void __sve_restore_state(void *sve_pffr, u32 *fpsr, int restore_ffr);
> +void __sme_save_state(void const *state, bool save_zt);
> +void __sme_restore_state(void const *state, bool restore_zt);
>
> u64 __guest_enter(struct kvm_vcpu *vcpu);
>
> diff --git a/arch/arm64/kvm/hyp/fpsimd.S b/arch/arm64/kvm/hyp/fpsimd.S
> index 6e16cbfc5df2..18b7a666016c 100644
> --- a/arch/arm64/kvm/hyp/fpsimd.S
> +++ b/arch/arm64/kvm/hyp/fpsimd.S
> @@ -29,3 +29,26 @@ SYM_FUNC_START(__sve_save_state)
> sve_save 0, x1, x2, 3
> ret
> SYM_FUNC_END(__sve_save_state)
> +
> +SYM_FUNC_START(__sme_save_state)
> + // Caller needs to ensure SMCR updates are visible
> + _sme_rdsvl 2, 1 // x2 = VL/8
> + sme_save_za 0, x2, 12 // Leaves x0 pointing to the end of ZA
> +
> + cbz x1, 1f
> + _str_zt 0
> +1:
> + ret
> +SYM_FUNC_END(__sme_save_state)
> +
> +SYM_FUNC_START(__sme_restore_state)
> + // Caller needs to ensure SMCR updates are visible
> + _sme_rdsvl 2, 1 // x2 = VL/8
> + sme_load_za 0, x2, 12 // Leaves x0 pointing to end of ZA
> +
> + cbz x1, 1f
> + _ldr_zt 0
> +
> +1:
> + ret
> +SYM_FUNC_END(__sme_restore_state)
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v14 00/28] Add new general DRM property "color format"
From: Daniel Stone @ 2026-05-21 14:53 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, wayland-devel, Werner Sembach,
Andri Yngvason, Cristian Ciocaltea, Marius Vlad, Dmitry Baryshkov,
Andy Yan
In-Reply-To: <20260423-color-format-v14-0-449a419ccbd4@collabora.com>
Hi there,
On Thu, 23 Apr 2026 at 20:04, Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
> We have an implementation in Weston at
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1825 that
> adds support for this property. This patch series has been tested
> against that MR on i915 (HDMI, DP), amdgpu (HDMI, DP) and on rockchip
> (HDMI).
This MR is R-b me.
> General notes on the approach taken by me: instead of silently switching
> to a different format than was explicitly requested, or even worse,
> outputting something to the sink the sink doesn't support, bubble up an
> error to userspace instead. "color format" is a "I want this" type
> property, not a "force this" type property, i.e. the kernel will respect
> the limits imposed by the hardware.
Yes! If userspace wants a fallback chain, it should encode it itself
through a series of test commits, rather than adding the sequential
logic to the kernel. Doing that might work for one axis, but pretty
quickly disintegrates when there are multiple parameters to perhaps
fall back on.
I had minor comments on 03 and 20, but they're Rb me with the obvious
fixes. 11, 12, and 19 are Acked-by me, as I don't quite know the
hardware specifics well enough to say. The rest are Reviewed-by me.
I suggest you merge the common code and VOP2/DW-QP implementations via
drm-misc, leaving Intel and AMD to merge through their own trees
whenever they're ready. We'll merge the Weston implementation when it
lands in DRM.
Thanks to you and all prior cooks for all the work, and to Maxime and
Dmitry for the help and review as well.
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH mm-unstable v17 04/14] mm/khugepaged: generalize __collapse_huge_page_* for mTHP support
From: Lorenzo Stoakes @ 2026-05-21 14:59 UTC (permalink / raw)
To: Nico Pache
Cc: David Hildenbrand (Arm), Wei Yang, Lance Yang, linux-doc,
linux-kernel, linux-mm, linux-trace-kernel, aarcange, akpm,
anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
liam, mathieu.desnoyers, matthew.brost, mhiramat, mhocko, peterx,
pfalcato, rakie.kim, raquini, rdunlap, rientjes, rostedt, rppt,
ryan.roberts, shivankg, sunnanyong, surenb, thomas.hellstrom,
tiwai, usamaarif642, vbabka, vishal.moola, wangkefeng.wang, will,
willy, yang, ying.huang, ziy, zokeefe
In-Reply-To: <CAA1CXcCNT51jeXh6Kwg1QN9e+AJB-1hg21kmeY6fTTKr2GACug@mail.gmail.com>
On Tue, May 19, 2026 at 01:05:13PM -0600, Nico Pache wrote:
> On Mon, May 18, 2026 at 1:33 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Mon, May 18, 2026 at 03:16:11PM +0200, David Hildenbrand (Arm) wrote:
> > > > For me, I would vote for fallback to 0.
> > >
> > > At this point I'll prefer to not return errors from collapse_max_ptes_none().
> > > It's just rather awkward to return an error deep down in collapse code for a
> > > configuration problem.
> > >
> > > For mthp collapse, we only support max_ptes_none==0 and
> > > max_ptes_none=="HPAGE_PMD_NR - 1" (default).
> > >
> > > If another value is specified while collapsing mTHP, print a warning and treat
> > > it as 0 (save value, no creep, no memory waste).
> > >
> > > In a sense, this is similar to how we handle max_ptes_shared + max_ptes_swap:
> > > for mTHP: we always treat them as being 0 for mTHP collapse (and don't issue a
> > > warning, because we would issue a warning with the default settings).
> > >
> > > @Lorenzo, fine with you?
> >
> > Yes 100%, this sounds sensible both in terms of the error and the default. Let's
> > keep our lives simple(-ish) please :)
>
> Ok thank you im glad we finally came to consensus on this! phew!
>
It happens sometimes ;)
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v7 2/6] mm/memory-failure: surface unhandlable kernel pages as -ENOTRECOVERABLE
From: Breno Leitao @ 2026-05-21 15:09 UTC (permalink / raw)
To: Lance Yang
Cc: linmiaohe, akpm, david, ljs, vbabka, rppt, surenb, mhocko, shuah,
nao.horiguchi, rostedt, mhiramat, mathieu.desnoyers, corbet,
skhan, liam, linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team
In-Reply-To: <f76b79d3-080a-4931-873e-99d4b3e1020f@linux.dev>
On Sat, May 16, 2026 at 12:06:14PM +0800, Lance Yang wrote:
>
>
> On 2026/5/15 21:13, Breno Leitao wrote:
> [...]
> > >
> > > Wonder if it would be simpler to just do a positive check near the top
> > > of get_any_page() instead. Something like:
> > >
> > > static bool hwpoison_unrecoverable_kernel_page(struct page *page,
> > > unsigned long flags)
> >
> > Ack. We probably want to call it something like HWPoisonKernelOwned() to
> > follow the same naming sematics of these helpers, such as HWPoisonHandlable()
> >
> > By the way, I will re-include the self test back to this patch series,
> > In case they are not useful, we do not merge it.
> >
>
> Sounds good :)
>
> Can you also test the relevant page types if possible, especially
> the ones the new helper is supposed to classify?
Ack. I will expand the test to cover different page types as well!
Thanks,
--breno
^ permalink raw reply
* Re: [PATCH v10 19/30] KVM: arm64: Provide assembly for SME register access
From: Mark Brown @ 2026-05-21 15:17 UTC (permalink / raw)
To: Mark Rutland
Cc: Oliver Upton, Marc Zyngier, Joey Gouly, Catalin Marinas,
Suzuki K Poulose, Will Deacon, Paolo Bonzini, Jonathan Corbet,
Shuah Khan, Dave Martin, Fuad Tabba, Ben Horgan, linux-arm-kernel,
kvmarm, linux-kernel, kvm, linux-doc, linux-kselftest,
Peter Maydell, Eric Auger
In-Reply-To: <ag8b7oq4SFpdmlP_@J2N7QTR9R3>
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
On Thu, May 21, 2026 at 03:51:26PM +0100, Mark Rutland wrote:
> While this specific instance is simple enough, I don't think we should
> continue to duplicate the low level save/restore routines between the
> main kernel and KVM hyp code.
> I've sent a series that avoids the need for this, and cleans up some
> other bits):
> https://lore.kernel.org/linux-arm-kernel/20260521132556.584676-1-mark.rutland@arm.com/
> Assuming Marc and Oliver are on board, I'd prefer that we do that
> cleanup first, and build the KVM SME support atop.
Yeah, I've got a laundry list of things that I want to improve with both
the main kernel and KVM but the latency on getting anything reviewed
with both sides and sometimes obscure implementation decisions means
I've been waiting until this is landed first.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 09/13] ima: Add support for staging measurements with prompt
From: Mimi Zohar @ 2026-05-21 15:18 UTC (permalink / raw)
To: Roberto Sassu, corbet, skhan, dmitry.kasatkin, eric.snowberg,
paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, chenste, nramas, Roberto Sassu
In-Reply-To: <20260429160319.4162918-10-roberto.sassu@huaweicloud.com>
On Wed, 2026-04-29 at 18:03 +0200, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Introduce the ability of staging the IMA measurement list and deleting them
> with a prompt.
>
> Staging means moving the current content of the measurement list to a
-> moving the current measurement list records ...
> separate location, and allowing users to read and delete it. This causes
> the measurement list to be atomically truncated before new measurements can
> be added.
The wording is a bit off - "before new measurements can be added". One of the
main objectives of staging the measurement list is to allow new measurement
records to continue to be added to the measurement list, while the staged
measurements are exported.
> Staging can be done only once at a time. In the event of kexec(),
> staging is reverted and staged entries will be carried over to the new
> kernel.
>
> Introduce ascii_runtime_measurements_<algo>_staged and
> binary_runtime_measurements_<algo>_staged interfaces to access and delete
> the measurements. Also, add write permission to the original measurement
> interfaces.
Wondering if adding "write" permission to the original measurement interface
will change based on your 9/13 comment.
The patch, like others in this patch set, are well written. There are a couple
of inline comments. I'll defer reviewing the rest of this patch to v6.
>
> Use 'echo A > <IMA original interface>' and
> 'echo D > <IMA _staged interface>' to respectively stage and delete the
> entire measurements list. Locking of these interfaces is also mediated with
> a call to _ima_measurements_open() and with ima_measurements_release().
>
> Implement the staging functionality by introducing the new global
> measurements list ima_measurements_staged, and ima_queue_stage() and
> ima_queue_staged_delete_all() to respectively move measurements from the
> current measurements list to the staged one, and to move staged
> measurements to the ima_measurements_trim list for deletion. Introduce
> ima_queue_delete() to delete the measurements.
>
> Finally, introduce the BINARY_STAGED and BINARY_FULL binary measurements
> list types, to maintain the counters and the binary size of staged
> measurements and the full measurements list (including entries that were
> staged). BINARY still represents the current binary measurements list.
>
> Use the binary size for the BINARY + BINARY_STAGED types in
> ima_add_kexec_buffer(), since both measurements list types are copied to
> the secondary kernel during kexec. Use BINARY_FULL in
> ima_measure_kexec_event(), to generate a critical data record.
>
> It should be noted that the BINARY_FULL counter is not passed through
> kexec. Thus, the number of entries included in the kexec critical data
> records refers to the entries since the previous kexec records.
>
> Note: This code derives from the Alt-IMA Huawei project, whose license is
> GPL-2.0 OR MIT.
>
> Link: https://github.com/linux-integrity/linux/issues/1
> Suggested-by: Gregory Lumen <gregorylumen@linux.microsoft.com> (staging revert)
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> ---
> security/integrity/ima/Kconfig | 13 +++
> security/integrity/ima/ima.h | 8 +-
> security/integrity/ima/ima_fs.c | 181 ++++++++++++++++++++++++++---
> security/integrity/ima/ima_kexec.c | 24 +++-
> security/integrity/ima/ima_queue.c | 97 +++++++++++++++-
> 5 files changed, 302 insertions(+), 21 deletions(-)
>
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 862fbee2b174..48c906793efb 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -332,4 +332,17 @@ config IMA_KEXEC_EXTRA_MEMORY_KB
> If set to the default value of 0, an extra half page of memory for those
> additional measurements will be allocated.
>
> +config IMA_STAGING
> + bool "Support for staging the measurements list"
> + default y
Exporting and deleting the IMA measurement list carries an inherent security
risk: if the measurements are not durably stored before deletion, they are
permanently lost. Deletion should be treated as experimental until a trusted
service exists to guarantee safe storage.
Please change the default to 'n'.
> + help
> + Add support for staging the measurements list.
> +
> + It allows user space to stage the measurements list for deletion and
> + to delete the staged measurements after confirmation.
> +
> + On kexec, staging is reverted and staged measurements are prepended
-> staging is aborted and any staged measurement records are .copied ..
> + to the current measurements list when measurements are copied to the
> + secondary kernel.
> +
> endif
Mimi
^ permalink raw reply
* RE: [PATCH net-next 2/5] net: ethernet: oa_tc6: Allow custom mii_bus
From: Regus, Ciprian @ 2026-05-21 15:26 UTC (permalink / raw)
To: Andrew Lunn, Selvamani Rajagopal
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <77df32ed-3e22-4e9b-941b-3046de25b88f@lunn.ch>
> > > This all seems pretty invasive and ugly. Please could you think what
> > > happens if instead of passing in an mdiobus, you pass a phydev. Is the
> > > change to the core simpler and cleaner?
> > >
> > > Andrew
> >
>
> > Kind of agree. Initially we were thinking about changing the
> > existing code (Microchip's vendor code) to alloc mii_bus so that
> > code would be same across multiple vendors. Either way, it would be
> > invasive changes. So, we decide to go with minimal change to other
> > vendor's code.
>
> That would be wrong. The standard defines this, so it should be in the
> core. Anything which the standard defines should be in the core, so
> that drivers for hardware which actually follow the standard are
> minimal. Also, we try to keep workarounds for broken hardware out of
> the core, hide it in the driver. That is not always possible, but the
> aim should be to make the core clean. We don't want to penalise
> vendors which got the implementation correct because of vendors who
> got is wrong.
>
> > Trying to understand your suggestion. Are you suggesting to move
> > entire mii_bus allocation/APIs implementation to vendor side and
> > keep only phy dev usage in oa_tc6.c?
>
> No. I'm thinking maybe extend oa_tc6_init, similar to what you
> did. Add a quirks flag, and define TC6_QUIRK_BROKEN_PHY. And allow a
> phydev to be passed as well.
>
> If the quirk is set, don't call oa_tc6_mdiobus_register() or
> phy_find_first(), nor oa_tc6_mdiobus_unregister().
>
The issue I can see with this approach is that we should have already registered
the mii_bus and read a valid PHY id from the device, before passing the phy_device to
to oa_tc_init(). Scanning the mdio bus requires OA TC6 SPI transfers (reading registers 0xFF02
and 0xFF03), while oa_tc6 has not yet initialized. For the ADIN1140 driver this is not an issue,
because we can return cached values for the PHY id, as you suggested. However, that limits
the usefulness of the BROKEN_PHY flag, because every new driver that cannot use the default
init sequence in oa_tc6 (and wants to set the BROKEN_PHY flag) has to fit this specific case.
I think the approach which involves the least amount of changes in the core would be for oa_tc6
to skip the oa_tc6_phy_init() and oa_tc6_phy_exit() if the BROKEN_PHY quirk flag is set and
leave it to the drivers using oa_tc6 to handle the mii_bus alloc/register/unregister/free and
phy_connect()/disconnect().
These would be the only changes in the core's phy handling path (besides adding the flag itself):
@@ -585,10 +586,13 @@ static int oa_tc6_phy_init(struct oa_tc6 *tc6)
{
int ret;
+ if (tc6->quirk_flags & OA_TC6_BROKEN_PHY)
+ return 0;
+
ret = oa_tc6_check_phy_reg_direct_access_capability(tc6);
if (ret) {
netdev_err(tc6->netdev,
"Direct PHY register access is not supported by the MAC-PHY\n");
return ret;
}
...
}
static void oa_tc6_phy_exit(struct oa_tc6 *tc6)
{
+ if (tc6->quirk_flags & OA_TC6_BROKEN_PHY)
+ return;
+
phy_disconnect(tc6->phydev);
oa_tc6_mdiobus_unregister(tc6);
}
> You probably want to start with a patch which breaks oa_tc6_phy_init()
> into two, since you still need the phy_connect_direct() and
> phy_attached_info(). Then add the quirk, and lastly your driver making
> use of the quirk.
>
> The quirks flag could also be used for devices which have MMD 30
> mapped into a vendor reserved MMS.
>
> Andrew
^ permalink raw reply
* Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-21 15:31 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Song Liu, linux-kernel, linux-doc, linux-kselftest, bpf,
live-patching, Greg Kroah-Hartman, Andrew Morton, Jonathan Corbet,
Mathieu Desnoyers, Joshua Peisach, Florian Weimer, Breno Leitao,
Anthony Iliopoulos, Michal Hocko, Jiri Olsa, John Fastabend,
Christian Brauner, KP Singh
In-Reply-To: <3dd6d852-18fb-4c64-a1ae-0d79ef7c061f@iogearbox.net>
On Thu, May 21, 2026 at 11:11:16AM +0200, Daniel Borkmann wrote:
>On 5/19/26 9:57 PM, Sasha Levin wrote:
>>Sure, this would also work. How do you see this happening? Can we let a certain
>>user/pid/etc disable the allowlist if they choose to?
>
>I don't think we should, given then we're back to square one where root
>or some other user would be able to just override/bypass an LSM.
killswitch already disables itself when lockdown is active. We can easily
disable it too when one of the LSMs that cares about this is active.
>[...]
>>How do you see this working with the allowlist?
>
>We should look at the underlying areas where most of the CVE-like fixes
>took place (these days should be more easily doable given Claude and friends)
>and based on that either extend ALLOW_ERROR_INJECTION() or (better) create
>new hooks which BPF LSM can consume where you can then have a policy to reject
>requests and tighten the attack surface. For example, the AF_ALG stuff you
So we could grow the LSM tentacles deeper into the kernel, and we can see where
current CVEs are happening, which I suspect is the darker corners of the kernel
(old unmaintained, rarely used code), but this definitely won't stay the case,
right? Newer and better LLMs will discover issues elsewhere, and once the low
hanging fruits are picked off of the current target subsystems, researchers
will move elsewhere. We will be dooming ourselves to an endless cat and mouse
game where we go add LSM hooks after some big security issue goes public.
One question I had here: how would we tackle security issues with BPF itself?
>can already easily cover today ...
>
>#include "vmlinux.h"
>#include <bpf/bpf_helpers.h>
>#include <bpf/bpf_tracing.h>
>
>#define AF_ALG 38
>#define EPERM 1
>
>char _license[] SEC("license") = "Dual BSD/GPL";
>
>SEC("lsm/socket_create")
>int BPF_PROG(block_af_alg, int family, int type, int protocol, int kern)
>{
> if (family == AF_ALG)
> return -EPERM;
> return 0;
>}
>
>... the problem is that distros enable and pull in all sort of crap which
>then non-root could pull in via request_module() as an example; similarly
>for netlink we want to have a BPF LSM policy to parse into netlink requests
>and then reject based on certain attribute matching (both on our todo list)
>which would have helped in case of exotic tc cls/act/qdisc modules to prevent
>them to be pulled from userns. I bet there are a ton more examples once we
>look further into the data.
I definitely agree that BPF is a much nicer hammer than the simple killswitch
implementation. I've actually been (privately) playing with an out of tree
killswitch that also supports BPF. I've pushed the (hacky) code I have to
https://github.com/sashalevin/killswitch , and you can see an example of a BPF
mitigation similar to the one you have above:
https://github.com/sashalevin/killswitch/blob/master/mitigations/cve-2025-21703.sh
My concern is mostly with the whitelist approach.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Simon Schuster @ 2026-05-21 15:37 UTC (permalink / raw)
To: Arnd Bergmann, Dinh Nguyen, Wolfram Sang, Miguel Ojeda
Cc: Ethan Nelson-Moore, Peter Zijlstra, linux-doc, devicetree,
workflows, Linux-Arch, dmaengine, linux-i2c, linux-iio, Netdev,
linux-pci, linux-pwm, linux-hardening, linux-kbuild,
linux-csky@vger.kernel.org, Jonathan Corbet, Shuah Khan,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Alex Shi, Yanteng Si, Dongliang Mu, Hu Haowen,
Kees Cook, Oleg Nesterov, Will Deacon, Aneesh Kumar K.V (Arm),
Andrew Morton, Nicholas Piggin, Vinod Koul, Frank Li,
Dave Penkler, Andi Shyti, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lorenzo Pieralisi,
Krzysztof WilczyDski, Andreas Oetken
In-Reply-To: <76af64fa-7820-4d92-8aa9-826c3bd812a1@app.fastmail.com>
Hi Arnd, Dinh, Wolfram, and Miguel,
thank you for your explanations and encouragement; I've now sent my
application for co-maintainership for arch/nios2 to you, Dinh.
On Wed, May 20, 2026 at 09:06:33AM +0200, Arnd Bergmann wrote:
> I think that is a reasonable target. We have a bunch of embedded
> architectures that have a similarly small user base and I expect
> that we will want to remove most of them at some point, as we did
> for seven architectures in linux-4.17.
>
> As long as there is a maintainer for nios2 and it's not actively
> getting in the way of a specific treewide change, I don't see any
> reason to remove this any earlier than the other ones.
>
> Obviously at some point nios2 will have to get removed because
> of the limit to gcc-14 or older, but that should not be a problem
> for the next few LTS releases.
This all sounds quite reasonable, including the toolchain
considerations. Thank you for the offer to keep it around a bit.
If any issues arise with tree-wide changes I'd be happy to look into
what can be done on the arch/nios2 side; now that the issues should
reliably reach me via mail.
> > Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
> > unsure about the netiquette (can I simply do so by self-proclamation? At
> > least the git history seems to suggest so...).
>
> Dinh already replied that he welcomes the help, and I also suggested
> the same thing a year ago. As the only known user that has contributed
> patches in a long time, you are obviously qualified.
>
> Sending a patch for the MAINTAINERS file to Dinh is the first step,
> once he has sent that upstream, you can (optionally) apply for
> kernel.org account that would let you host a git tree on kernel.org
> or have a tree that you both have access to.
I've sent the patch, I'm sure we can work everything else out from
there.
Best regards,
Simon
^ permalink raw reply
* Re: (subset) [PATCH v7 00/10] Support for Samsung S2MU005 PMIC and its sub-devices
From: Lee Jones @ 2026-05-21 16:01 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, Yassine Oudjana,
Kaustabh Chakraborty
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Conor Dooley, Krzysztof Kozlowski
In-Reply-To: <20260516-s2mu005-pmic-v7-0-73f9702fb461@disroot.org>
On Sat, 16 May 2026 03:08:32 +0530, Kaustabh Chakraborty wrote:
> S2MU005 is an MFD chip manufactured by Samsung Electronics. This is
> found in various devices manufactured by Samsung and others, including
> all Exynos 7870 devices. It is known to have the following features:
>
> 1. Two LED channels with adjustable brightness for use as a torch, or a
> flash strobe.
> 2. An RGB LED with 8-bit channels. Usually programmed as a notification
> indicator.
> 3. An MUIC, which works with USB micro-B (and USB-C?). For the micro-B
> variant though, it measures the ID-GND resistance using an internal
> ADC.
> 4. A charger device, which reports if charger is online, voltage,
> resistance, etc.
>
> [...]
Applied, thanks!
[03/10] dt-bindings: mfd: add documentation for S2MU005 PMIC
commit: 12479cc3750c6b741b6d87392e393d959cf2f013
[04/10] mfd: sec: add support for S2MU005 PMIC
commit: aeff14ae7271cc3070312f894de9a4e075855d31
[05/10] mfd: sec: set DMA coherent mask
commit: ba1f536070abd595a141c683f617eed3c6e42297
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH v7 00/10] Support for Samsung S2MU005 PMIC and its sub-devices
From: Lee Jones @ 2026-05-21 16:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, Yassine Oudjana,
Kaustabh Chakraborty
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Conor Dooley, Krzysztof Kozlowski
In-Reply-To: <20260516-s2mu005-pmic-v7-0-73f9702fb461@disroot.org>
On Sat, 16 May 2026 03:08:32 +0530, Kaustabh Chakraborty wrote:
> S2MU005 is an MFD chip manufactured by Samsung Electronics. This is
> found in various devices manufactured by Samsung and others, including
> all Exynos 7870 devices. It is known to have the following features:
>
> 1. Two LED channels with adjustable brightness for use as a torch, or a
> flash strobe.
> 2. An RGB LED with 8-bit channels. Usually programmed as a notification
> indicator.
> 3. An MUIC, which works with USB micro-B (and USB-C?). For the micro-B
> variant though, it measures the ID-GND resistance using an internal
> ADC.
> 4. A charger device, which reports if charger is online, voltage,
> resistance, etc.
>
> [...]
Applied, thanks!
[01/10] dt-bindings: leds: document Samsung S2M series PMIC flash LED device
commit: a794673949f1aa1dd948ce3ea436af48ea83d7b2
[06/10] leds: flash: add support for Samsung S2M series PMIC flash LED device
commit: f0878c58430c378c47aaece1b29484e4ae8d7faf
[07/10] leds: rgb: add support for Samsung S2M series PMIC RGB LED device
commit: 366ed7a6d22e682e6dfd4d64d8f543bc70c6b58e
[08/10] Documentation: leds: document pattern behavior of Samsung S2M series PMIC RGB LEDs
commit: 1795fd2dbe84ef4d393b69a0b2a3b371f810bde5
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v5 10/13] ima: Add support for flushing the hash table when staging measurements
From: Mimi Zohar @ 2026-05-21 16:06 UTC (permalink / raw)
To: Roberto Sassu, corbet, skhan, dmitry.kasatkin, eric.snowberg,
paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, chenste, nramas, Roberto Sassu
In-Reply-To: <20260429160319.4162918-11-roberto.sassu@huaweicloud.com>
On Wed, 2026-04-29 at 18:03 +0200, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Introduce the new kernel option ima_flush_htable to decide whether or not
> the digests of staged measurement entries are flushed from the hash table,
> when they are deleted.
Unless explicitly requested, the existing hash table is not cleared after
exporting the measurement list. Why is clearing the hash table configurable?
The boot command line option does not provide enough information to decide why
you would or wouldn't want to clear the hash table. Please update the patch
description and the boot command line option.
thanks,
Mimi
>
> When the option is enabled, replace the old hash table with a new one,
> by calling ima_alloc_replace_htable(), and completely delete the
> measurements entries.
>
> Note: This code derives from the Alt-IMA Huawei project, whose license is
> GPL-2.0 OR MIT.
>
> Link: https://github.com/linux-integrity/linux/issues/1
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
^ permalink raw reply
* [PATCH v2] dt-bindings: serial: rs485: remove deprecated .txt binding stub
From: Akash Sukhavasi @ 2026-05-21 16:21 UTC (permalink / raw)
To: krzk+dt
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-kernel, linux-serial,
devicetree, linux-doc
The plain text binding file was superseded by the YAML schema in
commit d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings
to json-schema"). The file now contains only a redirect notice.
Remove it, and update references in serial_core.c and
serial-rs485.rst to point to the YAML schema.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Changes in v2:
- Update references in serial_core.c and serial-rs485.rst to point
to rs485.yaml (Sashiko review).
v1: https://lore.kernel.org/all/20260521150748.4816-1-akash.sukhavasi@gmail.com/
Documentation/devicetree/bindings/serial/rs485.txt | 1 -
Documentation/driver-api/serial/serial-rs485.rst | 2 +-
drivers/tty/serial/serial_core.c | 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/rs485.txt
diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
deleted file mode 100644
index a7fe93efc..000000000
--- a/Documentation/devicetree/bindings/serial/rs485.txt
+++ /dev/null
@@ -1 +0,0 @@
-See rs485.yaml
diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst
index dce061ef7..f53043d21 100644
--- a/Documentation/driver-api/serial/serial-rs485.rst
+++ b/Documentation/driver-api/serial/serial-rs485.rst
@@ -132,4 +132,4 @@ RS485 Serial Communications
6. References
=============
-.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.txt
+.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.yaml
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 89cebdd27..df4589880 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3496,7 +3496,7 @@ EXPORT_SYMBOL_GPL(uart_try_toggle_sysrq);
* @port: uart device's target port
*
* This function implements the device tree binding described in
- * Documentation/devicetree/bindings/serial/rs485.txt.
+ * Documentation/devicetree/bindings/serial/rs485.yaml.
*/
int uart_get_rs485_mode(struct uart_port *port)
{
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: serial: rs485: remove deprecated .txt binding stub
From: Conor Dooley @ 2026-05-21 16:48 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: krzk+dt, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Conor Dooley, Jonathan Corbet, Shuah Khan, linux-kernel,
linux-serial, devicetree, linux-doc
In-Reply-To: <20260521162137.6325-1-akash.sukhavasi@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2590 bytes --]
On Thu, May 21, 2026 at 11:21:35AM -0500, Akash Sukhavasi wrote:
> The plain text binding file was superseded by the YAML schema in
> commit d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings
> to json-schema"). The file now contains only a redirect notice.
> Remove it, and update references in serial_core.c and
> serial-rs485.rst to point to the YAML schema.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
Unless I am missing something about how docs.kernel.org redirects
magically work or something along those lines,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Cheers,
Conor.
> ---
> Changes in v2:
> - Update references in serial_core.c and serial-rs485.rst to point
> to rs485.yaml (Sashiko review).
>
> v1: https://lore.kernel.org/all/20260521150748.4816-1-akash.sukhavasi@gmail.com/
>
> Documentation/devicetree/bindings/serial/rs485.txt | 1 -
> Documentation/driver-api/serial/serial-rs485.rst | 2 +-
> drivers/tty/serial/serial_core.c | 2 +-
> 3 files changed, 2 insertions(+), 3 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/serial/rs485.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
> deleted file mode 100644
> index a7fe93efc..000000000
> --- a/Documentation/devicetree/bindings/serial/rs485.txt
> +++ /dev/null
> @@ -1 +0,0 @@
> -See rs485.yaml
> diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst
> index dce061ef7..f53043d21 100644
> --- a/Documentation/driver-api/serial/serial-rs485.rst
> +++ b/Documentation/driver-api/serial/serial-rs485.rst
> @@ -132,4 +132,4 @@ RS485 Serial Communications
> 6. References
> =============
>
> -.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.txt
> +.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.yaml
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 89cebdd27..df4589880 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3496,7 +3496,7 @@ EXPORT_SYMBOL_GPL(uart_try_toggle_sysrq);
> * @port: uart device's target port
> *
> * This function implements the device tree binding described in
> - * Documentation/devicetree/bindings/serial/rs485.txt.
> + * Documentation/devicetree/bindings/serial/rs485.yaml.
> */
> int uart_get_rs485_mode(struct uart_port *port)
> {
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ti: icssg: Add HSR and LRE PA statistics
From: Felix Maurer @ 2026-05-21 17:06 UTC (permalink / raw)
To: Jakub Kicinski
Cc: MD Danish Anwar, Luka Gejak, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Roger Quadros, Andrew Lunn, Meghana Malladi, Jacob Keller,
David Carlier, Vadim Fedorenko, Kevin Hao, netdev, linux-doc,
linux-kernel, linux-arm-kernel, Vladimir Oltean
In-Reply-To: <20260520153303.33692fe3@kernel.org>
On Wed, May 20, 2026 at 03:33:03PM -0700, Jakub Kicinski wrote:
> On Wed, 20 May 2026 15:30:24 +0530 MD Danish Anwar wrote:
> > What should be the next steps here? Is there any existing defined set of
> > stats where I could populate stats from ICSSG firmware for HSR (similar
> > to ndo_get_stats64 callback). Or de we need to implement a new callback
> > that will do this for HSR.
>
> I'd try to plumb this thru ndo_get_offload_stats
> Close enough for my taste, let's see if anyone objects.
I'm not super well versed with the different options for stats we have
at the moment, so I'm definitely not going to object. I'm just going to
note that the stats I listed are applicable to all HSR/PRP interfaces,
not just the ones with hardware offloads. Therefore, it would IMHO be
nice if the two didn't diverge too much in the end and (best case)
userspace can ask for either the one or the other but get the same
structure back (no need to implement it for the software-only interfaces
in this patch series, I can do that afterwards as well).
Thanks,
Felix
^ permalink raw reply
* Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive
From: Song Liu @ 2026-05-21 18:02 UTC (permalink / raw)
To: Sasha Levin
Cc: Daniel Borkmann, linux-kernel, linux-doc, linux-kselftest, bpf,
live-patching, Greg Kroah-Hartman, Andrew Morton, Jonathan Corbet,
Mathieu Desnoyers, Joshua Peisach, Florian Weimer, Breno Leitao,
Anthony Iliopoulos, Michal Hocko, Jiri Olsa, John Fastabend,
Christian Brauner
In-Reply-To: <ag8Y8L2WCcSEDPkG@laps>
On Thu, May 21, 2026 at 7:38 AM Sasha Levin <sashal@kernel.org> wrote:
>
> On Tue, May 19, 2026 at 03:00:15PM -0700, Song Liu wrote:
> >On Tue, May 19, 2026 at 12:57 PM Sasha Levin <sashal@kernel.org> wrote:
> >[...]
> >> >Fully agree with Song here that there is no clear boundary, and that the
> >> >killswitch could lead to arbitrary, hard to debug breakage if applied to
> >> >the wrong function.. introducing worse bugs than the one being mitigated
> >> >or even /short-circuit LSM enforcement/ (engage security_file_open 0,
> >> >engage cap_capable 0, engage apparmor_* etc).
> >>
> >> This is similar to livepatch, right? Do we need guardrails there too?
> >
> >livepatch has the same guardrails as other kernel modules:
> >CONFIG_MODULE_SIG, CONFIG_MODULE_SIG_FORCE, etc.
>
> Which the user can choose to enable or disable. Livepatches will work just fine
> with CONFIG_MODULE_SIG=n, right?
>
> With the whitelist approach, the user has no choice but to accept it.
>
> Would it make sense to allow disabling the whitelist via a kernel config or
> some runtime flag?
I personally think it makes sense to have options to allow bypassing/blocking
more kernel functions than the current allow list. But I don't know whether
we would like to go all the way to allow it for all the ftrace-able functions.
I think we will need some careful analysis on this.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH v2] kconfig: add optional warnings for changed input values
From: Nicolas Schier @ 2026-05-21 18:09 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Nathan Chancellor, Masahiro Yamada, Jonathan Corbet, Shuah Khan,
linux-kbuild, linux-doc, linux-kernel
In-Reply-To: <20260521022824.38591-1-pengpeng@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 3041 bytes --]
On Thu, May 21, 2026 at 10:28:24AM +0800, Pengpeng Hou wrote:
> When reading .config input, Kconfig stores user-provided values first and
> then resolves the final value after applying dependencies, ranges, and
> other constraints.
>
> If the final value differs from the user's input, Kconfig already tracks
> that state internally, but it does not provide any focused diagnostic to
> show which explicit inputs were adjusted. This is particularly confusing
> for requested values that get forced down by unmet dependencies or
> clamped by ranges.
>
> Add an opt-in diagnostic controlled by KCONFIG_WARN_CHANGED_INPUT. Emit
> the warnings from conf_write() and conf_write_defconfig() after value
> resolution and through the existing message callback path so the default
> behavior stays unchanged and interactive frontends remain usable.
>
> Avoid the conf_message() formatting buffer for this diagnostic so long
> warning lists are not truncated before reaching the callback, and mark
> processed symbols as written before the SYMBOL_WRITE check so duplicate
> menu nodes cannot emit duplicate warnings.
>
> Document the new environment variable and add tests for both olddefconfig
> and savedefconfig.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> Changes since v1: https://lore.kernel.org/all/20260406233001.1-kconfig-warn-changed-input-pengpeng@iscas.ac.cn/
> - rename "found" to "changed_input_found" as suggested by Nicolas
> - avoid the conf_message() 4096-byte formatting buffer so long warning
> lists are not truncated before the callback sees them
> - mark each processed symbol as SYMBOL_WRITTEN before checking
> SYMBOL_WRITE to avoid duplicate warnings for duplicate menu nodes
> - add duplicate-definition selftest coverage
> - do not carry the Reviewed-by/Tested-by tags because v2 changes warning
> emission and duplicate suppression
>
> Documentation/kbuild/kconfig.rst | 5 +
> scripts/kconfig/confdata.c | 107 +++++++++++++++++-
> .../kconfig/tests/warn_changed_input/Kconfig | 40 +++++++
> .../tests/warn_changed_input/__init__.py | 27 +++++
> .../kconfig/tests/warn_changed_input/config | 3 +
> .../tests/warn_changed_input/expected_config | 6 +
> .../warn_changed_input/expected_defconfig | 1 +
> .../tests/warn_changed_input/expected_stdout | 4 +
> 8 files changed, 189 insertions(+), 4 deletions(-)
> create mode 100644 scripts/kconfig/tests/warn_changed_input/Kconfig
> create mode 100644 scripts/kconfig/tests/warn_changed_input/__init__.py
> create mode 100644 scripts/kconfig/tests/warn_changed_input/config
> create mode 100644 scripts/kconfig/tests/warn_changed_input/expected_config
> create mode 100644 scripts/kconfig/tests/warn_changed_input/expected_defconfig
> create mode 100644 scripts/kconfig/tests/warn_changed_input/expected_stdout
>
Thanks a lot!
Tested-by: Nicolas Schier <nsc@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive
From: Song Liu @ 2026-05-21 18:16 UTC (permalink / raw)
To: Sasha Levin
Cc: Daniel Borkmann, linux-kernel, linux-doc, linux-kselftest, bpf,
live-patching, Greg Kroah-Hartman, Andrew Morton, Jonathan Corbet,
Mathieu Desnoyers, Joshua Peisach, Florian Weimer, Breno Leitao,
Anthony Iliopoulos, Michal Hocko, Jiri Olsa, John Fastabend,
Christian Brauner, KP Singh
In-Reply-To: <ag8lOe6dAOgnWmsQ@laps>
On Thu, May 21, 2026 at 8:31 AM Sasha Levin <sashal@kernel.org> wrote:
>
> On Thu, May 21, 2026 at 11:11:16AM +0200, Daniel Borkmann wrote:
> >On 5/19/26 9:57 PM, Sasha Levin wrote:
> >>Sure, this would also work. How do you see this happening? Can we let a certain
> >>user/pid/etc disable the allowlist if they choose to?
> >
> >I don't think we should, given then we're back to square one where root
> >or some other user would be able to just override/bypass an LSM.
>
> killswitch already disables itself when lockdown is active. We can easily
> disable it too when one of the LSMs that cares about this is active.
>
> >[...]
> >>How do you see this working with the allowlist?
> >
> >We should look at the underlying areas where most of the CVE-like fixes
> >took place (these days should be more easily doable given Claude and friends)
> >and based on that either extend ALLOW_ERROR_INJECTION() or (better) create
> >new hooks which BPF LSM can consume where you can then have a policy to reject
> >requests and tighten the attack surface. For example, the AF_ALG stuff you
>
> So we could grow the LSM tentacles deeper into the kernel, and we can see where
> current CVEs are happening, which I suspect is the darker corners of the kernel
> (old unmaintained, rarely used code), but this definitely won't stay the case,
> right? Newer and better LLMs will discover issues elsewhere, and once the low
> hanging fruits are picked off of the current target subsystems, researchers
> will move elsewhere. We will be dooming ourselves to an endless cat and mouse
> game where we go add LSM hooks after some big security issue goes public.
Do we really need to add new LSM hooks for recent CVEs?
The LSM hooks are designed to cover all the user-kernel interfaces. Then
with properly designed policies, we should have coverage for potential CVEs.
Existing LSM hooks may not be perfect, but we can improve the hooks,
potentially with the help of smart LLMs, so that these hooks can cover
future security issues. In some cases, we will need new policies, but I don't
think new hooks will be needed for most of these CVEs.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH] docs: gpu: todo: fix spelling of "fucntion"
From: Shuah Khan @ 2026-05-21 18:28 UTC (permalink / raw)
To: Godswill Onwusilike, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet
Cc: dri-devel, linux-doc, linux-kernel, Shuah Khan
In-Reply-To: <20260516210141.42971-1-onwusilikegodswill@gmail.com>
On 5/16/26 15:01, Godswill Onwusilike wrote:
> Correct the spelling of "fucntion" to "function" in todo.rst
> documentation
>
> Signed-off-by: Godswill Onwusilike <onwusilikegodswill@gmail.com>
> ---
> Documentation/gpu/todo.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 841e4e986c48..7526ed31b0af 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -1001,4 +1001,4 @@ DRM driver that can run X11 and Weston.
>
> Contact: Thomas Zimmermann <tzimmermann@suse.de>
>
> -Level: Advanced
> +Level: Advanced
> \ No newline at end of file
Hmm. the patch doesn't fix the spelling in the following line mentioned
in the commit log. Instead it removes and adds the same line.
"rename all inlined fucntions according to driver conventions."
thanks,
-- Shuah
^ permalink raw reply
* [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Randy Dunlap @ 2026-05-21 19:14 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Stefan Dösinger, Linus Walleij,
Krzysztof Kozlowski, linux-arm-kernel, Jonathan Corbet,
Shuah Khan, linux-doc
Fix multiple documentation build warnings.
Improve punctuation and formatting of the rendered output.
Documentation/arch/arm/zte/zx297520v3.rst:66: WARNING: Title underline too short.
3. Building for built-in U-Boot
--------------------------- [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:90: WARNING: Enumerated list ends without a blank line; unexpected unindent. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:116: WARNING: Inline literal start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:137: ERROR: Unexpected indentation. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:138: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:164: WARNING: Inline literal start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:164: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:7: WARNING: Document or section may not begin with a transition. [docutils]
Fixes: 220ae5d36dba ("ARM: zte: Add zx297520v3 platform support")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Stefan Dösinger <stefandoesinger@gmail.com>
Cc: Linus Walleij <linusw@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
Documentation/arch/arm/zte/zx297520v3.rst | 119 +++++++++-----------
1 file changed, 59 insertions(+), 60 deletions(-)
--- linux-next.orig/Documentation/arch/arm/zte/zx297520v3.rst
+++ linux-next/Documentation/arch/arm/zte/zx297520v3.rst
@@ -4,15 +4,13 @@
Booting Linux on ZTE zx297520v3 SoCs
====================================
-...............................................................................
-
Author: Stefan Dösinger
Date : 27 Jan 2026
1. Hardware description
---------------------------
-Zx297520v3 SoCs use a 64 bit capable Cortex-A53 CPU and GICv3, although they
+Zx297520v3 SoCs use a 64-bit capable Cortex-A53 CPU and GICv3, although they
run in arm32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
it seems to lack VFP and NEON.
@@ -27,7 +25,7 @@ Some devices, especially the stationary
Ethernet switch.
Usually the devices have LEDs for status indication, although some have SPI or
-I2C connected displays
+I2C connected displays.
Some have an SD card slot. If it exists, it is a better choice for the root
file system because it easily outperforms the built-in NAND.
@@ -39,7 +37,7 @@ IRQs on either ends.
There is also a Cortex M0 CPU, which is responsible for early HW initialization
and starting the Cortex A53 CPU. It does not have any essential purpose once
-U-Boot is started. A SRAM-Based handover protocol exists to run custom code on
+U-Boot is started. An SRAM-based handover protocol exists to run custom code on
this CPU.
2. Booting via USB
@@ -63,13 +61,13 @@ Contains an U-Boot version that can be u
CPU and interrupt controller to comply with Linux's booting requirements.
3. Building for built-in U-Boot
----------------------------
+-------------------------------
The devices come with an ancient U-Boot that loads legacy uImages from NAND and
boots them without a chance for the user to interrupt. The images are stored in
files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs,
usually mtd4. A file named "fotaflag" switches between the two modes.
-In addition to the uImage header, those files have a 384 byte signature header,
+In addition to the uImage header, those files have a 384-byte signature header,
which is used for authenticating the images on some devices. Most devices have
this authentication disabled and it is enough to pad the uImage files with 384
zero bytes.
@@ -88,7 +86,7 @@ So to build an image that boots from NAN
6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin
7) cat uimg >> ap_recovery.bin
8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the
-free space is not enough.
+ free space is not enough.
9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag
For development, booting ap_recovery.bin is recommended because the normal boot
@@ -113,55 +111,56 @@ the binary blobs.
The assembly code below is given as an example of how to achieve this:
-```
-#include <linux/irqchip/arm-gic-v3.h>
-#include <asm/assembler.h>
-#include <asm/cp15.h>
-
-@ Detect sane bootloaders and skip the hack
-ldr r3, =0xf2000000
-ldr r3, [r3]
-ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
-cmp r3, r4
-beq skip_zx_hack
-@ This allows EL1 to handle ints hat are normally handled by EL2/3.
-ldr r3, =0xf2000000
-str r4, [r3]
-
-cps #MON_MODE
-
-@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
-@ seems to respond only to non-secure addresses. I have taken insipiration from
-@ Raspberry pi's armstub7.S here.
-mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
- @ Allow hypervisor call.
-mcr p15, 0, r3, c1, c1, 0
-
-@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
-ldr r3, =0xF22020a8
-ldr r4, =0x50
-str r4, [r3]
-ldr r3, =0xF22020ac
-ldr r4, =0x14
-str r4, [r3]
-
-@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
-@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
-mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
-orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
-mcr p15, 6, r3, c12, c12, 5
-mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
-orr r3, #(ICC_SRE_EL1_SRE)
-mcr p15, 0, r3, c12, c12, 5
-
-@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
-@ for EL2.
-mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
-orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
-mcr p15, 4, r3, c12, c9, 5
-isb
-
-@ Back to SVC mode
-cps #SVC_MODE
-skip_zx_hack:
-```
+::
+
+ #include <linux/irqchip/arm-gic-v3.h>
+ #include <asm/assembler.h>
+ #include <asm/cp15.h>
+
+ @ Detect sane bootloaders and skip the hack
+ ldr r3, =0xf2000000
+ ldr r3, [r3]
+ ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
+ cmp r3, r4
+ beq skip_zx_hack
+ @ This allows EL1 to handle ints hat are normally handled by EL2/3.
+ ldr r3, =0xf2000000
+ str r4, [r3]
+
+ cps #MON_MODE
+
+ @ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
+ @ seems to respond only to non-secure addresses. I have taken insipiration from
+ @ Raspberry pi's armstub7.S here.
+ mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
+ @ Allow hypervisor call.
+ mcr p15, 0, r3, c1, c1, 0
+
+ @ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
+ ldr r3, =0xF22020a8
+ ldr r4, =0x50
+ str r4, [r3]
+ ldr r3, =0xF22020ac
+ ldr r4, =0x14
+ str r4, [r3]
+
+ @ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
+ @ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
+ mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
+ orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
+ mcr p15, 6, r3, c12, c12, 5
+ mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
+ orr r3, #(ICC_SRE_EL1_SRE)
+ mcr p15, 0, r3, c12, c12, 5
+
+ @ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
+ @ for EL2.
+ mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
+ orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
+ mcr p15, 4, r3, c12, c9, 5
+ isb
+
+ @ Back to SVC mode
+ cps #SVC_MODE
+ skip_zx_hack:
+
^ permalink raw reply
* [PATCH v2 0/2] mm/damon: fix macro arguments and clarify quota goals doc
From: Maksym Shcherba @ 2026-05-21 20:20 UTC (permalink / raw)
To: SeongJae Park
Cc: Maksym Shcherba, Liam R. Howlett, Andrew Morton,
David Hildenbrand, Jonathan Corbet, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Shuah Khan, Suren Baghdasaryan, Vlastimil Babka,
damon, linux-doc, linux-kernel, linux-mm
- Patch 1 fixes missing parentheses in DAMON iterator macro arguments to
prevent potential build failures.
- Patch 2 clarifies in the sysfs documentation that the `current_value` of
quota goals is only for user input and is not updated by the kernel.
Changes from v1
- v1: https://lore.kernel.org/r/20260518190932.42270-1-maksym.shcherba@lnu.edu.ua/
- Drop patches 2, 3, 5, and 6 from v1 (which implemented and documented
update_schemes_quota_goals).
- Clarify `current_value` behavior in the documentation (Patch 2) instead
of modifying the sysfs API.
- Add SeongJae's Reviewed-by tag to the macro bugfix (Patch 1).
- Fix checkpatch.pl email address mismatch warning.
Maksym Shcherba (2):
mm/damon: fix missing parens in macro arguments
Docs/admin-guide/mm/damon/usage: clarify current_value of quota goals
Documentation/admin-guide/mm/damon/usage.rst | 6 ++++--
include/linux/damon.h | 8 ++++----
2 files changed, 8 insertions(+), 6 deletions(-)
base-commit: 85a7d9e080a3f65869f22c2d50b630462fce332b
--
2.34.1
^ permalink raw reply
* [PATCH v2 2/2] Docs/admin-guide/mm/damon/usage: clarify current_value of quota goals
From: Maksym Shcherba @ 2026-05-21 20:20 UTC (permalink / raw)
To: SeongJae Park
Cc: Maksym Shcherba, Liam R. Howlett, Andrew Morton,
David Hildenbrand, Jonathan Corbet, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Shuah Khan, Suren Baghdasaryan, Vlastimil Babka,
damon, linux-doc, linux-kernel, linux-mm
In-Reply-To: <20260521202020.126500-1-maksym.shcherba@lnu.edu.ua>
The sysfs interface for DAMON quota goals includes a `current_value` file.
This file is not updated by the kernel and only serves to receive user
input.
Clarify in the documentation that the kernel does not update
`current_value`, and that reading it only has meaning when `target_metric`
is set to `user_input`.
While at it, fix missing commas in the goal files list.
Assisted-by: Antigravity:Gemini-3.1-Pro
Signed-off-by: Maksym Shcherba <maksym.shcherba@lnu.edu.ua>
---
Documentation/admin-guide/mm/damon/usage.rst | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index e3e2ccab218a..5b85a7a2ddf0 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -511,10 +511,12 @@ to ``N-1``. Each directory represents each goal and current achievement.
Among the multiple feedback, the best one is used.
Each goal directory contains five files, namely ``target_metric``,
-``target_value``, ``current_value`` ``nid`` and ``path``. Users can set and
+``target_value``, ``current_value``, ``nid``, and ``path``. Users can set and
get the five parameters for the quota auto-tuning goals that specified on the
:ref:`design doc <damon_design_damos_quotas_auto_tuning>` by writing to and
-reading from each of the files. Note that users should further write
+reading from each of the files. Because the kernel does not update
+``current_value``, reading it only makes sense when ``target_metric`` is
+``user_input``. Note that users should further write
``commit_schemes_quota_goals`` to the ``state`` file of the :ref:`kdamond
directory <sysfs_kdamond>` to pass the feedback to DAMON.
--
2.34.1
^ permalink raw reply related
* RE: [PATCH net-next 3/5] net: phy: Add support for the ADIN1140 PHY
From: Regus, Ciprian @ 2026-05-21 20:24 UTC (permalink / raw)
To: Andrew Lunn
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <2cfa6680-503a-4c4a-91bc-5f9a4331967d@lunn.ch>
> > +static int adin1140_phy_read_mmd(struct phy_device *phydev, int
> devnum,
> > + u16 regnum)
> > +{
> > + struct mii_bus *bus = phydev->mdio.bus;
> > + int addr = phydev->mdio.addr;
> > +
> > + return __mdiobus_c45_read(bus, addr, devnum, regnum);
> > +}
> > +
> > +static int adin1140_phy_write_mmd(struct phy_device *phydev, int
> devnum,
> > + u16 regnum, u16 val)
> > +{
> > + struct mii_bus *bus = phydev->mdio.bus;
> > + int addr = phydev->mdio.addr;
> > +
> > + return __mdiobus_c45_write(bus, addr, devnum, regnum, val);
> > +}
>
> Why do these exist?
>
The PHY is always probed over C22. Unless read_mmd()/write_mmd() are defined,
phylib will default to indirect accesses to MMD devices. The 0xD and 0xE PHY registers
are not implemented, so those transfers won't have any effect.
^ permalink raw reply
* Re: [PATCH net-next 3/5] net: phy: Add support for the ADIN1140 PHY
From: Andrew Lunn @ 2026-05-21 20:44 UTC (permalink / raw)
To: Regus, Ciprian
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <1d7f5247b07f44f2a30cfed8f7d3cd6d@analog.com>
On Thu, May 21, 2026 at 08:24:41PM +0000, Regus, Ciprian wrote:
>
> > > +static int adin1140_phy_read_mmd(struct phy_device *phydev, int
> > devnum,
> > > + u16 regnum)
> > > +{
> > > + struct mii_bus *bus = phydev->mdio.bus;
> > > + int addr = phydev->mdio.addr;
> > > +
> > > + return __mdiobus_c45_read(bus, addr, devnum, regnum);
> > > +}
> > > +
> > > +static int adin1140_phy_write_mmd(struct phy_device *phydev, int
> > devnum,
> > > + u16 regnum, u16 val)
> > > +{
> > > + struct mii_bus *bus = phydev->mdio.bus;
> > > + int addr = phydev->mdio.addr;
> > > +
> > > + return __mdiobus_c45_write(bus, addr, devnum, regnum, val);
> > > +}
> >
> > Why do these exist?
> >
>
> The PHY is always probed over C22. Unless read_mmd()/write_mmd() are defined,
> phylib will default to indirect accesses to MMD devices. The 0xD and 0xE PHY registers
> are not implemented, so those transfers won't have any effect.
In oa_tc6_mdiobus_register() there is the comment:
/* OPEN Alliance 10BASE-T1x compliance MAC-PHYs will have both C22 and
* C45 registers space. If the PHY is discovered via C22 bus protocol it
* assumes it uses C22 protocol and always uses C22 registers indirect
* access to access C45 registers. This is because, we don't have a
* clean separation between C22/C45 register space and C22/C45 MDIO bus
* protocols. Resulting, PHY C45 registers direct access can't be used
* which can save multiple SPI bus access. To support this feature, PHY
* drivers can set .read_mmd/.write_mmd in the PHY driver to call
* .read_c45/.write_c45. Ex: drivers/net/phy/microchip_t1s.c
*/
which is what you are doing.
If this was a DT driven device, you would add:
compatible = "ethernet-phy-ieee802.3-c45";
which would result in the device being probed via C45, and is_c45
would be set true.
Maybe we need to improve the situation here. We know C45 is
implemented, it is part of the standard. So maybe we need to set
is_c45?
In oa_tc6_phy_init() we already have:
tc6->phydev->is_internal = true;
what happens if we add
tc6->phydev->is_c45 = true; ?
Maybe this was discussed already once, when oa_tc6.c? I don't
remember.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/mlx5: Apply devlink default eswitch mode during init
From: Mark Bloch @ 2026-05-21 21:02 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Tariq Toukan, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, David S. Miller, Thomas Gleixner, Arnd Bergmann,
Jonathan Corbet, Shuah Khan, Jiri Pirko, Simon Horman,
Saeed Mahameed, Leon Romanovsky, Borislav Petkov (AMD),
Andrew Morton, Randy Dunlap, Petr Mladek, Peter Zijlstra (Intel),
Tejun Heo, Vlastimil Babka, Feng Tang, Christian Brauner,
Dave Hansen, Dapeng Mi, Kees Cook, Marco Elver, Li RongQing,
Eric Biggers, Paul E. McKenney, linux-doc, linux-kernel, netdev,
linux-rdma, Gal Pressman, Dragos Tatulea, Jiri Pirko, Shay Drori,
Moshe Shemesh
In-Reply-To: <20260521152845-11899163-df79-435c-b8c9-d3003403c6c9@linutronix.de>
On 21/05/2026 16:41, Thomas Weißschuh wrote:
> On Thu, May 21, 2026 at 04:16:28PM +0300, Mark Bloch wrote:
> (...)
>
>> NIPA flagged this patch with a build_allmodconfig_warn failure:
>> https://netdev-ctrl.bots.linux.dev/logs/build/1098506/14585935/build_allmodconfig_warn/
>>
>> I do not see how this mlx5 patch is related to the reported issue,
>> but I looked into it anyway.
>>
>> After the kernel has been built once, the issue can be reproduced by rerunning sparse
>> only on version.o, which filters out the unrelated noise. I had an older sparse installed,
>> so I used a local copy:
>>
>> rm -f arch/x86/boot/version.o
>> make V=1 C=1 CHECK=/labhome/mbloch/bin/sparse arch/x86/boot/version.o
>>
>> This gives the same error reported by NIPA:
>>
>> ...
>> ...
>> make -f ./scripts/Makefile.vmlinux
>> make -f ./scripts/Makefile.build obj=arch/x86/boot arch/x86/boot/bzImage
>> make -f ./scripts/Makefile.build obj=arch/x86/boot/compressed arch/x86/boot/compressed/vmlinux
>> # CC arch/x86/boot/version.o
>> gcc -Wp,-MMD,arch/x86/boot/.version.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -std=gnu11 -fms-extensions -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -fno-pic -mno-mmx -mno-sse -fcf-protection=none -ffreestanding -fno-stack-protector -Wno-address-of-packed-member -mpreferred-stack-boundary=2 -D_SETUP -fno-asynchronous-unwind-tables -Wimplicit-fallthrough=5 -DKBUILD_MODFILE='"arch/x86/boot/version"' -DKBUILD_BASENAME='"version"' -DKBUILD_MODNAME='"version"' -D__KBUILD_MODNAME=version -c -o arch/x86/boot/version.o arch/x86/boot/version.c
>> # CHECK arch/x86/boot/version.c
>> /labhome/mbloch/bin/sparse -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ -Wbitwise -Wno-return-void -Wno-unknown-attribute -D__x86_64__ --arch=x86 -mlittle-endian -m64 -Wp,-MMD,arch/x86/boot/.version.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -std=gnu11 -fms-extensions -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -fno-pic -mno-mmx -mno-sse -fcf-protection=none -ffreestanding -fno-stack-protector -Wno-address-of-packed-member -mpreferred-stack-boundary=2 -D_SETUP -fno-asynchronous-unwind-tables -Wimplicit-fallthrough=5 -DKBUILD_MODFILE='"arch/x86/boot/version"' -DKBUILD_BASENAME='"version"' -DKBUILD_MODNAME='"version"' -D__KBUILD_MODNAME=version arch/x86/boot/version.c
>> arch/x86/boot/version.c: note: in included file (through arch/x86/include/uapi/asm/bitsperlong.h, include/uapi/asm-generic/int-ll64.h, include/asm-generic/int-ll64.h, include/uapi/asm-generic/types.h, ...):
>> ./include/asm-generic/bitsperlong.h:23:2: error: Inconsistent word size. Check asm/bitsperlong.h
>> ./include/asm-generic/bitsperlong.h:27:33: error: static assertion failed: "Inconsistent word size. Check asm/bitsperlong.h"
>> # cmd_gen_symversions_c arch/x86/boot/version.o
>> if nm arch/x86/boot/version.o 2>/dev/null | grep -q ' __export_symbol_'; then gcc -E -D__GENKSYMS__ -Wp,-MMD,arch/x86/boot/.version.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -std=gnu11 -fms-extensions -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -fno-pic -mno-mmx -mno-sse -fcf-protection=none -ffreestanding -fno-stack-protector -Wno-address-of-packed-member -mpreferred-stack-boundary=2 -D_SETUP -fno-asynchronous-unwind-tables -Wimplicit-fallthrough=5 -DKBUILD_MODFILE='"arch/x86/boot/version"' -DKBUILD_BASENAME='"version"' -DKBUILD_MODNAME='"version"' -D__KBUILD_MODNAME=version arch/x86/boot/version.c | ./scripts/genksyms/genksyms >> arch/x86/boot/.version.o.cmd; fi
>> # LD arch/x86/boot/setup.elf
>> ld -m elf_x86_64 -z noexecstack -m elf_i386 -z noexecstack -T arch/x86/boot/setup.ld arch/x86/boot/a20.o arch/x86/boot/bioscall.o arch/x86/boot/cmdline.o arch/x86/boot/copy.o arch/x86/boot/cpu.o arch/x86/boot/cpuflags.o arch/x86/boot/cpucheck.o arch/x86/boot/early_serial_console.o arch/x86/boot/edd.o arch/x86/boot/header.o arch/x86/boot/main.o arch/x86/boot/memory.o arch/x86/boot/pm.o arch/x86/boot/pmjump.o arch/x86/boot/printf.o arch/x86/boot/regs.o arch/x86/boot/string.o arch/x86/boot/tty.o arch/x86/boot/video.o arch/x86/boot/video-mode.o arch/x86/boot/version.o arch/x86/boot/video-vga.o arch/x86/boot/video-vesa.o arch/x86/boot/video-bios.o -o arch/x86/boot/setup.elf
>> # OBJCOPY arch/x86/boot/setup.bin
>> objcopy -O binary arch/x86/boot/setup.elf arch/x86/boot/setup.bin
>> # BUILD arch/x86/boot/bzImage
>> (dd if=arch/x86/boot/setup.bin bs=4k conv=sync status=none; cat arch/x86/boot/vmlinux.bin) >arch/x86/boot/bzImage
>> mkdir -p ./arch/x86_64/boot
>> ln -fsn ../../x86/boot/bzImage ./arch/x86_64/boot/bzImage
>>
>> To me this looks like sparse is getting a conflicting set of flags.
>> The command line contains both "-D__x86_64__ -m64" and "-m16 -march=i386 -D_SETUP".
>>
>> I confirmed that the following patch "fixes" the issue, but I do not know whether
>> this is the right fix. This area is outside my comfort zone, so it would be
>> helpful if someone more familiar with the x86 build/sparse flow could take a
>> look:
>>
>> diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
>> index 3f9fb3698d66..80923864f6f9 100644
>> --- a/arch/x86/boot/Makefile
>> +++ b/arch/x86/boot/Makefile
>> @@ -71,6 +71,10 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
>>
>> SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
>>
>> +realmode-checkflags-$(CONFIG_X86_64) := -m32 -U__x86_64__ -D__i386__
>> +REALMODE_CHECKFLAGS := $(filter-out -m64 -D__x86_64__,$(CHECKFLAGS)) $(realmode-checkflags-y)
>> +$(SETUP_OBJS): CHECKFLAGS := $(REALMODE_CHECKFLAGS)
>> +
>> sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [a-zA-Z] \(startup_32\|efi.._stub_entry\|efi\(32\)\?_pe_entry\|input_data\|kernel_info\|_end\|_ehead\|_text\|_e\?data\|_e\?sbat\|z_.*\)$$/\#define ZO_\2 0x\1/p'
>>
>> quiet_cmd_zoffset = ZOFFSET $@
>> diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
>> index a0fb39abc5c8..341b0ff20c3d 100644
>> --- a/arch/x86/realmode/rm/Makefile
>> +++ b/arch/x86/realmode/rm/Makefile
>> @@ -29,6 +29,10 @@ targets += $(realmode-y)
>>
>> REALMODE_OBJS = $(addprefix $(obj)/,$(realmode-y))
>>
>> +realmode-checkflags-$(CONFIG_X86_64) := -m32 -U__x86_64__ -D__i386__
>> +REALMODE_CHECKFLAGS := $(filter-out -m64 -D__x86_64__,$(CHECKFLAGS)) $(realmode-checkflags-y)
>> +$(REALMODE_OBJS): CHECKFLAGS := $(REALMODE_CHECKFLAGS)
>> +
>
> The idea looks good, we do something similar for the 32-bit vDSO:
>
> arch/x86/entry/vdso/vdso32/Makefile
>
> CHECKFLAGS := $(subst -m64,-m32,$(CHECKFLAGS))
> CHECKFLAGS := $(subst -D__x86_64__,-D__i386__,$(CHECKFLAGS))
>
> It seems the same kind of substitution would work here.
> We can add a helper function to arch/x86/Makefile and
> use that also for the compat vDSO.
>
> I am wondering why this didn't show up before.
> Are you going to send a patch or should I?
>
Yes, please take it if you don't mind.
Mark
>
> Thomas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox