On Sun, Oct 02, 2005 at 08:57:26AM -0400, Ed Tomlinson wrote:
> Is there any kernel api that adding would make cryopid more
> dependable/cleaner?
Currently a fair bit of information is obtained by injecting code
into the process's memory space, executing it, and reaping out the
results (eg, termcaps, file offsets, fcntl states, locks, signal
actions, etc). Can't think of ways to make it cleaner off the top
of my head, but I'm open to ideas.
Seeing as you asked though, here's my wishlist :) I don't expect all
of these to be implemented, but every bit would help. Issues I
haven't been able to address so far:
- Processes that cache their PID and need it, or rely on PIDs of
their children.
Some way to request a given PID when cloning/forking (or on the
fly even) would make life easier.
- UNIX sockets aren't currently supported but figuring out what is
connected to what seems a little shaky. Some old code used to
take a guess that socketpairs had inodes k and k+1 with k odd,
which seemed to work in all cases I saw. It certainly didn't feel
reliable though.
An extra field in /proc/net/unix saying what inode socket was on
the other end (only needed for the connect() end) would be great.
- Setting cmdline as appears in /proc/$pid/cmdline. argv and
environ point somewhere into the process's stack determined by
the size of argv and environ at exec time. Without va space
randomisation in the picture, it's not too difficult to reproduce
this and get it back where it should be (it's a hack though), but
with va space randomisation it's pretty much impossible.
An API to change the actual memory location of this (task's
mm->arg_start) would be handy (prctl maybe?)
- Merging tcpcp for TCP connection saving support.
- I haven't put a great deal of thought into the multithreading
side of things, but a non-intrusive way to determine which
threads share filesystem contexts, FDs, namespaces, VMAs, and so
on would be infinitely useful. My current plan of attack was to
tinker with one and see if I could observe it from the others.
That's all I can think of for now. If any of these look even
remotely plausible to incorporate, I'd be quite happy to prepare
patches (2 and 3 seem trivial enough :)
Kind regards,
Bernard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]