lkml.org 
[lkml]   [2022]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] fbcon: Use kzalloc() in fbcon_prepare_logo()
From
On 2022/12/15 18:36, Geert Uytterhoeven wrote:
> The next line is:
>
> scr_memsetw(save, erase, array3_size(logo_lines, new_cols, 2));
>
> So how can this turn out to be uninitialized later below?
>
> scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
>
> What am I missing?

Good catch. It turned out that this was a KMSAN problem (i.e. a false positive report).

On x86_64, scr_memsetw() is implemented as

static inline void scr_memsetw(u16 *s, u16 c, unsigned int count)
{
memset16(s, c, count / 2);
}

and memset16() is implemented as

static inline void *memset16(uint16_t *s, uint16_t v, size_t n)
{
long d0, d1;
asm volatile("rep\n\t"
"stosw"
: "=&c" (d0), "=&D" (d1)
: "a" (v), "1" (s), "0" (n)
: "memory");
return s;
}

. Plain memset() in arch/x86/include/asm/string_64.h is redirected to __msan_memset()
but memsetXX() are not redirected to __msan_memsetXX(). That is, memory initialization
via memsetXX() results in KMSAN's shadow memory being not updated.

KMSAN folks, how should we fix this problem?
Redirect assembly-implemented memset16(size) to memset(size*2) if KMSAN is enabled?

\
 
 \ /
  Last update: 2022-12-16 15:04    [W:0.079 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site