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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792253992; x=1792858792; darn=lists.altlinux.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=da8CSVyebftVv5EtKcPD6ZSvkbaqHsO2Q77RMgZ3YRQ=; b=KrwNq6eLh8DhpxPFI/FshfU45lDxO7aed+nq/ehO1zhwQzpmGpl6gusKdXEyW4Vzle XUOPuG6mH4w3pluNOAXuxzZm0UGngSw/xx+QaQA+235oEq7lbAszI61ZxJYhXMdA9pKl y+zy5X8p4TyVCPukzV0k7z0yqAPlNtvG+JszoTiu44bqQNSgtnThVVvfxc6cI9+Ihc6/ dzMic0g3ePMHOOD3bkUuBJNYuM4reh9oNkyQkudEu7b4oOHBvccmK0POHPsDcuO31f1R Jx3MRWpke0V9cNf14bGNd4gvEx9TsYOdLLqY4coQjj3qJT4XG5sB3QUpnW5BQF8PrCdG /7IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792253992; x=1792858792; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=da8CSVyebftVv5EtKcPD6ZSvkbaqHsO2Q77RMgZ3YRQ=; b=thZKPvGrHozMvyINspnvp7EnZGeHFnLRzP07ApwwYAiUj3ozzWliKTH2mq/Oj3BF/z G5p7bHYVYbCv2XD+MVjgNuGZxVkRudJaH64A+zjMU5587PiUS04LAop5X+rKBa8TmOqA L4vBmSPDv3pnOJGOnvU3ub/J76Od+DV+LFQGYCmNy1pQjU5053ySks6q69Nm5MT4ob9t LrxaebmakJvyiPnnA6JeKlK6ug214ChH6Na91GA9IvWbZj8+ehdsKs3dt5eKEncql6UL Y6Cc9ZznRpMT6+O3BNzIS9iHATK0doZj2jM27zJOSpY2qY9QoTzDCShRLX1KsNQwUsoB IsSA== X-Gm-Message-State: AFq9FYIVSqmKz1mjUhOmI6RqvKJSnWDmFyHcjooHNrk7l+ogl4Bn/DQe vkxBSiOBd6BnVqwB2ziM0+UVjKixHB91VDsva14abLYkVpV1YXFIBfNHeTwvHg== X-Gm-Gg: AYBFou0k6Jo/aMqbgTufIgVUOO6dgcA+XeNYr7oGYuy2vw0OLaDXJ8XAZiDLHK2hmXN 2gTwFdjOaUvkxQ4yp5GxR0QHyBDe0WJakIt+SGAhqrJOe+3KNRpXnb57IL1WNnq2rm/svDOCt0y dur0KFjA3plHtBgBJjxU4F5tPVqgfrICj1WMJnBl+bTSrkwB1cGI6IW95220BXQ2z7tZeJflki6 LZcRLl41ydN8hyUkRdeW3kL4Nz0aD6czCaCRSmWtlnT9f8E6JRpPSZX/NWQXJfxhFpv3coXEe0V RNJaWqIKGNBDZVTM0t+LgONBQLUzxhEAdUiFx12FZAwXcpfmw+Yrik1vYX4xmGTZOe/Y4cf0UQn mO+TfVb3a5P/PG7S7WvdgvGbazla0ftjZQwcfPLmuozjRgWBCw4HwcyIHGmCnoAjax943WJxQPp 8JVIGEQZ+xIg+OCf5CPx20ZWPSGMK1MSW3OFa3rT+JWeQBLtJDNeVETfsHHzuysWePGm8oRn914 SazTq5bWsfrp/W8 X-Received: by 2002:a05:6808:11c5:b0:539:a2c2:aba3 with SMTP id 5614622812f47-53cd7b4bca6mr2486750b6e.52.1792253992369; Sat, 17 Oct 2026 09:19:52 -0700 (PDT) Message-ID: <4509be5e-e769-4e84-90e8-daeceba47f76@gmail.com> Date: Sat, 17 Oct 2026 19:19:50 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: make-initrd@lists.altlinux.org References: <355e18e638f4631184c105d566e41029f1e5a1f1.1792152299.git.gladkov.alexey@gmail.com> <66dae82b-2bd9-4ac2-aa17-d04e3845fbc5@gmail.com> Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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:19:59 -0000 Archived-At: List-Archive: 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. > Без нужды я не вижу смысла такое городить. > Да, тут тебе конечно видней. -- WBR, Leonid Krivoshein.