From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 76609364941 for ; Wed, 15 Jul 2026 14:44:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784126644; cv=none; b=Nl041TlRkaOSy9NW3IY0wm47PLR2Rk/lU4j7Dp5AFG6RPURGKOE9qkajy/500/7ZzJGIxHaCWCPcBe7eY4pXiBDeQ97KEvVEKkK/tuWWICtz0twJOsePjdwOuaMDbANt1s/4DfWIhEdIp0TKTbPW3R0hPFB0RDNGGu707BVq3kc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784126644; c=relaxed/simple; bh=UGeZQus2QHc9nRCp/1be1I7UhFc6yQb3LaASDCBRQF8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pkYH5lvhbmHXLDUxFFqW7id4XiP2nNTp/6fffY44oyfULN3ZiMc1bHH0yBRritLbFC0Ja186IJoRVpJ8mDjN+Fyp9pUp2yqvNEAVp/Uil85dt0sxkABg4NQiozNHOpqiNx8H7B7lAIQ+xDxZE7cDCM765NSAOhNpKp5W/10GZrA= 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=WMuD71ph; arc=none smtp.client-ip=209.85.128.43 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="WMuD71ph" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-493f4638f4aso19011485e9.3 for ; Wed, 15 Jul 2026 07:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1784126640; x=1784731440; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=8pVZkFgsPCaB/alicTDNO3QjckyCngC96Qjq4Aj5c3c=; b=WMuD71ph47RfwCvcZPnJiY7YeKWMtoyOF3A8TCIZySVtgdZVkYCflMiZKpMDDY7ZoN 48RMOvQIyJWtpLnV64q8/r3/gfI5sbbDmCTPlfPFKSoo+MfeR5Sb4HqTuQFGS23l9J0+ rX3W9XBLYGgDhjsKkUU9eQg/W6iOQQZvyd2kFMosNxTXyE309tm5w/0ZJhooICt1RFMz 3cij6J9wYMwoxSTYfQ85XfrcYxEQRhpF7KH9UjWrDc/kspHM8tP4+4xUtQ3//fOYZjTI cADGDDDYGfzcuYLh15u1/oXvoRJwVlWX6wO4bHLO6JSnZ/5q6OgaAfUo74CX0rFeWSMw 20Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784126641; x=1784731441; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=8pVZkFgsPCaB/alicTDNO3QjckyCngC96Qjq4Aj5c3c=; b=tDCj4wdiUM9sZqtIZHEEyFU+XZblY2LeuoV+bO7bmJYaVpI9G3JlBY9J06i9PbCqdH ZEqR8H0rN8tOCyO27rMERBXkuAQTK2E4PtawsgjRKncy6p+HRBtgGprVpIblftS0OsjP R2GaMaSUZdkTqz2eAVURY9XNJ9zOSmJAMMcEem45AcJtyO1/laZwbxq3z9EDsEobFtR4 uYPuVZGx/CDnJn+f5lqJ2rvtAW4I3RoQ2JfBOJkHNesi1dLHUQN5JMMnXLZmdHG6laaZ lUW+oTU6l9SoWkdyPcwfJ7/aKePKr6fu5+TzyygKCIy5PbctLznLcIhZoi70B0zW2Llc dFfA== X-Forwarded-Encrypted: i=1; AHgh+RoyzYnbrhnE7W96oZmf30QM7e44RRVrqrmFqPrJO3sA77mEVQL7PzqxjBLdt+OL1wofwYQodN72LpCeWdg=@vger.kernel.org X-Gm-Message-State: AOJu0YwIms1BBTfLhMF/VzcdBFkgZAmvyAiTt+Dpatv3d07DAtYFavpL A8Iy9mRbXbkRtr+aONvFMqYz6/JHPC4PphHxD/GGJDyRVhMScCVuFLYgJ5u5uwIaV98= X-Gm-Gg: AfdE7ck/2KOZ45sbgtYinWlqU9vZod+1itB/3fuRH9NxmKsjH3/gJtNpC4ERGCJOs0m +yFocb4cway3xH04XbMPAOOqH/au1zSUWiySdG28xco0riesYsLXCgfEdcHgSDrqYi8LBcrhlkI 5/DVBmTOUG28dgYB6FSZXOu0tlQJCiKzF1+gEZ9D21bApZYpKFzyHwQb38VVFxZTHTg2G0zHLjz hPnJQtGns6JEHGep7CyOe0+Gqli+Kx02e0NBN72at4y6PzJprReUf2K3MSDd7taqNsGQdKEpvwT WTl8szSNE9a2pQrGLGeGN7mWiWVaaMQ/nLxXu9g9BI+XbCLzHuIajIliwqN85hFy1e2t1isACXk H54AUR6aeBbQ9LbuzVIqLGrdOPlJv5iQFArBdsJQUeH7EuJOsWaQgkcmaPd77do7HHbZQEyIunI jkn7Nq4ZIh0YnaVDo= X-Received: by 2002:a05:600c:c4a2:b0:493:a438:7f98 with SMTP id 5b1f17b1804b1-493fd45f96bmr165184705e9.18.1784126640514; Wed, 15 Jul 2026 07:44:00 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4950a2f951asm162661775e9.14.2026.07.15.07.43.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2026 07:43:59 -0700 (PDT) Date: Wed, 15 Jul 2026 16:43:57 +0200 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , Steven Rostedt , Marcos Paulo de Souza , Chris Down , Naveen Kumar Chaudhary , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 01/11] printk: Handle pre-enabled consoles in the top-level register_console() Message-ID: References: <20260604101459.393162-1-pmladek@suse.com> <20260604101459.393162-2-pmladek@suse.com> <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; charset=us-ascii Content-Disposition: inline In-Reply-To: <87qzl5bsqu.fsf@jogness.linutronix.de> On Tue 2026-07-14 15:39:45, John Ogness wrote: > 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. You are not alone ;-) > 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). My understanding is that these set CON_ENABLED because they are enabled another way, e.g. netconsole=, ramoops, ... And console_cmdline was originally only for consoles defined via the console= parameter, ... And it probably does not make sense to add a fake entry into console_cmdline[] array just to make sure that the console driver would match something. > - drivers/tty/ehv_bytechan.c > - drivers/tty/serial/ma35d1_serial.c > - drivers/tty/serial/mux.c My expectation is that these are some special platforms where the authors just wanted them enabled out-of-box. BTW, similar situation is also in handling SPCR on different architectures. I have investigated it some time ago and found the following. The console proposed by SPCR is: + ignored on "loongarch" architecture. + requested on "x86" when "acpi=spcr" is defined on the command line, otherwise ignored. + requested on "arm" architecture unless "acpi=nospcr" is defined on the command line. + requested on "riscv" architecture unless acpi is disabled So, again, some architectures get a particular console preferred by the particular HW by default. Others get the kernel default which is typically a graphical ttyX. > 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? I think that it is intentional. And Marcos is working on some clean up to remove the hack with CON_ENABLED completely, see https://lore.kernel.org/all/20251227-printk-cleanup-part3-v1-0-21a291bcf197@suse.com/ > > 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 Thanks for review. I am going to queue this patch for 7.3. I prevents a rather theoretical out-of-bound access to console_cmdline array, Best Regards, Petr