On 19/06/2024 23:02, Luca Weiss wrote:
> Allow placing an opp-table as a subnode that can be assigned using
> operating-points-v2 to specify the frequency table for the PLL.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/clock/qcom,a53pll.yaml | 3 +++
> 1 file changed,
On 19/06/2024 23:02, Luca Weiss wrote:
> Add the compatible for the A7PLL found in MSM8226 SoCs.
>
> Signed-off-by: Luca Weiss
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 19/06/2024 23:02, Luca Weiss wrote:
> Add the mailbox compatible for MSM8226 SoC.
>
> Signed-off-by: Luca Weiss
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
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 06:29:51PM +0800, Jason Wang wrote:
> > > > On Thu, May 30, 2024 at 2:10 PM Michael
> 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
> /sys/kernel/tracing/trace_stat/function*. It already gathers the number of
> hits.
>
Hi, Miro
On Wed, Jun 19, 2024 at 3:49 PM Vlastimil Babka wrote:
>
> When CONFIG_FUNCTION_ERROR_INJECTION is disabled,
> within_error_injection_list() will return false for any address and the
> result of check_non_sleepable_error_inject() denylist is thus redundant.
> The bpf_non_sleepable_error_inject lis
Similarly to should_failslab(), remove the overhead of calling the
noinline function should_fail_alloc_page() with a static key that guards
the callsite in the page allocator hotpath, and is controlled by the
fault and error injection frameworks and bpf.
Additionally, compile out all relevant code
Since commit 4f6923fbb352 ("mm: make should_failslab always available for
fault injection") should_failslab() is unconditionally a noinline
function. This adds visible overhead to the slab allocation hotpath,
even if the function is empty. With CONFIG_FAILSLAB=y there's additional
overhead, even wh
Functions marked for error injection can have an associated static key
that guards the callsite(s) to avoid overhead of calling an empty
function when no error injection is in progress.
Outside of the error injection framework itself, bpf programs can be
atteched to kprobes and override results of
Some fault injection sites are placed in hotpaths and incur overhead
even if not enabled, due to one or more function calls leading up to
should_fail_ex() that returns false due to attr->probability == 0.
This overhead can be eliminated if the outermost call into the checks is
guarded with a stati
Error injectable functions cannot be inlined and since some are called
from hot paths, this incurs overhead even if no error injection is
enabled for them.
To avoid this overhead when disabled, allow the callsites of error
injectable functions to put the calls behind a static key, which the
framew
This should now be complete, but perf_events attached bpf programs are
untested (Patch 3).
This is spread accross several subsystems but the easiest way would be
to go through a single tree, such as the mm tree.
As previously mentioned by myself [1] and others [2] the functions
designed for error
When CONFIG_FUNCTION_ERROR_INJECTION is disabled,
within_error_injection_list() will return false for any address and the
result of check_non_sleepable_error_inject() denylist is thus redundant.
The bpf_non_sleepable_error_inject list thus does not need to be
constructed at all, so #ifdef it out.
Functions marked for error injection can have an associated static key
that guards the callsite(s) to avoid overhead of calling an empty
function when no error injection is in progress.
Outside of the error injection framework itself, bpf programs can be
atteched to perf events and override result
From: Mike Rapoport (IBM)
On Thu, 13 Jun 2024 11:55:06 -0400, Steven Rostedt wrote:
> Reserve unspecified location of physical memory from kernel command line
>
> Background:
>
> In ChromeOS, we have 1 MB of pstore ramoops reserved so that we can extract
> dmesg output and some other informatio
On Wed, Jun 19, 2024 at 01:59:15PM -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 MODULE_
On Tue, Jun 18, 2024 at 09:36:56AM +, Takaya Saeki wrote:
> + TP_printk(
> + "dev %d:%d ino %lx ofs=%lu max_ofs=%lu",
It seems weird to have a space between dev and %d, but an equals between
ofs and %lu. I see there is some precedent for this elsewhere, but
there are other pla
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 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226.dt
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 provide the gcc node xo_board
instead of the XO via rpmcc since otherw
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 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/qcom
: 0efa3123a1658dbafdace0bfcdcc4f34eebc7f9f
change-id: 20240619-msm8226-cpufreq-788b0bf0256a
Best regards,
--
Luca Weiss
The MSM8226 has one PLL for its Cortex-A7 cores. The frequencies will be
specified in devicetree.
Signed-off-by: Luca Weiss
---
drivers/clk/qcom/a53-pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/a53-pll.c b/drivers/clk/qcom/a53-pll.c
index f9c5e296dba2..f43d455ab4b8
Add the compatible for the A7PLL found in MSM8226 SoCs.
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/clock/qcom,a53pll.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
b/Documentation/devicetree/bindings/clock/q
Allow placing an opp-table as a subnode that can be assigned using
operating-points-v2 to specify the frequency table for the PLL.
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/clock/qcom,a53pll.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetre
Add the mailbox compatible for MSM8226 SoC.
Signed-off-by: Luca Weiss
---
Documentation/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/Documentation/devicetree/bin
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 MODULE_DESCRIPTION() in lib/test_firmware.o
WARNING: modpost: missing MODULE_
On 6/19/24 18:42, Luca Weiss wrote:
With the binding and driver patches queued for 6.11[0][1], it's time to
update the dtsi files to use the new binding.
[0]
https://lore.kernel.org/linux-arm-msm/171840533352.102487.9576671528001022676.b4...@kernel.org/
[1]
https://git.kernel.org/pub/scm/li
On Mon, Jun 17, 2024 at 03:53:50PM -0700, Andrii Nakryiko wrote:
> On Mon, Jun 10, 2024 at 4:06 AM Jiri Olsa wrote:
> >
> > On Thu, Jun 06, 2024 at 09:52:39AM -0700, Andrii Nakryiko wrote:
> > > On Thu, Jun 6, 2024 at 9:46 AM Jiri Olsa wrote:
> > > >
> > > > On Wed, Jun 05, 2024 at 10:50:11PM +02
Thanks Steven for trying it out.
> I can see it bringing down the number of pages needed to be saved
> dramatically.
Yes, I agree.
However, note that wc does not count the size of the page caches
correctly since 'get_map_pages' gives you a range. In your example of
the less command, actually the
On Wed, 2024-06-19 at 17:08 +0200, Eugenio Perez Martin wrote:
> On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
> >
> > The virtqueue size is a pre-requisite for setting up any virtqueue
> > resources. For the upcoming optimization of creating virtqueues at
> > device add, the virtqueue si
On Wed, 2024-06-19 at 13:28 +0200, Eugenio Perez Martin wrote:
> On Mon, Jun 17, 2024 at 5:08 PM Dragos Tatulea wrote:
> >
> > The hardware VQ configuration is mirrored by data in struct
> > mlx5_vdpa_virtqueue . Instead of clearing just a few fields at reset,
> > fully clear the struct and initi
ommit: 2102cb0d050d34d50b9642a3a50861787527e922
change-id: 20240619-smsm-mbox-dts-3ee9daadf81b
Best regards,
--
Luca Weiss
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 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
b/arc
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 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64
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 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi
b/arch/arm64
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 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
b/arch/arm64
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 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm6
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> VQ indices in the range [cur_num_qps, max_vqs) represent queues that
> have not yet been activated. .set_vq_ready should not activate these
> VQs.
>
> Signed-off-by: Dragos Tatulea
> Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
>
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 TEE bus. If the associated Trusted
>> application is supported on secure part this
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> The vdpa device can be reset many times in sequence without any
> significant state changes in between. Previously this was not a problem:
> VQs were torn down only on first reset. But after VQ pre-creation was
> introduced, each reset will
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> There are a few conditions under which the hardware VQs need a full
> teardown and setup:
>
> - VQ size changed to something else than default value. Hardware VQ size
> modification is not supported.
>
> - User turns off certain device fe
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> Currently, hardware VQs are created right when the vdpa device gets into
> DRIVER_OK state. That is easier because most of the VQ state is known by
> then.
>
> This patch switches to creating all VQs and their associated resources
> at devi
On 2024-06-19 at 18:34:34 +0300, Nikolay Borisov wrote:
>
>
> On 19.06.24 г. 18:25 ч., Chen Yu wrote:
> > Hi Nikolay,
> >
> > On 2024-06-18 at 11:24:42 +0300, Nikolay Borisov wrote:
> > >
> > >
> > > On 26.05.24 г. 4:58 ч., Chen Yu wrote:
> > > > The kernel can change spinlock behavior when ru
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> Resume a VQ if it is already created when the number of VQ pairs
> increases. This is done in preparation for VQ pre-creation which is
> coming in a later patch. It is necessary because calling setup_vq() on
> an already created VQ will ret
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 a/arch/s390/kernel/t
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
---
mm/kmsan
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 --git
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
---
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
Signed-off-by: Ilya Leoshkevich
---
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
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]
https://githu
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
---
arch/s390/kernel/unwind_
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 c
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
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 ac
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 address
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__ i
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)
[
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 Potapen
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.
kmsan_init_shadow(
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 ever
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, an
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 ass
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 unpois
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
---
arch/s390/include/asm/kmsan.h | 59 +++
1 file change
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 c59d2b54df49..3cba4993d
v4: https://lore.kernel.org/lkml/20240613153924.961511-1-...@linux.ibm.com/
v4 -> v5: Fix the __memset() build issue.
Change the attribute #defines to lowercase in order to match
the existing code style.
Fix the kmsan_virt_addr_valid() implementation to avoid
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 counterin
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: Alexande
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
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
---
mm/kmsan/kmsan
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
Add a wrapper for memset() that prevents unpoisoning. This is useful
for filling memory allocator redzones.
Signed-off-by: Ilya Leoshkevich
---
include/linux/kmsan.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/kmsan.h b/include/linux/kmsan.h
index 23de1b3d6ae
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 --gi
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. Thi
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 Leos
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
Sign
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 a/arch/s39
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
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 the
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 con
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
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> There are a few more places modifying the VQ to Ready directly. Let's
> consolidate them into resume_vq().
>
> The redundant warnings for resume_vq() errors can also be dropped.
>
> There is one special case that needs to be handled for vir
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> Instead of blindly calling suspend/resume_vqs(), make then return error
> codes.
>
> To keep compatibility, keep suspending or resuming VQs on error and
> return the last error code. The assumption here is that the error code
> would be the
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 TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware i
On 19.06.24 г. 18:25 ч., Chen Yu wrote:
Hi Nikolay,
On 2024-06-18 at 11:24:42 +0300, Nikolay Borisov wrote:
On 26.05.24 г. 4:58 ч., Chen Yu wrote:
The kernel can change spinlock behavior when running as a guest. But
this guest-friendly behavior causes performance problems on bare metal.
S
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> Otherwise, when virtqueues are moved from INIT to READY the latest mkey
> will not be set appropriately.
>
> Signed-off-by: Dragos Tatulea
> Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c |
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> Currently rqt_size is initialized during device flag configuration.
> That's because it is the earliest moment when device knows if MQ
> (multi queue) is on or off.
>
> Shift this configuration earlier to device creation time. This implies
Hi Nikolay,
On 2024-06-18 at 11:24:42 +0300, Nikolay Borisov wrote:
>
>
> On 26.05.24 г. 4:58 ч., Chen Yu wrote:
> > The kernel can change spinlock behavior when running as a guest. But
> > this guest-friendly behavior causes performance problems on bare metal.
> > So there's a 'virt_spin_lock_k
On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea wrote:
>
> The virtqueue size is a pre-requisite for setting up any virtqueue
> resources. For the upcoming optimization of creating virtqueues at
> device add, the virtqueue size has to be configured.
>
> Store the default queue size in struct mlx5_v
On Thu, 13 Jun 2024 19:13:47 +0800
Jinjie Ruan wrote:
> Since commit 7caa9765465f60 ("ftrace: riscv: move from REGS to ARGS"),
> kprobe on ftrace is not supported by riscv, because riscv's support for
> FTRACE_WITH_REGS has been replaced with support for FTRACE_WITH_ARGS, and
> KPROBES_ON_FTRACE
On Tue, 18 Jun 2024 15:20:14 +0800
Jiapeng Chong wrote:
> Use existing str_plural() function rather than duplicating its
> implementation.
>
> ./kernel/trace/trace_selftest.c:880:56-60: opportunity for str_plural(size).
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show
On Tue, Jun 18, 2024 at 6:39 PM Michael S. Tsirkin wrote:
>
> On Mon, Jun 17, 2024 at 09:44:21AM -0700, Jakub Kicinski wrote:
> > On Mon, 17 Jun 2024 12:20:19 -0400 Michael S. Tsirkin wrote:
> > > > But the virtio spec doesn't allow setting the MAC...
> > > > I'm probably just lost in the conversa
Hello:
This series was applied to netdev/net-next.git (main)
by David S. Miller :
On Mon, 17 Jun 2024 11:09:00 -0700 you wrote:
> We set up our production packet drop monitoring around the kfree_skb
> tracepoint. While this tracepoint is extremely valuable for diagnosing
> critical problems, it a
On Tue, 2024-06-18 at 16:38 +0200, Alexander Potapenko wrote:
> On Thu, Jun 13, 2024 at 5:39 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 r
On Mon, Jun 17, 2024 at 5:08 PM Dragos Tatulea wrote:
>
> The hardware VQ configuration is mirrored by data in struct
> mlx5_vdpa_virtqueue . Instead of clearing just a few fields at reset,
> fully clear the struct and initialize with the appropriate default
> values.
>
> As clear_vqs_ready() is u
On Mon, Jun 17, 2024 at 5:08 PM Dragos Tatulea wrote:
>
> No need to iterate over max number of VQs.
>
> Signed-off-by: Dragos Tatulea
> Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
On Mon, Jun 17, 2024 at 5:08 PM Dragos Tatulea wrote:
>
> Use the dedicated suspend_vqs() function instead.
>
> Signed-off-by: Dragos Tatulea
> Reviewed-by: Cosmin Ratiu
Reviewed-by: Eugenio Pérez
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +--
> 1 file changed, 1 insertion(+), 6 dele
On Mon, Jun 17, 2024 at 5:08 PM Dragos Tatulea wrote:
>
> The check is done inside teardown_vq().
>
> Signed-off-by: Dragos Tatulea
> Reviewed-by: Cosmin Ratiu
Reviewed-by: Eugenio Pérez
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions
On Mon, Jun 17, 2024 at 5:08 PM Dragos Tatulea wrote:
Patch message suggestion:
Originally, the second loop initialized the CVQ. But (acde3929492b
("vdpa/mlx5: Use consistent RQT size") initialized all the queues in
the first loop, so the second iteration in ...
>
> The second iteration in init_
1 - 100 of 107 matches
Mail list logo
