Received-SPF: pass (google.com: domain of linux-kernel+bounces-73401-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <320c4dba-9919-404b-8a26-a8af16be1845@app.fastmail.com>
 <Y9ES4UKl/+DtvAVS@gmail.com> <16641a56-9139-4396-a5a8-89606bedd1f1@app.fastmail.com>
In-Reply-To: <16641a56-9139-4396-a5a8-89606bedd1f1@app.fastmail.com>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Tue, 20 Feb 2024 18:07:06 +0100
Message-ID: <CANiq72meap5C9bkj5rNDE=0U5gb5OKwDrrTSrVRwJbkAPWgUsg@mail.gmail.com>
Subject: Re: [PATCH] x86/insn_decoder_test: allow longer symbol-names
To: David Rheinsberg <david@readahead.eu>
Cc: Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org, 
	rust-for-linux@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org, 
	Dave Hansen <dave.hansen@linux.intel.com>, Borislav Petkov <bp@alien8.de>, 
	Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, 
	Masami Hiramatsu <mhiramat@kernel.org>, John Baublitz <john.m.baublitz@gmail.com>, 
	=?UTF-8?Q?Sergio_Gonz=C3=A1lez_Collado?= <sergio.collado@gmail.com>, 
	David Gow <davidgow@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 27, 2023 at 11:39=E2=80=AFAM David Rheinsberg <david@readahead.=
eu> wrote:
>
> The current workaround is to just disable CONFIG_X86_DECODER_SELFTEST, wh=
ich I thought is a sad state. I can gladly use `256 + KSYM_NAME_LEN` and ad=
d a comment ala "room for insn-encoding and a symbol name". Would that be a=
cceptable? The alternative would be to try to dyn-alloc a buffer and increa=
se it to the actual line-length?

John independently hit this issue again. Could we fix this? Going for
the `256 + KSYM_NAME_LEN` sounds good enough for the moment since it
would be a clear improvement, though I agree this could be cleaned up
further.

Sergio took the approach David suggested in a related patch [1], but
perhaps it is best to submit the fix on its own so that it is easier
to put it in. David, would you be so kind as to submit a v2 with that?
Hopefully x86 can pick it up, otherwise with an Acked-by I am happy to
take it too; and then Sergio can submit his patch on top again.

Thanks!

(Cc'ing also Masami who wrote this originally)

[1] https://lore.kernel.org/rust-for-linux/20231119180145.157455-1-sergio.c=
ollado@gmail.com/

Cheers,
Miguel