[dm-devel] A kernel panic (or soft lockup) due to stack overflow by recursive dm-table reload

[Coly Li]

> 2022年8月25日 21:49，Zdenek Kabelac <zkabelac at redhat.com> 写道：
> 
> 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....

Although I don’t have deep understand to device mapper, I agree that it sounds as a simple and working way to fix.

Thanks.

Coly Li