Dne 25. 08. 22 v 15:32 Mikulas Patocka napsal(a):
On Thu, 25 Aug 2022, Zdenek Kabelac wrote:
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
Detecting dm table self-reference is easy, but detecting a loop in the
dependency graph is complicated and I would't do it.
There is another (more serious) problem - the user can crash the kernel by
creating deep-enough non-recursive mapping. We do not specify any maximum
tree depth that is guaranteed to work. Perhaps we should specify such
depth and audit the code so that this maximum device depth doesn't
overflow the stack.
yep - I'd not mind if there is a total chaining limit enforced on creation
side as well.
Since the 'kernel stack size' is limit - the amount of recursive calls is also
limited - so having such limitation exposed on 'creation' time seems like fair
path - compared with crashing kernel during chaing processing....
So yeah - possibly checking remaining free space on stack might be an easy way
how to detect unsupportable 'device stacking' configuration.
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
