Re: [PATCH v1 2/2] ring-buffer: Unify ring buffer minimum page calculations

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] A hardcoded minimum page limit was missed during refactoring in trace_rb_cpu_prepare().
--

commit 699b707360c7ac89e4a8f2b996c220e5cb22ea93
Author: Vincent Donnefort <vdonnefort@google.com>

ring-buffer: Unify ring buffer minimum page calculations

The commit introduces the RING_BUFFER_MIN_NR_PAGES macro to formalize the
requirement of having at least two pages in a ring buffer. It updates multiple
sites across the codebase to use this new unified calculation instead of
scattered hardcoded values.

> diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
> index 7a1a92f876503..a9401b8ebc721 100644
> --- a/include/linux/ring_buffer.h
> +++ b/include/linux/ring_buffer.h
> @@ -99,6 +99,13 @@ struct trace_buffer *__ring_buffer_alloc_range(unsigned long size, unsigned flag
>  
>  void *ring_buffer_meta_scratch(struct trace_buffer *buffer, unsigned int *size);
>  
> +/*
> + * A minimum of 2 pages ensures we can always swap a page out of the ring
> + * buffer. This does not account for the reader page or any other page
> + * containing meta data used by static ring buffers.
> + */
> +#define RING_BUFFER_MIN_NR_PAGES 2UL
> +

[Severity: Low]
Was a hardcoded minimum page limit missed during this refactoring?

Looking at kernel/trace/ring_buffer.c:trace_rb_cpu_prepare(), when a newly
hotplugged CPU is brought online and detects varying subbuffer sizes across
existing CPUs (!nr_pages_same), it still uses a hardcoded fallback limit:

kernel/trace/ring_buffer.c:trace_rb_cpu_prepare() {
    ...
	/* allocate minimum pages, user can later expand it */
	if (!nr_pages_same)
		nr_pages = 2;
    ...
}

Should this fallback allocation use the newly introduced
RING_BUFFER_MIN_NR_PAGES macro instead to avoid a maintenance hazard if the
minimum requirement changes in the future?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907192643.42513-1-vdonnefort@google.com?part=2