60737 2026-09-29 14:57:57 +0300 vm-run: гость QEMU патологически тормозит, если stdin процесса — открытый молчащий pipe (как под rpmbuild) 2026-09-29 15:00:15 +0300 1 1 4 Development Sisyphus rpm-build-vm-run unstable all Linux NEW P5 normal --- 1 amakeenk obirvalger iv obirvalger qa-sisyphus oldest_to_newest 300569 0 amakeenk 2026-09-29 14:57:57 +0300 vm-run запускает qemu с -serial mon:stdio и наследуемым stdin. Если stdin qemu — открытый pipe, в который никто не пишет (именно так rpmbuild подключает stdin к %check-скриптам; проверено: у qemu fd 0 -> pipe:[...]), гостевая VM начинает работать катастрофически медленно: - vCPU гостя надолго засыпают в kvm_vcpu_block, в госте возникают "watchdog: BUG: soft lockup - CPU#N stuck for NNs! [swapper/N]"; - qemu снаружи при этом потребляет ~5% CPU; - гость выполняет работу в 10-20 раз медленнее обычного. Воспроизводится стабильно на сборочных хостах (AMD EPYC 7351, host kernel 6.12.74-6.12-alt1, qemu 9.1.2-alt1 из p11), и именно это является причиной стабильного FTBFS dm-secdel в %check на этих хостах: timeout 60 в check.sh истекает на фазе fill_fs/tests.sh. В girar тот же тест проходит за ~35 секунд. A/B-эксперимент (внутри hsh-shell, один и тот же qemu/guest/скрипт): stdin = pipe (hsh heredoc) -> stall: soft lockup, ~5% CPU, timeout stdin = /dev/null -> быстро: 12-35s на весь тест, 200-270% CPU stdin = tty -> быстро При этом НЕ влияют: загрузка хоста (падает и на idle), -smp/-m (1..32 cpu, 2G..251G одинаково), -sandbox on/off, chroot/uid/nice, halt_poll_ns, версия гостевого ядра (6.12 и 6.18). В vm-run уже есть обход для tty-случая: [ -t 0 ] && [ -v RPM_BUILD_DIR ] && NOSTDIN=y [ -v NOSTDIN ] && exec </dev/null но для pipe-stdin (как раз случай rpmbuild/%check) редиректа нет. Предлагаемое исправление: если stdin — не tty (или, шире, всегда, когда не запрошен интерактив/heredoc), перенаправлять stdin qemu (или всего vm-run до запуска qemu) с /dev/null. Грубо: [ -t 0 ] || [ -v HEREDOC ] || NOSTDIN=y Точечный workaround для пакетов: вызывать в %check `vm-run ... < /dev/null`. Возможно, та же причина у flaky-падений bpftrace в %check (https://bugzilla.altlinux.org/60610): там тесты тоже гоняются под vm-run, а падающие тесты — тайминг-зависимые (call.tseries, time series avg), что хорошо ложится на "гость с непредсказуемо искажённым ходом времени". Дополнительно (отдельно): timeout 60 в check.sh пакета dm-secdel впритык даже при здоровом окружении (~35/60s в girar) — стоит увеличить.