From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 59E9F2B9BA for ; Sun, 22 Feb 2026 19:25:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771788353; cv=none; b=gfunff8vAx9AcblcHPkHB0scLkH6uNrB5HPgvvRPhZ47sfV6c5mNPcJReGKSwt4yd1vVBCTVtHHVshhJuOo8IN2llCk7DL5fKiupcHS4El5V/em22DCF7oEZTOYk66gIlg1/bvpb2dW+vN5tEGAwKPfv4E3wSrQJMJkOfpLmZdE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771788353; c=relaxed/simple; bh=jRhvwYKLengz3nCiqXT4TEGm0S1wji0U6PJpKz3CsWc=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=gTWQP2NOLroD4lp6gYWJrZM/Kc1jvJG3QhPpYKwQweTilVtVHO9e9t+coOdxBJLwfsP52q9OHPbqCj/7h6ayeq27I6DLU03/FeeQbzvSlU6az77UeGcbe277mgci2M1s3C2YJqv1TRqCRM3Wfu0HNdWK5iJ5aom5EH3dhmw7Cys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=qWIhmvFg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="qWIhmvFg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DEC5C116D0; Sun, 22 Feb 2026 19:25:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1771788352; bh=jRhvwYKLengz3nCiqXT4TEGm0S1wji0U6PJpKz3CsWc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qWIhmvFgRmug/Do2GehzxHAQd0F41tzNhSNB5XC99NhWeXs58/qC0oj+iym475hqu o+k3ij3O7GLzHbLtduRNplWvUPXw8vb3Y70IoPYtSIT3fnFSXxPngyDTTBkzbqWLAj 57X9QMTDwQj2ewThvxpiYqKVmnyKOV4kezW15FeQ= Date: Sun, 22 Feb 2026 11:25:52 -0800 From: Andrew Morton To: Rio Cc: feng.tang@linux.alibaba.com, joel.granados@kernel.org, linux-kernel@vger.kernel.org, pmladek@suse.com, pnina.feder@mobileye.com, wangjinchao600@gmail.com Subject: Re: [PATCHv2] kernel/panic: allocate taint string buffer dynamically Message-Id: <20260222112552.c28915733dff5ad01ac3c2fc@linux-foundation.org> In-Reply-To: <20260222140804.22225-1-rioo.tsukatsukii@gmail.com> References: <20260220151500.13585-1-rioo.tsukatsukii@gmail.com> <20260222140804.22225-1-rioo.tsukatsukii@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Sun, 22 Feb 2026 19:38:04 +0530 Rio wrote: > The buffer used to hold the taint string is statically allocated, which > requires updating whenever a new taint flag is added. > > Instead, allocate the exact required length at boot once the allocator is > available in an init function. The allocation sums the string lengths in > taint_flags[], along with space for separators and formatting. > print_tainted() is switched to use this dynamically allocated buffer. > > If allocation fails, print_tainted() warns about the failure and continues > to use the original static buffer as a fallback. > Lovely, thanks. > > --- a/kernel/panic.c > +++ b/kernel/panic.c > @@ -802,7 +802,7 @@ EXPORT_SYMBOL(panic); > * small shell script that prints the TAINT_FLAGS_COUNT bits of > * /proc/sys/kernel/tainted. > * > - * Also, update TAINT_BUF_MAX below. > + * Also, update INIT_TAINT_BUF_MAX below. > */ > const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = { > TAINT_FLAG(PROPRIETARY_MODULE, 'P', 'G'), > @@ -856,17 +856,58 @@ static void print_tainted_seq(struct seq_buf *s, bool verbose) > } > } > > -/* 350 can accommodate all taint flags in verbose mode, with some headroom */ > -#define TAINT_BUF_MAX 350 > +/* The initial buffer can accommodate all taint flags in verbose > + * mode, with some headroom. Once the allocator is available, the > + * exact size is allocated dynamically; the initial buffer remains > + * as a fallback if allocation fails. > + * > + * The verbose taint string currently requires up to 327 characters. > + */ > +#define INIT_TAINT_BUF_MAX 350 > + > +static char init_taint_buf[INIT_TAINT_BUF_MAX]; OK, this cannot be __initdata because > +static char *taint_buf = init_taint_buf; > +static size_t taint_buf_size = INIT_TAINT_BUF_MAX; > + > +static __init int alloc_taint_buf(void) > +{ > + int i; > + char *buf; > + size_t size = 0; > + > + size += sizeof("Tainted: ") - 1; > + for (i = 0; i < TAINT_FLAGS_COUNT; i++) { > + size += 2; /* For ", " */ > + size += 4; /* For "[%c]=" */ > + size += strlen(taint_flags[i].desc); > + } > + > + size += 1; /* For NULL terminator */ > + > + buf = kmalloc(size, GFP_KERNEL); > + > + if (!buf) { > + /* Allocation may fail; this warning explains possibly > + * truncated taint strings > + */ > + pr_warn_once("taint string buffer allocation failed, using fallback buffer\n"); > + return 0; We may end up using it after boot time. > + } > + > + taint_buf = buf; > + taint_buf_size = size; > + > + return 0; > +} > +postcore_initcall(alloc_taint_buf); However there's a convention of assuming that __init-time allocations cannot fail. Because if a kmalloc() were to fail at this time, the kernel is hopelessly messed up anyway. So we could simply panic() if that kmalloc failed, then make that 350-byte buffer __initdata. That saves about $100 per machine with current DRAM prices ;)