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
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
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(
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
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
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 b/
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
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
v6: https://lore.kernel.org/lkml/20240621002616.40684-1-...@linux.ibm.com/
v6 -> v7: Drop the ptdump patch.
All patches are reviewed.
v5: https://lore.kernel.org/lkml/20240619154530.163232-1-...@linux.ibm.com/
v5 -> v6: Include KMSAN vmalloc areas in page table dump.
Fix doc co
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
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
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
Hi Andrew,
On 04/06/24 22:40, Andrew Davis wrote:
On 6/4/24 12:17 AM, Beleswar Padhi wrote:
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for mbox handle later during rproc start/attach. This a
uild on riscv (and I assume loongarch):
>
> error[E0432]: unresolved import `_static_key_false`
> --> /stuff/linux/rust/kernel/static_key.rs:87:10
> |
> 87 | pub use {_static_key_false, static_key_false};
> | ^ no external crate `_static_key_false`
>
> Cheers,
> Conor.
Thank you. Fixed in v3.
https://lore.kernel.org/all/20240621-tracepoint-v3-0-9e44eeea2...@google.com/
Alice
Make it possible to have Rust code call into tracepoints defined by C
code. It is still required that the tracepoint is declared in a C
header, and that this header is included in the input to bindgen.
Signed-off-by: Alice Ryhl
---
include/linux/tracepoint.h | 18 +++-
include/t
Add just enough support for static key so that we can use it from
tracepoints. Tracepoints rely on `static_key_false` even though it is
deprecated, so we add the same functionality to Rust.
It is not possible to use the existing C implementation of
arch_static_branch because it passes the argument
An important part of a production ready Linux kernel driver is
tracepoints. So to write production ready Linux kernel drivers in Rust,
we must be able to call tracepoints from Rust code. This patch series
adds support for calling tracepoints declared in C from Rust.
To use the tracepoint support,
On 21/06/2024 10:14, Valeriy Klimin wrote:
> Add the compatible for this device.
>
> Signed-off-by: Valeriy Klimin
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
> b/Documentation/
On 6/17/24 20:38, Daniel Wagner wrote:
> Use libtracefs as package name to lookup the CFLAGS for libtracefs. This
> makes it possible to use the distro specific path as include path for
> the header file.
So, I added it to my review branch and tested it. It is fine!
But, as the most important use
Hi Thomas
On 6/12/24 16:54, tglo...@redhat.com wrote:
> From: Tomas Glozar
I think we can split this into two patches, this first part on tools/Build:
> Add a test for libcpupower into feature tests and use it to add a
> dependency on libcpupower to rtla.
>
> Signed-off-by: Tomas Glozar
> ---
On 6/12/24 16:54, tglo...@redhat.com wrote:
> +
> + nr_states = cpuidle_state_count(cpu);
> +
Question: Is this library implemented for all archs or only
intel &| arm?
If it is restricted to few archs, it is another point to make
it optional.
-- Daniel
On 6/12/24 16:54, tglo...@redhat.com wrote:
> @@ -550,6 +555,7 @@ static struct timerlat_top_params
> {"aa-only", required_argument, 0, '5'},
> {"warm-up", required_argument, 0, '6'},
> {"trace-buffe
On Thu, 2024-06-20 at 17:19 +0100, David Woodhouse wrote:
>
> >
> > > +
> > > + /* Counter frequency, and error margin. Units of (second >> 64) */
> > > + uint64_t counter_period_frac_sec;
> >
> > AFAIU this might limit the precision in case of high counter frequencies.
> > Could the
PM8008 regulators are used for the cameras found on FP5. Configure the
chip and its voltages.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 105 -
1 file changed, 104 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcm6
PM8008 regulators are used for the cameras found on FP4. Configure the
chip and its voltages.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 109 +-
1 file changed, 108 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm72
With the PM8008 regulator driver scheduled for Linux v6.11[0] let's add
the dts bits for Fairphone 4 and Fairphone 5 which both use this PMIC
for powering the camera sensors - and the pull-up for the CCI (camera
I2C bus).
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=ib-m
On 6/12/24 16:12, John Kacur wrote:
>> +/* There are samples above the threshold */
> IMHO The comment isn't needed because the variable had_samples is
> descriptive, but it's not a big deal either
Yeah, I would not do it too, but it is fine.
I am adding it to my queue.
Thanks Luis
On Fri, Jun 21, 2024 at 2:26 AM Ilya Leoshkevich wrote:
>
> 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
Reviewed-by: Alexand
On Fri, 2024-06-21 at 02:25 +0200, Ilya Leoshkevich wrote:
> 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/d
On Fri, Jun 21, 2024 at 2:27 AM Ilya Leoshkevich wrote:
>
> Add KMSAN vmalloc metadata areas to kernel_page_tables.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
SD cards would exhibit errors similar to ones described in commit
27fe0fc05f35 ("ARM: dts: msm8974-FP2: Increase load on l20 for sdhci")
This patch applies the same change to the regulator for sdhc2.
Signed-off-by: Valeriy Klimin
---
arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-co
Add the compatible for this device.
Signed-off-by: Valeriy Klimin
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
b/Documentation/devicetree/bindings/arm/qcom.yaml
index ae885414b181..e53f061
Add the dts for the Z3 Compact. This is currently almost the same
as the plain Z3 as they share almost the same hardware and
nothing device-specific is currently supported.
Signed-off-by: Valeriy Klimin
---
arch/arm/boot/dts/qcom/Makefile| 1 +
.../qcom-msm8974pro-sony-xperi
This is almost the same as the dts of the Xperia Z3, except for the
battery charge limits.
The current on the l21 regulator for shinano is also bumped up
to stop SD card errors.
Signed-off-by: Valeriy Klimin
---
Valeriy Klimin (3):
ARM: dts: qcom: Add Sony Xperia Z3 Compact smartphone
101 - 134 of 134 matches
Mail list logo
