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 B6E903382F4 for ; Tue, 14 Jul 2026 13:33:55 +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=1784036037; cv=none; b=RQfYWntI7l+D4HNJ4md/04C0AFQUslwjbLWfJHWyEMP6hhlJObQBgjCSLHxPF+qRncrmXelVyaIQb8AAEMTKpyA7XbbifAIOKo/rDcoI+LkhiD5x7Ct8OD2YXQ5VbNxh6PT3GnlgYQhwyhafUE7RjT5l0YOW4XhdMgaYhAvuaws= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784036037; c=relaxed/simple; bh=c2C7Skc9WMFcnIQRJBkpcsnnw3U+XdPiXHyokld9JlM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mXHQDQ/OMzR7PfM6yVg+pGygeGhQ/lrnjZ4Poc3RAwJNIUs5jcd0ElquL20uDNB7ijRInzIv3iOTNvasPfHnjrUeKYNzIZUHzVGG3+pBXMPDjce79Kq7uR1d+gnZuwUr8XdVZbQ2P8QrEQzyFaE+MbGrKG9brf3F5IIeFAaLzQk= 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=wccCbMg6; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=rJmp9JnB; 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="wccCbMg6"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="rJmp9JnB" From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1784036026; 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=c2C7Skc9WMFcnIQRJBkpcsnnw3U+XdPiXHyokld9JlM=; b=wccCbMg6V7yy4TjEloozot/3DsiOJf7+k1UTcbL6H3kPYYazpQretdn4766L+WhAuzdDAe 9ugue8ypirR1A2rZjGdc0PHpwwJMA4HAhnHFoxQwPJ0kGS9YIk0X46ZUlBJAKfUxEkR9Jk Ijkf8TMQvuzl2ZKkBSp/3L3NHE6eoFdMlZT8vFFgaY1F+sU6R1tezU+bep+8WJ0HwRCIeE ncX3NoN5ScEBD3atMKOUdA/ol2S1S42xle5Fi02846jUomQSJcSY6sMtTVBAlpVovrHvJB urrP4pYmPJmmrdCCqWGX1tTY/Qy398zijH7daE0807eI1+A67J6/lSpDJ9pu9w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1784036026; 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=c2C7Skc9WMFcnIQRJBkpcsnnw3U+XdPiXHyokld9JlM=; b=rJmp9JnBQd+XOAtbd3r3pIKY0ZkDChS7CDaAkeDWzHTXMLe2tM568cadZemN91GDeAkiWf CpH9Ry9Okhh8ldAQ== To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Marcos Paulo de Souza , Chris Down , Naveen Kumar Chaudhary , linux-kernel@vger.kernel.org, Petr Mladek Subject: Re: [PATCH v4 01/11] printk: Handle pre-enabled consoles in the top-level register_console() In-Reply-To: <20260604101459.393162-2-pmladek@suse.com> References: <20260604101459.393162-1-pmladek@suse.com> <20260604101459.393162-2-pmladek@suse.com> Date: Tue, 14 Jul 2026 15:39:45 +0206 Message-ID: <87qzl5bsqu.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 On 2026-06-04, Petr Mladek wrote: > The function try_enable_preferred_console() currently has the > non-obvious side effect of returning success for consoles that are > already pre-enabled. This obscures the logic flow during console > registration. > > Move the check for pre-enabled consoles directly into the top-level > register_console(). This change makes the handling of pre-enabled > consoles explicit and easier to follow. > > Furthermore, this separation lays the groundwork for future cleanups > where try_enable_preferred_console() can be restricted to cases where > an entry actually exists in the console_cmdline[] array. > > Also it fixes a possible out-of-bound access when the console_cmdline[] > array is full and no console matched. In fact, the check of > c->user_specified did not make much sense. The new console either > matched and was handled in the for-cycle. Or it did not match > and then *c pointed to an unused entry. > > Possible behavior change: > > try_enable_preferred_console() will newly be called also with > @user_specified parameter set to "false" when it failed with the "true" > variant. But it looks like the right way to do. It will allow to call > newcon->setup() when the console was preferred by some platform > specific code. I agree that it is the right way to do it. But I am a bit confused about the pre-enabled consoles. I understood it that a driver manually sets CON_ENABLED because that console is not enabled via normal methods ("console=" or "stdout" in device-tree). There are several examples of this (netconsole, pstore, nfcon, kgdb). But then I see drivers like: - drivers/tty/ehv_bytechan.c - drivers/tty/serial/ma35d1_serial.c - drivers/tty/serial/mux.c that are also setting CON_ENABLED, but seem that they should be specified in the normal way. Are these drivers falsely setting CON_ENABLED? Is there a clear description about when a driver should manually set CON_ENABLED? > Reported-by: Naveen Kumar Chaudhary # out-of-bound access > Closes: https://lore.kernel.org/r/7sq4tr2nmlz32tvkf6vpsghv6exvqfghsrlvywjcqihzsqqbf7@bspclmti5xg4 > Signed-off-by: Petr Mladek Despite my open questions about CON_ENABLED, this patch is simplifying the pre-enabled path and correctly specifying the possible behavior change. Reviewed-by: John Ogness