From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA5AF32573F for ; Mon, 18 May 2026 10:16:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779099420; cv=none; b=XYKw7HgkIpIHWeqmRw/IK+3llE+a5lNTUf4FTusUmxjjnsNOIILE/Z9JG6YkTx2CdOcy5PepxQ9ib8L4CEs/v2pyh/UeoHqP+u5/J76FQ4CGWqI5Bon4O/F1MaLNY8PyERNIf9gnj8aDCIhdjH6C7q1SicA9FpAOUpvMrn2vgrc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779099420; c=relaxed/simple; bh=939sLjhibPwuZfp9kXIhK3lRYs0haWhOWevHWED8xuk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=TdkpRKnE0fYxpadhRcjF6TyeGDSZob0Xixfrjj/i1vfMRE9ImMkes5xRj313HAQ2dioTt7+XVN4OUcaeQRGHIkBAW1imGc7Ca8Qc20wFI5uech42XFrjxCJrUF3jpaBQ1+dvamoM+zBrRDQp66PShZILOUZzSeMrBCvT02f1xaU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=yZduSHu3; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=l66FHi6h; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="yZduSHu3"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="l66FHi6h" From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1779099417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=blpeAljgIlCZXeGanpFYV4lPzGbn67YUyhwM0Biikdo=; b=yZduSHu3ddX75q/psgL6Akz/aFDU5u1oVYH7wcLmt8s/DFixf/O2FYsRdfSbJ4voqbznAz gcLM84/GkrK/FsI7KJ8f/jk7If9XwQIH/By/FYcjZqVPRKzMjHwVubFivzQzFsd8JNeFIU W0Fmj92Hjid+oMrvRtSuIOkY5KvNSlY+/akUXiXInvD6KldERfppCqJws1W5JLQv4FqyVS DlENekxgwCno0zneeT4GrCS0+iHDuIAX5dslFv4z+ozzg5eagOrIvkGA954R95hCQrhIk6 KBfvg7gJmIrUz4Ypf+03eNmA1IDV211jXF0A0k3iQvHatzroNJ145ybirQ+APA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1779099417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=blpeAljgIlCZXeGanpFYV4lPzGbn67YUyhwM0Biikdo=; b=l66FHi6hdlzW6PblSN6IKlw4KwGz9THegJdGoB7QWG7+tW/0Uo9TxrcVoy07B3T0F7/1Ap /y1fGSkimhlEgvBw== To: Xiaochun Li , pmladek@suse.com Cc: rostedt@goodmis.org, senozhatsky@chromium.org, linux-kernel@vger.kernel.org, Xiaochun Li Subject: Re: [PATCH v1] printk: Unconditionally unregister boot consoles when any real console appears In-Reply-To: <20260518084251.3887779-1-lixiaochun@open-hieco.net> References: <20260518084251.3887779-1-lixiaochun@open-hieco.net> Date: Mon, 18 May 2026 12:22:56 +0206 Message-ID: <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 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.) > 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. 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.) John [0] https://lore.kernel.org/lkml/20260423130015.85175-1-pmladek@suse.com