This reverts commit b70d470e20.
That commit had been landed too fast after a mistake during migration
from old to new gerrit that didn't keep -1 vote ; it needs some fix
Change-Id: Ifc8a23e42449dfe471049270b4706e9b137e096e
Do not return from fork() until mcctrl side has created mckernel's
procfs entries for the child PID.
This fixes programs doing fork() immediately followed by opening
/proc/<child pid>/something, and would get some error
Refs: #1189
Change-Id: Ie10ea56b65c55f59e96a1ab6ef83a1070e36048d
The standard UNIX tool to get processes information, need to have the
process id inside /proc/<PID>/status.
Using ps without PID in /proc/<PID>/status gives :
PID TTY TIME CMD
2551 pts/0 00:00:00 bash
0 pts/0 00:00:00 exe
0 pts/0 00:00:00 exe
With this patch:
PID TTY TIME CMD
2551 pts/0 00:00:00 bash
11966 pts/0 00:00:00 exe
12619 pts/0 00:00:00 exe
Change-Id: Ic9d255cbef4d49e49bdaedcfc8e3545d9c144325
This replaces the chained list used to keep track of all memory ranges
of a process by a standard rbtree (no need of interval tree here
because there is no overlap)
Accesses that were done directly through vm_range_list before were
replaced by lookup_process_memory_range, even full list scan (e.g.
coredump).
The full scans will thus be less efficient because calls to rb_next()
will not be inlined, but these are rarer calls that can probably afford
this compared to code simplicity.
The only reference to the actual backing structure left outside of
process.c is a call to rb_erase in xpmem_free_process_memory_range.
v2: fix lookup_process_memory_range with small start address
v3: make vm_range_insert error out properly
Panic does not lead to easy debug, all error paths
are handled to just return someting on error
v4: fix lookup_process_memory_range (again)
That optimistically going left was a more serious bug than just
last iteration, we could just pass by a match and continue down
the tree if the match was not a leaf.
v5: some users actually needed leftmost match, so restore behavior
without the breakage (hopefully)
Reading data from procfs file more than 4096 byte caused a buffer
overrun in McKernel because the buffer was always mapped in McKernel
4096 byte regardless of actual buffer size.
