From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 4E61722D4E9 for ; Tue, 9 Dec 2025 16:40:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765298414; cv=none; b=KjjD1ZZkWXrBDjx3F3LiQBNuKqB22CPDZpMOuvQKeMqD4P1Uz1mnDO8M9JfS6R/5I+O0laiFuM3hiof/6WC2/vmg3iqcwAOtdxXPuDTWHbi1krmqxVfsF71ZzjG6NV4xqIkO8Mi3uXjU2igeC9uDXjqvyhObXJzkOexa/Vvbkpw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765298414; c=relaxed/simple; bh=nFsY/9i1CNy4SVWKdh7c618GtLT61Uzw4WXmDWFBfuA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=J2ikUILCO2D0hcC/JSB9czDY55ciqe5zqfGWfwDbtg4AfBHQGE+JB/F353aBGNEHqDycXNASkb6IhrkSlGB715co895Z1XXQmZ+hHuQz5FI+VHnFdnE2ZNhvYORZuPV3Ow5dYEgUZ7OG2ajr2M0BMSuoR5gy70z5JLDnoNPKIug= 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=BEt6urqS; arc=none smtp.client-ip=209.85.128.41 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="BEt6urqS" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-47a80d4a065so5356605e9.2 for ; Tue, 09 Dec 2025 08:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1765298410; x=1765903210; 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=lxe7OVi1sBDoa8IuiFqlloq3b4KfQMN9TPNt/6Lpir4=; b=BEt6urqSUgHz1nG8x9QpXwziCS3hUrfevls+5xcl3/KYL+T0oUowmwJB46szDFbJFx CgH6UCo4pM1XLdm47cdDL4xcHtjte9CAl77TuJjICggZYV26T1E8ohM3a+S2M7rmoaiY M2CA8g50ItVMGgXbIZu7OTFCTZtSSibJozm28EGQIxz/dp9MoKPJK4UK6MahYLx+dVAA /Mjl3WWkS1bmUFJHnxbaHmz6/WK4edQCI4VAW5ylBieumwMN5z8ZxZ1miMVDCWXFr+5q JVDWidIyexUhvcd5398Ssump/VREdvzhdSamUDWQ4TnRzEL3LPKz2jQiKWBykE8rVZhh tFoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765298410; x=1765903210; 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=lxe7OVi1sBDoa8IuiFqlloq3b4KfQMN9TPNt/6Lpir4=; b=DJH9Aa6Oy7lhfZzca0vDub/nnC4dKBCBFDIb/zmDD2Bg85qq91zau3pWQ09c3yenR/ U7d+SdABiuaiyPHdlInPtNBPqQJvw6UlWEXluqCYLv1vZf+nzpxuWDTZyYCaG8FAm//Y QzJ+l0FlXVdNiTfZH276QJk4ZT49jZeRkZ0v2EmbENc/oNzwpVE1VP4ceB2V00N63XGF IyZlB6sKW5CWPyMGK/Pv3mCThWTjHgW+scZgj4fDk+j4+n1HJEskaFN/gXitT3pawOm4 AuvsAjnXJ7tl13+a8QAeiujadyqUSz0gKZGY0vzMB0FROnN0d0Al3ZGCAZeTUBjzcZk7 ePEw== X-Gm-Message-State: AOJu0YwwY88SmrU9PsC7xIzL7jJj14b1PvByKu9vg6QyHjXKvRQqUUGd Jewp+mQVjWpHjPkc7IOJMz4uSN7ToK20eViCpP6VBoUjWLnAjMPvlN8s3On5sn0Yf7k= X-Gm-Gg: ASbGncs3WqrvobYsqTfgP0Xk79qwETy7EUfMQ+lGR3wVrwodhdTW1wnJ3AZucEz37zz H1APLbT3RZWDTZlUElInZUK5XU27kRxZZ0Beox5eHmYM93LUx66i7zu37Dj5g+ODy4f3k26yNqN JLZ7hQ6ROi9oPSAy9eQPqVW8uJt/8PYxftl56POrK9KnCpvy2ZA3v9UxGSWWt4aYGKJDY4Z6X5s BiqbU+Bx2/nBOS8BNT9Yrgq40ElGlFLQGRTGbKqirB7gc1jKb0C6WKqa3mLyIZJS4WkwwfbiJ6p dkc9Fd96CqDHD0wiiUkOjy4zdGA/kcaH+BZDq+Tq6Oxjet+56O5mh88zD51AmJyQGS1L/exql1D zdwqUcEgP6mzKf42vVZe46gtbvcDCfWnrXF0noTwPfT445fjc3qdskBjtpVpbbuNUBuguIc7/di RbC7E= X-Google-Smtp-Source: AGHT+IGYIXWSuGwAMUXerelSTdX5QLs3iiG+DDPGfcLInplFcQhfC+W03NhhR8/5raNW5Zr3/9G7Dw== X-Received: by 2002:a05:600c:4743:b0:477:54cd:202e with SMTP id 5b1f17b1804b1-47939deaaaemr105504895e9.2.1765298409598; Tue, 09 Dec 2025 08:40:09 -0800 (PST) Received: from pathway ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42f7cbfeae9sm32868277f8f.13.2025.12.09.08.40.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Dec 2025 08:40:09 -0800 (PST) Date: Tue, 9 Dec 2025 17:40:06 +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: <62f3a734401016a387b59bda8ecd39252a8da849.1764272407.git.chris@chrisdown.name> 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. 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 though about moving printk_delay() into vprintk_store(). But we would need to temporary release IRQs disabled by printk_enter_irqsave(recursion_ptr, irqflags). But then the process might get migrated to another CPU. And the message generated by printk_sprint() need not fit into the reserved space. I personally prefer the alternative solution A. But I am not sure if it is worth it. Best Regards, Petr