From: Josh Triplett <josh@joshtriplett.org>
To: linux-kernel@vger.kernel.org, git@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: A note on the 5.12-rc1 tag
Date: Thu, 4 Mar 2021 12:51:40 -0800 [thread overview]
Message-ID: <YEFIXFyP5tWrPDMw@localhost> (raw)
In-Reply-To: <CAHk-=wjnzdLSP3oDxhf9eMTYo7GF-QjaNLBUH1Zk3c4A7X75YA@mail.gmail.com>
[CCing the git list]
On Wed, Mar 03, 2021 at 12:53:18PM -0800, Linus Torvalds wrote:
> Hey peeps - some of you may have already noticed that in my public git
> tree, the "v5.12-rc1" tag has magically been renamed to
> "v5.12-rc1-dontuse". It's still the same object, it still says
> "v5.12-rc1" internally, and it is still is signed by me, but the
> user-visible name of the tag has changed.
>
> The reason is fairly straightforward: this merge window, we had a very
> innocuous code cleanup and simplification that raised no red flags at
> all, but had a subtle and very nasty bug in it: swap files stopped
> working right. And they stopped working in a particularly bad way:
> the offset of the start of the swap file was lost.
>
> Swapping still happened, but it happened to the wrong part of the
> filesystem, with the obvious catastrophic end results.
[...]
> One additional reason for this note is that I want to not just warn
> people to not run this if you have a swapfile - even if you are
> personally not impacted (like I am, and probably most people are -
> swap partitions all around) - I want to make sure that nobody starts
> new topic branches using that 5.12-rc1 tag. I know a few developers
> tend to go "Ok, rc1 is out, I got all my development work into this
> merge window, I will now fast-forward to rc1 and use that as a base
> for the next release". Don't do it this time. It may work perfectly
> well for you because you have the common partition setup, but it can
> end up being a horrible base for anybody else that might end up
> bisecting into that area.
Even if people avoid basing their topic branches on 5.12-rc1, it's still
possible for a future bisect to end up wandering to one of the existing
dangerous commits, if someone's trying to find a historical bug and git
happens to choose that as a halfway point. And if they happen to be
using a swap file, they could end up with serious data loss, years from
now when "5.12-rc1 is broken" isn't on the top of their mind or even
something they heard about originally.
Would it make sense to add a feature to git that allows defining a
"dangerous" region for bisect? Rough sketch:
- Add a `/.git-bisect-dangerous` file to the repository, containing a
list of of commit range expressions (contains commit X, doesn't
contain commit Y) and associated messages ("Do not use these kernels
if you have a swap file; if you need to bisect into here, disable swap
files first").
- git-bisect, as it navigates commits, always checks that file for any
commit it processes, and adds any new entries it sees into
`.git/bisect-dangerous`; it never removes entries from there.
- git-bisect avoids choosing bisection points anywhere in that range
until it absolutely has to (because it's narrowed an issue to that
range). This can use something similar to the existing `git bisect
skip` machinery. Manual bisections print the message at that point.
Automated bisections (`git bisect run`) stop and print the range
without narrowing further, unless the user passes something like
`--dangerous-ok=commit-range`.
(git notes would be nice for this, but they're hard to share reliably;
the above mechanism to accumulate entries from a file in the repo seems
simpler. I can imagine other possibilities.)
Does something like this seem potentially reasonable, and worth doing to
help people avoid future catastrophic data loss?
- Josh Triplett
next prev parent reply other threads:[~2021-03-04 20:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-03 20:53 A note on the 5.12-rc1 tag Linus Torvalds
2021-03-04 12:43 ` Pavel Machek
2021-03-04 13:23 ` Krzysztof Kozlowski
2021-03-04 17:57 ` Linus Torvalds
2021-03-06 12:54 ` Ingo Molnar
2021-03-04 15:00 ` Geert Uytterhoeven
2021-03-04 16:56 ` David Laight
2021-03-04 18:58 ` Geert Uytterhoeven
2021-03-05 9:14 ` David Laight
2021-03-04 20:51 ` Josh Triplett [this message]
2021-03-05 5:39 ` Christian Couder
2021-03-05 18:10 ` Junio C Hamano
2021-03-05 23:06 ` Josh Triplett
2021-03-05 23:38 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YEFIXFyP5tWrPDMw@localhost \
--to=josh@joshtriplett.org \
--cc=git@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).