When x86 CPU Stacks Overflow, They Will Now Be More Pronounced With Linux 5.2+

[phoronix]

Phoronix: When x86 CPU Stacks Overflow, They Will Now Be More Pronounced With Linux 5.2+

While the x86 IRQ changes to the Linux kernel during the merge window periods don't tend to be too interesting for end-users, there is a pleasant change introduced with the Linux 5.2 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=x86-IRQ-Stack-Overflow

[tildearrow]

Typo?

odd behavior creaping in with time.

[coder]

It's about time!

[discordian]

Thats a feature that should be backported to the LTS kernels immediately. Those kernel crashes with messed up stack are a pain.

[ShizzyG]

Indeed.

[skeevy420]

The stability and support of LTS and "stable"software is a myth, nobody has the resources to test with every possible combination of software and hardware. Let the whole system to roll to get new features and bug fixes fast, that is modern computing. Back porting is a waste of resources.

For the most part, yep...especially for general-use desktops, media centers, gaming setups, etc. Sometimes features like that need to be backported simply because some devices and hardware configurations may not like kernels 4.17 to, I dunno, let's go with 5.4 until some new regression or bug is fixed.

Outside of the kernel, it probably is a waste of time unless you're Red Hat or Suse with paying enterprise customers. I can understand wanting to run an OS where you don't have to worry about little crap like R600_DEBUG switching to AMD_DEBUG or kernel command lines values changing when you're trying to offer next-to-no downtime servers to random customers (distributions and random 3rd parties that offer servers).

[xorbe]

Wait what? How was this not the default implementation all along!

[GreenReaper]

Previously, kernel stack space was directly-mapped as a contiguous block, so you'd be wasting one real page of memory per stack.

Personally I patch my stacks back to 4/8K on 32/64-bit x86, but I like living on the edge. ;-p