On Fri, 2025-04-18 at 07:18 -0700, Sean Christopherson wrote:
> On Thu, Apr 17, 2025, Kai Huang wrote:
> > I think the sgx_updatesvn() should just return true when EUPDATESVN returns
> > 0 or
> > SGX_NO_UPDATE, and return false for all other error codes. And it should
> > ENCLS_WARN() for all oth
On 21/04/25 20:28, Andrew Davis wrote:
> On 4/17/25 1:19 PM, Beleswar Padhi wrote:
>> The .kick rproc ops implementations in TI K3 R5, DSP and M4 remoteproc
>> drivers sends a mailbox message to the remote processor in the same
>> way. Refactor the implementations into a common function
>> 'k3_rp
Hi Andrew,
On 21/04/25 20:12, Andrew Davis wrote:
> On 4/17/25 1:19 PM, Beleswar Padhi wrote:
>> The rproc_reset() implementations in TI K3 DSP and M4 remoteproc drivers
>> assert reset in the same way. Refactor the above function into the
>> ti_k3_common.c driver as k3_rproc_reset() and use it th
On Mon, Apr 21, 2025 at 10:16 AM Suren Baghdasaryan wrote:
>
> On Sat, Apr 19, 2025 at 12:26 PM Alejandro Colomar wrote:
> >
> > Hi Lorenzo, Suren, Andrea,
> >
> > On Sat, Apr 19, 2025 at 07:57:36PM +0100, Lorenzo Stoakes wrote:
> > > +cc Alejandro
> >
> > Thanks!
> >
> > > On Wed, Dec 06, 2023 a
On Thu, Mar 20, 2025 at 02:09:50PM +0200, Daniel Baluta wrote:
> Daniel Baluta (5):
> arm64: dts: imx8mp: Use resets property
> arm64: dts: imx8mp: Add mu2 root clock
> arm64: dts: imx8mp: Configure dsp node for rproc usage
> arm64: dts: imx8mp: Add DSP clocks
> arm64: dts: Enable DSP nod
;> -INIT_DELAYED_WORK(&vsk->close_work,
>> - virtio_transport_close_timeout);
>> +INIT_DELAYED_WORK(&vsk->close_work, virtio_transport_close_timeout);
>
> Ditto.
>
> These 2 could go together in a single `cleanup` patch, although I
> usually avoid it so that `git blame` makes sense. But if we want to
> make checkpatch happy, that's fine.
All right, dropping these. I've thought, since I was touching this function
and this wasn't a bug fix (and wouldn't be backported), it'd be okay to do
some trivial cleanups along the way.
Here's v2:
https://lore.kernel.org/netdev/20250421-vsock-linger-v2-0-fe9febd64...@rbox.co/
Thanks,
Michal
Currently vsock's lingering effectively boils down to waiting (or timing
out) until packets are consumed or dropped by the peer; be it by receiving
the data, closing or shutting down the connection.
To align with the semantics described in the SO_LINGER section of man
socket(7) and to mimic AF_INE
Flatten the function. Remove the nested block by inverting the condition:
return early on !timeout.
No functional change intended.
Suggested-by: Stefano Garzarella
Signed-off-by: Michal Luczaj
---
net/vmw_vsock/virtio_transport_common.c | 36 -
1 file changed, 1
Change vsock's lingerning to wait on close() until all data is sent, i.e.
until workers picked all the packets for processing.
Changes in v2:
- Comment that some transports do not implement unsent_bytes [Stefano]
- Reduce the indentation of virtio_transport_wait_close() [Stefano]
- Do not linger
There was an issue with SO_LINGER: instead of blocking until all queued
messages for the socket have been successfully sent (or the linger timeout
has been reached), close() would block until packets were handled by the
peer.
Add a check to alert on close() lingering when it should not.
Signed-of
The SCP is currently described in the Devicetree as a single-core
processor, but really it is a cluster with two cores. Describe the full
cluster but enable only core0 on the current mt8188 platforms since
that's the only one usable with the upstream firmware.
Co-developed-by: Tinghan Shen
Signed
Add the firmware-name property for SCP core0 so the firmware can be
loaded from its canonical location in the linux-firmware repository.
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Nícolas F. R. A. Prado
---
arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi | 1 +
1 file changed
reg's maxItems is already defined as 3 in the base schema. Remove the
redundant assignment in the if branch for mt8192/mt8195.
Suggested-by: Krzysztof Kozlowski
Signed-off-by: Nícolas F. R. A. Prado
---
Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 1 -
1 file changed, 1 deletion(
The SCP present on MT8188 does not have an L1TCM memory region, but the
binding incorrectly requires one for the dual-core description of the
MT8188 SCP. Remove that requirement. Also update the minimum number of
reg and reg-names to 1, since as this is a multi-core SCP with no
L1TCM memory, only t
Both MT8192 and MT8195 have an L1TCM memory, so it should be described
in reg, and therefore reg's minItems should be 3, as is already implicit
by reg-names being three entries long. However minItems is currently
unset for mt8192/mt8195, resulting in it being equal to 2, from the base
schema. Fix r
This series updates the MT8188 SCP description to dual-core and prepares
its usage. Patch 4 updates the MT8188 DT to describe the SCP as a dual
core cluster and patch 5 adds the firmware-name property so the firmware
can be loaded. Patches 1 through 3 are dt-binding fixes for the SCP.
Signed-off-b
On Sat, Apr 19, 2025 at 11:00:41AM +0200, Luca Weiss wrote:
> From: Kevin Widjaja
>
> Add the dts for the Z Ultra. This is currently almost the same as Z1
> Compact (amami) and Z1 (honami) as they share almost the same hardware.
>
> Only USB Networking and volume button are confirmed working.
>
On Sat, Apr 19, 2025 at 11:00:39AM +0200, Luca Weiss wrote:
> From: Kevin Widjaja
>
> An upcoming board in the sony-xperia-rhine family (sony-togari) does not
> have dedicated camera buttons, so move those from common rhine dtsi to
> amami and honami dts files.
>
> Signed-off-by: Kevin Widjaja
On Sat, Apr 19, 2025 at 11:00:38AM +0200, Luca Weiss wrote:
> From: Kevin Widjaja
>
> Set usb-charge-current-limit to enable charging over USB for all
> sony-rhine devices.
>
> Signed-off-by: Kevin Widjaja
> Signed-off-by: Luca Weiss
> ---
> arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhi
On Sat, Apr 19, 2025 at 12:26 PM Alejandro Colomar wrote:
>
> Hi Lorenzo, Suren, Andrea,
>
> On Sat, Apr 19, 2025 at 07:57:36PM +0100, Lorenzo Stoakes wrote:
> > +cc Alejandro
>
> Thanks!
>
> > On Wed, Dec 06, 2023 at 02:36:56AM -0800, Suren Baghdasaryan wrote:
> > > From: Andrea Arcangeli
> > >
From: Geliang Tang
When running diag.sh in a loop, chk_dump_one will report the following
"grep: write error":
13 chk 2 cestab [ OK ]
grep: write error
14 chk dump_one [ OK ]
15 chk 2->0 msk in use after flush
From: Mat Martineau
When path manager entries are deleted from the local address list, they
are first unlinked from the address list using list_del_rcu(). The
entries must not be freed until after the RCU grace period, but the
existing code immediately frees the entry.
Use kfree_rcu_mightsleep()
: 750d0ac001e85b754404178ee8ce01cbc76a03be
change-id: 20250421-net-mptcp-pm-defer-freeing-f9cd01b70043
Best regards,
--
Matthieu Baerts (NGI0)
Memory barriers are building blocks for concurrent code, hence provide
a minimal set of them.
The compiler barrier, barrier(), is implemented in inline asm instead of
using core::sync::atomic::compiler_fence() because memory models are
different: kernel's atomics are implemented in inline asm ther
RCU protected pointers are an atomic pointer that can be loaded and
dereferenced by mulitple RCU readers, but only one updater/writer can
change the value (following a read-copy-update pattern usually).
This is useful in the case where data is read-mostly. The rationale of
this patch is to provide
Add atomic support for raw pointer values, similar to `isize` and
`usize`, the representation type is selected based on CONFIG_64BIT.
`*mut T` is not `Send`, however `Atomic<*mut T>` definitely needs to be
a `Sync`, and that's the whole point of atomics: being able to have
multiple shared referenc
(This is more an RFC)
Add arithmetic operations support for `Atomic<*mut T>`. Currently the
semantics of arithmetic atomic operation is the same as pointer
arithmetic, that is, e.g. `Atomic<*mut u64>::add(1)` is adding 8
(`size_of::`) to the pointer value.
In Rust std library, there are two sets
Add generic atomic support for `usize` and `isize`. Note that instead of
mapping directly to `atomic_long_t`, the represention type
(`AllowAtomic::Repr`) is selected based on CONFIG_64BIT. This reduces
the necessarity of creating `atomic_long_*` helpers, which could save
the binary size of kernel i
Add generic atomic support for basic unsigned types that have an
`AtomicImpl` with the same size and alignment.
Signed-off-by: Boqun Feng
---
rust/kernel/sync/atomic.rs | 80 ++
1 file changed, 80 insertions(+)
diff --git a/rust/kernel/sync/atomic.rs b/rust/k
One important set of atomic operations is the arithmetic operations,
i.e. add(), sub(), fetch_add(), add_return(), etc. However it may not
make senses for all the types that `AllowAtomic` to have arithmetic
operations, for example a `Foo(u32)` may not have a reasonable add() or
sub(), plus subword
xchg() and cmpxchg() are basic operations on atomic. Provide these based
on C APIs.
Note that cmpxchg() use the similar function signature as
compare_exchange() in Rust std: returning a `Result`, `Ok(old)` means
the operation succeeds and `Err(old)` means the operation fails. With
the compiler opt
To provide using LKMM atomics for Rust code, a generic `Atomic` is
added, currently `T` needs to be Send + Copy because these are the
straightforward usages and all basic types support this. The trait
`AllowAtomic` should be only implemented inside atomic mod until the
generic atomic framework is m
Preparation for atomic primitives. Instead of a suffix like _acquire, a
method parameter along with the corresponding generic parameter will be
used to specify the ordering of an atomic operations. For example,
atomic load() can be defined as:
impl Atomic {
pub fn load(&self, _
In order to support LKMM atomics in Rust, add rust_helper_* for atomic
APIs. These helpers ensure the implementation of LKMM atomics in Rust is
the same as in C. This could save the maintenance burden of having two
similar atomic implementations in asm.
Originally-by: Mark Rutland
Signed-off-by:
Preparation for generic atomic implementation. To unify the
implementation of a generic method over `i32` and `i64`, the C side
atomic methods need to be grouped so that in a generic method, they can
be referred as ::, otherwise their parameters and return
value are different between `i32` and `i64
Hi,
v3 for LKMM atomics in Rust, you can find the previous versions:
v2:
https://lore.kernel.org/rust-for-linux/20241101060237.1185533-1-boqun.f...@gmail.com/
v1:
https://lore.kernel.org/rust-for-linux/20240612223025.1158537-1-boqun.f...@gmail.com/
wip:
https://lore.kernel.org/rust-for-linux/2
On Sat, Nov 02, 2024 at 03:35:36PM +0800, David Gow wrote:
> On Fri, 1 Nov 2024 at 14:04, Boqun Feng wrote:
> >
> > Hi,
> >
> > This is another RFC version of LKMM atomics in Rust, you can find the
> > previous versions:
> >
> > v1:
> > https://lore.kernel.org/rust-for-linux/20240612223025.115853
On Sat, 19 Apr 2025 11:00:37 +0200, Luca Weiss wrote:
> Do some tweaks to the common file for the devices in the 'rhine' family
> of Sony devices, and add a dts for togari.
>
> Signed-off-by: Luca Weiss
> ---
> Kevin Widjaja (4):
> ARM: dts: qcom: sony-xperia-rhine: Enable USB charging
>
On Sat, 19 Apr 2025 11:08:19 +0200, Luca Weiss wrote:
> From: Adam Honse
>
> Add support for the touchkeys on the Samsung Galaxy Note 3 (hlte).
>
> Signed-off-by: Adam Honse
> ---
> Signed-off-by: Luca Weiss
> ---
> .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts| 45
>
On 4/17/25 1:19 PM, Beleswar Padhi wrote:
The .kick rproc ops implementations in TI K3 R5, DSP and M4 remoteproc
drivers sends a mailbox message to the remote processor in the same
way. Refactor the implementations into a common function
'k3_rproc_kick()' in the ti_k3_common.c driver.
Signed-off
On 4/17/25 1:19 PM, Beleswar Padhi wrote:
The rproc_reset() implementations in TI K3 DSP and M4 remoteproc drivers
assert reset in the same way. Refactor the above function into the
ti_k3_common.c driver as k3_rproc_reset() and use it throughout DSP and
M4 drivers for resetting the remote process
kernel test robot writes:
> All warnings (new ones prefixed by >>):
>
>>> kernel/bpf/core.c:3037:13: warning: no previous prototype for
>>> 'bpf_jit_bypass_spec_v1' [-Wmissing-prototypes]
> 3037 | bool __weak bpf_jit_bypass_spec_v1(void)
> | ^~
>>> ke
On Fri, Apr 18, 2025 at 10:22:04PM +0200, André Apitzsch via B4 Relay wrote:
> From: André Apitzsch
>
> Add tristate prompt to allow codec selection.
>
> Signed-off-by: André Apitzsch
> ---
Generally its good to say why one wants to make the symbol
selectable, usually its to use it with simple
On 2025-04-21 12:38, Dmitry Baryshkov wrote:
On Mon, Apr 21, 2025 at 04:04:16AM +0200, Barnabás Czémán wrote:
mbox_request_channel() returning value was changed in case of error.
It uses returning value of of_parse_phandle_with_args().
It is returning with -ENOENT instead of -ENODEV when no mbox
On Mon, Apr 21, 2025 at 11:39:14AM +0800, Jason Wang wrote:
> On Mon, Apr 21, 2025 at 10:45 AM Cindy Lu wrote:
> >
> > This patch reintroduces kthread mode support in vhost,
> > It also introduces struct vhost_worker_ops to abstract
> > worker create/stop/wakeup operations.
> >
> > * Bring back th
On Mon, Apr 21, 2025 at 10:44:08AM +0800, Cindy Lu wrote:
> This patch reintroduces kthread mode support in vhost,
> It also introduces struct vhost_worker_ops to abstract
> worker create/stop/wakeup operations.
>
> * Bring back the original vhost_worker() implementation,
> and renamed to vhost_
On Mon, Apr 21, 2025 at 04:04:16AM +0200, Barnabás Czémán wrote:
> mbox_request_channel() returning value was changed in case of error.
> It uses returning value of of_parse_phandle_with_args().
> It is returning with -ENOENT instead of -ENODEV when no mboxes property
> exists.
Why? What is the ra
This is based on the gadget from the description of commit 9183671af6db
("bpf: Fix leakage under speculation on mispredicted branches").
Signed-off-by: Luis Gerhorst
---
.../selftests/bpf/progs/verifier_unpriv.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/tools/t
ALU sanitization was introduced to ensure that a subsequent ptr access
can never go OOB, even under speculation. This is required because we
currently allow speculative scalar confusion. Spec. scalar confusion is
possible because Spectre v4 sanitization only adds a nospec after
critical stores (e.g
Insert a nospec before the access to prevent it from ever using an index
that is subject to speculative scalar-confusion.
The access itself can either happen directly in the BPF program (reads
only, check_stack_read_var_off()) or in a helper (read/write,
check_helper_mem_access()).
This relies on
This implements the core of the series and causes the verifier to fall
back to mitigating Spectre v1 using speculation barriers. The approach
was presented at LPC'24 [1] and RAID'24 [2].
If we find any forbidden behavior on a speculative path, we insert a
nospec (e.g., lfence speculation barrier o
This is made to clarify that this flag will cause a nospec to be added
after this insn and can therefore be relied upon to reduce speculative
path analysis.
Signed-off-by: Luis Gerhorst
Cc: Henriette Herzog
Cc: Maximilian Ott
Cc: Milan Stephan
---
include/linux/bpf_verifier.h | 2 +-
kernel/b
This changes the semantics of BPF_NOSPEC (previously a v4-only barrier)
to always emit a speculation barrier that works against both Spectre v1
AND v4. If mitigation is not needed on an architecture, the backend
should set bpf_jit_bypass_spec_v4/v1().
As of now, this commit only has the user-visib
Mark these cases as non-recoverable to later prevent them from being
caught when they occur during speculative path verification.
Eduard writes [1]:
The only pace I'm aware of that might act upon specific error code
from verifier syscall is libbpf. Looking through libbpf code, it seems
that
JITs can set bpf_jit_bypass_spec_v1/v4() if they want the verifier to
skip analysis/patching for the respective vulnerability. For v4, this
will reduce the number of barriers the verifier inserts. For v1, it
allows more programs to be accepted.
The primary motivation for this is to not regress unp
This prevents us from trying to recover from these on speculative paths
in the future.
Signed-off-by: Luis Gerhorst
Reviewed-by: Eduard Zingerman
Acked-by: Henriette Herzog
Cc: Maximilian Ott
Cc: Milan Stephan
---
kernel/bpf/verifier.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions
Currently, __xlated_unpriv and __jited_unpriv do not work because the
BPF syscall will overwrite info.jited_prog_len and info.xlated_prog_len
with 0 if the process is not bpf_capable(). This bug was not noticed
before, because there is no test that actually uses
__xlated_unpriv/__jited_unpriv.
To
This is required to catch the errors later and fall back to a nospec if
on a speculative path.
Eliminate the regs variable as it is only used once and insn_idx is not
modified in-between the definition and usage.
Still pass insn simply to match the other check_*() functions. As Eduard
points out
This improves the expressiveness of unprivileged BPF by inserting
speculation barriers instead of rejecting the programs.
The approach was previously presented at LPC'24 [1] and RAID'24 [2].
To mitigate the Spectre v1 (PHT) vulnerability, the kernel rejects
potentially-dangerous unprivileged BPF
Some common KVM test cases are supported on LoongArch now as following:
coalesced_io_test
demand_paging_test
dirty_log_perf_test
dirty_log_test
guest_print_test
hardware_disable_test
kvm_binary_stats_test
kvm_create_max_vcpus
kvm_page_table_test
memslot_modification_stress_test
Add ucall test support for LoongArch, ucall method on LoongArch uses
undefined mmio area. It will cause vCPU exits to hypervisor so that
hypervisor can communicate with vCPU.
Signed-off-by: Bibo Mao
---
.../selftests/kvm/include/loongarch/ucall.h | 20 ++
.../selftests/kvm/lib/loongarc
Add KVM selftests header files for LoongArch, including processor.h
and kvm_util_base.h. It mainly contains LoongArch CSR register
definition and page table entry definition.
Signed-off-by: Bibo Mao
---
.../testing/selftests/kvm/include/kvm_util.h | 5 +
.../kvm/include/loongarch/kvm_util_arc
Add core KVM selftests support for LoongArch, it includes exception
handler, mmu page table setup and vCPU startup entry support.
Signed-off-by: Bibo Mao
---
.../selftests/kvm/lib/loongarch/exception.S | 59 +++
.../selftests/kvm/lib/loongarch/processor.c | 342 ++
2 files c
This patchset adds KVM selftests for LoongArch system, currently only
some common test cases are supported and pass to run. These test cases
are listed as following:
coalesced_io_test
demand_paging_test
dirty_log_perf_test
dirty_log_test
guest_print_test
hardware_disable_tes
On LoongArch system, GVA width is 47 bit and GPA width is 47 bit also,
here add new vm mode VM_MODE_P47V47_16K.
Signed-off-by: Bibo Mao
---
tools/testing/selftests/kvm/include/kvm_util.h | 1 +
tools/testing/selftests/kvm/lib/kvm_util.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a
65 matches
Mail list logo
