Re: [GIT PULL] ring-buffer: Updates for v6.15

[Steven Rostedt]

On Thu, 27 Mar 2025 19:17:34 -0700
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> Anyway, I'm not arguing any more. I'm telling you that this code will
> 
>  (a) not be pulled this merge window
> 
>  (b) not be pulled EVER unless you clean it up
> 
>  (c) you need to stop with this hackery

This entire debate was on the very first commit that allowed the persistent
ring buffer to be memory mapped by user space, which introduced the:

	if (virt_addr_valid((void *)cpu_buffer->subbuf_ids[s]))
		page = virt_to_page((void *)cpu_buffer->subbuf_ids[s]);
	else
		page = vmalloc_to_page((void *)cpu_buffer->subbuf_ids[s]);

"hack" that you hate.

This commit was the first thing added as I wrote it right after fixing the
issue that caused it to crash when user space tried to map it. I basically
fixed it and forgot about it (which is why there were 5 instances of that
code, where I did plan on at least wrapping it, but forgot).

Most of the work was Masami's saving the module addresses in the persistent
ring buffer so that it can be retrieved after a crash. That code is totally
unrelated to this.

I just did a rebase removing this commit and one commit that fixed not
adding a typecast of a long to a pointer in virt_addr_valid() (yes, my
pseudo code had the same bug with the virt_to_page() but I didn't compile
it, I actually wrote that directly in the email).

No other commit depends on this commit. Are you fine with the rest of the
pull request? I can start running it through my tests without these changes.

-- Steve