On Mon, Jan 06, 2025 at 04:13:29PM -0800, Kees Cook wrote:
> On Fri, Jan 03, 2025 at 05:13:32PM +0100, Petr Pavlu wrote:
> > On 12/5/24 20:46, Christophe Leroy wrote:
> > > This series reworks module loading to avoid leaving the module in a
> > > stale state when protecting ro_after_init section fa
Hello wpan maintainers/developers,
This is a 31-day syzbot report for the wpan subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/wpan
During the period, 0 new issues were detected and 0 were fixed.
In total, 4 issues are still open and 25 have al
On Tue, Jan 07, 2025 at 03:46:41PM +0530, Gokul Sriram Palanisamy wrote:
> From: Manikanta Mylavarapu
>
> Add new binding document for hexagon based WCSS secure PIL remoteproc.
> IPQ5332, IPQ5424 and IPQ9574 follows secure PIL remoteproc.
>
> Signed-off-by: Manikanta Mylavarapu
> Signed-off-by:
On Tue, Jan 07, 2025 at 03:46:45PM +0530, Gokul Sriram Palanisamy wrote:
> From: Manikanta Mylavarapu
>
> Enable nodes required for q6 remoteproc bring up.
>
> Signed-off-by: Manikanta Mylavarapu
> Signed-off-by: Gokul Sriram Palanisamy
> ---
> arch/arm64/boot/dts/qcom/ipq5332.dtsi | 64 +
On Thu, Jan 02, 2025 at 03:42:10PM -0300, Filipe Xavier wrote:
> This new test makes sure that ftrace can trace a
> function that was introduced by a livepatch.
>
Hi Filipe,
Thanks for adding a test!
Aside: another similar test could verify that the original function, in
this case cmdline_proc_s
On 11/14/24 5:40 PM, Pratik R. Sampat wrote:
> This patch series extends the sev_init2 and the sev_smoke test to
> exercise the SEV-SNP VM launch workflow.
>
> Primarily, it introduces the architectural defines, its support in the SEV
> library and extends the tests to interact with the SEV-SNP
During the execution of validate_complete_va_space() a lot of memory is
on the VM subsystem. When running on a low memory subsystem an OOM may
be triggered, when writing to the dump file as the filesystem may also
require memory.
On my test system with 1100MiB physical memory:
Tasks state
, 6 deletions(-)
---
base-commit: fbfd64d25c7af3b8695201ebc85efe90be28c5a3
change-id: 20250107-virtual_address_range-tests-95843766fa97
Best regards,
--
Thomas Weißschuh
If not enough physical memory is available the kernel may fail mmap();
see __vm_enough_memory() and vm_commit_limit().
In that case the logic in validate_complete_va_space() does not make
sense and will even incorrectly fail.
Instead skip the test if no mmap() succeeded.
Fixes: 010409649885 ("self
The virtual_address_range selftest reads from the start of each mapping
listed in /proc/self/maps.
However not all mappings are valid to be arbitrarily accessed.
For example the vvar data used for virtual clocks on x86 can only be
accessed if 1) the kernel configuration enables virtual clocks and 2
On 2025-01-06 13:24:28 [-0800], Sami Tolvanen wrote:
> Hi,
Hi,
> OK, great. That makes sense. Thanks for taking the time to test this!
Thank you two for testing, confirming and adding more informations to
what and why. I take some of this for the patch description.
> Sami
Sebastian
When mremap()ing a memory region previously registered with userfaultfd
as write-protected but without UFFD_FEATURE_EVENT_REMAP, an
inconsistency in flag clearing leads to a mismatch between the vma flags
(which have uffd-wp cleared) and the pte/pmd flags (which do not have
uffd-wp cleared). This m
Hi All,
This series contains a fix for a warning emitted when a uffd-registered region,
which doesn't have UFFD_FEATURE_EVENT_REMAP, is mremap()ed. patch 1 describes
the problem and fixes it, and patch 2 adds a selftest to verify the fix.
Thanks to Mikołaj Lenczewski who originally created the pa
Introduce a test that registers a range of memory for
UFFDIO_WRITEPROTECT_MODE_WP without UFFD_FEATURE_EVENT_REMAP. First
check that the uffd-wp bit is set for every PTE in the range. Then
mremap() the range to a new location and check that the uffd-wp bit is
clear for every PTE in the range.
Run
On Fri, 03 Jan 2025 12:11:56 +0100, Luca Weiss wrote:
> While out-of-tree already two of the three camera sensors are working on
> this smartphone, getting those upstream-ready will still take a while.
>
> Until then already enable the EEPROMs found on those camera sensors
> which doesn't have a
Switching to -O2 when building the mm tests has the unexpected side
effect of triggering many unused-result warnings on certain distros
like Ubuntu, where GCC is configured so that -O2 implies
-D_FORTIFY_SOURCE.
Explicitly disable FORTIFY_SOURCE to avoid those warnings. This has
no effect on upstr
On 2025-01-02 13:47:06 [+0100], Christophe Leroy wrote:
> Hi Sebastian,
Hi Christophe,
> How did you generate that cover letter ?
>
> It should contain the full list of files modified by the series, so that I
> can see if any of them is of interest to me without going into each patch.
>
> This i
syscall_set_arguments() is going to be needed to implement
PTRACE_SET_SYSCALL_INFO API.
This is a partial revert: on a few architectures syscall_set_arguments()
implementations were buggy, so instead of adding them here and applying
fixes on top, cleaner implementations are coming in follow-up com
Similar to syscall_set_arguments() that complements
syscall_get_arguments(), introduce syscall_set_nr()
that complements syscall_get_nr().
syscall_set_nr() is going to be needed along with
syscall_set_arguments() on all HAVE_ARCH_TRACEHOOK
architectures to implement PTRACE_SET_SYSCALL_INFO API.
S
Check whether PTRACE_SET_SYSCALL_INFO semantics implemented in the
kernel matches userspace expectations.
Signed-off-by: Dmitry V. Levin
---
tools/testing/selftests/ptrace/Makefile | 2 +-
.../selftests/ptrace/set_syscall_info.c | 436 ++
2 files changed, 437 insert
On 1/3/25 2:10 AM, Bastien Curutchet (eBPF Foundation) wrote:
+static int ping_setup(struct test_data *data)
+{
+ struct nstoken *nstoken = NULL;
+ int i;
+
+ data->ns[0] = netns_new(NS0, false);
+ if (!ASSERT_OK_PTR(data->ns[0], "create ns"))
+ return -1;
+
From: Manikanta Mylavarapu
Enable nodes required for q6 remoteproc bring up.
Signed-off-by: Manikanta Mylavarapu
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/qcom/ipq5332.dtsi | 64 ++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/arc
From: Manikanta Mylavarapu
Enable nodes required for q6 remoteproc bring up.
Signed-off-by: Manikanta Mylavarapu
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 60 ++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/arc
Enable nodes required for q6 remoteproc bring up.
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/qcom/ipq5424.dtsi | 80 ++-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq5424.dtsi
b/arch/arm64/boot/dts/qcom/ipq
On Mon, Jan 06, 2025 at 01:03:31PM -0800, Shakeel Butt wrote:
> Hey Lorenzo & Christian, what's the latest here? I see Christian has
> code suggestions at [1] which just needs to be addressed. Any thing
> else? I am hoping we can get this merged in the coming open window.
This is on my radar don't
On Fri, Dec 20, 2024 at 06:41:14PM +0100, Sebastian Andrzej Siewior wrote:
> Hi,
>
> This is an updated version of the inital post after PeterZ made me aware
> that there are users outside of the module directory.
> The goal is replace the mix auf rcu_read_lock(), rcu_read_lock_sched()
> and preem
On (24/12/20 18:41), Sebastian Andrzej Siewior wrote:
> dereference_symbol_descriptor() needs to obtain the module pointer
> belonging to pointer in order to resolve that pointer.
> The returned mod pointer is obtained under RCU-sched/ preempt_disable()
> guarantees and needs to be used within this
This series depends on Sricharan's tmel-qmp mailbox driver series v2 [1].
- Secure PIL is signed, split firmware images which only TrustZone (TZ)
can authenticate and load. Linux kernel will send a request to TZ to
authenticate and load the PIL images.
- When secure PIL support was added to t
From: Manikanta Mylavarapu
IPQ5332 security software running under trustzone requires metadata size.
With new command support added in TrustZone that includes a size parameter,
pass metadata size as well. This new command is specific to IPQ5332 SoC.
Signed-off-by: Manikanta Mylavarapu
Signed-of
This series depends on Sricharan's tmel-qmp mailbox driver series v2 [1].
- Secure PIL is signed, split firmware images which only TrustZone (TZ)
can authenticate and load. Linux kernel will send a request to TZ to
authenticate and load the PIL images.
- When secure PIL support was added to t
From: Manikanta Mylavarapu
Add new binding document for hexagon based WCSS secure PIL remoteproc.
IPQ5332, IPQ5424 and IPQ9574 follows secure PIL remoteproc.
Signed-off-by: Manikanta Mylavarapu
Signed-off-by: Gokul Sriram Palanisamy
Reviewed-by: Krzysztof Kozlowski
---
.../remoteproc/qcom,wc
From: Manikanta Mylavarapu
IPQ5332 security software running under trustzone requires metadata size.
With new command support added in TrustZone that includes a size parameter,
pass metadata size as well. This new command is specific to IPQ5332 SoC.
Signed-off-by: Manikanta Mylavarapu
Signed-of
From: Vignesh Viswanathan
Add support to bring up hexagon based WCSS secure PIL remoteproc.
IPQ5332, IPQ9574 supports secure PIL remoteproc.
Signed-off-by: Vignesh Viswanathan
Signed-off-by: Manikanta Mylavarapu
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/Kconfig
IPQ5424 mailbox do not have clock support and reuses msm8994_apcs_data.
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
index
Add compatible for the Qualcomm IPQ5424 APCS block.
Signed-off-by: Gokul Sriram Palanisamy
---
.../devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
b/Documentati
On 1/8/2025 10:46 AM, Hangbin Liu wrote:
On Mon, Jan 06, 2025 at 10:47:16AM +, Hangbin Liu wrote:
On Thu, Jan 02, 2025 at 11:33:34AM +0800, Jianbo Liu wrote:
Re-locking doesn't look great, glancing at the code I don't see any
obvious better workarounds. Easiest fix would be to don't let
On 07/01/25 8:44 pm, Thomas Weißschuh wrote:
If not enough physical memory is available the kernel may fail mmap();
see __vm_enough_memory() and vm_commit_limit().
In that case the logic in validate_complete_va_space() does not make
sense and will even incorrectly fail.
Instead skip the test if
[..]
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
This will require mailbox maintainer to first accept the tmelcom mailbox
driver, and share a immutable branch wit
Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()"
and "k3_r5_rproc_kick()" callbacks to exit if the remote core's state
was "RPROC_DETACHED". However, this caused issues in IPC-only mode, as
the default sta
Commit ea1d6fb5b571 ("remoteproc: k3-dsp: Acquire mailbox handle during
probe routine") introduced a check in the "k3_dsp_rproc_mbox_callback()"
and "k3_dsp_rproc_kick()" callbacks to exit if the remote core's state
was "RPROC_DETACHED". However, this caused issues in IPC-only mode, as
the default
The existing implementation of the waiting mechanism in
"k3_r5_cluster_rproc_init()" waits for the "released_from_reset" flag to
be set as part of the firmware boot process in "k3_r5_rproc_start()".
The "k3_r5_cluster_rproc_init()" function is invoked in the probe
routine which causes unexpected fa
This series cleans up the TI R5F remoteproc driver by addressing various bugs.
This is also the second series as part of the refactoring of K3 remoteproc
drivers[0]. The third and final series for K3 Refactoring is also posted[1]
which deals with the TI DSP and TI M4 drivers. The R5F driver takes c
Hey,
it looks like this patch is missing in 6.13-rc6 while the driver and DTS
changes got merged. Gentle ping if it's not somewhere else in a queue
for 6.14.
- Daniel
On 02.08.24 17:21, Andrew Davis wrote:
> From: Hari Nagalla
>
> Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core.
On Wed, Jan 08, 2025 at 11:40:05AM +0800, Jianbo Liu wrote:
>
>
> On 1/8/2025 10:46 AM, Hangbin Liu wrote:
> > On Mon, Jan 06, 2025 at 10:47:16AM +, Hangbin Liu wrote:
> > > On Thu, Jan 02, 2025 at 11:33:34AM +0800, Jianbo Liu wrote:
> > > > > > Re-locking doesn't look great, glancing at the
On Wed, Jan 08, 2025 at 11:39:40AM +0530, Dev Jain wrote:
>
> On 07/01/25 8:44 pm, Thomas Weißschuh wrote:
> > During the execution of validate_complete_va_space() a lot of memory is
> > on the VM subsystem. When running on a low memory subsystem an OOM may
> > be triggered, when writing to the du
On Wed, Jan 8, 2025 at 10:57 AM Cindy Lu wrote:
>
> On Thu, Jan 2, 2025 at 11:29 AM Jason Wang wrote:
> >
> > On Mon, Dec 30, 2024 at 8:45 PM Cindy Lu wrote:
> > >
> > > Reintroduce the previously removed functions vhost_attach_cgroups_work()
> > > and vhost_attach_cgroups() to support kthread m
PFN_DEV is used by callers of dax_direct_access() to figure out if the
returned PFN is associated with a page or not. However all DAX PFNs
now require an assoicated ZONE_DEVICE page so can assume a page
exists.
Other users of PFN_DEV were setting it before calling
vmf_insert_mixed(). This is unnec
Once my series[1] and Dan's cleanup[2] is merged all users of DAX will
require a ZONE_DEVICE page which is properly refcounted. This means there
is no longer any need for the PFN_DEV and PFN_MAP flags. Furthermore the
PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used. It is
therefo
The PFN_MAP flag is no longer used for anything, so remove it. The
PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used so
also remove them.
Signed-off-by: Alistair Popple
---
include/linux/pfn_t.h | 10 ++
tools/testing/nvdimm/test/iomap.c | 4
2 files cha
None of the functionality in pfn_t.h is required so delete it.
Signed-off-by: Alistair Popple
---
include/linux/pfn.h | 10 +-
include/linux/pfn_t.h | 88 +
2 files changed, 98 deletions(-)
delete mode 100644 include/linux/pfn_t.h
diff --git a/
All PFN_* pfn_t flags have been removed. Therefore there is no longer
a need for the pfn_t type and all uses can be replaced with normal
pfns.
Signed-off-by: Alistair Popple
---
I'm guessing people will want this split up into several patches for
merging/review. If so I will do that once the pr
On Tue, Jan 07, 2025 at 03:46:43PM +0530, Gokul Sriram Palanisamy wrote:
> From: Vignesh Viswanathan
>
> Add support to bring up hexagon based WCSS secure PIL remoteproc.
> IPQ5332, IPQ9574 supports secure PIL remoteproc.
I'd love for this to be extended with a short description of what the
WCSS
On Tue, Jan 07, 2025 at 03:46:40PM +0530, Gokul Sriram Palanisamy wrote:
> From: Manikanta Mylavarapu
>
> IPQ5332 security software running under trustzone requires metadata size.
> With new command support added in TrustZone that includes a size parameter,
> pass metadata size as well. This new
On Wed, Jan 08, 2025 at 12:18:47PM +1100, Alistair Popple wrote:
> All PFN_* pfn_t flags have been removed. Therefore there is no longer
> a need for the pfn_t type and all uses can be replaced with normal
> pfns.
Looks good in general:
Reviewed-by: Christoph Hellwig
Would be nice if you'd fix
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
I'd just merge this into the previous patch, but otherwise this looks
good:
Reviewed-by: Christoph Hellwig
On 07/01/2025 13:56, Gokul Sriram P wrote:
>>> +examples:
>>> + - |
>>> +#include
>>> +#include
>>> +remoteproc@d10 {
>>> + compatible = "qcom,ipq5332-wcss-sec-pil";
>>> + reg = <0xd10 0x4040>;
>>> + firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw0.mdt";
>> Nit: .m
On Mon, Jan 06, 2025 at 10:47:16AM +, Hangbin Liu wrote:
> On Thu, Jan 02, 2025 at 11:33:34AM +0800, Jianbo Liu wrote:
> > > > Re-locking doesn't look great, glancing at the code I don't see any
> > > > obvious better workarounds. Easiest fix would be to don't let the
> > > > drivers sleep in t
On Thu, Jan 2, 2025 at 11:37 AM Jason Wang wrote:
>
> On Mon, Dec 30, 2024 at 8:45 PM Cindy Lu wrote:
> >
> > Add a new UAPI to enable setting the vhost device to task mode.
> > The userspace application can use VHOST_SET_INHERIT_FROM_OWNER
> > to configure the mode if necessary.
> > This setting
On Thu, Jan 2, 2025 at 11:33 AM Jason Wang wrote:
>
> On Mon, Dec 30, 2024 at 8:45 PM Cindy Lu wrote:
> >
> > Restore the previously removed functions kthread_wakeup and
> > kthread_stop, and add two new function pointers to wake up and stop
> > the workers. The function vhost_worker_create will
On Thu, Jan 2, 2025 at 11:29 AM Jason Wang wrote:
>
> On Mon, Dec 30, 2024 at 8:45 PM Cindy Lu wrote:
> >
> > Reintroduce the previously removed functions vhost_attach_cgroups_work()
> > and vhost_attach_cgroups() to support kthread mode. Rename
> > vhost_attach_cgroups() to vhost_attach_task_to_
On Thu, Jan 2, 2025 at 11:19 AM Jason Wang wrote:
>
> On Mon, Dec 30, 2024 at 8:45 PM Cindy Lu wrote:
> >
> > Add the previously removed function vhost_worker() back to support the
> > kthread and rename it to vhost_run_work_kthread_list.
> >
> > The old function vhost_worker() was changed to sup
On 1/8/2025 11:59 AM, Sricharan Ramabadhran wrote:
[..]
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
This will require mailbox maintainer to first accept the t
From: Yongliang Gao
When counting the number of hardirqs in the x86 architecture,
it is essential to add arch_irq_stat_cpu to ensure accuracy.
For example, a CPU loop within the rcu_read_lock function.
Before:
[ 70.910184] rcu: INFO: rcu_preempt self-detected stall on CPU
[ 70.910436] rcu:
65 matches
Mail list logo
