This is still a critical vulnerability as no user interaction is basically required and there's no way to disable this "feature" before your distro pushes an update (and some Linux distros are not exactly agile in this regard).

From Release AnnouncementsKDE Frameworks 5.61.0 :

KConfig

        Security: remove support for $(...) in config keys with [] marker // b.

But now we're discussing a technical issue and many engineers/geeks/computer lovers prefer to remain anonymous or they just won't bother joining the discussion ...

The review you're referring to tested a situation when the entire drive was free which is OK when you overwrite it many times over.

Now imagine a real computer which already has a lot of data. Now imaging only little space is left. In this case disk writes will be in the same region and will decrease its life span a lot faster, in many cases thousands times faster if your SSD drive doesn't have reserved space (many don't).

Also, SSD disks tend to die without any warning signs and data on them is usually not recoverable unlike with the spinning rust from which you can extract your data in most cases (unless you burn it down).

Why are anonymous comments disabled in this topic? I've created a user account just to leave a comment because I don't want to reveal my real identity on /.

> If you're running without swap space, you can probably get any Unix to behave this way under memory pressure...

That's not true and multiple FreeBSD/MacOS (Unix kernel based) users have confirmed that. Also, "probably" in this statement makes it vague and utterly inconsequential. You can use "probably" with too many things in the world like, "probably it may snow in Costa Rica tomorrow" except it most likely will never happen but theoretically it can.

The author of this blog post for some reasons hasn't bothered to read the discussion on LKML, as well as discussions on slashdot, reddit and Hacker News. Meanwhile multiple Linux kernel developers (including the ones who work on the memory subsystem) on LKML have admitted that:

1) The issue raised by Artem S. Tashkinov is real and easily reproducible, and more importantly it's been like that for many many years.
2) You can get absolutely the same issue with SWAP enabled (since in Linux it's usually not dynamic)
3) Once you hit this issue with SWAP enabled, it will be even worse
4) The issue is not about SWAP at all, its about OOMkiller not doing its job due to a flawed logic
5) Currently the Linux kernel cannot handle this situation and in order to solve the issue once you hit it you can a) use userspace free RAM watchers like earlyoom ( https://github.com/rfjakob/ear...) b) press SysRq + F/REISUB 3) limit application's RAM allocations using limits.conf or `systemd-run --user --scope -p MemoryLimit=1G`

Yes, SWAP might improve performance (in a different situation altogether, not when you're running of your virtual memory) but it can also degrade it because the kernel doesn't know which applications should be kept in memory and which must be swapped out. No, SWAP does not solve low memory pressure stall, it only exacerbates it.

And one last point: there's a myth that you must always have SWAP enabled. No, if you have enough RAM for running apps and system caches and there's some left, you don't really need to enable it. Also, enabling it on SSD disks will shorten their lifespan.

"You must always have SWAP enabled" myth was born out of necessity (and I cannot stress it enough) - nowadays you can decide whether to enable it on a case-by-case basis. Various operating systems enable it by default not because Linux/Microsoft/Apple/Oracle/whatever programmers are absolutely certain SWAP is always required, they do it because they don't know your memory requirements and available RAM in advance. In 2019 if your laptop/workstation contains 8gigs of RAM and all you do is light web browsing and editing documents/spreadsheets, you will do just fine without ever enabling SWAP.

I have over a hundred high load servers under my command, none of them have SWAP enabled and everything works smoothly. What's more some of them slow down to a crawl if you enable SWAP (even with `swappiness` turned down to 0). But certainly this system administrator knows better ... myths. // b.