Language Selection

English French German Italian Portuguese Spanish

A warning about 5.12-rc1

Filed under
Linux

  • A warning about 5.12-rc1
    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.
    
    
    
    
    Now, the good news is even if you do use swap (and hey, that's nowhere
    near as common as it used to be), most people don't use a swap *file*,
    but a separate swap *partition*. And the bug in question really only
    happens for when you have a regular filesystem, and put a file on it
    as a swap.
    
    
    
    
    And, as far as I know, all the normal distributions set things up with
    swap partitions, not files, because honestly, swapfiles tend to be
    slower and have various other complexity issues.
    
    
    
    
    The bad news is that the reason we support swapfiles in the first
    place is that they do end up having some flexibility advantages, and
    so some people do use them for that reason. If so, do not use rc1.
    Thus the renaming of the tag.
    
    
    
    
    Yes, this is very unfortunate, but it really wasn't a very obvious
    bug, and it didn't even show up in normal testing, exactly because
    swapfiles just aren't normal. So I'm not blaming the developers in
    question, and it also wasn't due to the odd timing of the merge
    window, it was just simply an unusually nasty bug that did get caught
    and is fixed in the current tree.
    
    
    
    
    But I want everybody to be aware of because _if_ it bites you, it
    bites you hard, and you can end up with a filesystem that is
    essentially overwritten by random swap data. This is what we in the
    industry call "double ungood".
    
    
    
    
    Now, there's a couple of additional reasons for me writing this note
    other than just "don't run 5.12-rc1 if you use a swapfile". Because
    it's more than just "ok, we all know the merge window is when all the
    new scary code gets merged, and rc1 can be a bit scary and not work
    for everybody". Yes, rc1 tends to be buggier than later rc's, we are
    all used to that, but honestly, most of the time the bugs are much
    smaller annoyances than this time.
    
    
    
    
    And in fact, most of our rc1 releases have been so solid over the
    years that people may have forgotten that "yeah, this is all the new
    code that can have nasty bugs in it".
    
    
    
    
    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.
    
    
    
    
    And the *final* reason I want to just note this is a purely git
    process one: if you already pulled my git tree, you will have that
    "v5.12-rc1" tag, and the fact that it no longer exists in my public
    tree under that name changes nothing at all for you. Git is
    distributed, and me removing that tag and replacing it with another
    name doesn't magically remove it from other copies unless you have
    special mirroring code.
    
    
    
    
    So if you have a kernel git tree (and I'm here assuming "origin"
    points to my trees), and you do
    
    
    
    
         git fetch --tags origin
    
    
    
    
    you _will_ now see the new "v5.12-rc1-dontuse" tag. But git won't
    remove the old v5.12-rc1 tag, because while git will see that it is
    not upstream, git will just assume that that simply means that it's
    your own local tag. Tags, unlike branch names, are a global namespace
    in git.
    
    
    
    
    So you should additionally do a "git tag -d v5.12-rc1" to actually get
    rid of the original tag name.
    
    
    
    
    Of course, having the old tag doesn't really do anything bad, so this
    git process thing is entirely up to you. As long as you don't _use_
    v5.12-rc1 for anything, having the tag around won't really matter, and
    having both 'v5.12-rc1' _and_ 'v5.12-rc1-dontuse' doesn't hurt
    anything either, and seeing both is hopefully already sufficient
    warning of "let's not use that then".
    
    
    
    
    Sorry for this mess,
                 Linus
    
    
    
    
    
  • A warning about 5.12-rc1

    Linus Torvalds has sent out a note telling people not to install the recent 5.12-rc1 development kernel; this is especially true for anybody running with swap files. "But I want everybody to be aware of because _if_ it bites you, it bites you hard, and you can end up with a filesystem that is essentially overwritten by random swap data. This is what we in the industry call 'double ungood'." Additionally, he is asking maintainers to not start branches from 5.12-rc1 to avoid future situations where people land in the buggy code while bisecting problems.

  •  

  • Linux 5.12-rc2 Likely Coming Early Due To That Nasty File-System Corruption Bug

    Linus Torvalds has now warned developers over using Linux 5.12-rc1 as a basis for their future branches and is looking to release 5.12-rc2 ahead of schedule as a result of that problematic file-system corruption bug stemming from a swap file bug. 

Don't Try Or Use Linux 5.12-rc1

  • Don't Try Or Use Linux 5.12-rc1

    Linus Torvalds has renamed Linux 5.12-rc1 to 5.12-rc1-dontuse in git and the release has been pulled from kernel.org due to an extremely unfortunate bug related to swap files, not swap partitions, that could cause random files to be overwritten with garbage data. You may want to revert to a previous kernel if you've already upgraded to Linux 5.12 rc1.

Torvalds warns the world: Don’t use the Linux 5.12-rc1 kernel

  • Torvalds warns the world: Don’t use the Linux 5.12-rc1 kernel

    As it turns out, when Linus Torvalds flags some code dontuse, he really means it—the problem with this 5.12 release candidate broke swapfile handling in a very unpleasant way. Specifically, the updated code would lose the proper offset pointing to the beginning of the swapfile. Again, in Torvalds' own words, "swapping still happened, but it happened to the wrong part of the filesystem, with the obvious catastrophic end results."

    If your imagination is insufficient, this means that when the kernel paged contents of memory out to disk, the data would land on random parts of the same disk and partition the swapfile lived on... not as files, mind you, but as garbage spewed directly to raw sectors on the disk. This means overwriting not only data in existing files, but also rather large chunks of metadata whose corruption would likely render the entire filesystem unmountable and unusable.

    [...]

    This also leads into one of my own rather frequent warnings to fellow Linux users: don't blindly leap ahead into cowboy code that hasn't yet been sufficiently tested. Linux kernel release candidates are usually very, very solid, and it's tempting to dive into new features as early as possible—but doing so can have very, very ugly consequences. And many of those consequences could have been avoided by waiting for the code to enter production status in the first place.

Torvalds Warns the World: Don't Use the Linux 5.12-rc1 Kernel

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

today's leftovers

     
  • What is Raspberry Pi 4 “Model B”? [Ed: I'm still waiting for them to formally apologise for going behind customers' backs, making secret deals with Microsoft to put Microsoft malware on all those devices]

    Raspberry Pi has conquered the world of SoC (System on a Chip). It has already garnered millions of followers since its release in 2012. Not only is it inexpensive, but it’s also versatile, modular, and multi-purpose. It has become popular not only as a credit-sized computer board but also as a controller in electronic, robotics, and IoT projects. The size, features, and price drive the popularity of the Pi, especially in the DIY community. To keep up with the current technological trends, the tiny board has undergone plenty of upgrades over the years, and there have been many varieties so it can cater to the needs and demands of its users. In 2019, the Raspberry Pi Foundation released the fourth generation of the multi-purpose board, the Raspberry Pi 4 B. It is the most powerful Pi to date, sporting huge upgrades from its predecessors. The compact board is touted to deliver a PC-level performance, and it didn’t disappoint.

  • Kentaro Hayashi: Grow your ideas for Debian Project

    There may be some "If it could be ..." ideas for Debian Project. If idea is concreate and worth to make things forward, it should make a proposal for Project Funding. [...] I'm not confident whether mechanism works, but Debian needs change.

  • Sam Thursfield: Calliope, slowly building steam

    There are some interesting complexities to this, and in 12 hours of hacking I didn’t solve them all. Firstly, Bandcamp artist and album names are not normalized. Some artist names have spurious “The”, some album names have “(EP)” or “(single)” appended, so they don’t match your tags. These details are of interest only to librarians, but how can software tell the difference? The simplest approach is use Musicbrainz, specifically cpe musicbrainz resolve-ids. By comparing ids where possible we get mostly good results. There are many albums not on Musicbrainz, though, which for now turn up as false positives. Resolving Musicbrainz IDs is a tricky process, too — how do we distinguish Multi-Love (album) from Multi-Love (single) if we only have an album name? If you want to try it out, great! It’s still aimed at hackers — you’ll have to install from source with Meson and probably fix some bugs along the way. Please share the fixes!

  • Neovide Is A Graphical Neovim Client Written In Rust

    Neovide is a really cool GUI client for Neovim. Although it essentially functions like Neovim in the terminal, Neovide does add some nice graphical improvements such as cursor animations and smooth scrolling. It even has me thinking about making it my new "vim" alias.

Linux 5.11.13, 5.10.29, 5.4.111, 4.19.186, 4.14.230, 4.9.266, and 4.4.266

Get involved with Mageia, become a Packager

With Mageia 8 just released and development for Mageia 9 getting underway in Cauldron, the unstable branch of Mageia, now is a great time to get involved with packaging. We are starting to look at the features that we want to include for Mageia 9, and as it is so early in the development cycle, now is the time for major developments, or big updates to key pieces of software. This is a great time to join the project as you can propose features you would like to see, help to implement large changes or see how a distribution evolves through development, stabilisation and then is released. If there is an application that you are interested in, if you want to help maintain part of the distribution, or if you want to learn something new, there are many opportunities to do so with the packaging team. Read more

Google does not want you to tell your players about your donation page

I recently updated Pixel Wheels banner image on Google Play. That triggered a review of the game: shortly after the update I received a message telling me Pixel Wheels was "not compliant with Google Play Policies". What nefarious activity does the game engage in? Sneak on users? Mine bitcoins? [...] Meanwhile you can still get the game from F-Droid or itch.io, since they do not have a problem with a link to a donation page. Read more