linux-kernel - Re: [PATCH] docs: bug-bisect: Add a note about bisecting -next

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 for Android: free password hash cracker in your pocket

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

Message-ID: <7cca53ec-1893-45dd-832b-dc845d08474e@leemhuis.info>
Date: Wed, 23 Oct 2024 20:05:33 +0200
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Mark Brown <broonie@...nel.org>, Jonathan Corbet <corbet@....net>
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] docs: bug-bisect: Add a note about bisecting -next

On 22.10.24 17:59, Mark Brown wrote:
> We don't explicitly mention anywhere in the kernel tree that bisects
> between -next versions won't work well and it's better to bisect between
> mainline and -next. Let's add a note about that to try to help people avoid
> this particular gotcha.
> 
> Signed-off-by: Mark Brown <broonie@...nel.org>

Thx for this!

> ---
>  Documentation/admin-guide/bug-bisect.rst | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> [...]
> +Bisecting linux-next
> +--------------------
> +
> +Since linux-next is a series of merges rebuilt every day starting from
> +Linus' tree there is no commmon history between multiple versions of
> +-next. This means that the history of a given -next release won't
> +include prior -next releases which confuses bisect if you try to
> +bisect between them. Bisects will run much better if performed between
> +-next and the commit in Linus' tree which that version of -next is
> +based on instead.

Hmmmm. That describes the problem (somewhat in style of a "reference
guide"), but does not really match the approach the rest of the text
uses (which is more of an "howto"). So for me it feels like a bad fit,
even if users of linux-next are less likely to need a howto.

How about something like this instead:

---

Bisecting linux-next
--------------------

If you face a problem that only happens in linux-next, bisect between
the linux-next branches "stable" and "master". Use these commands to
start the bisection for a linux-next tree you added as a remote called
"next"::

  git bisect start
  git bisect good next/stable
  git bisect bad next/master

The "stable" branch refers to the state of linux-mainline the current
linux-next release is based on -- so it should be free of any problems
that show up in -next, but not in Linus' tree.

This approach will mean that you have to bisect across a wide range of
changes, some of which you might have used in earlier linux-next
releases without problems. Sadly it's impossible to bisect from one
linux-next release to a later one (say between next-20241022 and
next-20241023), as the -next specific changes of the two share no common
history.

---

I did not check the commands in that text yet, hope I did not do
anything stupid there.

Ciao, Thorsten