There were mainly two problems with shebangs:
- Suffix arguments handling e.g. '#!/bin/sh -x'
- Recursive handling e.g. script1 fetchs '#!/path/to/script2'
and script2 itself has a shebang
- (did I say two?) running shebang would replace argv[optind] instead
of appending e.g. script with '#!/bin/sh' and running './script -c'
would run '/bin/sh -c' instead of '/bin/sh ./script -c'
There also are two places where this needs parsing:
- starting a fresh program from mcexec
- starting a new program from execve in mcexec
The first was easy to fix as we already had argv around, but the later
required a new way to transfer the 'new argv elements from the script'
to mckernel to append before its argv -- it used to be 'desc->shell_path'
but that was no longer used at some point and just one keyword is not
enough to handle this properly.
This commit does:
- Refactors the lookup_path + load_elf_desc that was only done at most
twice in its own function that loops indefinitely and use that in both
situations described above
- Transmits the argv addition in the transfer to mckernel after the
desc; mckernel allocates 4 pages (hardcoded) for the descs and we will
hopefully have room for the script arguments on top of that... (there is
no guard!!!)
- Change flatten_strings to allow prepending a flattened string instead
of a single string.
Note that the flatten_string change also brought in a difference in the
format, to have the full length embedded within the string, the latest
slot that used to be zeroes now contains the position of the end of the
buffer (where the last+1 string would be if there had been one)
This required a trivial change in mckernel prepare args function that
used this property for no real reason.
Hopefully things work™, this probably warrants adding a couple of new
ostests...
- create a couple of scripts with recursive invocation/arguments and
check their own argv.
- execute "mcexec script args" and "mcexec sh -c 'script args'"
Change-Id: I2cf9cde5c07c9293f730de89c9731bd93dbfa789
Refs: #1115
This includes the following fix:
send_syscall, do_syscall: remove argument pid
Fujitsu: POSTK_TEMP_FIX_26
Refs: #1165
Change-Id: I702362c07a28f507a5e43dd751949aefa24bc8c0
We had a deadlock between:
- free_process_memory_range (take lock) -> ihk_mc_pt_free_range ->
... -> remote_flush_tlb_array_cpumask -> "/* Wait for all cores */"
and
- obj_list_lookup() under fileobj_list_lock that disabled irqs
and thus never ack'd the remote flush
The rework is quite big but removes the need for the big lock,
although devobj and shmobj needed a new smaller lock to be
introduced - the new locks are used much more locally and
should not cause problems.
On the bright side, refcounting being moved to memobj level means
we could remove refcounting implemented separately in all object
types and simplifies code a bit.
Change-Id: I6bc8438a98b1d8edddc91c4ac33c11b88e097ebb
Defining C structures for the following objects:
(1) Remote and local context
(2) Stack of system call arguments / return values
Change-Id: Iafbb6c795bd765e3c78c54a255d8a1e4d4536288
(1) Masquerade clv
(2) Fix timeout
(3) Let mcexec thread with the same tid as McKernel thread migrating
to Linux handles the migration request
(4) Call create_tracer() before creating proxy related objects
Change-Id: I6b2689b70db49827f10aa7d5a4c581aa81319b55
One CPU could be chosen by concurrent forks because CPU selection and
runq addition are not done atomicly. So this fix makes the two steps
atomic.
Change-Id: Ib6b75ad655789385d13207e0a47fa4717dec854a
Heavily inspired off linux kernel's dynamic debug:
* add a /sys/kernel/debug/dynamic_debug/control file
(accessible from linux side in /sys/class/mcos/mcos0/sys/kernel/debug/dynamic_debug/control)
* read from file to list debug statements (currently limited to 4k in size)
* write to file with '[file foo ][func bar ][line [x][-[y]]] [+-]p' to change values
Side effects:
* reindented all linker scripts, there is a new __verbose section
* added string function strpbrk
Change-Id: I36d7707274dcc3ecaf200075a31a2f0f76021059
While we are here, also optimize code a bit: perf_desc does not need
to be allocated for every cpu; and fix coding style.
Change-Id: Iad19fed08205d38594fd3f1b7ddf2b19a9cf0d9d
Many ikc messages expecting a reply use wait_event_interruptible
incorrectly, freeing memory that could still be used on the other side.
This commit implements a generic ikc send and wait helper that helps
with memory management and ownership properly:
- if the message succeeds and a reply comes back normally, the memory
is freed by the caller as usual
- if the wait fails (signal before the reply comes or timeout) then the
memory is set as owner by ikc and will be free when the reply comes back
later
- if the reply never comes, the memory is freed at shutdown when
destroying ikc channels
Refs: #1076
Change-Id: I7f348d9029a6ad56ba9a50c836105ec39fa14943
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)
