| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf events fixes from Ingo Molnar:
- Fix a perf_event_attr::remove_on_exec bug for group events
(Taeyang Lee)
- Fix uprobes CALL emulation interaction with shadow stacks, and
add a testcase for this (David Windsor)
- Fix uprobes unregister bug (Jiri Olsa)
* tag 'perf-urgent-2026-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline
selftests/x86: Add shadow stack uprobe CALL test
x86/uprobes: Keep shadow stack in sync for emulated CALLs
perf/core: Detach event groups during remove_on_exec
|
|
Correct the MMIO ranges and IRQs for T8122 I2C controllers.
They were mistakenly incorrect in the original commit. This
fix is required for i2c dependent hardware to function
correctly, i.e. audio codecs.
Tested on J613 (MacBook Air M3).
Fixes: c65ab4905e58 ("arm64: dts: apple: Initial t8122 (M3) device trees")
Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
Link: https://patch.msgid.link/20260629-t8122-i2c-fix-v1-1-cec044001550@gmail.com
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Since this file just implements a hwrng driver, move it into
drivers/char/hw_random/. Rename the kconfig option accordingly as well.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS fixes from Thomas Bogendoerfer.
* tag 'mips-fixes_7.2_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: configs: Enable the current Ingenic USB PHY symbol
MIPS: loongson64: add IRQ work based on self-IPI
MIPS: mm: Add check for highmem before removing memory block
mips: Add build salt to the vDSO
MIPS: DEC: Ensure RTC platform device deregistration upon failure
|
|
The amd_uncore driver currently does not validate event groups and
allows creation of groups with more events than the number of available
hardware counters. Because of this, pmu->event_init() succeeds but
counter assignment fails later in pmu->add() which returns -EBUSY once
all counters are exhausted.
Address this by introducing group validation in the pmu->event_init()
path. Since the uncore PMUs have no per-event constraints and all
counters of a PMU are interchangeable, validation is reduced to just
counting the group members that target a PMU and ensuring that they fit
within the available set of counters.
Fixes: c43ca5091a37 ("perf/x86/amd: Add support for AMD NB and L2I "uncore" counters")
Signed-off-by: Sandipan Das <sandipan.das@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/750877d66e208603c3047f13eed6399625d43969.1782884387.git.sandipan.das@amd.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
- Fix a crash when a kretprobe reads from the stack
- Fix an issue with the build-time mcount sorter that broke ftrace
- Fix the rv32 IRQ stack frame padding to match the ABI
- Only defer IOMMU configuration during initialization. This avoids an
issue where IOMMU configuration could be indefinitely deferred
- Add the missing build salt to the vDSO
- Now that RISC-V systems with higher numbers of cores are starting to
become available, raise NR_CPUS for RISC-V to 256
- Clean up some warnings from sparse caused by the RISC-V-optimized
RAID6 code
- Clean up our __cpu_up() code with a few minor fixes
* tag 'riscv-for-linus-7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: probes: save original sp in rethook trampoline
riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI
scripts/sorttable: Handle RISC-V patchable ftrace entries
riscv: smp: use secs_to_jiffies in __cpu_up
ACPI: RIMT: Only defer the IOMMU configuration in init stage
riscv: Add build salt to the vDSO
raid6: fix raid6_recov_rvv symbol undeclared warning
raid6: fix riscv symbol undeclared warnigns
riscv: Raise default NR_CPUS for 64BIT to 256
|
|
Fix all kernel-doc warnings in imr.c:
imr.c:300: warning: Function parameter or struct member 'rmask' not described in 'imr_add_range'
imr.c:300: warning: Function parameter or struct member 'wmask' not described in 'imr_add_range'
imr.c:300: warning: Excess function parameter 'read_mask' description in 'imr_add_range'
imr.c:300: warning: Excess function parameter 'write_mask' description in 'imr_add_range'
Fixes: 28a375df16c2 ("x86/intel/quark: Add Isolated Memory Regions for Quark X1000")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20250620065639.3348609-1-rdunlap@infradead.org
|
|
Along with RiscPC and SA1100, these are the last remaining Intel StrongARM
machines. The Corel NetWinder used to be particular popular in the late
1990s, but was discontinued during the bankruptcy of rebel.com in 2001.
The other machine is the DEC (later Intel) EBSA285 evaluation board that
was made in small numbers in 1997 for software developers.
The footbridge/netwinder platform was the main target for the first Debian
2.0 "Hamm" release on the Arm architecture back in 1998, but was dropped
in Debian 6.0 "Squeeze" in 2011, which only supported ARMv4T and higher
with the EABI based ports as ARMv4 hardware had fallen already out of
use by that time.
Link: http://netwinder.org/
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Acked-by: Ralph Siemsen <ralphs@netwinder.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This platform is the oldest still supported machine, dating back
to the original 1994 ARM610 version. The only currently supported
configuration uses an ARMv4 StrongARM but still requires building
for ARMv3 because of the board design not supporting 16-bit
data access.
ARMv3 support has been removed in gcc-9, and the gcc-8 release
is already old but still supported for building the kernel.
The only set of machines that lacks support for 16-bit load/store
instructions (Alpha EV5 and older) was recently removed from
the kernel.
Since there is little hope of this being maintainable much
longer, plan to remove it in early 2027 while it is still expected
to mostly work.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Most of the old StrongARM1100 machines were removed two years ago as part
of a wider cleanup, the remaining four were left either because someone
showed interest in converting them to devicetree, or because they were
still supported by qemu and therefore useful to keep the platform alive.
None of the devicetree conversion actually happened, and qemu has
marked the platform as deprecated, so do the same in the kernel now.
If anyone is still running one of these four machines and planning
to keep updating their kernels, please speak up now so we can adapt
the plans as needed.
If nobody is found using StrongARM1100 any more, it can be removing
during 2027, leaving 7.3-LTS as the last longterm support kernel
for it.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Conversion of the old orion5x board files to devicetree has
stalled over the past few years, so it seems better to remove
the remaining ones in order to allow cleaning up the device
drivers.
Debian and OpenWRT no longer support orion5x, and buildroot
could keep using linux-7.3-LTS for a few more years.
Jeremy Peper still plans to convert the Terastation 2 Pro
to devicetree in the future, but that can be done even
after it is removed.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
In the 2021 board file removal, the gumstix and sharpsl
support was left around in order to make it easier to convert
more of the PXA platform to device tree, given that both
platforms had some level of support in qemu.
As far as I can tell, nobody has worked on additional DT
conversion in that time, and qemu has in turn deprecated
the entire PXA platform.
Schedule the remaining board files for removal now, as they
are unlikely to be of any help in the future. If anyone
wants to revive support for these machines, they can
obviously still contribute device tree based code and
work on updating the corresponding drivers.
Any drivers that are only usable on legacy PXA board files
can also get removed along with the boards, or saved by
adding devicetree support.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The Marvell Armada 510 (Dove) platform is supported both as devicetree
and atags/boardfile variants, with varying degrees of hardware support.
Russell was the last known user of the board file version, and there
are very few users overall. Unless Russell still needs this variant,
let's remove after the next LTS kernel, leaving the CONFIG_MACH_DOVE
variant with devicetree.
Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
With no remaining users and support getting removed from future compilers,
there seems little point in keeping iwmmxt around much longer.
On the other hand, the iwmmxt support in the kernel rarely gets in the
way, so there is little cost, so set a removal date of early 2027 for
the moment. If anyone is still using this, it can be extended as long
there is binutils support.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The help text is seriously outdated and predates the introduction of
VFP floating point units that were available as early as some ARM926
based systems.
Change the help text to reflect that this is now a legacy feature
and that it will go away along with OABI support in the future.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Ralph Siemsen <ralphs@netwinder.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Mark Brown is still using this machine for regular work, so it should
not be removed as originally scheduled.
Give the platform another year, with the option to extend it further
based on the state of ATAGS support next year.
I expect that we end up removing all of s3c64xx when either Mark has
moved his test setup to other hardware, or when all other ATAGS based
machines are getting removed.
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This configuration option is for the older boot method that preceeded
ATAGS. This was scheduled for removal back in 2001, but the removal
never happened, presumably because nobody cared enough to actually do it,
not because there are any users left.
Add "(DEPRECATED)' to the Kconfig line and update the timeline so we can
remove it next year along with the other options that are not scheduled
for that timeframe.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Following the deprecation of big-endian ARMv8 mode in arch/arm64 in commit
1cf89b6bf660 ("arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN"),
this does the same for ARMv7 (and v6), leaving the code around but
disabled by default: There are no known products that make use of this
mode any more, and it only hangs around for testing that it still works.
At the moment, there are no known bugs with big-endian ARMv7 mode, but
it does break occasionally and require someone to fix it. By marking
the code as 'depends on BROKEN' now, it will no longer be covered by CI
testing. If any users remain, they can keep patching out the dependency
but are more likely to run into regressions.
The big-endian ARMv5 support (CONFIG_CPU_ENDIAN_BE32) in contrast is
still used on Intel IXP4xx platform, and is the only currently supported
mode there, so this one can still be enabled.
There is no timeline for actually removing the code at this point,
we will likely debate this if we ever remove IXP4xx support on arm,
or big-endian support on ARM64.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Only a very small number of machines remain that rely on
traditional board files with the ATAGS boot data instead
of devicetree, and we have not accepted new ones for
a decade.
Most of the remaining ones are on their way out of the
kernel, but the Kconfig option that controls ATAGS
is still enabled by default.
To reflect the actual status of ATAGS support and alert
the remaining users of upstream and out-of-tree platforms
with this, change it to being default-disabled and
add a dependency on CONFIG_EXPERT.
The board specific defconfig files that rely on ATAGS
are changed to turn on both EXPERT and ATAGS if they
were not doing that already, and the ones that explicitly
turned it off before no longer need to.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This CPU revision remains a special case as it is now incompatible
with CONFIG_SMP. Only the Nokia N8x0 is used in practice, and even
that one is fairly rare these days, so let's plan to remove all of
them after the 2026 LTS kernel release.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Vladimir Zapolskiy <vz@mleia.com> # Freescale i.MX31
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Support for SMP on ARM1136r0 has been broken for a while, and nobody
is working on fixing it. I had a plan to change ARMv6 support to no
longer coexist in a common kernel with ARMv7 CPUs but instead ARMv5 and
below. This would have addressed the problem, but after a recent mailing
list discussion, we concluded that an easier approach is to just forbid
ARM1136r0 CPU support on SMP-enabled kernels.
This mainly affects users of the Nokia N800/N810 tablets using an
OMAP2420 SoC, which is the only commercial product with an ARM1136r0
that is still supported by the kernel.
The other machines that are still in the same hardware catogory are:
- TI OMAP2420 H4 reference board
- TI OMAP2430 SDP software development platform
- Freescale/NXP i.MX31 Lite Development Kit
- Buglabs i.MX31 Bug 1.x prototype
- Arm Integrator/AP with CM1136JF-S core module
To my knowledge, none of these have any actual users aside from
reference boards being used to more easily test the platforms.
There are also a few ARM1136r1 machines, which implement the
ARMv6K SMP support (barriers, atomics and TLS):
- Eukrea CPUIMX35 reference platform
- Freescale/NXP i.MX35 Product Development Kit
- ARM Integrator/CP/IM-LT3 with ARM1136J Core Tile
- ARM Realview/EB with ARM1136J Core Tile
Again, these are mainly reference implementations rather than
actual products, but since they support ARMv6K, they should
continue to work correctly in SMP-enabled kernels. For the
ARM Core Tile, I have not found a datasheet but instead use
the revision based on what the respective virtual models
report.
All the other ARMv6 platforms use an ARM1176 with ARMv6K,
VMSAv7 and Trustzone support.
To avoid the broken configuration, annotate the ARM1136 based
machines with specific CPU_ARM1136R0 or CPU_ARM1136R2 symbols
in Kconfig and make the r0 variants depend on !SMP.
Link: https://lore.kernel.org/linux-arm-kernel/2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com/T/
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
As discussed on the mailing lists, there is no way to build OABI userspace
binaries any more since gcc-4.8, and now support is also getting dropped in
binutils, which will make it impossible to build pure OABI kernels at some
point in the future.
I found no evidence of anyone still sing OABI userspace on embedded systems
that keep getting kernel updates, but there are a few desktop-class machines
that date back to the 1990s using Intel StrongARM processors that were
supported by old versions of Debian, Red Hat or the official Corel
Netwinder distribution.
Add a much stricter Kconfig dependency for both native OABI and OABI_COMPAT
enabled kernels, only allowing either of them to be selected when building
a kernel that targets a StrongARM based machine.
Link: https://lore.kernel.org/lkml/2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com/
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
On ARMv4 and ARMv5, the default is still to build for OABI, with
CONFIG_AEABI disabled, even though distros and toolchains no longer
support OABI as a target.
Change the default to EABI for all architecture levels and change
the defconfig entries as follows:
- All machines that used to explicitly enable EABI can drop that line now
- Machines that are likely to actually use old distros and had NWFPE
enabled in combination with OABI (rpc, footrbridge, netwinder,
assabet, neponset) explicitly turn it on now.
- Machines that already had both EABI and NWFPE disabled in defconfig
(spear3xx, spear6xx) were likely not usable with either OABI or
EABI and now use EABI instead implicitly, making it more likely that
they could work.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP
Acked-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fixes from Juergen Gross:
- rename function parameters and a comment related to
xen_exchange_memory() (Jan Beulich)
- replace __ASSEMBLY__ with __ASSEMBLER__ (Thomas Huth)
- add some sanity checking to the Xen pvcalls frontend driver (Michael
Bommarito)
- fix error handling in the Xen gntdev driver (Wentao Liang)
- fix several minor bugs in Xen related drivers (Yousef Alhouseen)
* tag 'for-linus-7.2a-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
x86/Xen: correct commentary and parameter naming of xen_exchange_memory()
xenbus: reject unterminated directory replies
xen/gntalloc: validate grant count before allocation
xen/gntalloc: make grant counters unsigned
xen/front-pgdir-shbuf: free grant reference head on errors
xen/gntdev: fix error handling in ioctl
xen: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files
xen/pvcalls: bound backend response req_id before indexing rsp[]
|
|
Andrii reported an issue with optimized uprobes [1] that can clobber
redzone area with call instruction storing return address on stack
where user code may keep temporary data without adjusting rsp.
Fixing this by moving the optimized uprobes on top of 10-bytes nop
instruction, so we can squeeze another instruction to escape the
redzone area before doing the call, like:
lea -0x80(%rsp), %rsp
call tramp
Note the lea instruction is used to adjust the rsp register without
changing the flags.
We use nop10 and following transformation to optimized instructions
above and back as suggested by Peterz [2].
Optimize path (int3_update_optimize):
1) Initial state after set_swbp() installed the uprobe:
cc 2e 0f 1f 84 00 00 00 00 00
From offset 0 this is INT3 followed by the tail of the original
10-byte NOP.
After a previous unoptimization bytes 5..9 may still contain the
old call instruction, which remains valid for threads already there.
2) Rewrite the LEA tail and call displacement:
cc [8d 64 24 80 e8 d0 d1 d2 d3]
From offset 0 this traps on the uprobe INT3. Bytes 1..9 are not
executable entry points while byte 0 is trapped.
3) Publish the first LEA byte:
[48] 8d 64 24 80 e8 d0 d1 d2 d3
From offset 0 this is:
lea -0x80(%rsp), %rsp
call <uprobe-trampoline>
Unoptimize path (int3_update_unoptimize):
1) Initial optimized state:
48 8d 64 24 80 e8 d0 d1 d2 d3
Same as 3) above.
2) Trap new entries before restoring the NOP bytes:
[cc] 8d 64 24 80 e8 d0 d1 d2 d3
From offset 0 this traps. A thread that had already executed the
LEA can still reach the intact CALL at offset 5.
3) Restore bytes 1..4 of the original NOP while keeping byte 0 trapped
and byte 5 as CALL.
cc [2e 0f 1f 84] e8 d0 d1 d2 d3
From offset 0 this still traps. Offset 5 is still the CALL for any
thread that was already past the first LEA byte.
4) Publish the first byte of the original NOP:
[66] 2e 0f 1f 84 e8 d0 d1 d2 d3
From offset 0 this is the restored 10-byte NOP; the CALL opcode and
displacement are now only NOP operands. Offset 5 still decodes as
CALL for a thread that was already there.
Tthere is only a single target uprobe-trampoline for the given nop10
instruction address, so the CALL instruction will not be changed across
unoptimization/optimization cycles.
Therefore, any task that is preempted at the CALL instruction is guaranteed
to observe that CALL and not anything else.
Note as explained in [2] we need to use following nop10:
PF1 PF2 ESC NOPL MOD SIB DISP32
NOP10: 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 -- cs nopw 0x00000000(%rax,%rax,1)
which means we need to allow 0x2e prefix which maps to INAT_PFX_CS
attribute in is_prefix_bad function.
Also changing the uprobe syscall error when called out of uprobe
trampoline to -EPROTO, so we are able to detect the fixed kernel.
The optimized uprobe performance stays the same:
uprobe-nop : 3.129 ± 0.013M/s
uprobe-push : 3.045 ± 0.006M/s
uprobe-ret : 1.095 ± 0.004M/s
--> uprobe-nop10 : 7.170 ± 0.020M/s
uretprobe-nop : 2.143 ± 0.021M/s
uretprobe-push : 2.090 ± 0.000M/s
uretprobe-ret : 0.942 ± 0.000M/s
--> uretprobe-nop10: 3.381 ± 0.003M/s
usdt-nop : 3.245 ± 0.004M/s
--> usdt-nop10 : 7.256 ± 0.023M/s
[1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/
[2] https://lore.kernel.org/bpf/20260518104306.GU3102624@noisy.programming.kicks-ass.net/#t
Closes: https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/
Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes")
Reported-by: Andrii Nakryiko <andrii@kernel.org>
Assisted-by: Codex:GPT-5.5
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Link: https://patch.msgid.link/20260703114917.238144-6-jolsa@kernel.org
|
|
When we do fork or clone without CLONE_VM the new process won't
have uprobe trampoline vma objects and at the same time it will
have optimized code calling that trampoline and crash.
Fixing this by allowing vma uprobe trampoline objects to be copied
on fork to the new process.
Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes")
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Link: https://patch.msgid.link/20260703114917.238144-5-jolsa@kernel.org
|
|
In case the optimization fails, we leak new-ly created trampoline
vma mapping (in case we just created it), let's unmap it.
Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes")
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Link: https://patch.msgid.link/20260703114917.238144-4-jolsa@kernel.org
|
|
Removing struct uprobe_trampoline object and it's tracking code,
because it's not needed. We can do same thing directly on top of
struct vm_area_struct objects.
This makes the code simpler and allows easy propagation of the
trampoline vma object into child process in following change.
Note the original code called destroy_uprobe_trampoline if the
optimiation failed, but it only freed the struct uprobe_trampoline
object, not the vma. The new vma leak is fixed in following change.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://patch.msgid.link/20260703114917.238144-3-jolsa@kernel.org
|
|
Pick up fixes and dependencies.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
|
|
Add pinctrl and irqchip-gpio device nodes for A9 SoC.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Link: https://patch.msgid.link/20260629-a9-node-v2-1-dadd3401fccb@amlogic.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add the clock measure device to the T7 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260421-clkmsr_a1_t7-v3-4-efc00b0f9e6b@amlogic.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add the clock measure device to the A1 SoC family.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Link: https://patch.msgid.link/20260421-clkmsr_a1_t7-v3-3-efc00b0f9e6b@amlogic.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
The 32-bit MSR interface rdmsr() is planned to be removed. Use the
related 64-bit variant instead.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20260629060526.3638272-29-jgross@suse.com
|
|
The 32-bit MSR interface rdmsr() is planned to be removed. Use the
related 64-bit variant instead.
This conversion also simplifies the code a bit.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Long Li <longli@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Link: https://patch.msgid.link/20260629060526.3638272-28-jgross@suse.com
|
|
numa_add_memblk() now sets the node in numa_nodes_parsed itself, so the
caller's own node_set() is redundant. Remove it.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260703041329.2797584-7-ekffu200098@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
numa_add_memblk() now sets the node in numa_nodes_parsed itself, so the
caller's own node_set() is redundant. Remove it.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260703041329.2797584-5-ekffu200098@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux
Pull mod_devicetable.h header split from Uwe Kleine-König:
"Split <linux/mod_devicetable.h> in per subsystem headers
<linux/mod_devicetable.h> is included transitively in nearly every
driver in an x86_64 allmodconfig build of v7.1:
$ find drivers -name \*.o -not -name \*.mod.o | wc -l
21330
$ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l
17038
The result of this mixture of different and unrelated subsystem
details is that even when touching an obscure device id struct most of
the kernel needs to be recompiled. Given that each driver typically
only needs one or two of these structures, splitting into per
subsystem headers and only including what is really needed reduces the
amount of needed recompilation.
This split is implemented in the first commit and then after some
preparatory work in the following commits, the last two replace
includes of <linux/mod_devicetable.h> by the actually needed more
specific headers.
There are still a few instances left, but the ones with high impact
(that is in headers that are used a lot) and the easy ones (.c files)
are handled. These remaining includes will be addressed during the
next merge window"
* tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux:
Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)
Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (headers)
parisc: #include <linux/compiler.h> for unlikely() in <asm/ptrace.h>
media: em28xx: Add include for struct usb_device_id
LoongArch: KVM: Add include defining struct cpu_feature
ALSA: hda/core: Add include defining struct hda_device_id
usb: dwc2: Add include defining struct pci_device_id
platform/x86: int3472: Add include defining struct dmi_system_id
platform/x86: x86-android-tablets: Add include defining struct dmi_system_id
i2c: Let i2c-core.h include <linux/i2c.h>
of: Explicitly include <linux/types.h> and <linux/err.h>
platform/x86: msi-ec: Ensure dmi_system_id is defined
usb: serial: Include <linux/usb.h> in <linux/usb/serial.h>
driver core: platform: Include header for struct platform_device_id
driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver
media: ti: vpe: #include <linux/platform_device.h> explicitly
mod_devicetable.h: Split into per subsystem headers
|
|
Cross-merge networking fixes after downstream PR (net-7.2-rc2).
No conflicts.
Adjacent changes:
MAINTAINERS:
56114690ff3c ("MAINTAINERS: Update Marvell octeontx2 driver maintainers")
eb56577ae9a5 ("ehea: remove the ehea driver")
net/core/netpoll.c:
45f1458a8501 ("netpoll: fix a use-after-free on shutdown path")
84c0ff1efb62 ("netpoll: do not warn when the best-effort pool refill fails")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
files)
Replace the #include of <linux/mod_devicetable.h> by the more specific
<linux/device-id/*.h> where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
(headers)
<linux/mod_devicetable.h> is included in a many files:
$ git grep '<linux/mod_devicetable.h>' ef0c9f75a195 | wc -l
1598
; some of them are widely used headers. To stop mixing up different and
unrelated driver( type)s let the subsystem headers only use the subset
of the recently split <linux/mod_devicetable.h> that are relevant for
them.
The fallout (I hope) is addressed in the previous commits that handle
sources relying on e.g. <linux/i2c.h> pulling in the full legacy header
and thus providing pci_device_id.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/199fe46b624ba07fb9bd3e0cd6ff13757932cb5f.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
Currently <linux/compiler.h> isn't included at all (not even
transitively) in <asm/ptrace.h>.
arch/parisc/kernel/asm-offsets.c just happens to include the following
chain of includes before <asm/ptrace.h>:
<linux/sched.h>
-> <asm/processor.h>
-> <asm/hardware.h>
-> <linux/mod_devicetable.h>
-> <linux/uuid.h>
-> <linux/string.h>
-> <linux/compiler.h>
. That chain will be broken, because in one of the next commits
<asm/hardware.h> is changed to only include <linux/device-id/parisc.h>
instead of <linux/mod_devicetable.h>. So to ensure
arch/parisc/kernel/asm-offsets.c knows about unlikely() even after that
change, #include <linux/compiler.h> explicitly.
Link: https://patch.msgid.link/0574a2b73363c3cbf21c55c27455c3cecfb33583.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
Traditionally <linux/mod_devicetable.h> was a header defining a plethora
of structs, among them struct cpu_features. This was split now with the
objective that only the relevant bits are included.
Currently <linux/mod_devicetable.h> is transitively included in
arch/loongarch/kvm/main.c via:
arch/loongarch/kvm/main.c ->
<linux/kvm_host.h> ->
<linux/entry-virt.h> ->
<linux/resume_user_mode.h> ->
<linux/memcontrol.h> ->
<linux/cgroup.h> ->
<linux/kernel_stat.h> ->
<linux/interrupt.h> ->
<linux/hardirq> ->
<asm/hardirq.h> ->
<linux/irq.h> ->
<asm/irq.h> ->
<linux/irqdomain.h> ->
<linux/of.h> ->
<linux/mod_devicetable.h>
To keep struct cpu_features available once <linux/of.h> stops including
<linux/mod_devicetable.h>, include it here explicitly.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/052feec0e04ea8f5b2706a19a5b236679eed0aba.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
Pull BPF fixes from Daniel Borkmann:
- Initialize task local storage before fork bails out to free the task
(Jann Horn)
- Fix insn_aux_data leak on verifier error path (KaFai Wan)
- Reject BPF inode storage map creation when BPF LSM is uninitialized
(Matt Bobrowski)
- Mask pseudo pointer values in verifier logs when pointer leaks are
not allowed (Nuoqi Gui)
- Harden BPF JIT against spraying via IBPB flush (Pawan Gupta)
- Reject a skb-modifying SK_SKB stream parser since the latter is only
meant to measure the next message (Sechang Lim)
- Fix bpf_refcount_acquire to reject refcounted allocation arguments
with a non-zero fixed offset (Yiyang Chen)
* tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
bpf: Prefer dirty packs for eBPF allocations
bpf: Prefer packs that won't trigger an IBPB flush on allocation
bpf: Skip redundant IBPB in pack allocator
bpf: Restrict JIT predictor flush to cBPF
x86/bugs: Enable IBPB flush on BPF JIT allocation
bpf: Support for hardening against JIT spraying
bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized
bpf,fork: wipe ->bpf_storage before bailouts that access it
bpf: Fix insn_aux_data leak on verifier err_free_env path
selftests/bpf: Cover pseudo-BTF ksym log masking
bpf: Mask pseudo pointer values in verifier logs
selftests/bpf: Cover refcount acquire node offsets
bpf: Reject offset refcount acquire arguments
selftests/bpf: test rejection of a packet-modifying SK_SKB stream parser
bpf, sockmap: reject a packet-modifying SK_SKB stream parser
selftests/bpf: don't modify the skb in the strparser parser prog
|
|
The syscall trace path reloads syscall arguments from pt_regs before
calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall
arguments are prepared as stack arguments before invoking syscallid.
The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since
those offsets are relative to the original pt_regs base, loading them
after changing sp fetches the wrong slots. As a result, traced syscalls
that use the 5th or 6th argument may receive corrupted arguments.
This is visible with mmap2(), which takes six arguments. A small
PTRACE_SYSCALL reproducer opens a file and maps one page with:
mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0)
Before the fix, the traced child fails the mmap and exits with 12.
After the fix, the mapping succeeds and the child exits with 0.
Fix the trace path by loading a4/a5 from pt_regs before changing sp.
Tested on: ck860f, linux-4.19.15, C-SKY abiv2
Fixes: e0bbb53843b5 ("csky: Fixup abiv2 syscall_trace break a4 & a5")
Suggested-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Hanlin Song <pgeorge8929@gmail.com>
Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org>
|
|
The RB5gen2 is an embedded development platform for the
QCS8550, based on the Snapdragon 8 Gen 2 SoC (SM8550).
This change implements the main board, the vision mezzanine
will be supported in a follow up patch.
The main board has the following features:
- Qualcomm Dragonwing QCS8550 SoC
- Adreno GPU 740
- Spectra ISP
- Adreno VPU 8550
- Adreno DPU 1295
- 1 x 1GbE Ethernet (USB Ethernet)
- WIFI 7 + Bluetooth 5.4
- 1 x USB 2.0 Micro B (Debug)
- 1 x USB 3.0 Type C (ADB, DP out)
- 2 x USB 3.0 Type A
- 1 x HDMI 1.4 Type A
- 1 x DP 1.4 Type C
- 2 x WSA8845 Speaker amplifiers
- 2 x Speaker connectors
- 1 x On Board PDM MIC
- Accelerometer + Gyro Sensor
- 96Boards compatible low-speed and high-speed connectors [1]
- 7 x LED indicators (4 user, 2 radio, 1 power)
- Buttons for power, volume up/down, force USB boot
- 3 x Dip switches
On-Board PMICs:
- PMK8550 2.1
- PM8550 2.0
- PM8550VS 2.0 x4
- PM8550VE 2.0
- PM8550B 2.0
- PMR735D 2.0
- PM8010 1.1 x2
Product Page: [2]
[1] https://www.96boards.org/specifications/
[2] https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit
The default msi-map from sm8550.dtsi is deleted for both pcie0 and
pcie1. The QPS615 PCIe switch on each port exposes more than two
devices (1 USP + 3 DSPs), but Gunyah currently limits ITS device
mappings to two per root complex to save memory. With msi-map
present, the ITS MAPD command times out.
Deleting msi-map causes the DWC controller to fall back to its
internal iMSI-RX module, which handles MSIs without this limitation.
Signed-off-by: Joe Sandom <jsandom@axon.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260420-rb5gen2-dts-v4-5-b461909c2de8@axon.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Move qcom,gsi-loader and memory-region properties from individual board
DTS files into the SoC DTSI, since these are common to all SM8550-based
boards.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Joe Sandom <jsandom@axon.com>
Link: https://lore.kernel.org/r/20260420-rb5gen2-dts-v4-3-b461909c2de8@axon.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add labels to the root port nodes (pcie0_port0, pcie1_port0) to
allow board DTS files to reference them for adding endpoint devices
to each pcie root port.
Update the pcieport0 reference to pcie0_port0 in sm8550-hdk.dts and
sm8550-qrd.dts to match the label rename in sm8550.dtsi.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Joe Sandom <jsandom@axon.com>
Link: https://lore.kernel.org/r/20260420-rb5gen2-dts-v4-2-b461909c2de8@axon.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the MHI register regions to the pcie0 and pcie1 controller nodes
to expose link power state transition counters (L0s/L1/L1.1/L1.2/L2)
via debugfs. The PCIe host driver uses this region to read the
link_transition_count from the MHI registers.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Joe Sandom <jsandom@axon.com>
Link: https://lore.kernel.org/r/20260420-rb5gen2-dts-v4-1-b461909c2de8@axon.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add an IMEM on glymur which falls back to mmio-sram and define the
PIL relocation info region as its child, for post mortem tools to
locate the loaded remoteprocs.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260424-glymur-imem-v5-2-18ede63cf063@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add the mode-switch property to the QMP combo PHY so that mode-switch
events are routed to it, allowing the PHY to enter DisplayPort Alternate
Mode. Expand the DP data-lanes assignment from two to four lanes to make
use of the full link bandwidth available in this configuration.
Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260420-kodiak_4k-v1-1-83dfc66b8f06@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
