> And, as far as I know, all the normal distributions set things up with swap partitions, not files I guess Ubuntu is not a "normal" distribution then? Because it uses a swap file by default.
A warning about 5.12-rc1
41–50 of 115 posts
Re: A warning about 5.12-rc1
#42> it didn't even show up in normal testing, exactly because swapfiles just aren't normal. Uhh, does it mean swapfiles are undertested in the Linux kernel? Or is there some "non-normal" extra testing that is being run for non-rc releases, but not for rc ones? (!?)
I fear you grossly overestimate how detailed the kernel's testing is. (Do please note that the word "detailed" above was carefully chosen.)
Re: A warning about 5.12-rc1
#43Earlier quoted context omitted.
Swapfiles are quite common when you use FDE (say, LUKS) and you don't want your swap to be in plaintext on disk. (Although, you could just have an entire LUKS-encrypted swap volume instead of a swapfile...)
While maybe not the most performant my favorite is LVM2 on top of a single large LUKS-encrypted partition (+no boot partition and a single (custom platform key) signed EFI bootable kernel blob containing the initram fs in the EFI partition). This: - Allows a encrypted swap partition (on in lvm2 on top of luks, sure not perfect but I don't really use swap) - Allows hibernation (which I don't really use tbh.) - Fully e…
However, an alternative is having your EFI partition reside on a USB drive that in turn boots into your encrypted partition.
Re: A warning about 5.12-rc1
#44this is unlikely to hurt you unless you use a swap file , rather than a dedicated swap partition. for performance reasons most any modern linux installation would be using a dedicated swap partition, that is defined as swap-only during the install process with mkswap In my experience some of the reasons for using a swap file were more common maybe 10 or 15 years ago. Nowadays with disk space being less costly and rar…
Swapfiles are quite common when you use FDE (say, LUKS) and you don't want your swap to be in plaintext on disk. (Although, you could just have an entire LUKS-encrypted swap volume instead of a swapfile...)
partition > LUKS > LVM > swap volume
That way you get encrypted swap without having swap be a file in your filesystem.
Re: A warning about 5.12-rc1
#45Earlier quoted context omitted.
It is a lot more uncommon for MBR-based boot partitions these days. It is no longer the default for Windows. With EFI and GPT, it is a lot simpler. Linux can use a Windows EFI boot partition, or vice-versa. Additionally, in my specific case I have a separate EFI partition saved on a USB stick for booting my encrypted root partition. It adds plausible deniability.
> It adds plausible deniability. How so?
There is no requirement on what type of partition type you use for your LUKS2 encrypted partition, so ideally you'd use something that isn't going to be apparent.
Then, as long as knowledge of a tiny USB drive or micro SD card existing isn't known (which is a lot easier to hide) it is more difficult to discover that an encrypted partition even exists.
Re: A warning about 5.12-rc1
#46Earlier quoted context omitted.
The email mentions that normal testing didn't catch it as it's not a typical use-case for the devs apparently.
Which is exactly why automated testing exists, to catch cases like this.
And since kernel is basically involved into everything that computer does, you would have to test everything, to find every error. Linux kernel is also extremely customizable, so that it can run from watches, to mars rowers, to HPC and cloud.
Linux kernels are continuously heavily tested on various different hardware architectures, by various organizations (RH, IBM, Oracle, Google).
So there are automated tests done. It's just seems nobody tested this.
Re: A warning about 5.12-rc1
#47this is unlikely to hurt you unless you use a swap file , rather than a dedicated swap partition. for performance reasons most any modern linux installation would be using a dedicated swap partition, that is defined as swap-only during the install process with mkswap In my experience some of the reasons for using a swap file were more common maybe 10 or 15 years ago. Nowadays with disk space being less costly and rar…
Re: A warning about 5.12-rc1
#48Earlier quoted context omitted.
But if you suddenly need it and don't have it, you'll get segfaults (I assume). Sounds a bit too dangerous for me :p
You'll get OOM killed as if you ran out of RAM. This doesn't happen unless the program is buggy. Moreover, if your working set is larger than RAM, you're screwed regardless. So don't do that. Swap exists so you can use more RAM for the disk cache. It's doesn't exist so that buggy programs can crawl instead of dying
I mean, this is patently false. I've used 1TB swapfiles to get out of a sticky situation with some terrible research software that used a ton of memory to solve really valuable problems.
There's nothing wrong with an absolute shit ton of swap when the alternative is OOM.
Re: A warning about 5.12-rc1
#49> it didn't even show up in normal testing, exactly because swapfiles just aren't normal. Uhh, does it mean swapfiles are undertested in the Linux kernel? Or is there some "non-normal" extra testing that is being run for non-rc releases, but not for rc ones? (!?)
My understanding is that is the point of RC builds, they are the builds used for testing before a stable release.
Re: A warning about 5.12-rc1
#50I was interested to see the code. Linus's message doesn't provide commit IDs, so you have to go looking yourself. I believe this is the commit which introduces the bug: https://github.com/torvalds/linux/commit/48d15436fde6feebcde... And I believe this is the commit which fixes it: https://github.com/torvalds/linux/commit/caf6912f3f4af723234...
It changes the behaviour of swap_page_sector() to take into account the offset. But swap_page_sector() was already used before the bug was introduced, a few lines earlier in the bdev_write_page() fast path, as introduced by this commit from 2014: https://github.com/torvalds/linux/commit/dd6bd0d9c7dbb395100...
So either:
1. The bdev_write_page() call was also broken, and has been for years, or
2. The bdev_write_page() uses the sector value differently, worked fine with the old swap_page_sector(), but is now broken with the new version, or
3. The change in swap_page_sector() somehow doesn't affect bdev_write_page(); maybe it's a noop when using swap files?