The kernel column #88

[ Thanks to Linux User &
Developer magazine for this link. ]

“With the release of 2.6.34 came the opening of the merge window
for 2.6.35, during which time we can expect a lot of very
interesting patches, which will have have gone through the daily
linux-next testing development source tree already. The new
features in 2.6.34 and beyond are of course interesting, and there
will be more to say about these in future issues, but perhaps the
most important thing to come out of this most recent development
cycle was a tremendous feeling of satisfaction from many core
kernel developers that a particularly nasty VM (virtual memory)
glitch was tracked down and fixed as quickly as it was. Linus
himself was likely particularly happy to take a break from
maintaining the tree to do a lot of very heavy thought and
reasoning about VM behaviour.

“The problem reports first began to show up a matter of weeks
ago, in particular from Borislav Petkov, who would find that every
time he resumed his laptop from a suspend-to-disk operation, there
would be a nasty kernel crash. He didn’t have a lot to go on at
first, and it took a few days of instrumenting kernel code with
diagnostic messages, and rebooting over and over to figure out
roughly what was happening, but not the why of the matter. The what
requires that you understand anonymous VMAs (virtual memory areas).
VMAs are the kernel’s means to represent regions of allocated
memory in tasks (known as processes to users) and they are what you
see in /proc/pid/maps (where pid is any normal user process ID for
some running application). The anonymous part refers to VMAs that
are not representing a memory mapped file – created with a
call to a kernel feature such as mmap – but are instead
representing pure ‘anonymous’ memory used by the running process
for some data structure, stack, etc.”

Complete
Story