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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <886acd97-e837-4bff-a8e2-26638525cab5@efficios.com>
Date: Tue, 16 Jul 2024 16:28:06 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 LKML <linux-kernel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>,
 Dan Carpenter <dan.carpenter@...aro.org>,
 Thorsten Blum <thorsten.blum@...lux.com>
Subject: Re: [GIT PULL] ring-buffer: Updates for 6.11

On 2024-07-16 16:11, Steven Rostedt wrote:
> On Tue, 16 Jul 2024 16:05:26 -0400
> Mathieu Desnoyers <mathieu.desnoyers@...icios.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