Received-SPF: pass (google.com: domain of linux-kernel+bounces-213397-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240611144911.327227285@goodmis.org> <20240611144949.703297941@goodmis.org>
 <202406121145.8860502D7@keescook> <20240612145228.5bf426e0@rorschach.local.home>
 <ZmqLejL1mblOikLp@kernel.org> <CAMj1kXHLSROujjc_OifzVmuAd7BpA+b4D2JrPGLJJYj2au7SfQ@mail.gmail.com>
 <20240613092642.385461d5@rorschach.local.home>
In-Reply-To: <20240613092642.385461d5@rorschach.local.home>
From: Ard Biesheuvel <ardb@kernel.org>
Date: Thu, 13 Jun 2024 16:06:47 +0200
Message-ID: <CAMj1kXFGnk4vYpTk4PwUg8iYHcbXdrPaYP+OBxHrD5+=jvow+g@mail.gmail.com>
Subject: Re: [PATCH v3 2/2] pstore/ramoops: Add ramoops.mem_name= command line option
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Mike Rapoport <rppt@kernel.org>, Kees Cook <kees@kernel.org>, linux-kernel@vger.kernel.org, 
	linux-trace-kernel@vger.kernel.org, Masami Hiramatsu <mhiramat@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, 
	Andrew Morton <akpm@linux-foundation.org>, "Liam R. Howlett" <Liam.Howlett@oracle.com>, 
	Vlastimil Babka <vbabka@suse.cz>, Lorenzo Stoakes <lstoakes@gmail.com>, linux-mm@kvack.org, 
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Peter Zijlstra <peterz@infradead.org>, Tony Luck <tony.luck@intel.com>, 
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>, linux-hardening@vger.kernel.org, 
	Guenter Roeck <linux@roeck-us.net>, Ross Zwisler <zwisler@google.com>, wklin@google.com, 
	Vineeth Remanan Pillai <vineeth@bitbyteword.org>, Joel Fernandes <joel@joelfernandes.org>, 
	Suleiman Souhlal <suleiman@google.com>, Linus Torvalds <torvalds@linuxfoundation.org>, 
	Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>
Content-Type: text/plain; charset="UTF-8"

On Thu, 13 Jun 2024 at 15:26, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 13 Jun 2024 08:11:48 +0200
> Ard Biesheuvel <ardb@kernel.org> 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.