From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 888E63FFD for ; Thu, 11 Dec 2025 15:28:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765466917; cv=none; b=tMimukrcnJHb46gfxU4eKSvk+Xrh/DcWtKerJtO5F0Gpy8iIxtwqDKhIGL9pMN2XGAAJnZcV6WUBDFgiZjb748nBQ45rAKI5f/UnKp+2Z1f593ItGy4lVm9gCHjligydjEBuDsfECKDJzFHLmfCTdYh967W6i30DbQ7g3XCVsXM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765466917; c=relaxed/simple; bh=5wKG+haT009wYbrxxi7AHmWpePJglQfrNLIPsmtJUtI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OvbnUA5dO44DaIR3QESU3Q0+L+++nnLpE7MEpLlt3YyE+s7UUR6mHA2ldCZxXwNoWWIcNVyRgJ185X74PQlu5qBN+LRjw6xyk/luqYxvehgqC2cxjgPud6fUYqp49Xo8J3mLrKQ2/Wded4yvcwR9ozy1iqbb3EBLaHZfRk7zBDM= 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=UZ4HVAze; arc=none smtp.client-ip=209.85.128.48 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="UZ4HVAze" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-47795f6f5c0so1891755e9.1 for ; Thu, 11 Dec 2025 07:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1765466914; x=1766071714; 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=CVvvdNUmqMnpBFUuLHR2LbYv7rDZWZkZF+pZuGnoBbI=; b=UZ4HVAzeUBRnZiMKyF83Ki1amsm9yxbtno6GyZK0g0GghauLR8GCsrZCRVmAjjYfSq cj4TMi+zeCrh6rruSJo5eah3wtdG9fWK6GOng3LcEbzKo7N2AibsXeadQitDrEqvPsNU M765z4ucXQEfamynyKDvYP4ZcVKna4yzqtaKTkRJhIJpkt1D9TOqphiSf/Cd2Q5TIBpm WjBWr5T+KjspMOezcQfIjU6fBzRf/mXB4OSYvUyWt5C02uHdJbdDSA/nZILOh3RuglZ9 WygaAy87KuUn/rZTF2GPGV2LmjaSCMFSO2MtjbYapfafaJ+Nbcwo3GXvd+HqvvdUNh0S 9qRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765466914; x=1766071714; 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=CVvvdNUmqMnpBFUuLHR2LbYv7rDZWZkZF+pZuGnoBbI=; b=dW5ykQGn+tkif2YhlKT0X2/dNgMhCHerhLwwwmniMErUVQFELlKtF8tn85OYtchiKS g2drjy6CZLIJcGEEwdZLH9+bX5GXaqthJSeqcguhJ1Wdjb0jWMZJRgDXcZgWu/Osmr8N zmPcLCptdczKUgvov6IkdqmQ0TsxWQzRw+NDq1LVuqfNALi5vxpxiGGsCMhWhqp6k0hS dE1BRWpXCVTOQ+I40s/YC3JWjkXhUqgNG2dAhe1j3+17wU/hrs5twhIzlC4BhI0IE0Jc OwV2dyk7pPzaoWUmtosWiHrW6SRwm4gaAGIKYlbQMyaIiPPCcfzQVfo9/7T2D8xGd/nZ ATxQ== X-Gm-Message-State: AOJu0Yz09VGitngZUaCXfZ/jwVGZNcohUYzzKj5dH+IO+FKGif1EXQXT aei1ioBt8DyRQ2TC3PLe/QSKQKRJvZBMb09sw774g39gsLmUmH98jpBZOHILfqiup+k= X-Gm-Gg: AY/fxX4y5Jev+x2Ngq3qqvOOi0i7FoxHTSs96/E0FvKywBF59ElA5EXicMs7O4r5k8N gjfDZMjQFdI1Yi6gyBBF8WLfPxMtZNozVIvAWZu0tub/qBEUe+1ddJMGOfNaqJFt9DVu+Qbcn4y IvL5gRJrochDmH2JXjE3uu+SWyPcthjF4XdHEk/q6iUeXdrFSz4rsk61vUcy00cfuMyNXP9J5Qt DHsydDP59UhmlA4d9VQr9utFkASVer6Bhf0yaHnP5JPgngru6w49O+dthU+VJ/WieV/48FsA67u h79odsATbxcARglfZzBPaTN1Ses4H5DXfltiq/83eaQ4tmRhSOru+sqTXrKP4VRj/6U92CxKEGl ezDLTqkoqyVPiCpHzbk6dw+oREoj+B4tpI1mXt44Eud0gk8u/CxB1ReV+mFv9sWaCjOCQrBqNz4 fpxpg= X-Google-Smtp-Source: AGHT+IGXb6mRIlbSfTt5bexUcNMOOMpWuHnhS39bxJcvRq3M16oiuKGcWHGz/oudXnFmmjpKleqzdg== X-Received: by 2002:a05:600c:1385:b0:477:aed0:f3fd with SMTP id 5b1f17b1804b1-47a837946f9mr56671005e9.8.1765466913681; Thu, 11 Dec 2025 07:28:33 -0800 (PST) Received: from pathway ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47a89f0d6f2sm38776435e9.13.2025.12.11.07.28.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Dec 2025 07:28:33 -0800 (PST) Date: Thu, 11 Dec 2025 16:28:31 +0100 From: Petr Mladek To: Chris Down Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Sergey Senozhatsky , Steven Rostedt , John Ogness , Geert Uytterhoeven , Tony Lindgren , kernel-team@fb.com Subject: Re: [PATCH v8 01/21] printk: Fully resolve loglevel before deciding printk delay suppression Message-ID: References: <62f3a734401016a387b59bda8ecd39252a8da849.1764272407.git.chris@chrisdown.name> 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: On Thu 2025-12-11 15:49:54, Petr Mladek wrote: > On Tue 2025-12-09 17:40:11, Petr Mladek wrote: > > On Fri 2025-11-28 03:43:12, Chris Down wrote: > > > When printk_delay() is called from vprintk_emit(), the level argument > > > may be LOGLEVEL_DEFAULT (-1) if the loglevel was not explicitly provided > > > by the caller. > > > > > > If printk_delay() relies on comparing level against the console loglevel > > > (e.g. for suppression), receiving -1 results in incorrect behaviour > > > because -1 is treated as a high priority (so not suppressed), causing > > > unnecessary delays for default-level messages. > > > > Great catch! > > > > > Parse the format string prefix to resolve the actual loglevel before > > > passing it to printk_delay(). > > > > > > --- a/kernel/printk/printk.c > > > +++ b/kernel/printk/printk.c > > > @@ -2179,6 +2179,32 @@ u16 printk_parse_prefix(const char *text, int *level, > > > return prefix_len; > > > } > > > > > > +/** > > > + * printk_resolve_loglevel - Resolve the effective loglevel for a message > > > + * > > > + * @facility: The log facility (0 for kernel messages) > > > + * @level: The initial loglevel, may be LOGLEVEL_DEFAULT > > > + * @fmt: The format string, potentially containing a loglevel prefix > > > + * > > > + * Determines the actual loglevel to use for a printk message. If the level > > > + * is LOGLEVEL_DEFAULT and the facility indicates a kernel message, parses > > > + * the format string prefix to extract an embedded loglevel. If no loglevel > > > + * is found, falls back to the default_message_loglevel. > > > + * > > > + * Return: The resolved loglevel value > > > + */ > > > +static inline int printk_resolve_loglevel(int facility, int level, > > > + const char *fmt) > > > +{ > > > + if (facility == 0 && level == LOGLEVEL_DEFAULT && fmt) > > > + printk_parse_prefix(fmt, &level, NULL); > > > + > > > + if (level == LOGLEVEL_DEFAULT) > > > + level = default_message_loglevel; > > > > This is not ideal: > > > > 1. It more or less duplicates the code from vprintk_store(). > > > > 2. It does not handle loglevel passed via parameter, for example, see > > _btrfs_printk() which calls _printk("%sBTRFS %s: %pV\n", lvl, type, &vaf). > > Note that vprintk_store() calls vsnprintf() before checking the loglevel. > > > > > + return level; > > > +} > > > > Alternative solutions: > > > > A. We might call vsnprintf() one more times here. > > > > It is ugly but we could do it only when anyone wants a delay. > > Also this is not easy because we would need to check printk_delay_msec, > > boot_delay, and system_state. > > > > Anyway, this solution would need some refactoring in printk_delay() > > and vprintk_store() to avoid code duplication. > > Even more duplicated code was added by later patches. > > I tried to implement this alternative solution and remove all code > duplication. But I think that this is a wrong way after all: The solution is not good: + It adds a lot of code complexity and one more vscnprintf() is needed. + One more vscnprintf() call is needed. + It still does not work properly. For example, backtraces from all CPUs (SysRq l) prints the entire backtrace at once because the console flush is delayed. The same problem will happen for any delayed messages, e.g. during early boot before the 1st console is registered. > B. We could move printk_delay(). > > > > It should be called before storing the message. Otherwise, we > > would need to call it from various console flush calls. And there > > are many flush paths. Also the message might get lost when > > consoles fall far behind. I looked at this variant and I think that it might be much better after all. IMHO, it should be enough to move printk_delay() from vprintk_emit() to: + console_flush_one_record() + nbcon_emit_one() Note that it is possible only in 6.19. It includes some refactoring which allows to release locks between each record in both legacy and nbcon code paths. One piece is still missing, see https://lore.kernel.org/r/20251202135832.156559-1-pmladek@suse.com I would suggest to solve this separately. The printk_delay() never worked correctly. And it seems to be a more complex problem. I mean. Let's keep this patchset only for adding per-console loglevels. Do only the bare minimum (like in v7) and remove the rather complex improvements added in v8. Or we could move the printk_delay to console emit code paths first. And rebase the per-console patchset on top of it. Sigh, I do not want to block the per-console patchset once again. But the printk_delay()-related changes in v8 are too hacky my taste. Best Regards, Petr