[PATCH AUTOSEL 6.11 15/21] selftests/watchdog-test: Fix system accidentally reset after watchdog-test

From: Li Zhijian [ Upstream commit dc1308bee1ed03b4d698d77c8bd670d399dcd04d ] When running watchdog-test with 'make run_tests', the watchdog-test will be terminated by a timeout signal(SIGTERM) due to the test timemout. And then, a system reboot would happen due to watchdog not stop. see the dm

Re: [PATCH] dax: Allow block size > PAGE_SIZE

On Fri 01-11-24 21:22:31, Asahi Lina wrote: > For virtio-dax, the file/FS blocksize is irrelevant. FUSE always uses > large DAX blocks (2MiB), which will work with all host page sizes. Since > we are mapping files into the DAX window on the host, the underlying > block size of the filesystem and it

Re: [PATCH net-next] selftests: net: include lib/sh/*.sh with lib.sh

"Matthieu Baerts (NGI0)" writes: > Recently, the net/lib.sh file has been modified to include defer.sh from > net/lib/sh/ directory. The Makefile from net/lib has been modified > accordingly, but not the ones from the sub-targets using net/lib.sh. > > Because of that, the new file is not instal

Re: [PATCH v4 2/2] vsock/test: fix parameter types in SO_VM_SOCKETS_* calls

On Thu, Oct 31, 2024 at 11:04:06AM -0500, Konstantin Shkolnyy wrote: On 10/31/2024 09:16, Stefano Garzarella wrote: On Tue, Oct 29, 2024 at 09:49:54AM -0500, Konstantin Shkolnyy wrote: Change parameters of SO_VM_SOCKETS_* to uint64_t so that they are always In include/uapi/linux/vm_sockets.h

[PATCH AUTOSEL 6.6 10/14] selftests/watchdog-test: Fix system accidentally reset after watchdog-test

From: Li Zhijian [ Upstream commit dc1308bee1ed03b4d698d77c8bd670d399dcd04d ] When running watchdog-test with 'make run_tests', the watchdog-test will be terminated by a timeout signal(SIGTERM) due to the test timemout. And then, a system reboot would happen due to watchdog not stop. see the dm

[PATCH v13 1/7] remoteproc: core: Introduce rproc_pa_to_va helper

When a resource table is loaded by an external entity such as U-boot or OP-TEE, we do not necessarily get the device address(da) but the physical address(pa). This helper performs similar translation than the rproc_da_to_va() but based on a physical address. Signed-off-by: Arnaud Pouliquen --- d

[PATCH v13 2/7] remoteproc: Add TEE support

Add a remoteproc TEE (Trusted Execution Environment) driver that will be probed by the TEE bus. If the associated Trusted application is supported on secure part this driver offers a client interface to load a firmware by the secure part. This firmware could be authenticated by the secure trusted a

[PATCH v13 5/7] dt-bindings: remoteproc: Add compatibility for TEE support

The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration where the Cortex-M4 firmware is loaded by the Trusted Execution Environment (TEE). For instance, this compatible is used in both the Linux and OP-TEE device trees: - In OP-TEE, a node is defined in the device tree with the

[PATCH v13 4/7] remoteproc: Introduce release_fw optional operation

This patch updates the rproc_ops struct to include an optional release_fw function. The release_fw ops is responsible for releasing the remote processor firmware image. The ops is called in the following cases: - An error occurs in rproc_start() between the loading of the segments and the

[PATCH v13 0/7] Introduction of a remoteproc tee to load signed firmware

Main updates from version V12[1]: Fix warning build by fixing the inline declaration in remoteproc_tee.h (when CONFIG_REMOTEPROC_TEE is not set). Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202410262040.pwnrkv2q-...@intel.com/ Main updates from version V11[2]: -

[PATCH v13 3/7] remoteproc: core: Refactor resource table cleanup into rproc_release_fw

This patch centralizing the cleanup of the resource table into a new helper function rproc_release_fw(). More than just factorizing the code into a common function, it is the first step to integrate the release of the firmware image loaded by the OP-TEE remoteproc framework. Suggested-by: Mathieu

[PATCH v13 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware

The new TEE remoteproc driver is used to manage remote firmware in a secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is introduced to delegate the loading of the firmware to the trusted execution context. In such cases, the firmware should be signed and adhere to the image format de

[PATCH v13 6/7] remoteproc: stm32: Create sub-functions to request shutdown and release

To prepare for the support of TEE remoteproc, create sub-functions that can be used in both cases, with and without remoteproc TEE support. Signed-off-by: Arnaud Pouliquen --- drivers/remoteproc/stm32_rproc.c | 82 +++- 1 file changed, 49 insertions(+), 33 deletions(-

Re: [syzbot] [mm?] WARNING: locking bug in __rmqueue_pcplist

On Mon, Nov 04, 2024 at 12:45:06PM +0100, Peter Zijlstra wrote: > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c > index 6310a180278b..ac9f6682bb2f 100644 > --- a/mm/kasan/generic.c > +++ b/mm/kasan/generic.c > @@ -521,12 +521,12 @@ size_t kasan_metadata_size(struct kmem_cache *cache, > bool

Re: [syzbot] [mm?] WARNING: locking bug in __rmqueue_pcplist

On Mon, 4 Nov 2024 at 12:45, Peter Zijlstra wrote: > > On Mon, Nov 04, 2024 at 12:25:03PM +0100, Vlastimil Babka wrote: > > On 11/4/24 12:11, Vlastimil Babka wrote: > > > >> __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4771 > > >> alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 > > >

<    1   2