On Sat, 15 Feb 2025 11:45:40 -0500 Steven Rostedt <[email protected]> wrote:
> On Sat, 15 Feb 2025 11:21:53 -0500 > Steven Rostedt <[email protected]> wrote: > > > On Sun, 16 Feb 2025 00:37:02 +0900 > > Masami Hiramatsu (Google) <[email protected]> wrote: > > > > > My concern is related to the fixes policy. If this is a "fix", we will > > > backport the new "disables mmap on persistent ring buffer" limitation > > > to the stable kernel (that was not documented previously.) > > > > > > However, from the user point of view, "mmap() ring buffers" is already > > > supported (although it did not work on stable kernel for now). Thus I > > > think > > > the "Fix" is expected as "fixing mmap() persistent ring buffer". > > > > This only disables mmapping of the persistent ring buffer. Other ring > > buffers can be mapped. We never supported mmapping the persistent ring > > buffer. Even in stable kernels, if you mmap it, it will crash just like > > it does now. Thus, this doesn't cause any regressions. It's a fix even > > for stable kernels. > > > > Or did the virt_to_page() change recently where that wasn't the case? > > > > Although the fixes tag is wrong. As the persistent ring buffer didn't > even exist then. It should be: > > Fixes: 9b7bdf6f6ece6 ("tracing: Have trace_printk not use binary prints if > boot buffer") > > As that's what added the BOOT flag and is in the same kernel version > that added the persistent ring buffer. OK, so this fix is for the limitation of the buffer which has TRACE_ARRAY_FL_BOOT. When this flag is introduced, it should also prohibit the mmap. Thank you, > > -- Steve -- Masami Hiramatsu (Google) <[email protected]>
