4 ms·

That's very interesting. Userfaultfd opened a lot of features in Linux. When I saw 'unfork' I thought 'someone found out how to replace the current process wit

That's very interesting. Userfaultfd opened a lot of features in Linux. When I saw 'unfork' I thought 'someone found out how to replace the current process with a child process that was a older snapshot'. Any idea on how to do this? Like 'OK I did something wrong, let me back up a bit, kill me, replace me with my child x and refather every other one of my children processes to child x and gooo'.

agumonkey 5y ago
ProlOS
- touisteur 5y ago
  OK I really tried but my Googlefu seems lacking. Any pointer, pretty please?
  - agumonkey 5y ago
    Oh it was mostly a pun blending prolog like backtracking at the os-process level.
    - touisteur 5y ago
      I figured. I went down the rabbit hole, prolo, and prolog and hoped it wasn't a pun :-) yes I think backtracking as a general OS mechanism. Since the kernel already knows which pages differ between both processes, and could 'just' plug back any socket, file, shm, pipe 'as is' when 'restoring'. All the state is know to the OS! Maybe something with ebpf in twelve years...
      - agumonkey 5y ago
        and live exploratory debugging when your fs fails
        touisteur 5y ago
        Well if I could synchronise that with lvm snapshots and go back... Once you start going the backtracking rabbit hole, there's lots of thing one can imagine.
        agumonkey 5y ago
        time to make a pull-request
        touisteur 5y ago
        Wish I had the chops. Time to find money to have someone do it you mean.
        agumonkey 5y ago
        who sets up the kickstarter ? :p
snarfy 5y ago
iirc emacs implements a generic 'unexec' function which serializes the current process state so it can be reloaded later. Seems like you could use it to make snapshots.
- touisteur 5y ago
  Thanks for the emacs pointer. Interesting. It screams of continuations. I know how to do snapshots of a process, what with criu. But if I just want a checkpoint to go back later, not a full serialization, and I don't want to save/restore a complete process, but take advantage of fork()'s CoW to save the least possible in a stopped process, then be able to come back. The rest of fork()' semantics are a problem, with threads, sockets, signals that are not passed down. An example of that approach is perf-fuzz where they add a new syscall to make fuzzing faster. [0] https://github.com/sslab-gatech/perf-fuzz https://github.com/sslab-gatech/perf-fuzz
  - the8472 5y ago
    Does `rr` fit the bill?
    - touisteur 5y ago
      From memory rr has a substantive recording overhead, and is specially made for debugging, right? But yes it is very useful to analyse a past state and to understand a chain of events. I should clarify my use case: I would use such a feature (go back to previous state) for a speculative execution tool. I'd execute the happy path all the time assuming no error occured, but if I found out later that something went wrong somewhere, I'd want to go back and start from there knowing what went wrong, and so on. With as little perf loss as possible. Not sure my explanation makes sense. I know about dmtcp, criu, vm snapshots, but they all come with big overhead (I don't want to pay too much for the checkpoint). The closest I found was @gamozolabs amazing work on snapshot fuzzing (pushing the limit of what's possible on x86_64 hardware, including using Intel PML - similar to userfaultfd but hw-accelerated...).
      - 5y ago
mattgreenrocks 5y ago
This is the first I've heard of userfaultfd! It is rather mind-blowing. Thank you for the comment.
- touisteur 5y ago
  There are so many features in the Linux kernel it sometimes blows my mind. eventfd, signalfd, timerfd, memfd, pidfd. The whole fricking tc/qdisc featureset (OMG). netlink. io_uring. criu. SO_REUSEPORT. Teaming. Namespaces. veths. vsocks. Dpdk/netmap/af_packet. XDP ! Seccomp. I mean look at that https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking https://developers.redhat.com/blog/2018/10/22/introduction-t... Amazing.
CJefferson 5y ago
I would really like that function. While fork is often a bad idea, it can be an easy way of adding parallelization and backtracking to old large serial C code bases.
IanGabes 5y ago
You might be interested in CRIU: https://github.com/checkpoint-restore/criu https://github.com/checkpoint-restore/criu
- touisteur 5y ago
  I'm hoping somewhere deep in Google or Cloudflare someone is implementing all this in chained ebpf scriptw...
- cpufry 5y ago
  this is neat. thanks.
remram 5y ago
Easier to do it the other way: when you fork, keep the parent as the snapshot and keep going in the child. That way you can back up by terminating and resuming in the parent. I think this is what timetravelpdb does for Python: https://github.com/TomOnTime/timetravelpdb https://github.com/TomOnTime/timetravelpdb
- touisteur 5y ago
  Yeah, thanks it was my first idea, but then 1) I'd have to re-attach everything to the child process and 2) I'd have to go one step further for every snapshot, right ? If everything goes well and I want to continue, next snapshot I'll have to fork the child process, and so on, no? The idea is to keep a somewhat short (some minutes?) of snapshots. Thanks for the timetravelpdb link!
  - thomasballinger 5y ago
    Here's another implementation of what's described above, it forks on each invocation of readline to provide undo for interactive interpreters. https://github.com/thomasballinger/rlundo https://github.com/thomasballinger/rlundo
    - touisteur 5y ago
      OK I love this, and not just because of the calls to system(nc) :-) Your code made me think, maybe I'm tying myself into knots... But my thing is making hundred thousands of checkpoints so I'd have to have as many forks as savespoints. No way to coalesce parents, maybe reparenting could work there...

agumonkey 5y ago

ProlOS

touisteur 5y ago
OK I really tried but my Googlefu seems lacking. Any pointer, pretty please?
- agumonkey 5y ago
  Oh it was mostly a pun blending prolog like backtracking at the os-process level.
  - touisteur 5y ago
    I figured. I went down the rabbit hole, prolo, and prolog and hoped it wasn't a pun :-) yes I think backtracking as a general OS mechanism. Since the kernel already knows which pages differ between both processes, and could 'just' plug back any socket, file, shm, pipe 'as is' when 'restoring'. All the state is know to the OS! Maybe something with ebpf in twelve years...
    - agumonkey 5y ago
      and live exploratory debugging when your fs fails
      - touisteur 5y ago
        Well if I could synchronise that with lvm snapshots and go back... Once you start going the backtracking rabbit hole, there's lots of thing one can imagine.
        agumonkey 5y ago
        time to make a pull-request
        touisteur 5y ago
        Wish I had the chops. Time to find money to have someone do it you mean.
        agumonkey 5y ago
        who sets up the kickstarter ? :p

snarfy 5y ago

iirc emacs implements a generic 'unexec' function which serializes the current process state so it can be reloaded later. Seems like you could use it to make snapshots.

touisteur 5y ago
Thanks for the emacs pointer. Interesting. It screams of continuations. I know how to do snapshots of a process, what with criu. But if I just want a checkpoint to go back later, not a full serialization, and I don't want to save/restore a complete process, but take advantage of fork()'s CoW to save the least possible in a stopped process, then be able to come back. The rest of fork()' semantics are a problem, with threads, sockets, signals that are not passed down. An example of that approach is perf-fuzz where they add a new syscall to make fuzzing faster. [0] https://github.com/sslab-gatech/perf-fuzz https://github.com/sslab-gatech/perf-fuzz
- the8472 5y ago
  Does `rr` fit the bill?
  - touisteur 5y ago
    From memory rr has a substantive recording overhead, and is specially made for debugging, right? But yes it is very useful to analyse a past state and to understand a chain of events. I should clarify my use case: I would use such a feature (go back to previous state) for a speculative execution tool. I'd execute the happy path all the time assuming no error occured, but if I found out later that something went wrong somewhere, I'd want to go back and start from there knowing what went wrong, and so on. With as little perf loss as possible. Not sure my explanation makes sense. I know about dmtcp, criu, vm snapshots, but they all come with big overhead (I don't want to pay too much for the checkpoint). The closest I found was @gamozolabs amazing work on snapshot fuzzing (pushing the limit of what's possible on x86_64 hardware, including using Intel PML - similar to userfaultfd but hw-accelerated...).
    - 5y ago

mattgreenrocks 5y ago

This is the first I've heard of userfaultfd! It is rather mind-blowing. Thank you for the comment.

touisteur 5y ago
There are so many features in the Linux kernel it sometimes blows my mind. eventfd, signalfd, timerfd, memfd, pidfd. The whole fricking tc/qdisc featureset (OMG). netlink. io_uring. criu. SO_REUSEPORT. Teaming. Namespaces. veths. vsocks. Dpdk/netmap/af_packet. XDP ! Seccomp. I mean look at that https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking https://developers.redhat.com/blog/2018/10/22/introduction-t... Amazing.

CJefferson 5y ago

I would really like that function. While fork is often a bad idea, it can be an easy way of adding parallelization and backtracking to old large serial C code bases.

IanGabes 5y ago

You might be interested in CRIU: https://github.com/checkpoint-restore/criu https://github.com/checkpoint-restore/criu

touisteur 5y ago
I'm hoping somewhere deep in Google or Cloudflare someone is implementing all this in chained ebpf scriptw...
cpufry 5y ago
this is neat. thanks.

remram 5y ago

Easier to do it the other way: when you fork, keep the parent as the snapshot and keep going in the child. That way you can back up by terminating and resuming in the parent. I think this is what timetravelpdb does for Python: https://github.com/TomOnTime/timetravelpdb https://github.com/TomOnTime/timetravelpdb

touisteur 5y ago
Yeah, thanks it was my first idea, but then 1) I'd have to re-attach everything to the child process and 2) I'd have to go one step further for every snapshot, right ? If everything goes well and I want to continue, next snapshot I'll have to fork the child process, and so on, no? The idea is to keep a somewhat short (some minutes?) of snapshots. Thanks for the timetravelpdb link!
- thomasballinger 5y ago
  Here's another implementation of what's described above, it forks on each invocation of readline to provide undo for interactive interpreters. https://github.com/thomasballinger/rlundo https://github.com/thomasballinger/rlundo
  - touisteur 5y ago
    OK I love this, and not just because of the calls to system(nc) :-) Your code made me think, maybe I'm tying myself into knots... But my thing is making hundred thousands of checkpoints so I'd have to have as many forks as savespoints. No way to coalesce parents, maybe reparenting could work there...