Hello,
I'm running into an unexpected behaviour on lvm and sanlock: if I create a snapshot on an inactive logical volume the operation succeeds but the origin lv gets locked (while reported as inactive by lvm).

I get the same result both with the stock lvm from Ubuntu 18 and the latest master version from https://github.com/lvmteam/lvm2.git. Follows the procedure to reproduce the issue:

1. Setup a shared volume group vg01 and some (inactive) logical volumes as follow:

```
root@lvm2:~# lvs -o +lv_uuid
  LV   VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert LV UUID
  lv   vg01 -wi------- 12.00m                                                     YzSN30-OE1O-TMqI-ali5-gm1x-Ws8J-Re1bFR
  lv2  vg01 -wi------- 12.00m                                                     FoNx4D-jbOO-HRl7-OJNT-AtQi-d4Cw-lHLG5S
```

Lvmlockctl consistently reports both lv and lv2 as unlocked:

```
root@lvm2:~# lvmlockctl -i
VG vg01 lock_type=sanlock Dhth4G-Fool-tugB-hcjK-ZAL4-cXnM-Q3A4x0
LS sanlock lvm_vg01
LK VG un ver 29
LK GL un ver 0
LK LV un FoNx4D-jbOO-HRl7-OJNT-AtQi-d4Cw-lHLG5S
LK LV un YzSN30-OE1O-TMqI-ali5-gm1x-Ws8J-Re1bFR
```

2. Then create a snapshot of lv2:

```
root@lvm2:~/lvm2# lvcreate -L 12m -s lv2 -n vg01/lv2-snap
  Logical volume "lv2-snap" created.
```

Lvm still thinks lv2 is inactive

```
root@lvm2:~/lvm2# lvs -o +lv_uuid
  LV       VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert LV UUID
  lv       vg01 -wi------- 12.00m                                                     YzSN30-OE1O-TMqI-ali5-gm1x-Ws8J-Re1bFR
  lv2      vg01 owi---s--- 12.00m                                                     FoNx4D-jbOO-HRl7-OJNT-AtQi-d4Cw-lHLG5S
  lv2-snap vg01 swi---s--- 12.00m      lv2                                            Tu3XQP-Bkcu-cQP5-XWY3-7CMc-9Fqa-b0y2m0
```

However `lv2` is still locked for lvmlockctl:

```
root@lvm2:~/lvm2# lvmlockctl -i
VG vg01 lock_type=sanlock Dhth4G-Fool-tugB-hcjK-ZAL4-cXnM-Q3A4x0
LS sanlock lvm_vg01
LK VG un ver 31
LK GL un ver 0
LK LV ex FoNx4D-jbOO-HRl7-OJNT-AtQi-d4Cw-lHLG5S <== locked
LK LV un YzSN30-OE1O-TMqI-ali5-gm1x-Ws8J-Re1bFR
```

Trying to activate lv2 on another host will fail; issuing `lvchange -a n lv2` from the locking host will fix it.

Looking a bit deeper in lvcreate, it seems that the leaked lock happens at `metadata/lv_manip.c:8082`:

```
#0  lockd_lv_name (cmd=0x555555c5f3b0, vg=0x5555564aa110, lv_name=0x5555564aa6d0 "lv2", lv_id=0x5555564aa5b0, lock_args=0x5555564aa6d8 "1.0.0:71303168",
    def_mode=0x555555787fb1 "ex", flags=2) at locking/lvmlockd.c:2195
#1  0x00005555556cab0c in lockd_lv (cmd=0x555555c5f3b0, lv=0x5555564aa590, def_mode=0x555555787fb1 "ex", flags=2) at locking/lvmlockd.c:2387
#2  0x00005555556cb6f2 in lockd_init_lv (cmd=0x555555c5f3b0, vg=0x5555564aa110, lv=0x5555564aaf98, lp=0x7fffffffe250) at locking/lvmlockd.c:2682
#3  0x000055555565aabe in _lv_create_an_lv (vg=0x5555564aa110, lp=0x7fffffffe250, new_lv_name=0x7fffffffe82e "lv2-snap") at metadata/lv_manip.c:8082
#4  0x000055555565c743 in lv_create_single (vg=0x5555564aa110, lp=0x7fffffffe250) at metadata/lv_manip.c:8496
#5  0x00005555555ab271 in _lvcreate_single (cmd=0x555555c5f3b0, vg_name=0x555555c97318 "vg01", vg=0x5555564aa110, handle=0x555555c96f00)@lvcreate.c:1737
```

Any idea what's going on?


Kind regards,

   Andrea Leofreddi