[lvc-project] KMSAN vs. kmemleak

[Fedor Pchelkin]

Добрый день, Дмитрий!

On Fri, 29. Nov 07:21, Antipov, Dmitriy wrote:
> Уважаемые коллеги,
> 
> никто не пытался использовать kmemleak на ядре с включенным CONFIG_KMSAN?
> Когда один отладочный механизм ругается на другой, становится очень грустно:
> 
> # echo scan > /sys/kernel/debug/kmemleak
> 
> ==>
> 
> [   36.257737][ T1895] BUG: KMSAN: uninit-value in scan_block+0x1e1/0x250
> [   36.258046][ T1895]  scan_block+0x1e1/0x250
> [   36.258257][ T1895]  kmemleak_scan+0x87b/0x2630
> [   36.258485][ T1895]  kmemleak_write+0xba0/0xd30
> [   36.258756][ T1895]  full_proxy_write+0x15a/0x370
> [   36.258998][ T1895]  vfs_write+0x462/0x14b0
> [   36.259213][ T1895]  ksys_write+0x1e4/0x490
> [   36.259429][ T1895]  __x64_sys_write+0x97/0xf0
> [   36.259658][ T1895]  x64_sys_call+0x3080/0x3d90
> [   36.259891][ T1895]  do_syscall_64+0xd9/0x1b0
> [   36.260112][ T1895]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> [   36.260398][ T1895]
> [   36.260515][ T1895] Uninit was stored to memory at:
> [   36.260766][ T1895]  scan_block+0x1da/0x250
> [   36.260978][ T1895]  kmemleak_scan+0x87b/0x2630
> [   36.261205][ T1895]  kmemleak_write+0xba0/0xd30
> [   36.261433][ T1895]  full_proxy_write+0x15a/0x370
> [   36.261674][ T1895]  vfs_write+0x462/0x14b0
> [   36.261896][ T1895]  ksys_write+0x1e4/0x490
> [   36.262120][ T1895]  __x64_sys_write+0x97/0xf0
> [   36.262359][ T1895]  x64_sys_call+0x3080/0x3d90
> [   36.262633][ T1895]  do_syscall_64+0xd9/0x1b0
> [   36.262880][ T1895]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> (Наблюдается на upstream по состоянию на 7af08b57bcb9ebf78675c50069c54125c0a8b795).

Полагаю, Kmemleak и KMSAN никогда особо не были совместимы. Или наблюдаемое
поведение встретилось только на определённом состоянии репозитория, а
раньше не возникало?

Должно быть, разработчиков этих отладочных инструментов не интересует
возможность их совмещения - в тех же доступных тестовых конфигурациях ядра
с Syzbot одновременно они нигде не используются. Запросов от сообщества
тоже не было опубликовано, видимо никому не требуется их использовать
одновременно.

KASAN судя по истории коммитов подружили с Kmemleak, но для KMSAN подобной
работы проделано не было..

Разработчики наверно могут дать более исчерпывающий ответ.
- Catalin Marinas <catalin.marinas at arm.com> (maintainer:KMEMLEAK)
- Alexander Potapenko <glider at google.com> (maintainer:KMSAN)
- Marco Elver <elver at google.com> (reviewer:KMSAN)
- Dmitry Vyukov <dvyukov at google.com> (reviewer:KMSAN)
- kasan-dev at googlegroups.com (open list:KMSAN)
- linux-mm at kvack.org (open list:MEMORY MANAGEMENT)