From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A21D033BBC0 for ; Fri, 22 May 2026 14:46:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779461199; cv=none; b=mpK/vhxxvB/Z4PHWdAokrfDeVmEos0Zz8jy2yp7KtIp2pliTQOSwmYaLe+OtJdh6mRwEbkVH5oZ/35Kbk4jsyLqsBTupHmV7KO078mOJMDkGnhEwh4zBkOHk26D81gj4qOJVp98/dW4WWK6MEMMpHkXG2x8NlOP6pGM2aYkTQ9o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779461199; c=relaxed/simple; bh=JvHRNwAS6TgaOaPpVgv7Z/WbF+Gca+zueF1yYBSr3eQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=N20J5H3aNPpx4VF377+6IL50fJwcTAPBY3MWek2EqteEjqW7hl1oczRWbhS3bJuVzVjc55te56Ln2mdub6UMpdmN9toWZWeXQaX63CkwQa7VPomJyeI77N3JYbW7gBVOxm2nPOwPaVViaP2Ke3IxSNsuVdk+IW+K3652U44+uEM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=O4tqDgJ7; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="O4tqDgJ7" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49039a8851fso20153975e9.2 for ; Fri, 22 May 2026 07:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779461196; x=1780065996; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=zU3/5yUqo+IhGHWuiK/FiWnlBn7ugz9ApbdXe9h4DaU=; b=O4tqDgJ7uRdtTi6afGIyecxN7CDb0Smsi+MntywEhG2pjqiRuy8O70kkZMOe4MZ2Xm 3yRXt789wvkH35kVvt9w1OndtvsXUAoL/lDyoAO1/Ll0qY143JdHNNL9UgtylJ3uszMy bFXhyyIsVyxfTFkLRFhDuWPxXpdD/dOAuvte6UwNh27dOkjAQkUc2A6o2JmvKKsGrEHW tnu2k/Z/6BgeYy2OpfgwEWNQBlJf2DLTVev7Hm+JynMqbMhauy5gLolK6sUjgzYAsxm3 qrkXgKW0r6VJbB45PEYOiw5YG92lM9MtTSHIfIvsLLna1OqkbJke4px16Bfrc/w0y5qQ bBkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779461196; x=1780065996; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zU3/5yUqo+IhGHWuiK/FiWnlBn7ugz9ApbdXe9h4DaU=; b=CgbyfC+Bp8KYOTFkORm9sYOOD/OkVN7FDS2XZbVt1VJln0/0DmvnqPMbZ6VjqiR+O+ EbcZ6uzHCGUsfgYo0CWmiqntBs4TEPh3QDwZ2huF3dok8/DYeyJRT8XdP+j9Nvsozp+b feJCDy37Ycox1dDK0cTxQqd6xcDs4tGqXZ9vOKlKSVIZx8RgkUM7wZk9Mktef4GradyC afu8be3WA87d1ukV8eGlA/qfeIthx6bUQDu1YW11ktEo1/JijCp+RO6KrcSXnGTHrbd7 qVYevI3e+y4AIW5QTFgx3xa8Cr82+VdEHyyIBW/u4U0J+pTJUgvo3ji03zSrLL+SjAeG f6cw== X-Forwarded-Encrypted: i=1; AFNElJ/tVJT8ko1BHlq5Gl3wAGlZS0veUdxkXhQP91+K5myiF4QJuB2Q+6e8MxEmhsklwt0ZSgBZ7gih2QQVhRY=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4Q8KzgHFwwwR8xonlLHwriSYXCl3XpsRD1oX5OjrWJNC5UX8k KLNpo5tK7iYPp5ST85mn5SMNGv5ZcogMxsdQw344X4pYLNJQlBKFEadFIpLTt9AEECZ78i/+G0G qWpn7 X-Gm-Gg: Acq92OHUmdveQ49FM4OkAsS9IrtzfMHLRf0lRrK6TpFFf+J9hYPj20ek5PoDBcMZMqn Lzfcm+rn+p0MOTiMkcnm++5c6MWhO9pPlfDokhfD69Cofum7dVymVEpN52zziUhxGaJFkRbS000 0fP+GnGOxSk3jWgwcz9RUKm63B70dg4GVX+IImWbQ2RyqXyhvHEMQLAPVocPfCVfJ0Q0vrpRv6T 4kvng3we8UZvFYD8+0UQ6BdZmlnx9R0cqPBvFpsKudd7ZaxDt0DSr6aWk/VpEQFZC0ZIIi71t8e pfml66KMmw4vbCwppnxnlbjyu0CwjsAe4bIQMoG0cqaW6/vRhpkgxDVTwesznHKDn5TR+bLCfvG 3ko4sWBoX1Z5qMLylB47TbKUERLA0kiwzNG2WczTMgzEOg+N8JCzXu5JjrnSGhVTbDLDtxZn27S ZKK1kjC6Sh38/ulnm5MgnwcaQWqw== X-Received: by 2002:a05:600c:4510:b0:490:3d2e:b67d with SMTP id 5b1f17b1804b1-490428eb9aamr52878125e9.30.1779461195913; Fri, 22 May 2026 07:46:35 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45eb6cce01asm5091371f8f.11.2026.05.22.07.46.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 07:46:35 -0700 (PDT) Date: Fri, 22 May 2026 16:46:33 +0200 From: Petr Mladek To: John Ogness Cc: Xiaochun Li , rostedt@goodmis.org, senozhatsky@chromium.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] printk: Unconditionally unregister boot consoles when any real console appears Message-ID: References: <20260518084251.3887779-1-lixiaochun@open-hieco.net> <87mrxxuinb.fsf@jogness.linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mrxxuinb.fsf@jogness.linutronix.de> On Mon 2026-05-18 12:22:56, John Ogness wrote: > Hi Xiaochun, > > On 2026-05-18, Xiaochun Li wrote: > > The design of kernel message printing ensures that boot consoles are > > temporary and should be unregistered once a real console appears, > > preventing duplicate output without any loss of kernel messages. > > > > But currently, when multiple "console=" parameters are specified > > (e.g., console=ttyS0 console=ttyS1) together with a boot console > > (earlyprintk=ttyS0 and/or earlycon=uart,io,0x3f8), the boot console > > remains active indefinitely. As a result, after the real console > > active, each kernel message line is printed twice consecutively that > > is not as expected. > > Although specifying multiple consoles using the same driver is improper > usage, I would still consider this a bug. Thanks for pointing this out. > > (The fact that you cannot specify multiple consoles with the same driver > is a ridiculous historical artifact... but that is another topic.) Yeah. > > Currently, register_console() unregisters boot consoles only when the > > newly registered console has CON_CONSDEV (i.e., it is the preferred > > console). However, when multiple "console=" arguments are given for > > the same driver (e.g., 8250), the try_enable_preferred_console() > > matches only the first console_cmdline entry and returns immediately. > > The enabled real console (ttyS0) is therefore not the preferred one > > and does not set CON_CONSDEV, because preferred_console points to the > > last entry (ttyS1). Consequently, the boot console is never unregistered. > > > > Fix this issue by removing the CON_CONSDEV requirement and > > unregistering all boot consoles whenever any real console > > (i.e., any console without CON_BOOT flag) is registered > > I do not think this is the correct fix. It relies on the buggy > unregister_console_locked() code that even warns: > > * > * If this isn't the last console and it has CON_CONSDEV set, we > * need to set it on the next preferred console. > * > * > * The above makes no sense as there is no guarantee that the next > * console has any device attached. Oh well.... > > I expect that the correct fix would be to make sure the registered > regular console gets CON_CONSDEV if the preferred console could not be > registered. The boot consoles are already automatically removed in printk_late_init(). But it removes only early consoles which use a code in the init section. It does not remove all boot consoles because the real console might get registered later by a deferred probe. Idea 1: It would make sense to remove all boot consoles in printk_later_init() when there is at least one real (non-boot) console registered. We could not guarantee that all the boot consoles were replaced by proper drivers. But we could at least guarantee that some console will stay and the messages might be visible there. Idea 2: We actually know that a boot console was replaced by a proper one when newcon->match() succeeds in try_enable_preferred_console(). It might be acceptable to remove the boot consoles in this case. We do not know exactly which boot console was replaced but we know that at least one was replaced. Note that .match() callback works only for a subset of early consoles. I see only univ8250_console_match() and pl011_console_match(). But it should catch "earlycon=uart,io,0x3f8" mentioned as an example in the original commit message. > Or maybe the unregister_console_locked() should be fixed so that there > is a proper fallback when a CON_CONSDEV console unregisters. > > The preferred console code is quite tricky and is even in the process of > being cleaned up. (Although the bug is present after applying the > cleanup series as well.) Sigh, CON_CONSDEV is another thing which would deserve a clean up. The current code is a mess. The flag should be set only for the driver which gets associated with /dev/console. But it is not guaranteed. The driver associated with /dev/console is selected by console_device(). It is the first driver where c->device() returns a valid tty_driver. But CON_CONSDEV could not be assigned correctly in register_console() because the tty_driver layer gets initialized later. Historically, CON_CONSDEV is used to order the drivers in console_list: 1. CON_CONSDEV is set by try_enable_preferred_console() for the preferred console. As a result, it is put first in the list in register_console(). 2. register_console()/unregister_console() always sets CON_CONSDEV for the first console in the list. The first driver has the biggest chance to get assigned to /dev/console console_device() function. But it is skipped when c->device() either does not exist or returns NULL. AFAIK, early console drivers never have con->device() callback so they never will get assigned to /dev/console. But we still keep them first in the console_list() because it affects the order of later added drivers. And we need to keep the ordering right to avoid regressions. My proposal: We could try to implement the above mentioned "Idea 1" and "Idea 2". They should fix most of the real life scenarios. "Idea 1" is even independent on the currently pending cleanup [0]. In the long term, we should stop using CON_CONSDEV for the ordering in register_console(). Instead, it should get set properly in console_device(). But it would require another careful code clean up. [0] https://lore.kernel.org/lkml/20260423130015.85175-1-pmladek@suse.com Best Regards, Petr