On June 13, 2024 7:06:47 AM PDT, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: >On Thu, 13 Jun 2024 at 15:26, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: >> >> On Thu, 13 Jun 2024 08:11:48 +0200 >> Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: >> > > >> > > I've added one more comment to v5, with that fixed I can take this. >> > > >> > >> > So how is this supposed to work wrt to the rigid 'no user visible >> > regressions' rule, given that this whole thing is a best effort thing >> >> This has nothing to do with user space. The kernel command line has >> broken in the past. If you update the kernel, you can update the >> command line. There's no "no user visible regressions" rule. It's >> "Don't break user space". This has nothing to do with user space. >> >> > to begin with. This needs at least a huge disclaimer that this rule >> > does not apply, and if this works today, there is no guarantee that it >> > will keep working on newer kernels. Otherwise, you will be making the >> > job of the people who work on the boot code significantly more >> > difficult. And even then, I wonder whether Linus and #regzcop are >> > going to honour such a disclaimer. >> >> Again, this has nothing to do with user space. The rule Linus talks >> about is breaking user space. This is about kernel debugging. Something >> *completely different*! >> >> > >> > So this belongs downstream, unless some guarantees can be provided >> > that this functionality is exempt from the usual regression policies. >> >> I disagree. kexec/kdump also has the same issues. >> > >Fair enough. As long as it is documented that there is no guarantee >that this will keep working over a kernel upgrade, then I have no >objections. Yeah, I should better document this for pstore as a whole, but I've already made the call that cross-kernel-versison operation is best effort. -Kees -- Kees Cook
