Dne 24. 08. 22 v 21:42 Mikulas Patocka napsal(a):
On Thu, 25 Aug 2022, Coly Li wrote:
Hi folks,
Recently I received a bug report from Intel developers (big thanks), the
kernel panic is caused by a kernel stack overflow and it seems from a
recursive dm-table reload.
Here is the simplified process to reproduce the panic, I use three 960GB name SSDs.
1, create 2 dm devices,
# echo '0 181065567 linear /dev/nvme2n1 0' | dmsetup create nvme2n1bbm
# echo '0 196616709 linear /dev/nvme3n1 0' | dmsetup create nvm3n1bbm
2, create a raid with these dm devices and another nvme SSD,
# mdadm -C /dev/md0 -l 5 -n 3 /dev/nvme4n1 /dev/dm-0 /dev/dm-1
3, wait for resync to finish
4, stop the md array
# mdadm —manage —stop /dev/md0
5, reload dm table for dm-0
# cat dm-table-reload | dmsetup reload /dev/dm-0
And the content of dm-table-reload is,
0 1 linear /dev/dm-0 0
1 181065566 linear /dev/dm-0 1
6, suspend and resume dm-0
# dmsetup suspend /dev/dm-0
# dmsetup resume /dev/dm-0
The panic can be reproduced in Linux-v5.3 kernel[1], and it changes to
silent deadlock after minutes in Linux v6.0-rc2. So the problem should
still exist in upstream kernel.
My question are,
1) Does anyone observe or encounter such panic or deadlock before?
2) To permit recursive dm-table reload, is it a bug or just as-designed ?
Thanks in advance.
Coly Li
Hi
I would just say "don't do this".
Note that only root can reload dm table, so there are no security
implications in this. And if someone has root, he can do much more harm
than crashing the system with kernel stack overflow.
Recursive table mappings or very deep non-recursive mappings aren't
supposed to work.
Since reproducing this issue is rather 'trival' - since creation of simple
linear DM device and reloading it with 'self-reference' table line is easy I'd
advocate for some simplistic check on kernel side - as such 'crash' can't be
even rebooted with SysRQ+B (on my laptop).
I guess some 'bitmap/tree' of already visited device during some check might
avoid endless loop although it's quite 'ugly' this check needs to happen on
'resume' phase - so the failure here is hard to deal with - still better than
this kernel busy loop.
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
