kern/52900: dm: Fix kernel panic when target's ->init() failed

[kusumi.tomohiro%gmail.com@localhost]

>Number:         52900
>Category:       kern
>Synopsis:       dm: Fix kernel panic when target's ->init() failed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 05 13:40:00 +0000 2018
>Originator:     Tomohiro Kusumi
>Release:        -current, but existed since before.
>Organization:
>Environment:
Architecture independent.
# uname -r
8.99.9

>Description:
Having dm_target_unbusy() when target's ->init() failed causes
kernel panic if DIAGNOSTIC is enabled at L65 of below function,
and it's wrong anyway even if DIAGNOSTIC isn't enabled.

If ->init() failed, ->destroy() called by dm_table_destroy() has
already called dm_target_unbusy(), thus it shouldn't be calling
it again to decrement ->ref_cnt to below zero. It's either ioctl
side or ->destroy() who unrefs the counter, but not both.

 62 void
 63 dm_target_unbusy(dm_target_t * target)
 64 {
 65         KASSERT(target->ref_cnt > 0);
 66         atomic_dec_32(&target->ref_cnt);
 67 }

>How-To-Repeat:
The screenshot in the below link is an example of what happens
when ->init() handler fails (i.e. returns non zero) with DIAGNOSTIC
enabled. Having dm_target_unbusy() here means dm target drivers
can't fail on ->init() otherwise wrongly unref or panic.

https://leaf.dragonflybsd.org/~tkusumi/diff/netbsd/dm_ref_cnt_panic.PNG

>Fix:
https://leaf.dragonflybsd.org/~tkusumi/diff/netbsd/dm-1.patch