Bug 38796

Summary: libevms не может деактивировать RAID массив, если на нем находится LVM LV
Product: Sisyphus Reporter: Slava Aseev <ptrnine>
Component: libevmsAssignee: Slava Aseev <ptrnine>
Status: REOPENED --- QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: mcpain, mike, ptrnine, rider, snowmix, zerg
Version: unstable   
Hardware: x86_64   
OS: Linux   

Description Slava Aseev 2020-08-11 11:50:49 MSK
Баг проявляется на стартеркитах в виде "падения" инталлятора. Возможно, не только на стартеркитах.
Для воспроизведения необходимо создать RAID массив, создать на нем LVM LV, затем запустить инсталлятор и выбрать "Destroy all partitions, then autopartion"

Причина вот в чем. evms сам располагает все у себя в /dev/evms
Но в данном случае происходит один неприятный момент - при запуске RAID массива (ioctl RUN_ARRAY) автоматически запускается и LVM LV на нем, про который evms ничего не знает. Соответственно, деактивировать RAID массив у него не получится - он будет занят запущенным LVM LV.

Вот выводы lsblk на 3 стадиях для наглядности:

1. Сразу же после создания RAID массива и LVM LV на нем:
NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
loop0         7:0    0  1.9G  1 loop  /.ro
sda           8:0    0   20G  0 disk  
└─sda1        8:1    0    3G  0 part  
  └─md127     9:127  0    3G  0 raid1 
    └─vg-lv 252:0    0    1G  0 lvm   
sdb           8:16   0   20G  0 disk  
└─sdb1        8:17   0    3G  0 part  
  └─md127     9:127  0    3G  0 raid1 
    └─vg-lv 252:0    0    1G  0 lvm

2. После запуска инсталлятора (выполнился /usr/share/install2/initinstall.d/80-stop-md-dm.sh)
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0    7:0    0  1.9G  1 loop /.ro
sda      8:0    0   20G  0 disk 
└─sda1   8:1    0    3G  0 part 
sdb      8:16   0   20G  0 disk 
└─sdb1   8:17   0    3G  0 part

3. На стадии volume management, когда evms выполнил discovery:
NAME             MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
loop0              7:0    0  1.9G  1 loop  /.ro
sda                8:0    0   20G  0 disk  
├─sda1             8:1    0    3G  0 part  
└─sda1           252:0    0    3G  0 dm    
  └─md127          9:127  0    3G  0 raid1 
    ├─lvm2|vg|lv 252:2    0    1G  0 dm    
    └─vg-lv      252:3    0    1G  0 lvm   
sdb                8:16   0   20G  0 disk  
├─sdb1             8:17   0    3G  0 part  
└─sdb1           252:1    0    3G  0 dm    
  └─md127          9:127  0    3G  0 raid1 
    ├─lvm2|vg|lv 252:2    0    1G  0 dm    
    └─vg-lv      252:3    0    1G  0 lvm
Comment 1 Slava Aseev 2020-08-11 11:53:24 MSK
И на данный момент мне пока неизвестно, как решить эту проблему без навороченных костылей
Comment 2 Anton Farygin 2020-08-11 11:58:51 MSK
Слава, а можешь оценить принциальную возможность отвязать libevms от /dev/evms и использовать его просто как удобную универсальную библиотеку для работы с томами и файловыми системами разного формата ?
Comment 3 Slava Aseev 2020-08-11 16:11:54 MSK
(Ответ для Anton Farygin на комментарий #2)
> Слава, а можешь оценить принциальную возможность отвязать libevms от
> /dev/evms и использовать его просто как удобную универсальную библиотеку для
> работы с томами и файловыми системами разного формата ?

Это принципиально возможно.
То есть я не вижу непреодолимых препятствий, которые не позволят заставить работать необходимое для alterator-vm "подмножество" libevms без /dev/evms/
Насколько это будет просто, и какие проблемы могут возникнуть я пока не знаю, нужно детально разбираться.
Comment 4 Slava Aseev 2020-08-12 14:11:37 MSK
Можно подойти немного по-другому. Если бы evms не раздавал названия для свой лад, подобных проблем бы не было.
evms в именах для device mapper заменяет "/" на "|", а в плагине lvm2 добавляет еще и префикс lvm2
Если это поправить, то dm клона уже не наблюдается:

NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
loop0         7:0    0  1.9G  1 loop  /.ro
sda           8:0    0   20G  0 disk  
├─sda1        8:1    0    5G  0 part  
└─sda1      252:0    0    5G  0 dm    
  └─md127     9:127  0    5G  0 raid1 
    └─vg-lv 252:2    0    1G  0 dm    
sdb           8:16   0   20G  0 disk  
├─sdb1        8:17   0    5G  0 part  
└─sdb1      252:1    0    5G  0 dm    
  └─md127     9:127  0    5G  0 raid1 
    └─vg-lv 252:2    0    1G  0 dm    
sr0          11:0    1    2G  0 rom   /image
Comment 5 Anton Farygin 2020-08-12 14:44:57 MSK
а какие отрицательные последствия могут быть для нас от этого шага ?
Comment 6 Slava Aseev 2020-08-12 16:37:03 MSK
(Ответ для Anton Farygin на комментарий #5)
> а какие отрицательные последствия могут быть для нас от этого шага ?

Тут сложно ответить, нужно будет тщательно протестировать на различных комбинациях ФС/raid и т.д.

Но он данного поведения evms в прошлом были только одни проблемы. Этот баг тоже отчасти возникает по этой же причине.
Непонятно, как и зачем был выбран символ '|'. dmsetup вот вообще ругается символы '|' в имени:

# dmsetup info
The name "lvm2|vg|lv" should be mangled but it contains blacklisted character
Comment 7 Anton Farygin 2020-08-12 18:55:26 MSK
тогда давай сделаем экспериментальную сборку, с которой соберём инсталятор и проверим в наших базовых сценариях.
Comment 8 Michael Shigorin 2020-08-15 11:03:28 MSK
(Ответ для Slava Aseev на комментарий #6)
> Но он данного поведения evms в прошлом были только одни проблемы.
+1

Возможно, это ещё с AIX приползло и так и осталось.
Comment 9 Slava Aseev 2020-09-02 12:13:12 MSK
Сделал тестовый таск, где '/' в названиях LV заменяется на '-', а также убран префикс "lvm2/"

http://webery.altlinux.org/task/257200

Проверил на raid+lvm2 - работает
Comment 10 Slava Aseev 2020-10-02 18:14:51 MSK
В общем, новости печальные, обнаружился еще один баг, гораздо более серьезный.
Оказалось, что evms при деактивации RAID на LVM2 LV может повиснуть намертво, да так, что никакой SIGKILL не поможет (либо срабатывает с ооочень огромной задержкой)

Баг воспроизводится не всегда, при чем от действи
Comment 11 Slava Aseev 2020-10-02 18:16:50 MSK
(Ответ для Slava Aseev на комментарий #10)
> В общем, новости печальные, обнаружился еще один баг, гораздо более
> серьезный.
> Оказалось, что evms при деактивации RAID на LVM2 LV может повиснуть
> намертво, да так, что никакой SIGKILL не поможет (либо срабатывает с ооочень
> огромной задержкой)
> 
> Баг воспроизводится не всегда, при чем от действи

При чем от действий пользователя ничего не зависит, т.е. возможно это какая-то гонка в ядре.
Comment 12 Slava Aseev 2020-10-02 18:54:44 MSK
Вот фрагмент dmesg в момент дективации RAID массива и последующего зависания evms. Воспроизвел на evms-ncurses, но то же самое происходит и на инсталляторе. Лог периодически пополняется, Call Trace каждый раз разный, закономерности никакой, разве что в RIP очень часто всякие спинлоки и мьютексы (deadlock?)
Сейчас еще попробую на un-def.

[Oct 2 18:24] md: md255: resync interrupted.
[  +0.004418] md255: detected capacity change from 5363466240 to 0
[  +0.000016] md: md255 stopped.
[ +24.731606] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [evmsn:2751]
[  +0.000003] Modules linked in: dm_mod(E) raid1(E) af_packet(E) rfkill(E) snd_seq_midi(E) snd_seq_midi_event(E) snd_seq(E) snd_rawmidi(E) snd_seq_device(E) intel_rapl_msr(E) intel_rapl_common(E) intel_pmc_core_pltdrv(E) intel_pmc_core(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) snd_intel8x0(E) snd_ac97_codec(E) pktcdvd(E) snd_pcm(E) aesni_intel(E) crypto_simd(E) cryptd(E) glue_helper(E) input_leds(E) snd_timer(E) psmouse(E) joydev(E) pcspkr(E) snd(E) soundcore(E) i2c_piix4(E) ac97_bus(E) intel_agp(E) intel_gtt(E) ac(E) sch_fq_codel(E) vboxsf(OE) vboxguest(OE) ip_tables(E) x_tables(E) ipv6(E) crc_ccitt(E) autofs4(E) overlay(E) squashfs(E) nls_utf8(E) isofs(E) uas(E) usb_storage(E) hid_generic(E) usbhid(E) hid(E) sr_mod(E) cdrom(E) sd_mod(E) pata_acpi(E) ata_generic(E) ohci_pci(E) ata_piix(E) ehci_pci(E) ohci_hcd(E) vmwgfx(E) ehci_hcd(E) drm_kms_helper(E) libata(E) evdev(E) ttm(E) crc32c_intel(E) serio_raw(E) drm(E) usbcore(E) e1000(E) usb_common(E) scsi_mod(E) battery(E)
[  +0.000031]  video(E) button(E)
[  +0.000003] CPU: 1 PID: 2751 Comm: evmsn Tainted: G           OE     5.4.62-std-def-alt1 #1
[  +0.000001] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[  +0.000010] RIP: 0010:__raw_callee_save___pv_queued_spin_unlock+0x1/0x12
[  +0.000003] Code: 90 90 90 90 90 90 90 90 90 51 52 56 57 41 50 41 51 41 52 41 53 e8 6f 05 00 00 41 5b 41 5a 41 59 41 58 5f 5e 5a 59 c3 66 90 52 <b8> 01 00 00 00 31 d2 f0 0f b0 17 3c 01 75 02 5a c3 56 0f b6 f0 e8
[  +0.000000] RSP: 0018:ffffc900039bbbd8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
[  +0.000002] RAX: 0000000000000000 RBX: 00000000000000ff RCX: 0000000000000000
[  +0.000001] RDX: ffff888070eb63d8 RSI: 000000000800001f RDI: ffffffff8291d8f8
[  +0.000000] RBP: 0000000000000000 R08: 0000000000000001 R09: ffff888070eb6000
[  +0.000001] R10: 0000000000000001 R11: 0000000000000000 R12: ffff888070eb6000
[  +0.000000] R13: 00000000009000ff R14: 0000000000000001 R15: ffff888070e85000
[  +0.000002] FS:  00007ff08ef0d740(0000) GS:ffff88807a100000(0000) knlGS:0000000000000000
[  +0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000001] CR2: 0000555bb2cc4d08 CR3: 0000000027780001 CR4: 00000000000606e0
[  +0.000003] Call Trace:
[  +0.000016]  mddev_find+0x104/0x280
[  +0.000007]  md_open+0x16/0xd0
[  +0.000004]  __blkdev_get+0xe1/0x550
[  +0.000006]  ? blkdev_get_by_dev+0x50/0x50
[  +0.000001]  blkdev_get+0x38/0x130
[  +0.000001]  ? bd_acquire+0xbc/0xf0
[  +0.000001]  ? blkdev_get_by_dev+0x50/0x50
[  +0.000002]  do_dentry_open+0x13d/0x3a0
[  +0.000004]  path_openat+0x570/0x1630
[  +0.000002]  ? filename_lookup+0xf1/0x170
[  +0.000002]  ? kmem_cache_alloc+0x1ca/0x580
[  +0.000001]  ? __check_object_size+0x130/0x141
[  +0.000002]  do_filp_open+0x91/0x100
[  +0.000001]  ? kmem_cache_alloc+0x1ca/0x580
[  +0.000001]  ? __check_object_size+0x130/0x141
[  +0.000002]  do_sys_open+0x184/0x220
[  +0.000003]  do_syscall_64+0x5c/0x140
[  +0.000009]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  +0.000005] RIP: 0033:0x7ff08f33b674
[  +0.000002] Code: 84 00 00 00 00 00 44 89 54 24 0c e8 96 f4 ff ff 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 32 44 89 c7 89 44 24 0c e8 c8 f4 ff ff 8b 44
[  +0.000001] RSP: 002b:00007ffe54567650 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
[  +0.000001] RAX: ffffffffffffffda RBX: 6d76652f7665642f RCX: 00007ff08f33b674
[  +0.000000] RDX: 0000000000000002 RSI: 00007ffe54567710 RDI: 00000000ffffff9c
[  +0.000001] RBP: 00007ffe54567710 R08: 0000000000000000 R09: 00000000000000ff
[  +0.000001] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002
[  +0.000000] R13: 00007ffe54567e30 R14: 0000000000000000 R15: 0000000000000000
Comment 13 Repository Robot 2020-10-19 20:00:40 MSK
evms-2.5.5-alt46 -> sisyphus:

 Tue Sep 29 2020 Slava Aseev <ptrnine@altlinux> 2.5.5-alt46
 - Fix LVM2 logical volume deactivation (closes: #38796)
 - Remove broken dependency on
   /usr/share/install2/initinstall.d/80-stop-md-dm.sh
Comment 14 Slava Aseev 2020-10-20 12:14:46 MSK
(Ответ для Repository Robot на комментарий #13)
> evms-2.5.5-alt46 -> sisyphus:
> 
>  Tue Sep 29 2020 Slava Aseev <ptrnine@altlinux> 2.5.5-alt46
>  - Fix LVM2 logical volume deactivation (closes: #38796)
>  - Remove broken dependency on
>    /usr/share/install2/initinstall.d/80-stop-md-dm.sh

Отправил исправление для этого бага по ошибке, оно еще не готово.
Comment 15 Repository Robot 2020-10-22 20:38:20 MSK
evms-2.5.5-alt47 -> p9:

 Tue Oct 20 2020 Slava Aseev <ptrnine@altlinux> 2.5.5-alt47
 - Revert "Fix LVM2 logical volume deactivation"
   Fix not ready yet and was sent by mistake
 Tue Sep 29 2020 Slava Aseev <ptrnine@altlinux> 2.5.5-alt46
 - Fix LVM2 logical volume deactivation (closes: #38796)
 - Remove broken dependency on
   /usr/share/install2/initinstall.d/80-stop-md-dm.sh
 Tue Sep 15 2020 Slava Aseev <ptrnine@altlinux> 2.5.5-alt45
 - plugins/md:
   + fix raid discovering and md_minor getting for metadata=1.*
     (closes: #35918)
   + use better name's collision resolving for metadata=1.*
   + use metadata=1.2 by default
   + add RAID test
Comment 16 Slava Aseev 2020-10-23 11:30:05 MSK
Опять переоткрываю. Скрипт отработал после того, как прошло в p9 :)