On startup, Trinity creates a bunch of MAP_SHARED mmaps that are inherited by the child processes.
These addresses get handed off to other syscalls, and well.. not much really happens.
There are several problems here.
- We can’t do things like mmap huge pages here, because after a few children fault them in, we trigger the oom killer. Not fun.
- We don’t track things that happen to a page. So we hand it to say, mprotect(), which marks it read only. Then later we hand the same page to read(), which.. segfaults. Great.
- We weren’t storing any of the results of syscalls made by the child processes. So if a child created an mmap, we never did anything with it.
All of this is fixed after the last few days of hacking. The results so far look promising, but there’s more work ahead in this area next week.
First day back after a week off. Skimmed through thousands of emails.
Damage so far:
- Router OOM’d itself to the point of locking up completely last night. Normally I reboot it daily into Linus’ kernel of the day, but as I was on vacation, something kept leaking memory over a period of a week. Updated everything to current, with a plan to keeping an eye on it over the next week. Looking at mrtg graphs, the memory goes down every night after cron runs, and is never reclaimed.
- hit a GPF in aio_migratepage
- Still seeing some bugs from before my vacation that aren’t fixed yet.
- My AMD test box completely died. Powers up for a second and then turns itself off. Annoying, as this was my I/O test machine.
bugs bugs bugs.
Made a bunch of small improvements to trinity (mostly fixing up warnings). Coming closer to another point release before merging some interesting stuff.
Found a bunch of bugs with trinity today after tweaking some code that caused it to hang when closing bluetooth sockets. (Still not sure I want to commit the workaround I came up with). Now that it’s back in action, the roadkill is piling up.
After Linus pulled in a bunch of trees including drivers/staging yesterday, I was expecting the worst this morning after seeing the overnight results.
So I was taken aback somewhat when I saw that after last nights run, we got 49 new issues, but eliminated 57. A definite move in the right direction, especially after a big merge of 1832 patches.
3.12′s staging merge was a lot uglier due to the addition of lustre, which was a huge body of code, which has quite a few potential defects that need reviewing. For 3.13, there’s nothing really of comparable size (at least so far).
Of the 49 new results, most of them are in staging, but there’s a handful in IIO, MIC and USB.