Josh Triplett[CCing the git list]
On Wed, Mar 03, 2021 at 12:53:18PM -0800, Linus Torvalds wrote:
Show 14 quoted lines
> 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.
[...]
Show 11 quoted lines
> 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
