[GIT PULL] ring-buffer: Updates for 6.11

[GIT PULL] ring-buffer: Updates for 6.11

[Steven Rostedt]

Linus,

tracing/ring-buffer: Have persistent buffer across reboots

This allows for the tracing instance ring buffer to stay persistent across
reboots. The way this is done is by adding to the kernel command line:

  trace_instance=boot_map@0x285400000:12M

This will reserve 12 megabytes at the address 0x285400000, and then map
the tracing instance "boot_map" ring buffer to that memory. This will
appear as a normal instance in the tracefs system:

  /sys/kernel/tracing/instances/boot_map

A user could enable tracing in that instance, and on reboot or kernel
crash, if the memory is not wiped by the firmware, it will recreate the
trace in that instance. For example, if one was debugging a shutdown of a
kernel reboot:

 # cd /sys/kernel/tracing
 # echo function > instances/boot_map/current_tracer
 # reboot
[..]
 # cd /sys/kernel/tracing
 # tail instances/boot_map/trace
       swapper/0-1       [000] d..1.   164.549800: restore_boot_irq_mode <-native_machine_shutdown
       swapper/0-1       [000] d..1.   164.549801: native_restore_boot_irq_mode <-native_machine_shutdown
       swapper/0-1       [000] d..1.   164.549802: disconnect_bsp_APIC <-native_machine_shutdown
       swapper/0-1       [000] d..1.   164.549811: hpet_disable <-native_machine_shutdown
       swapper/0-1       [000] d..1.   164.549812: iommu_shutdown_noop <-native_machine_restart
       swapper/0-1       [000] d..1.   164.549813: native_machine_emergency_restart <-__do_sys_reboot
       swapper/0-1       [000] d..1.   164.549813: tboot_shutdown <-native_machine_emergency_restart
       swapper/0-1       [000] d..1.   164.549820: acpi_reboot <-native_machine_emergency_restart
       swapper/0-1       [000] d..1.   164.549821: acpi_reset <-acpi_reboot
       swapper/0-1       [000] d..1.   164.549822: acpi_os_write_port <-acpi_reboot

On reboot, the buffer is examined to make sure it is valid. The validation
check even steps through every event to make sure the meta data of the
event is correct. If any test fails, it will simply reset the buffer, and
the buffer will be empty on boot.


Please pull the latest ring-buffer-v6.11 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
ring-buffer-v6.11

Tag SHA1: d3d32acdae295a7eb0600aa878ff33f4fe52460d
Head SHA1: b96c312551b241bc17226c5347c6d6b38a1efd3e


Dan Carpenter (1):
      tracing: Fix NULL vs IS_ERR() check in enable_instances()

Steven Rostedt (Google) (13):
      ring-buffer: Allow mapped field to be set without mapping
      ring-buffer: Add ring_buffer_alloc_range()
      ring-buffer: Add ring_buffer_meta data
      tracing: Implement creating an instance based on a given memory region
      ring-buffer: Add output of ring buffer meta page
      ring-buffer: Add test if range of boot buffer is valid
      ring-buffer: Validate boot range memory events
      tracing: Add option to use memmapped memory for trace boot instance
      ring-buffer: Save text and data locations in mapped meta data
      tracing/ring-buffer: Add last_boot_info file to boot instance
      tracing: Handle old buffer mappings for event strings and functions
      tracing: Update function tracing output for previous boot buffer
      tracing: Add last boot delta offset for stack traces

Thorsten Blum (1):
      ring-buffer: Use vma_pages() helper function

----
 Documentation/admin-guide/kernel-parameters.txt |   9 +
 include/linux/ring_buffer.h                     |  20 +
 kernel/trace/ring_buffer.c                      | 886 +++++++++++++++++++++---
 kernel/trace/trace.c                            | 244 ++++++-
 kernel/trace/trace.h                            |  10 +-
 kernel/trace/trace_output.c                     |  12 +-
 6 files changed, 1061 insertions(+), 120 deletions(-)
---------------------------

Re: [GIT PULL] ring-buffer: Updates for 6.11

[Mathieu Desnoyers]

On 2024-07-16 15:51, Steven Rostedt wrote:
> 
> 
> Linus,
> 
> tracing/ring-buffer: Have persistent buffer across reboots

Hi Steven,

Perhaps I'm missing something here, but we discussed previously that
you would document the fact that users of this feature are expected
to run the same kernel before/after reboot.

Looking at this PR, I fail to find that documentation, or in fact
any documentation at all. Is this something that was overlooked ?

Thanks,

Mathieu

> 
> This allows for the tracing instance ring buffer to stay persistent across
> reboots. The way this is done is by adding to the kernel command line:
> 
>    trace_instance=boot_map@0x285400000:12M
> 
> This will reserve 12 megabytes at the address 0x285400000, and then map
> the tracing instance "boot_map" ring buffer to that memory. This will
> appear as a normal instance in the tracefs system:
> 
>    /sys/kernel/tracing/instances/boot_map
> 
> A user could enable tracing in that instance, and on reboot or kernel
> crash, if the memory is not wiped by the firmware, it will recreate the
> trace in that instance. For example, if one was debugging a shutdown of a
> kernel reboot:
> 
>   # cd /sys/kernel/tracing
>   # echo function > instances/boot_map/current_tracer
>   # reboot
> [..]
>   # cd /sys/kernel/tracing
>   # tail instances/boot_map/trace
>         swapper/0-1       [000] d..1.   164.549800: restore_boot_irq_mode <-native_machine_shutdown
>         swapper/0-1       [000] d..1.   164.549801: native_restore_boot_irq_mode <-native_machine_shutdown
>         swapper/0-1       [000] d..1.   164.549802: disconnect_bsp_APIC <-native_machine_shutdown
>         swapper/0-1       [000] d..1.   164.549811: hpet_disable <-native_machine_shutdown
>         swapper/0-1       [000] d..1.   164.549812: iommu_shutdown_noop <-native_machine_restart
>         swapper/0-1       [000] d..1.   164.549813: native_machine_emergency_restart <-__do_sys_reboot
>         swapper/0-1       [000] d..1.   164.549813: tboot_shutdown <-native_machine_emergency_restart
>         swapper/0-1       [000] d..1.   164.549820: acpi_reboot <-native_machine_emergency_restart
>         swapper/0-1       [000] d..1.   164.549821: acpi_reset <-acpi_reboot
>         swapper/0-1       [000] d..1.   164.549822: acpi_os_write_port <-acpi_reboot
> 
> On reboot, the buffer is examined to make sure it is valid. The validation
> check even steps through every event to make sure the meta data of the
> event is correct. If any test fails, it will simply reset the buffer, and
> the buffer will be empty on boot.
> 
> 
> Please pull the latest ring-buffer-v6.11 tree, which can be found at:
> 
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
> ring-buffer-v6.11
> 
> Tag SHA1: d3d32acdae295a7eb0600aa878ff33f4fe52460d
> Head SHA1: b96c312551b241bc17226c5347c6d6b38a1efd3e
> 
> 
> Dan Carpenter (1):
>        tracing: Fix NULL vs IS_ERR() check in enable_instances()
> 
> Steven Rostedt (Google) (13):
>        ring-buffer: Allow mapped field to be set without mapping
>        ring-buffer: Add ring_buffer_alloc_range()
>        ring-buffer: Add ring_buffer_meta data
>        tracing: Implement creating an instance based on a given memory region
>        ring-buffer: Add output of ring buffer meta page
>        ring-buffer: Add test if range of boot buffer is valid
>        ring-buffer: Validate boot range memory events
>        tracing: Add option to use memmapped memory for trace boot instance
>        ring-buffer: Save text and data locations in mapped meta data
>        tracing/ring-buffer: Add last_boot_info file to boot instance
>        tracing: Handle old buffer mappings for event strings and functions
>        tracing: Update function tracing output for previous boot buffer
>        tracing: Add last boot delta offset for stack traces
> 
> Thorsten Blum (1):
>        ring-buffer: Use vma_pages() helper function
> 
> ----
>   Documentation/admin-guide/kernel-parameters.txt |   9 +
>   include/linux/ring_buffer.h                     |  20 +
>   kernel/trace/ring_buffer.c                      | 886 +++++++++++++++++++++---
>   kernel/trace/trace.c                            | 244 ++++++-
>   kernel/trace/trace.h                            |  10 +-
>   kernel/trace/trace_output.c                     |  12 +-
>   6 files changed, 1061 insertions(+), 120 deletions(-)
> ---------------------------

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: [GIT PULL] ring-buffer: Updates for 6.11

[Steven Rostedt]

On Tue, 16 Jul 2024 16:05:26 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> On 2024-07-16 15:51, Steven Rostedt wrote:
> > 
> > 
> > Linus,
> > 
> > tracing/ring-buffer: Have persistent buffer across reboots  
> 
> Hi Steven,
> 
> Perhaps I'm missing something here, but we discussed previously that
> you would document the fact that users of this feature are expected
> to run the same kernel before/after reboot.
> 
> Looking at this PR, I fail to find that documentation, or in fact
> any documentation at all. Is this something that was overlooked ?

Hmm, was that for this code, or the one that used the reserved_mem
change, which isn't in this pull request, as it depends on the code
that is going through the mm tree.

Technically it can work with different kernels (I have even done that).
But yeah, it isn't guaranteed to work in such cases. But that is just a
documentation update.

-- Steve

Re: [GIT PULL] ring-buffer: Updates for 6.11

[Mathieu Desnoyers]

On 2024-07-16 16:11, Steven Rostedt wrote:
> On Tue, 16 Jul 2024 16:05:26 -0400
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
>> On 2024-07-16 15:51, Steven Rostedt wrote:
>>>
>>>
>>> Linus,
>>>
>>> tracing/ring-buffer: Have persistent buffer across reboots
>>
>> Hi Steven,
>>
>> Perhaps I'm missing something here, but we discussed previously that
>> you would document the fact that users of this feature are expected
>> to run the same kernel before/after reboot.
>>
>> Looking at this PR, I fail to find that documentation, or in fact
>> any documentation at all. Is this something that was overlooked ?
> 
> Hmm, was that for this code, or the one that used the reserved_mem
> change, which isn't in this pull request, as it depends on the code
> that is going through the mm tree.
> 
> Technically it can work with different kernels (I have even done that).
> But yeah, it isn't guaranteed to work in such cases. But that is just a
> documentation update.

If the documentation just ends up being in a different PR, I have no
objection.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: [GIT PULL] ring-buffer: Updates for 6.11

[Steven Rostedt]

On Tue, 16 Jul 2024 16:05:26 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> On 2024-07-16 15:51, Steven Rostedt wrote:
> > 
> > 
> > Linus,
> > 
> > tracing/ring-buffer: Have persistent buffer across reboots  
> 
> Hi Steven,
> 
> Perhaps I'm missing something here, but we discussed previously that
> you would document the fact that users of this feature are expected
> to run the same kernel before/after reboot.
> 
> Looking at this PR, I fail to find that documentation, or in fact
> any documentation at all. Is this something that was overlooked ?

So I went to update this, and realized there's no place that actually
mentions anything about this being used across reboots (besides in the
change logs). The only documentation is in kernel-parameters.txt:

                        If memory has been reserved (see memmap for x86), the instance
                        can use that memory:
                        
                                memmap=12M$0x284500000 trace_instance=boot_map@0x284500000:12M

                        The above will create a "boot_map" instance that uses the physical
                        memory at 0x284500000 that is 12Megs. The per CPU buffers of that
                        instance will be split up accordingly.

I do plan on adding more documentation on the use cases of this, but I
was planning on doing that in the next merge window when the
reserve_mem kernel parameter can be used. Right now, we only document
what it does, and not what it is used for.

Do you still have an issue with that part missing? No where does it
mention that this is used across boots. There is a file created in the
boot mapped instance directory that hints to the usage
(last_boot_info), but still there's no assumptions made.

In other words, why document a restriction on something that hasn't
been documented?

-- Steve

Re: [GIT PULL] ring-buffer: Updates for 6.11

[Mathieu Desnoyers]

On 2024-07-19 10:32, Steven Rostedt wrote:
> On Tue, 16 Jul 2024 16:05:26 -0400
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
>> On 2024-07-16 15:51, Steven Rostedt wrote:
>>>
>>>
>>> Linus,
>>>
>>> tracing/ring-buffer: Have persistent buffer across reboots
>>
>> Hi Steven,
>>
>> Perhaps I'm missing something here, but we discussed previously that
>> you would document the fact that users of this feature are expected
>> to run the same kernel before/after reboot.
>>
>> Looking at this PR, I fail to find that documentation, or in fact
>> any documentation at all. Is this something that was overlooked ?
> 
> So I went to update this, and realized there's no place that actually
> mentions anything about this being used across reboots (besides in the
> change logs). The only documentation is in kernel-parameters.txt:
> 
>                          If memory has been reserved (see memmap for x86), the instance
>                          can use that memory:
>                          
>                                  memmap=12M$0x284500000 trace_instance=boot_map@0x284500000:12M
> 
>                          The above will create a "boot_map" instance that uses the physical
>                          memory at 0x284500000 that is 12Megs. The per CPU buffers of that
>                          instance will be split up accordingly.
> 
> I do plan on adding more documentation on the use cases of this, but I
> was planning on doing that in the next merge window when the
> reserve_mem kernel parameter can be used. Right now, we only document
> what it does, and not what it is used for.
> 
> Do you still have an issue with that part missing? No where does it
> mention that this is used across boots. There is a file created in the
> boot mapped instance directory that hints to the usage
> (last_boot_info), but still there's no assumptions made.
> 
> In other words, why document a restriction on something that hasn't
> been documented?

AFAIU the intended use of this feature is to convey trace buffer
data from one kernel to the next across a reboot, which makes it
a whole different/new kind of ABI.

Having no documentation will not stop anyone from using this new
feature and make assumptions about ABI guarantees. I am concerned
that this ABI ends up being defined by accident/misuses rather than
by design if it is merged without documentation.

Very often when I find myself documenting a feature, I look back at
the user-facing result and modify the ABI where it does not make
sense. Merging this ABI without documentation prevents that.

So if you ask my honest opinion there, I would say that merging this
ABI without documentation feels rushed.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: [GIT PULL] ring-buffer: Updates for 6.11

[Steven Rostedt]

On Fri, 19 Jul 2024 10:59:37 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> > So I went to update this, and realized there's no place that actually
> > mentions anything about this being used across reboots (besides in the
> > change logs). The only documentation is in kernel-parameters.txt:
> > 
> >                          If memory has been reserved (see memmap for x86), the instance
> >                          can use that memory:
> >                          
> >                                  memmap=12M$0x284500000 trace_instance=boot_map@0x284500000:12M
> > 
> >                          The above will create a "boot_map" instance that uses the physical
> >                          memory at 0x284500000 that is 12Megs. The per CPU buffers of that
> >                          instance will be split up accordingly.
> > 
> > I do plan on adding more documentation on the use cases of this, but I
> > was planning on doing that in the next merge window when the
> > reserve_mem kernel parameter can be used. Right now, we only document
> > what it does, and not what it is used for.
> > 
> > Do you still have an issue with that part missing? No where does it
> > mention that this is used across boots. There is a file created in the
> > boot mapped instance directory that hints to the usage
> > (last_boot_info), but still there's no assumptions made.
> > 
> > In other words, why document a restriction on something that hasn't
> > been documented?  
> 
> AFAIU the intended use of this feature is to convey trace buffer
> data from one kernel to the next across a reboot, which makes it
> a whole different/new kind of ABI.

That may be my intention, but there's nothing here to imply that. In
fact, after I read the document, it looks to me as a way to simply
designate a location of address space for the ring buffer. This could
be because of some special hardware. Nothing here says "exists on
reboot". Thinking that this implies that the ring buffer will last
across boots is not going to make it a new API. In fact, in my test
cases, it fails (due to KASLR) approximately once every 5 boots. So
it's not something you can even rely on.

> 
> Having no documentation will not stop anyone from using this new
> feature and make assumptions about ABI guarantees. I am concerned
> that this ABI ends up being defined by accident/misuses rather than
> by design if it is merged without documentation.

This is not an ABI. Remember, Linus's mandate is to "not break user
space". There's no use space involved here.

> 
> Very often when I find myself documenting a feature, I look back at
> the user-facing result and modify the ABI where it does not make
> sense. Merging this ABI without documentation prevents that.

Again, this isn't a "user facing feature", where I consider "user"
being user space.

> 
> So if you ask my honest opinion there, I would say that merging this
> ABI without documentation feels rushed.

It's not an ABI (Application Binary Interface). What's the application?
What's the binary interface? It's a kernel command line telling the
kernel to place the ring buffer at some specific address space. Nothing
more.

-- Steve

Re: [GIT PULL] ring-buffer: Updates for 6.11

[Mathieu Desnoyers]

On 2024-07-19 12:19, Steven Rostedt wrote:
> On Fri, 19 Jul 2024 10:59:37 -0400
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
>>> So I went to update this, and realized there's no place that actually
>>> mentions anything about this being used across reboots (besides in the
>>> change logs). The only documentation is in kernel-parameters.txt:
>>>
>>>                           If memory has been reserved (see memmap for x86), the instance
>>>                           can use that memory:
>>>                           
>>>                                   memmap=12M$0x284500000 trace_instance=boot_map@0x284500000:12M
>>>
>>>                           The above will create a "boot_map" instance that uses the physical
>>>                           memory at 0x284500000 that is 12Megs. The per CPU buffers of that
>>>                           instance will be split up accordingly.
>>>
>>> I do plan on adding more documentation on the use cases of this, but I
>>> was planning on doing that in the next merge window when the
>>> reserve_mem kernel parameter can be used. Right now, we only document
>>> what it does, and not what it is used for.
>>>
>>> Do you still have an issue with that part missing? No where does it
>>> mention that this is used across boots. There is a file created in the
>>> boot mapped instance directory that hints to the usage
>>> (last_boot_info), but still there's no assumptions made.
>>>
>>> In other words, why document a restriction on something that hasn't
>>> been documented?
>>
>> AFAIU the intended use of this feature is to convey trace buffer
>> data from one kernel to the next across a reboot, which makes it
>> a whole different/new kind of ABI.
> 
> That may be my intention, but there's nothing here to imply that. In
> fact, after I read the document, it looks to me as a way to simply
> designate a location of address space for the ring buffer. This could
> be because of some special hardware. Nothing here says "exists on
> reboot". Thinking that this implies that the ring buffer will last
> across boots is not going to make it a new API. In fact, in my test
> cases, it fails (due to KASLR) approximately once every 5 boots. So
> it's not something you can even rely on.

Then the commit message is misrepresenting the usefulness of the
feature. What is the use-case for specifying the location of the
ring buffer address space in physical memory beyond re-accessing
it after reboot ? What is that special hardware you are referring
to ?

> 
>>
>> Having no documentation will not stop anyone from using this new
>> feature and make assumptions about ABI guarantees. I am concerned
>> that this ABI ends up being defined by accident/misuses rather than
>> by design if it is merged without documentation.
> 
> This is not an ABI. Remember, Linus's mandate is to "not break user
> space". There's no use space involved here.

I should have used filesystem terminology here rather than ABI. This
ring buffer memory area is similar to a filesystem on-disk format,
because it needs to be agreed upon by two distinct kernel instances.

I'm pretty sure there are inherent expectations about not breaking
file systems.

IMHO it makes it even more important to clearly document the guarantees
given about it or lack thereof.

> 
>>
>> Very often when I find myself documenting a feature, I look back at
>> the user-facing result and modify the ABI where it does not make
>> sense. Merging this ABI without documentation prevents that.
> 
> Again, this isn't a "user facing feature", where I consider "user"
> being user space.

You are right, it's not about userspace. It is about the in-memory
equivalent of an on-disk format, and it should be documented.

> 
>>
>> So if you ask my honest opinion there, I would say that merging this
>> ABI without documentation feels rushed.
> 
> It's not an ABI (Application Binary Interface). What's the application?
> What's the binary interface?

No argument there, it's not about userspace applications. It's the
in-memory equivalent of an "on-disk format".

> It's a kernel command line telling the
> kernel to place the ring buffer at some specific address space. Nothing
> more.

The whole justification for adding this feature *is* keeping a ring
buffer around across kernel reboots. If it's just a way to let the
kernel specify where to place the ring buffer in memory, then what
is the use-case justifying its integration ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: [GIT PULL] ring-buffer: Updates for 6.11

[Steven Rostedt]

On Fri, 19 Jul 2024 14:05:39 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> The whole justification for adding this feature *is* keeping a ring
> buffer around across kernel reboots. If it's just a way to let the
> kernel specify where to place the ring buffer in memory, then what
> is the use-case justifying its integration ?

Yes, but this is broken up into two parts. With this release you have to
know the memory layout and add it explicitly per machine. This takes
quite a bit of knowledge to get right and that's for every individual
system. It's not going to happen for some general application. You have
to know your memory layout and adding this is an advanced operation.
If you are doing this, you should already know what to expect.

When I add the: reserver_mem=12M:4096:trace trace_instance=bootmap@trace
which will allow for a much more generic operation, then yes. I'll be
adding a bunch more documentation and will add the limitations of this.
But that's for the next merge window. This merge window was just to get
the functionality there and a way to test it. But honestly, the
hardcoding of the address is already a high bar and one that even I can
only use on my own machines (that's not going out to chromebooks). For
the more broader audience, I need the reserver_mem option available.
And then I agree that people need to know the limitations of that, as
that *is* a generic operation that can go out into the field.

For now, this is just the infrastructure with a very specific way to
even use it (you need to know the layout of your individual machines).
I don't want to add documentation about rebooting yet, because then the
next merge window is just going to rewrite it.

-- Steve

Re: [GIT PULL] ring-buffer: Updates for 6.11

[Steven Rostedt]

Hi Linus,

I just noticed that this wasn't pulled. Was there an issue with it?

-- Steve


On Tue, 16 Jul 2024 15:51:18 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> Linus,
> 
> tracing/ring-buffer: Have persistent buffer across reboots
> 
> This allows for the tracing instance ring buffer to stay persistent across
> reboots. The way this is done is by adding to the kernel command line:
> 
>   trace_instance=boot_map@0x285400000:12M
> 
> This will reserve 12 megabytes at the address 0x285400000, and then map
> the tracing instance "boot_map" ring buffer to that memory. This will
> appear as a normal instance in the tracefs system:
> 
>   /sys/kernel/tracing/instances/boot_map
> 
> A user could enable tracing in that instance, and on reboot or kernel
> crash, if the memory is not wiped by the firmware, it will recreate the
> trace in that instance. For example, if one was debugging a shutdown of a
> kernel reboot:
> 
>  # cd /sys/kernel/tracing
>  # echo function > instances/boot_map/current_tracer
>  # reboot
> [..]
>  # cd /sys/kernel/tracing
>  # tail instances/boot_map/trace
>        swapper/0-1       [000] d..1.   164.549800: restore_boot_irq_mode <-native_machine_shutdown
>        swapper/0-1       [000] d..1.   164.549801: native_restore_boot_irq_mode <-native_machine_shutdown
>        swapper/0-1       [000] d..1.   164.549802: disconnect_bsp_APIC <-native_machine_shutdown
>        swapper/0-1       [000] d..1.   164.549811: hpet_disable <-native_machine_shutdown
>        swapper/0-1       [000] d..1.   164.549812: iommu_shutdown_noop <-native_machine_restart
>        swapper/0-1       [000] d..1.   164.549813: native_machine_emergency_restart <-__do_sys_reboot
>        swapper/0-1       [000] d..1.   164.549813: tboot_shutdown <-native_machine_emergency_restart
>        swapper/0-1       [000] d..1.   164.549820: acpi_reboot <-native_machine_emergency_restart
>        swapper/0-1       [000] d..1.   164.549821: acpi_reset <-acpi_reboot
>        swapper/0-1       [000] d..1.   164.549822: acpi_os_write_port <-acpi_reboot
> 
> On reboot, the buffer is examined to make sure it is valid. The validation
> check even steps through every event to make sure the meta data of the
> event is correct. If any test fails, it will simply reset the buffer, and
> the buffer will be empty on boot.
> 
> 
> Please pull the latest ring-buffer-v6.11 tree, which can be found at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
> ring-buffer-v6.11
> 
> Tag SHA1: d3d32acdae295a7eb0600aa878ff33f4fe52460d
> Head SHA1: b96c312551b241bc17226c5347c6d6b38a1efd3e
> 
> 
> Dan Carpenter (1):
>       tracing: Fix NULL vs IS_ERR() check in enable_instances()
> 
> Steven Rostedt (Google) (13):
>       ring-buffer: Allow mapped field to be set without mapping
>       ring-buffer: Add ring_buffer_alloc_range()
>       ring-buffer: Add ring_buffer_meta data
>       tracing: Implement creating an instance based on a given memory region
>       ring-buffer: Add output of ring buffer meta page
>       ring-buffer: Add test if range of boot buffer is valid
>       ring-buffer: Validate boot range memory events
>       tracing: Add option to use memmapped memory for trace boot instance
>       ring-buffer: Save text and data locations in mapped meta data
>       tracing/ring-buffer: Add last_boot_info file to boot instance
>       tracing: Handle old buffer mappings for event strings and functions
>       tracing: Update function tracing output for previous boot buffer
>       tracing: Add last boot delta offset for stack traces
> 
> Thorsten Blum (1):
>       ring-buffer: Use vma_pages() helper function
> 
> ----
>  Documentation/admin-guide/kernel-parameters.txt |   9 +
>  include/linux/ring_buffer.h                     |  20 +
>  kernel/trace/ring_buffer.c                      | 886 +++++++++++++++++++++---
>  kernel/trace/trace.c                            | 244 ++++++-
>  kernel/trace/trace.h                            |  10 +-
>  kernel/trace/trace_output.c                     |  12 +-
>  6 files changed, 1061 insertions(+), 120 deletions(-)
> ---------------------------