Messages in this thread | | | Date | Fri, 16 Dec 2022 23:02:56 +0900 | Subject | Re: [PATCH] fbcon: Use kzalloc() in fbcon_prepare_logo() | From | Tetsuo Handa <> |
| |
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?
| |