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=1792230319; bh=UvpirErsHafsEn0HHU6obGZzW76jghuHv+7y0JlbviQ=; h=Date:From:To:Subject:References:In-Reply-To; b=Z2V34UXMFcvXF5APA/DvNkYPflZEMMIhLratbvV1Xtnqd2AMhx2AVDJAUC/DQ6sL8 7+0AtuVYKwxV5FXygvTnh+mKj2fcxLIbLTMKSKwOp7CI6hHOtNjWdz1FPwmEm4r+wA 74Dugojt35v3t8pf/smcw643stGI1FU/c5LkVS7C68DWzGHgCUnJ/uRSromaCq5LvM z2JVpEAq/94VoVki8DODBtPUJbWSIe8q1EufVNGHiHL0rHEN4H8H9C/OnkSVyoSu+k SE5nmErNyoZnn69BS3RBwxqX54Ll5MB+bTuYOFveji7XyjJ4ILculi0OhQ2sIj5AjT mKA21tlh0wKZQ== Date: Sat, 17 Oct 2026 11:45:15 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <66dae82b-2bd9-4ac2-aa17-d04e3845fbc5@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 09:45:23 -0000 Archived-At: List-Archive: 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 выглядит криво. Плюс если потребуется залочить ещё какой-то ресурс, то встанет проблема синхронизации номеров дескрипторов. Поэтому я решил не прятать эти аргументы и предоставить вызывающему больший контроль. > Насколько безопасно использовать статически заданный дескриптор для этой > блокировки? Не лучше ли его определять динамически? В шелле нет хорошего способа выбрать свободный дескриптор. Только перебор по /proc/self/fd/*. Это намного затратнее и требует смонтированного /proc. Всё это будет медленнее. И опять же придётся делать целую библиотеку с выбором дескрптора, глобальной переменной, где этот номер будет жить. Без нужды я не вижу смысла такое городить. -- Rgrds, legion