On Wed, 19 Jun 2024 13:59:15 -0700
Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports for lib/test_*.ko:
> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/test_hexdump.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/test_dhry.o
> WARNING: modpost: missing
arch_kmsan_get_meta_or_null() finds the lowcore shadow by querying the
prefix and calling kmsan_get_metadata() again.
kmsan_virt_addr_valid() delegates to virt_addr_valid().
Acked-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
put_user() uses inline assembly with precise constraints, so Clang is
in principle capable of instrumenting it automatically. Unfortunately,
one of the constraints contains a dereferenced user pointer, and Clang
does not currently distinguish user and kernel pointers. Therefore
KMSAN attempts to
Now that everything else is in place, enable KMSAN in Kconfig.
Acked-by: Heiko Carstens
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index
The unwind code can read uninitialized frames. Furthermore, even in
the good case, KMSAN does not emit shadow for backchains. Therefore
disable it for the unwinding functions.
Reviewed-by: Alexander Potapenko
Acked-by: Heiko Carstens
Signed-off-by: Ilya Leoshkevich
---
uaccess.h uses instrument_get_user() and instrument_put_user(), which
are defined in linux/instrumented.h. Currently we get this header from
somewhere else by accident; prefer to be explicit about it and include
it directly.
Suggested-by: Alexander Potapenko
Reviewed-by: Alexander Potapenko
stcctm() uses the "Q" constraint for dest, therefore KMSAN does not
understand that it fills multiple doublewords pointed to by dest, not
just one. This results in false positives.
Unpoison the whole dest manually with kmsan_unpoison_memory().
Reported-by: Alexander Gordeev
Reviewed-by:
This is normally done by the generic entry code, but the
kernel_stack_overflow() flow bypasses it.
Reviewed-by: Alexander Potapenko
Acked-by: Heiko Carstens
Signed-off-by: Ilya Leoshkevich
---
arch/s390/kernel/traps.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
The pages for the KMSAN metadata associated with most kernel mappings
are taken from memblock by the common code. However, vmalloc and module
metadata needs to be defined by the architectures.
Be a little bit more careful than x86: allocate exactly MODULES_LEN
for the module shadow and origins,
Lockdep generates the following false positives with KMSAN on s390x:
[6.063666] DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled())
[ ...]
[6.577050] Call Trace:
[6.619637] [<0690d2de>] check_flags+0x1fe/0x210
[6.665411] ([<0690d2da>] check_flags+0x1fa/0x210)
Add KMSAN vmalloc metadata areas to kernel_page_tables.
Signed-off-by: Ilya Leoshkevich
---
arch/s390/mm/dump_pagetables.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/s390/mm/dump_pagetables.c b/arch/s390/mm/dump_pagetables.c
index
Add KMSAN support for the s390 implementations of the string functions.
Do this similar to how it's already done for KASAN, except that the
optimized memset{16,32,64}() functions need to be disabled: it's
important for KMSAN to know that they initialized something.
The way boot code is built with
Architectures use assembly code to initialize ftrace_regs and call
ftrace_ops_list_func(). Therefore, from the KMSAN's point of view,
ftrace_regs is poisoned on ftrace_ops_list_func entry(). This causes
KMSAN warnings when running the ftrace testsuite.
Fix by trusting the architecture-specific
Adjust the stack size for the KMSAN-enabled kernel like it was done
for the KASAN-enabled one in commit 7fef92ccadd7 ("s390/kasan: double
the stack size"). Both tools have similar requirements.
Reviewed-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
Add a KMSAN check to the CKSM inline assembly, similar to how it was
done for ASAN in commit e42ac7789df6 ("s390/checksum: always use cksm
instruction").
Acked-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/include/asm/checksum.h | 2 ++
1
s390 uses assembly code to initialize ftrace_regs and call
kprobe_ftrace_handler(). Therefore, from the KMSAN's point of view,
ftrace_regs is poisoned on kprobe_ftrace_handler() entry. This causes
KMSAN warnings when running the ftrace testsuite.
Fix by trusting the assembly code and always
Diagnose 224 stores 4k bytes, which currently cannot be deduced from
the inline assembly constraints. This leads to KMSAN false positives.
Fix the constraints by using a 4k-sized struct instead of a raw
pointer. While at it, prettify them too.
Suggested-by: Heiko Carstens
Reviewed-by: Alexander
It should be possible to have inline functions in the s390 header
files, which call kmsan_unpoison_memory(). The problem is that these
header files might be included by the decompressor, which does not
contain KMSAN runtime, causing linker errors.
Not compiling these calls if __SANITIZE_MEMORY__
KMSAN relies on memblock returning all available pages to it
(see kmsan_memblock_free_pages()). It partitions these pages into 3
categories: pages available to the buddy allocator, shadow pages and
origin pages. This partitioning is static.
If new pages appear after kmsan_init_runtime(), it is
The inline assembly block in s390's chsc() stores that much.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan/instrumentation.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/kmsan/instrumentation.c b/mm/kmsan/instrumentation.c
index
Prevent KMSAN from complaining about buffers filled by cpacf_trng()
being uninitialized.
Tested-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Acked-by: Heiko Carstens
Signed-off-by: Ilya Leoshkevich
---
arch/s390/include/asm/cpacf.h | 3 +++
1 file changed, 3 insertions(+)
diff
All other sanitizers are disabled for boot as well. While at it, add a
comment explaining why we need this.
Reviewed-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/boot/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git
KMSAN warns about check_canary() accessing the canary.
The reason is that, even though set_canary() is properly instrumented
and sets shadow, slub explicitly poisons the canary's address range
afterwards.
Unpoisoning the canary is not the right thing to do: only
check_canary() is supposed to
On s390 the virtual address 0 is valid (current CPU's lowcore is mapped
there), therefore KMSAN should not complain about it.
Disable the respective check on s390. There doesn't seem to be a
Kconfig option to describe this situation, so explicitly check for
s390.
Reviewed-by: Alexander Potapenko
KMSAN_WARN_ON() is required for implementing s390-specific KMSAN
functions, but right now it's available only to the KMSAN internal
functions. Expose it to subsystems through .
Signed-off-by: Ilya Leoshkevich
---
include/linux/kmsan.h | 25 +
mm/kmsan/kmsan.h | 24
The constraints of the DFLTCC inline assembly are not precise: they
do not communicate the size of the output buffers to the compiler, so
it cannot automatically instrument it.
Add the manual kmsan_unpoison_memory() calls for the output buffers.
The logic is the same as in [1].
[1]
Improve the readability by replacing the custom aligning logic with
ALIGN_DOWN(). Unlike other places where a similar sequence is used,
there is no size parameter that needs to be adjusted, so the standard
macro fits.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
Building the kernel with CONFIG_SLUB_DEBUG and CONFIG_KMSAN causes
KMSAN to complain about touching redzones in kfree().
Fix by extending the existing KASAN-related metadata_access_enable()
and metadata_access_disable() functions to KMSAN.
Acked-by: Vlastimil Babka
Reviewed-by: Alexander
Avoid false KMSAN negatives with SLUB_DEBUG by allowing
kmsan_slab_free() to poison the freed memory, and by preventing
init_object() from unpoisoning new allocations by using __memset().
There are two alternatives to this approach. First, init_object()
can be marked with __no_sanitize_memory.
Even though the KMSAN warnings generated by memchr_inv() are suppressed
by metadata_access_enable(), its return value may still be poisoned.
The reason is that the last iteration of memchr_inv() returns
`*start != value ? start : NULL`, where *start is poisoned. Because of
this, somewhat
x86's alloc_node_data() rounds up node data size to PAGE_SIZE. It's not
explained why it's needed, but it's most likely for performance
reasons, since the padding bytes are not used anywhere. Some other
architectures do it as well, e.g., mips rounds it up to the cache line
size.
The value assigned to prot is immediately overwritten on the next line
with PAGE_KERNEL. The right hand side of the assignment has no
side-effects.
Fixes: b073d7f8aee4 ("mm: kmsan: maintain KMSAN metadata for page operations")
Suggested-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Add a wrapper for memset() that prevents unpoisoning. This is useful
for filling memory allocator redzones.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
include/linux/kmsan.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/linux/kmsan.h
Like for KASAN, it's useful to temporarily disable KMSAN checks around,
e.g., redzone accesses. Introduce kmsan_disable_current() and
kmsan_enable_current(), which are similar to their KASAN counterparts.
Make them reentrant in order to handle memory allocations in interrupt
context. Repurpose
Comparing pointers with TASK_SIZE does not make sense when kernel and
userspace overlap. Assume that we are handling user memory access in
this case.
Reported-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan/hooks.c | 3 ++-
1 file changed, 2
When building the kmsan test as a module, modpost fails with the
following error message:
ERROR: modpost: "panic_on_kmsan" [mm/kmsan/kmsan_test.ko] undefined!
Export panic_on_kmsan in order to improve the KMSAN usability for
modules.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya
It's useful to have both tests and kmsan.panic=1 during development,
but right now the warnings, that the tests cause, lead to kernel
panics.
Temporarily set kmsan.panic=0 for the duration of the KMSAN testing.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
Replace the x86-specific asm/pgtable_64_types.h #include with the
linux/pgtable.h one, which all architectures have.
While at it, sort the headers alphabetically for the sake of
consistency with other KMSAN code.
Fixes: f80be4571b19 ("kmsan: add KMSAN runtime core")
Suggested-by: Heiko Carstens
v5: https://lore.kernel.org/lkml/20240619154530.163232-1-...@linux.ibm.com/
v5 -> v6: Include KMSAN vmalloc metadata areas in page table dump.
Fix doc comments; use KMSAN_WARN_ON (Alexander P.).
Patches that need review:
- [PATCH 16/39] kmsan: Expose KMSAN_WARN_ON()
Each s390 CPU has lowcore pages associated with it. Each CPU sees its
own lowcore at virtual address 0 through a hardware mechanism called
prefixing. Additionally, all lowcores are mapped to non-0 virtual
addresses stored in the lowcore_ptr[] array.
When lowcore is accessed through virtual
Comparing pointers with TASK_SIZE does not make sense when kernel and
userspace overlap. Skip the comparison when this is the case.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan/instrumentation.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
On Thu, 2024-06-20 at 10:06 -0500, Haitao Huang wrote:
> Hi Kai
>
> On Thu, 20 Jun 2024 05:30:16 -0500, Huang, Kai wrote:
>
> >
> > On 18/06/2024 12:53 am, Huang, Haitao wrote:
> > > From: Kristen Carlson Accardi
> > >
> > > Previous patches have implemented all infrastructure needed for
> >
On Wed, Jun 19, 2024 at 08:30:37AM +, Yusong Gao wrote:
> Add log information in kernel-space when loading module failures.
> Try to load the unsigned module and the module with bad signature
> when set 1 to /sys/module/module/parameters/sig_enforce.
>
> Unsigned module case:
> (linux) insmod
> >
> > > In other cases, the caller may invoke this function in a
> > > loop to ensure enough pages reclaimed for its usage. To ensure all
> > > descendant groups scanned in a round-robin fashion in those cases,
> > > sgx_cgroup_reclaim_pages() takes in a starting cgroup and returns the
> > >
On Thu, Jun 20, 2024 at 05:31:42PM GMT, Komal Bajaj wrote:
> From: Melody Olvera
>
> Some chipsets will have DSPs which will have begun running prior
> to linux booting, so add support to late attach these DSPs by
> adding support for:
> - run-time checking of an offline or running DSP via rmb
On Thu, Jun 20, 2024 at 05:31:41PM GMT, Komal Bajaj wrote:
> From: Melody Olvera
>
> When attaching a running Q6, the remoteproc driver needs a way
> to communicate with the Q6 using rmb registers, so allow the
> rmb register to be gotten from the device tree if present.
rmb or RMB? And what is
On Thu, Jun 20, 2024 at 12:40 PM Oleg Nesterov wrote:
>
> On 06/20, Andrii Nakryiko wrote:
> >
> > Can we instead ask loongarch folks to rewrite it to be a constant?
> > Having this as a function call is both an inconvenience and potential
> > performance problem (a minor one, but still). I would
On Tue, Jun 11, 2024 at 09:39:00AM +0200, Arnaud Pouliquen wrote:
> When a resource table is loaded by an external entity such as U-boot or
> OP-TEE, we do not necessary get the device address(da) but the physical
s/necessary/necessarily
> address(pa).
> This helper performs similar translation
On Donnerstag, 20. Juni 2024 22:54:37 MESZ Dmitry Baryshkov wrote:
> On Wed, Jun 19, 2024 at 11:02:49PM GMT, Luca Weiss wrote:
> > Add a node for the a7pll with its frequencies. With this we can use the
> > apcs-kpss-global driver for the apcs node and use the apcs to scale the
> > CPU frequency
On Wed, Jun 19, 2024 at 11:02:51PM GMT, Luca Weiss wrote:
> Since we now have the apcs set up as a mailbox provider, let's use the
> interface for all drivers where possible.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 6 +++---
> 1 file changed, 3
On Wed, Jun 19, 2024 at 11:02:50PM GMT, Luca Weiss wrote:
> Add cooling-maps for the CPU thermal zones so the driver can actually do
> something when the CPU temperature rises too much.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 25 +
On Wed, Jun 19, 2024 at 06:33:05PM +0200, Arnaud POULIQUEN wrote:
> Hi,
>
> On 6/19/24 17:41, Mathieu Poirier wrote:
> > Hi,
> >
> > On Tue, Jun 11, 2024 at 09:39:01AM +0200, Arnaud Pouliquen wrote:
> >> Add a remoteproc TEE (Trusted Execution Environment) driver
> >> that will be probed by the
On Wed, Jun 19, 2024 at 11:02:49PM GMT, Luca Weiss wrote:
> Add a node for the a7pll with its frequencies. With this we can use the
> apcs-kpss-global driver for the apcs node and use the apcs to scale the
> CPU frequency according to the opp-table.
>
> At the same time unfortunately we need to
On Wed, Jun 19, 2024 at 06:42:31PM GMT, Luca Weiss wrote:
> With the smsm bindings and driver finally supporting mboxes, switch to
> that and stop using apcs as syscon.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/msm8976.dtsi | 4 +---
> 1 file changed, 1 insertion(+), 3
On Wed, Jun 19, 2024 at 06:42:30PM GMT, Luca Weiss wrote:
> With the smsm bindings and driver finally supporting mboxes, switch to
> that and stop using apcs as syscon.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/msm8953.dtsi | 3 +--
> 1 file changed, 1 insertion(+), 2
On Wed, Jun 19, 2024 at 06:42:29PM GMT, Luca Weiss wrote:
> With the smsm bindings and driver finally supporting mboxes, switch to
> that and stop using apcs as syscon.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/msm8939.dtsi | 3 +--
> 1 file changed, 1 insertion(+), 2
On Wed, Jun 19, 2024 at 06:42:28PM GMT, Luca Weiss wrote:
> With the smsm bindings and driver finally supporting mboxes, switch to
> that and stop using apcs as syscon.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 +--
> 1 file changed, 1 insertion(+), 2
On Wed, Jun 19, 2024 at 06:42:27PM GMT, Luca Weiss wrote:
> With the smsm bindings and driver finally supporting mboxes, switch to
> that and stop using apcs as syscon.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 4 +---
> 1 file changed, 1 insertion(+), 3
On Tue, Jun 11, 2024 at 09:39:01AM +0200, Arnaud Pouliquen wrote:
> 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 in
On 06/20, Andrii Nakryiko wrote:
>
> Can we instead ask loongarch folks to rewrite it to be a constant?
> Having this as a function call is both an inconvenience and potential
> performance problem (a minor one, but still). I would imagine it's not
> hard to hard-code an instruction as a constant
On Tue, Jun 18, 2024 at 12:43 PM Jiri Olsa wrote:
>
> Nathan reported compilation fail for loongarch arch:
>
> kernel/events/uprobes.c: In function 'arch_uprobe_trampoline':
> arch/loongarch/include/asm/uprobes.h:12:33: error: initializer element is
> not constant
> 12 | #define
On 06/20, Guenter Roeck wrote:
>
> On Tue, Jun 11, 2024 at 01:21:52PM +0200, Jiri Olsa wrote:
> > Adding uretprobe syscall instead of trap to speed up return probe.
> >
>
> This patch results in:
>
> Building loongarch:allmodconfig ... failed
> --
> Error log:
> In file included from
On Thu, 2024-06-20 at 13:19 +0200, Ilya Leoshkevich wrote:
> On Thu, 2024-06-20 at 10:36 +0200, Alexander Potapenko wrote:
> > On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich
> >
> > wrote:
> > >
> > > put_user() uses inline assembly with precise constraints, so
> > > Clang
> > > is
> > > in
On 19/06/2024 05:40, Andy Chiu wrote:
On Tue, Jun 18, 2024 at 9:40 PM Alexandre Ghiti wrote:
Hi Andy,
On Tue, Jun 18, 2024 at 2:48 PM Andy Chiu wrote:
On Tue, Jun 18, 2024 at 8:02 PM Alexandre Ghiti wrote:
Hi Conor,
On 17/06/2024 15:23, Alexandre Ghiti wrote:
Hi Conor,
Sorry for the
On Thu, 2024-06-20 at 14:37 +0200, Peter Hilber wrote:
> Changing virtio-dev address to the new one. The discussion might also be
> relevant for virtio-comment, but it is discouraged to forward it to both.
I will happily take it to whichever forum you think is most
appropriate. (And you have my
To allow precise tracking of page caches accessed, add new tracepoints
that trigger when a process actually accesses them.
The ureadahead program used by ChromeOS traces the disk access of
programs as they start up at boot up. It uses mincore(2) or the
'mm_filemap_add_to_page_cache' trace event
Thank you Matthew for taking a look at this!
I fix both points and send a V2 patch.
> This needs to be cast to an loff_t before shifting.
I found that this applies to add_to_page_cache and delete_from_page_cache, too.
I could fix them too, but I didn't since it will change the max value
of those
On Thu, 20 Jun 2024 08:28:57 -0500, Huang, Kai wrote:
On 18/06/2024 12:53 am, Huang, Haitao wrote:
From: Kristen Carlson Accardi
Currently in the EPC page allocation, the kernel simply fails the
allocation when the current EPC cgroup fails to charge due to its usage
reaching limit. This
+ if (cgroup_subsys_enabled(misc_cgrp_subsys)) {
+ sgx_cg_wq = alloc_workqueue("sgx_cg_wq", WQ_UNBOUND |
WQ_FREEZABLE,
+ WQ_UNBOUND_MAX_ACTIVE);
+ return -ENOMEM;
Argh, missing if(!sgx_cg_wq), sorry for the brain
Hi Kai
On Thu, 20 Jun 2024 05:30:16 -0500, Huang, Kai wrote:
On 18/06/2024 12:53 am, Huang, Haitao wrote:
From: Kristen Carlson Accardi
Previous patches have implemented all infrastructure needed for
per-cgroup EPC page tracking and reclaiming. But all reclaimable EPC
pages are still
On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich wrote:
>
> Avoid false KMSAN negatives with SLUB_DEBUG by allowing
> kmsan_slab_free() to poison the freed memory, and by preventing
> init_object() from unpoisoning new allocations by using __memset().
>
> There are two alternatives to this
On Thu, 2024-06-20 at 14:01 +0200, Peter Hilber wrote:
> On 15.06.24 10:01, David Woodhouse wrote:
> > On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
> > >
> > > + ret = viortc_hw_xtstamp_params(_counter, _id);
> > > + if (ret)
> > > + return ret;
> > > +
> > > +
On Thu, Jun 20, 2024 at 4:18 PM Alexander Potapenko wrote:
>
> On Thu, Jun 20, 2024 at 3:38 PM Ilya Leoshkevich wrote:
> >
> > On Thu, 2024-06-20 at 11:25 +0200, Alexander Gordeev wrote:
> > > On Wed, Jun 19, 2024 at 05:44:11PM +0200, Ilya Leoshkevich wrote:
> > >
> > > Hi Ilya,
> > >
> > > >
On Thu, Jun 20, 2024 at 3:38 PM Ilya Leoshkevich wrote:
>
> On Thu, 2024-06-20 at 11:25 +0200, Alexander Gordeev wrote:
> > On Wed, Jun 19, 2024 at 05:44:11PM +0200, Ilya Leoshkevich wrote:
> >
> > Hi Ilya,
> >
> > > +static inline bool is_lowcore_addr(void *addr)
> > > +{
> > > + return addr
On Wed, Jun 19, 2024 at 05:44:11PM +0200, Ilya Leoshkevich wrote:
> arch_kmsan_get_meta_or_null() finds the lowcore shadow by querying the
> prefix and calling kmsan_get_metadata() again.
>
> kmsan_virt_addr_valid() delegates to virt_addr_valid().
>
> Signed-off-by: Ilya Leoshkevich
> ---
>
On Thu, 20 Jun 2024 17:31:40 +0530, Komal Bajaj wrote:
> From: Melody Olvera
>
> Document the compatible for the component used to boot the MPSS on the
> QDU1000 and QRU1000 SoCs.
>
> The QDU1000 and QRU1000 mpss boot process now requires the specification
> of an RMB register space to
On Thu, 2024-06-20 at 11:25 +0200, Alexander Gordeev wrote:
> On Wed, Jun 19, 2024 at 05:44:11PM +0200, Ilya Leoshkevich wrote:
>
> Hi Ilya,
>
> > +static inline bool is_lowcore_addr(void *addr)
> > +{
> > + return addr >= (void *)_lowcore &&
> > + addr < (void *)(_lowcore + 1);
> >
On 18/06/2024 12:53 am, Huang, Haitao wrote:
> From: Kristen Carlson Accardi
>
> Currently in the EPC page allocation, the kernel simply fails the
> allocation when the current EPC cgroup fails to charge due to its usage
> reaching limit. This is not ideal. When that happens, a better way is
>
On 20/06/2024 14:01, Komal Bajaj wrote:
> From: Melody Olvera
>
> Document the compatible for the component used to boot the MPSS on the
> QDU1000 and QRU1000 SoCs.
>
> The QDU1000 and QRU1000 mpss boot process now requires the specification
> of an RMB register space to complete the handshake
Changing virtio-dev address to the new one. The discussion might also be
relevant for virtio-comment, but it is discouraged to forward it to both.
On 15.06.24 10:40, David Woodhouse wrote:
> On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
>> RFC v3 updates
>> --
>>
>> This
Add the compatible for the mpss found in the QDU1000 and QRU1000
SoCs. These platforms require the driver to complete a modem
handshake using the RMB registers provided.
Signed-off-by: Melody Olvera
Signed-off-by: Komal Bajaj
---
drivers/remoteproc/qcom_q6v5_pas.c | 1 +
1 file changed, 1
From: Melody Olvera
Some chipsets will have DSPs which will have begun running prior
to linux booting, so add support to late attach these DSPs by
adding support for:
- run-time checking of an offline or running DSP via rmb register
- a late attach framework to attach to the running DSP
- a
From: Melody Olvera
When attaching a running Q6, the remoteproc driver needs a way
to communicate with the Q6 using rmb registers, so allow the
rmb register to be gotten from the device tree if present.
Signed-off-by: Melody Olvera
Signed-off-by: Komal Bajaj
---
From: Melody Olvera
Document the compatible for the component used to boot the MPSS on the
QDU1000 and QRU1000 SoCs.
The QDU1000 and QRU1000 mpss boot process now requires the specification
of an RMB register space to complete the handshake needed to start or
attach the mpss.
Signed-off-by:
Changing virtio-dev address to the new one.
On 15.06.24 09:50, David Woodhouse wrote:
> On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
>>
>> +int viortc_hw_xtstamp_params(u16 *hw_counter, enum clocksource_ids *cs_id)
>> +{
>> + *hw_counter = VIRTIO_RTC_COUNTER_ARM_VIRT;
>
> Hm, but
This patchset adds support for the mpss found in the QDU1000 and QRU1000
SoCs.
The mpss boot process now supports late attach for an already running
mpss. For this, it uses an RMB register space to perform a handshake
with the mpss for the late attach process. This is implemented in the
patches
On 15.06.24 10:01, David Woodhouse wrote:
> On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
>>
>> + ret = viortc_hw_xtstamp_params(_counter, _id);
>> + if (ret)
>> + return ret;
>> +
>> + ktime_get_snapshot(_begin);
>> + if (history_begin.cs_id !=
Just a friendly ping to the patch :)
https://lore.kernel.org/all/20240612011156.2891254-1-lihongb...@huawei.com/
Thanks,
Hongbo
On 2024/6/12 9:11, Hongbo Li wrote:
Here we use the hugetlbfs tracepoint to track the call stack. And
the output in trace is as follows:
```
touch-5307[004]
On Thu, Jun 20, 2024 at 1:19 PM Ilya Leoshkevich wrote:
>
> On Thu, 2024-06-20 at 10:36 +0200, Alexander Potapenko wrote:
> > On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich
> > wrote:
> > >
> > > put_user() uses inline assembly with precise constraints, so Clang
> > > is
> > > in principle
On Thu, 2024-06-20 at 10:36 +0200, Alexander Potapenko wrote:
> On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich
> wrote:
> >
> > put_user() uses inline assembly with precise constraints, so Clang
> > is
> > in principle capable of instrumenting it automatically.
> > Unfortunately,
> > one of
On 18/06/2024 12:53 am, Huang, Haitao wrote:
> From: Kristen Carlson Accardi
>
> Previous patches have implemented all infrastructure needed for
> per-cgroup EPC page tracking and reclaiming. But all reclaimable EPC
> pages are still tracked in the global LRU as sgx_epc_page_lru() always
>
Hi,
On Thu, 20 Jun 2024, zhang warden wrote:
>
>
> > On Jun 7, 2024, at 17:07, Miroslav Benes wrote:
> >
> > It would be better than this patch but given what was mentioned in the
> > thread I wonder if it is possible to use ftrace even for this. See
> >
On Wed, Jun 19, 2024 at 05:44:11PM +0200, Ilya Leoshkevich wrote:
Hi Ilya,
> +static inline bool is_lowcore_addr(void *addr)
> +{
> + return addr >= (void *)_lowcore &&
> +addr < (void *)(_lowcore + 1);
> +}
> +
> +static inline void *arch_kmsan_get_meta_or_null(void *addr, bool
On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich wrote:
>
> Even though the KMSAN warnings generated by memchr_inv() are suppressed
> by metadata_access_enable(), its return value may still be poisoned.
>
> The reason is that the last iteration of memchr_inv() returns
> `*start != value ? start :
Hello Steven Rostedt (Google),
Commit 5f3b6e839f3c ("ring-buffer: Validate boot range memory
events") from Jun 12, 2024 (linux-next), leads to the following
Smatch static checker warning:
kernel/trace/ring_buffer.c:1824 rb_meta_validate_events()
error: uninitialized symbol
The trace_array_create_systems() function returns error pointers, not
NULL. Fix the check to match.
Fixes: e645535a954a ("tracing: Add option to use memmapped memory for trace
boot instance")
Signed-off-by: Dan Carpenter
---
kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+), 1
On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich wrote:
>
> put_user() uses inline assembly with precise constraints, so Clang is
> in principle capable of instrumenting it automatically. Unfortunately,
> one of the constraints contains a dereferenced user pointer, and Clang
> does not currently
在 2024/6/20 下午3:44, Michael S. Tsirkin 写道:
Moving initialization of stats structure into
__free_old_xmit reduces the code size slightly.
It also makes it clearer that this function shouldn't
be called multiple times on the same stats struct.
Signed-off-by: Michael S. Tsirkin
---
Especially
On Thu, Jun 20, 2024 at 1:58 PM Michael S. Tsirkin wrote:
>
> On Thu, Jun 06, 2024 at 08:22:13AM +0800, Jason Wang wrote:
> > On Fri, May 31, 2024 at 8:18 AM Jason Wang wrote:
> > >
> > > On Thu, May 30, 2024 at 9:09 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Thu, May 30, 2024 at
On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich wrote:
>
> uaccess.h uses instrument_get_user() and instrument_put_user(), which
> are defined in linux/instrumented.h. Currently we get this header from
> somewhere else by accident; prefer to be explicit about it and include
> it directly.
>
>
1 - 100 of 107 matches
Mail list logo
