The 4.9 merge window closes

[Posted October 15, 2016 by corbet]

Linus has released 4.9-rc1 and closed the merge window for this release one day earlier than some might have expected. "My own favorite 'small detail under the hood' happens to be Andy Lutomirski's new virtually mapped kernel stack allocations. They make it easier to find and recover from stack overflows, but the effort also cleaned up some code, and added a kernel stack mapping cache to avoid any performance downsides." The virtually mapped kernel stack work was covered here in June. There were 14,308 non-merge changesets pulled for this release, meaning that 4.9 will be, by far, the busiest development cycle ever.

The 4.9 merge window closes

Posted Oct 17, 2016 3:55 UTC (Mon) by sergey.senozhatsky (subscriber, #91933) [Link] (1 responses)

> The virtual stack mapping also happens to mean that people who try to
> do DMA from temporary buffers on the stack ("Don't do it!") now really
> need to change their evil ways. So there is some fallout from this,
> and I expect a couple of drivers to need minor fixes.

using a pointer to a stack-allocated memory in SG list won't work either.

-ss

The 4.9 merge window closes

Posted Oct 17, 2016 17:41 UTC (Mon) by luto (guest, #39314) [Link]

I have a patch sitting around that lets you put a stack buffer into an sg list. It takes one or two slots depending on whether the buffer spans a page boundary.

This is a terrible hack and I hope to never submit this patch :)

The 4.9 merge window closes

Posted Oct 17, 2016 11:39 UTC (Mon) by adobriyan (subscriber, #30858) [Link] (4 responses)

So after all Windows kernel developers with their big bloated stacks were right.

The 4.9 merge window closes

Posted Oct 17, 2016 13:30 UTC (Mon) by pbonzini (subscriber, #60935) [Link] (2 responses)

From the linked LWN article, "There are a number of advantages to doing so, including elimination of some high-order memory allocations, improved security, and better diagnostic output when a stack overflow occurs". The stack size remains 16 KB, but it need not be physically contiguous anymore.

The 4.9 merge window closes

Posted Oct 17, 2016 15:29 UTC (Mon) by adobriyan (subscriber, #30858) [Link] (1 responses)

It was 8 KB for a long time and there was even an option for 4 KB stack on i386.
Now it is 8/16 KB and optionally virtual (wait and see what RHEL and SLES will do).

I wonder if Windows kernel stacks are vmalloc'd. With non-power-of-2 sizes they probably are.

The 4.9 merge window closes

Posted Oct 17, 2016 18:54 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

8KB still "mostly" works on 64-bit, just like 32-bit could work with 4KB stacks. Having a stack twice as large however is not surprising as the pointer size doubles. I mean, memory has increased by more than 1000 times since Linux 0.01. :-)

The 4.9 merge window closes

Posted Oct 18, 2016 12:38 UTC (Tue) by lkundrak (subscriber, #43452) [Link]

Do they have "big bloated stacks"? The WDM documentation suggests it's "approximately three pages".