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: <87ms5ak8lw.fsf@trenco.lwn.net>
Date: Tue, 28 Oct 2025 15:40:59 -0600
From: Jonathan Corbet <corbet@....net>
To: Thorsten Leemhuis <linux@...mhuis.info>
Cc: workflows@...r.kernel.org, linux-doc@...r.kernel.org,
 regressions@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 07/30] docs: reporting-issues: explain need for fresh
 vanilla kernel

Thorsten Leemhuis <linux@...mhuis.info> writes:

> Rewrite the section that explains why a fresh kernel is needed and why
> bug reporters might have to compile one themselves for testing and
> debugging purposes.
>
> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.info>
> ---
>  .../admin-guide/reporting-issues.rst          | 141 +++++++++++-------
>  1 file changed, 85 insertions(+), 56 deletions(-)
>
> diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
> index 7dfb3ca4b3e322..2f387e8766f21d 100644
> --- a/Documentation/admin-guide/reporting-issues.rst
> +++ b/Documentation/admin-guide/reporting-issues.rst
> @@ -49,11 +49,25 @@ Step-by-step guide on reporting Linux kernel issues
>  Note: Only the steps starting with '*you must*' are strictly required -- but
>  following the others is usually in your own interest.
>  
> - * Are you facing an issue with a Linux kernel a hardware or software vendor
> -   provided? Then in almost all cases you are better off to stop reading this
> -   document and reporting the issue to your vendor instead, unless you are
> -   willing to install the latest Linux version yourself. Be aware the latter
> -   will often be needed anyway to hunt down and fix issues.
> +.. _intro_repisbs:
> +
> +* Be aware:
> +
> +  * You should report issues using a Linux kernel that is both really fresh and
> +    vanilla. That often means that you will have to remove software that
> +    requires externally developed kernel modules and install the newest upstream
> +    Linux development kernel yourself.
> +
> +  * There is a decent chance you will have to report the problem by email, in
> +    which case your email address will become part of public archives.
> +
> +  * You might need to patch and build your own kernel to help developers debug
> +    and fix the bug.
> +
> + If these three aspects sound too demanding, consider reporting the issue to
> + your Linux distributor or hardware manufacturer instead.

So nothing to object to here, but this does make me wonder who the
audience is for this document?  It seems that you are aiming at people
who do not run upstream kernels, but who want to work with upstream to
get bugs fixed...?  That seems worth saying explicitly if so.  How big
of a group is this?

Thanks,

jon

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ