From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792255278; bh=3JuOit2W4+s1lnxPvtqJaohU9kcW4jpVTIAVW9GRad8=; h=Date:From:To:Subject:References:In-Reply-To; b=ABrEkpgvZ7xCYLiUbGgqSAkIq/ZT7XUfoEuH8KU2ColONhf8RqrdBzVpbK8c3Y8ST a99JwHqKogpdyaFk1NNurJHXLWX9ACFYPBgM4qNA1r0q3M2cxv61J5JxQfBawWPvDk ETuPNKQWNJlhYXrzTWVyJ3b0m5MOt52TyujaLewqCQfGvxG5tHNLDi6FRzAKaIdsdN WanEQj22yzgimWBGZQ+OKorc8lyQVFAdpB/TeNfVRje0OmhEvHAZTOovsJjbIU87LT hwmbKtq8cu2IPgQAMtvh2wfNhk3crvoE+iLIh26OhNlt4p++wiqLctRphbqco+FlIn YeStIC3krnnTQ== Date: Sat, 17 Oct 2026 18:41:13 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: References: <355e18e638f4631184c105d566e41029f1e5a1f1.1792152299.git.gladkov.alexey@gmail.com> <66dae82b-2bd9-4ac2-aa17-d04e3845fbc5@gmail.com> <4509be5e-e769-4e84-90e8-daeceba47f76@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4509be5e-e769-4e84-90e8-daeceba47f76@gmail.com> Subject: Re: [make-initrd] [PATCH 2/2] runtime: Fix console lock shadowing by /dev mount X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2026 16:41:23 -0000 Archived-At: List-Archive: On Sat, Oct 17, 2026 at 07:19:50PM +0300, Leonid Krivoshein wrote: > > > On 10/17/26 12:45 PM, Alexey Gladkov wrote: > > On Fri, Oct 16, 2026 at 11:02:36PM +0300, Leonid Krivoshein wrote: > > > Привет! > > > > > > > > > On 10/16/26 3:06 PM, Alexey Gladkov wrote: > > > > /etc/rc.d/rc acquires an exclusive lock on /dev/console before starting > > > > runlevel services. When the mountfs service mounts devtmpfs over /dev, > > > > the original /dev/console inode on rootfs is shadowed by a new inode on > > > > devtmpfs. Consequently, rc holds the lock on the shadowed inode while > > > > processes started after mountfs lock the new /dev/console inode without > > > > waiting for rc to finish starting services. In particular, with the > > > > rdshell boot parameter, rootdelayd acquires the console lock and starts > > > > the emergency shell in the middle of runlevel 3 instead of after all > > > > services have started. > > > > > > > > Once the console lock is preserved across mountfs, the network-up init > > > > service deadlocks against its parent /etc/rc.d/rc because network-up > > > > requests a shared lock on the console while rc already holds an > > > > exclusive lock for the duration of the runlevel scripts. > > > > > > > > Use a dedicated /.initrd/console.lock file in /.initrd so the lock > > > > remains on the same inode across /dev mount operations, and drop the > > > > redundant lock acquisition from the synchronous network-up init script. > > > > > > Хорошо, что нашлось решение и есть в сообществе люди, умеющие не только > > > репортить баги, но и разбирающиеся в них, предлагающие патчи! Я всего-то > > > хотел уточнить, поскольку вносил изменения в свою документацию, а тут > > > столько всего поменялось. :-) > > > > > > Но есть вопросы к этим изменениям, см. ниже... > > > > > > > > > > > > > > Fixes: 598a4b241a4f ("Rewrite console locking") > > > > Reported-by: Leonid Krivoshein > > > > Signed-off-by: Alexey Gladkov > > > > --- > > > > features/fsck/data/lib/uevent/handlers/040-mountdev | 2 +- > > > > features/luks/data/lib/uevent/handlers/085-luks | 2 +- > > > > features/network/data/etc/rc.d/init.d/network-up | 3 --- > > > > features/runtime/data/etc/rc.d/rc | 2 +- > > > > features/runtime/data/init | 1 + > > > > .../runtime/data/lib/uevent/handlers/mount/900-localdev | 2 +- > > > > features/runtime/data/sbin/rootdelayd | 6 +++--- > > > > features/sshfsroot/data/lib/uevent/handlers/040-sshfsroot | 2 +- > > > > features/zfs/data/sbin/ueventd-zfs | 2 +- > > > > 9 files changed, 10 insertions(+), 12 deletions(-) > > > > > > > > diff --git a/features/fsck/data/lib/uevent/handlers/040-mountdev b/features/fsck/data/lib/uevent/handlers/040-mountdev > > > > index 53208f0d..9e9f06ea 100755 > > > > --- a/features/fsck/data/lib/uevent/handlers/040-mountdev > > > > +++ b/features/fsck/data/lib/uevent/handlers/040-mountdev > > > > @@ -56,7 +56,7 @@ handler() > > > > } > > > > exec 0/dev/console 2>&1 > > > > -fd_lock 90 /dev/console > > > > +fd_lock 90 /.initrd/console.lock > > > Получается, здесь сначала выполняется открытие файла консоли, только потом > > > её захват. Не лучше ли наоборот или это непринципиально? > > > > Это блокировка не открытия /dev/console, а записи в неё. Открыть и держать > > открытой её может кто угодно. > > > > По всем трём вопросам теперь понятно, спасибо! Однако замечу... > > > > > Коль блокировка консоли используется внутри make-initrd во многих местах, > > > нет ли смысла скрыть её внутреннюю реализацию как раз на случай таких > > > изменений? Что-то типа fd_lock_console() / fd_unlock_console(). > > > > Я этого не делал с самого начала в первую очередь из-за номера > > дескриптора. Для вызываемых утилит его иногда стоит закрывать по номеру. > > Хардкодить этот номер внутри функции и использовать магические числа в > > коде выше выглядит неправильно: > > > > fd_lock_console > > rdshell "Emergency shell" 90<&- > > fd_unlock_console > > > > или > > > > fd_lock_console > > rdshell "Emergency shell" $fd_console<&- > > fd_unlock_console > > > > выглядит криво. > > а если так? > > fd_lock_console > fd_locked_console rdshell "Emergency shell" > fd_unlock_console > > # wrapper > fd_locked_console() > { > "$@" $fd_console<&- > } > > > > > Плюс если потребуется залочить ещё какой-то ресурс, то > > встанет проблема синхронизации номеров дескрипторов. > > > > Этой проблемы нет, если назначать номера дескрипторов динамически. > > > > Поэтому я решил не прятать эти аргументы и предоставить вызывающему > > больший контроль. > > > > > Насколько безопасно использовать статически заданный дескриптор для этой > > > блокировки? Не лучше ли его определять динамически? > > > > В шелле нет хорошего способа выбрать свободный дескриптор. Только перебор > > по /proc/self/fd/*. Это намного затратнее и требует смонтированного /proc. > > Всё это будет медленнее. > > > > И опять же придётся делать целую библиотеку с выбором дескрптора, > > глобальной переменной, где этот номер будет жить. > > > > Есть вариант для bash >= 4.1. Причём, если делать это в субшеле, то даже > необязательно закрывать файл, bash его сама закроет. Пример: > > exec {fd_console}>/.initrd/console-fd.lock > echo "..." >&$fd_console > exec {fd_console}>&- > > Только я не знаю, можно ли в случае make-initrd полагаться, что у bash > версия не меньше 4.1, но на Альте данный код работает, проверил на p11. Ты будешь смеяться, но я буквально только что нашёл этот же снипет :) Я уже тестирую новый API для блокировок [1]. Как пройдут тесты сделаю v2 патчей. Даже bash-4.2 появился 15 лет назад. Думаю, что это достаточно большой срок, чтобы добавить requires bash >= 4.1 [1] https://github.com/osboot/make-initrd/commit/6fb0fe5992568859e5bb6c95b6289eaee6a70f4e > > > Без нужды я не вижу смысла такое городить. > > > > Да, тут тебе конечно видней. > > -- > WBR, Leonid Krivoshein. > > _______________________________________________ > Make-initrd mailing list > Make-initrd@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/make-initrd -- Rgrds, legion