From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 1C9A535DA55 for ; Thu, 19 Mar 2026 09:26:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773912419; cv=none; b=Z+Wo4sbLnb8duYRUzdFend0H9rk75jbz3NLWSd2P/7f33S1AeofXtslR4pshhKvbdo5KoX8/k4qimVublRnu8GsdqZbWC9On9AjoQBu8x9ajUzr1FQoB2JkNWio0GBfnlArfjb7AY7TfAGlgpjj9IcefsyneTXZvaQ9McvAeleQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773912419; c=relaxed/simple; bh=6jVKirYmGrKYQMPSeIoxtjtPffyLAJa5u4HlSr1oyqI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tyf2CuQOAqhcLpr2WQn4xAWT14s0B5yJu5NJgAVV9MAOikAXw2YI5q1Kw4gHrcudRdzC/gk3o2efV6dxuPALn9cmmUwZhD3kO0yN8j0IhDfF2CucBmv9CXREOHu+Gb/DdhxL2Dj0iYqNwK7ab4FIHttVDeQH2ehhU6U02c1TBlg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=uGclf/kX; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="uGclf/kX" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4852b81c73aso6218765e9.3 for ; Thu, 19 Mar 2026 02:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1773912416; x=1774517216; 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=Xhh2W7ZRDnedQ3ezldSQErfD/pHbhtH5vOkIkKKOL30=; b=uGclf/kXTzutUAbkDHqQJjtS2Ik1pXrzY+Il4/BokAVN93uiXOTx8Fhutzf4E8yMP+ b35FP61rmIwEKMjq81iG/nHEz9PQkkkpC5qH5deQkqVsEwwxxlRcpv0duQaLytOaEPPc QsduYjU6DMu3UMptLvGdOmRF/OFWDJEaSKZaLlaX5i9XqsJAL955L9XUhoUTOs0dLfRZ 1u0TR/3RUDa0Uohmf1Jd7pAjYCxu6dTZON755e7rzGz00M9BY3xB2NDSejFHfnSwyUke mG5AEoXvfLF5tH+PGk1MdINbAPp9NjRW+tGC+dA9y93hJxSuBADBUBtEcMQvEpqSZR0/ B7oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773912416; x=1774517216; 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=Xhh2W7ZRDnedQ3ezldSQErfD/pHbhtH5vOkIkKKOL30=; b=MSOB0FAFwDyw2vQKV+E7D+RTV2LiAvVbTC4OUeJaougbhach/qLTAwB7MpO5vhtYY4 s/f418Uu1KXB4tjkiPDTDoqab4Q7oyWbEJzi0C7ZvSI+q1Nl9+GUZKN30PSUeVTkZMK5 nDAgRXTtGchzVjANLG/+eZQZwOkWxUDf4FwsB1WF56P+Vqf3bWxq6zbro5fnPndf1EWO BmfdC2xNT7YkU/6BDbjWhJGHoR0cKMjrL5hRHxDVGRmAON8BoNK4caMgJqsUgYurAalb q6EfvlrMdwo5atOflhbWYE5XOsF+CjvjWTd1iDtLAUpYTojq+drWJEUiD2hTKgdEjviW rhDg== X-Forwarded-Encrypted: i=1; AJvYcCWBsod+2D2OrJCQHIBe9+Ti6G4Gs7Lv9JMYxoBUK220JZALd2gusZdbs4z4U/JoSenaKkzR/5yUe7jM50A=@vger.kernel.org X-Gm-Message-State: AOJu0YwRSU+lGR2uwpPJh0e/0DGA3Czxfnz3rnja4eqUR7ssm2qyY+NL IvjERFCr/qLsrBdhB0wo5GWU9eEp014AW/gmjzX91TZYsus61jxYlmTSCeNKHfGfIA== X-Gm-Gg: ATEYQzz6R9AG4Uvgj+Nw6DoPd8Bt8ow2cPF/ptA54RcqXN4KfRllPMt9EbvwVcTYM3u 6DE7uytlo+ZdJJikdTqGX6a8wZcp1YQ53VR5K3ISAzhgbf35h1Nn0sw0t4UviaHcChrWiOGI3GH liBHFLPyc5wiVrvkOVILTdZMMGrVH2+0S+rHAQ4Q1c1MgsVqtjmzU+zeojpTk1qM2ePEIoo0th2 QNe0aCQopMkoY/HeuElY3wq7Xhvam0WSPcfc21fRpfRKCLXtMKD+u7RHDV499u5FfHwOuEz72Y5 NtcObt5zNizzlhvqzjdAcG4ZGMfBdy/Sf8Hw+BLjCW3BA6M04fu1W4xRmZUfw+VHK3XfbgNpOz0 aFzSxNeM1Fi4rtq+2aDDxktKMeTDcE04padwuOkh1QY2VnB0ecjdfqYEbw8264Pt7JKQMtV7ZDT xu2STCJJ1zfhB3wRkfQ9D0GRit4zVda3W6TICuSGLUHAskM3u02YpcbyVL/05tNgb8HYU= X-Received: by 2002:a05:600c:45d2:b0:485:ae14:8191 with SMTP id 5b1f17b1804b1-486f441bad8mr106718325e9.5.1773912415817; Thu, 19 Mar 2026 02:26:55 -0700 (PDT) Received: from google.com (198.115.140.34.bc.googleusercontent.com. [34.140.115.198]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486f8b949a5sm51412145e9.11.2026.03.19.02.26.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Mar 2026 02:26:55 -0700 (PDT) Date: Thu, 19 Mar 2026 09:26:52 +0000 From: Vincent Donnefort To: Steven Rostedt Cc: David Carlier , Masami Hiramatsu , Mathieu Desnoyers , linux-kernel@vger.kernel.org, maz@kernel.org Subject: Re: [PATCH] tracing: Fix nr_subbufs initialization in simple_ring_buffer_init_mm() Message-ID: References: <20260318171907.19640-1-devnexen@gmail.com> <20260318152804.26a8d6be@gandalf.local.home> 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: <20260318152804.26a8d6be@gandalf.local.home> On Wed, Mar 18, 2026 at 03:28:04PM -0400, Steven Rostedt wrote: > On Wed, 18 Mar 2026 17:19:07 +0000 > David Carlier wrote: > > > In simple_ring_buffer_init_mm(), meta->nr_subbufs is assigned from > > cpu_buffer->nr_pages at line 398, but cpu_buffer was just zeroed by > > memset() at line 390. The actual page count is only computed later in > > the loop (lines 410-429), so nr_subbufs is always set to 0. > > Did you use an AI agent to discover this? If so, you need to disclose that. > (AI agents are typically the only one that uses line numbers to describe > problems like this) > > > > > This field is part of struct trace_buffer_meta (UAPI), exposed to > > consumers who rely on it for buffer geometry calculations (e.g., > > data_len = subbuf_size * nr_subbufs). A value of 0 breaks ring buffer > > consumption entirely. > > > > Fix by using desc->nr_page_va directly, which holds the correct total > > page count (reader + ring pages) and is available at this point. This > > matches the UAPI documentation: "Number of subbufs in the ring-buffer, > > including the reader." > > As this will likely be pulled into mainline via the ARM64 tree, and they > are currently the only ones actually using this code, this should go > through them. > > -- Steve > I don't think it is fixing anything at the moment. It sets nr_subbufs for the sack of completing the meta_page but this field isn't read by the kernel. It doesn't need it because the reader is using the ring_buffer_desc. Nonetheless it's probably worth to fix now, that will be less work if later we e.g. allow remotes to be mapped by userspace. (Not something I have on my todo list). > > > > > Fixes: 34e5b958bdad ("tracing: Introduce simple_ring_buffer") > > Signed-off-by: David Carlier > > --- > > kernel/trace/simple_ring_buffer.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/trace/simple_ring_buffer.c b/kernel/trace/simple_ring_buffer.c > > index 02af2297ae5a..e991a0d8def2 100644 > > --- a/kernel/trace/simple_ring_buffer.c > > +++ b/kernel/trace/simple_ring_buffer.c > > @@ -395,7 +395,7 @@ int simple_ring_buffer_init_mm(struct simple_rb_per_cpu *cpu_buffer, > > > > memset(cpu_buffer->meta, 0, sizeof(*cpu_buffer->meta)); > > cpu_buffer->meta->meta_page_size = PAGE_SIZE; > > - cpu_buffer->meta->nr_subbufs = cpu_buffer->nr_pages; > > + cpu_buffer->meta->nr_subbufs = desc->nr_page_va; I would just move this assignment later to make sure cpu_buffer->nr_pages is aligned with the meta page, instead of relying on the ring_buffer_desc. > > > > /* The reader page is not part of the ring initially */ > > page = load_page(desc->page_va[0]); >