Skip to content

Conversation

@Keno
Copy link
Member

@Keno Keno commented Aug 24, 2016

First add syscall buffering for rt_sigprocmask, second if a clone forks the address space, keep the state of thread local initialization since there won't be an explicit re-initialization (and without this the syscallbuf is effectively disabled).

if (set && (how == SIG_BLOCK || how == SIG_SETMASK)) {
local_memcpy(&modified_set, set, sizeof(kernel_sigset_t));
// SIGSTKFLT (PerfCounters::TIME_SLICE_SIGNAL) and
// SIGPWR(SYSCALLBUF_DESCHED_SIGNAL) are used by
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"by rr"

@rocallahan
Copy link
Collaborator

Looks good!

@rocallahan
Copy link
Collaborator

This causes a number of test failures...

@Keno
Copy link
Member Author

Keno commented Aug 24, 2016

Oops, sorry. I will take a look.

@rocallahan
Copy link
Collaborator

sigprocmask is one. I'm looking into it...

@Keno
Copy link
Member Author

Keno commented Aug 24, 2016

Ah yes, of course. Should have realized that (well, should have remembered that I realized that ;)). This gets our understanding of which signals are blocked out of whack, which as we learned before is a bad idea. I had thought about using an extra thread-local field to hold a copy of the current sigmask that rr can reload when it needs to. Thoughts?

@rocallahan
Copy link
Collaborator

This looks like it should be easy but it's not :-(

@rocallahan
Copy link
Collaborator

ah right. I thought about that and then forgot about it.

@rocallahan
Copy link
Collaborator

The way we handle this for mprotect is that we create a list of "mprotect records" and apply them in RecordTask::maybe_flush_syscallbuf. It's a little more tricky for mprotect because we need to also do work during replay, whereas here we don't.

@Keno
Copy link
Member Author

Keno commented Aug 24, 2016

that could work, but I don't think it needs to be that fancy, because we don't really need to know the full history.

@rocallahan
Copy link
Collaborator

Storing a signal mask in syscallbuf_hdr and saving/reloading it after each syscallbuf flush would work. The only thing is it creates a memory divergence unless we also maintain it during replay.

@rocallahan
Copy link
Collaborator

Maybe stick it in preload_globals and hack iterate_checksums to zero it out temporarily so it doesn't break checksums.

@Keno
Copy link
Member Author

Keno commented Aug 25, 2016

Unless I'm missing something, we can't put this in preload_globals because it's a per-task setting, but preload_globals is not per-task. The syscallbuf_hdr would work though and we can still hack it into iterate_checksums, since the syscallbuf already has special handling anyway.

@rocallahan
Copy link
Collaborator

sycallbuf_hdr sounds fine.

It can go in preload_globals as long as we set it in Task::resume_execution like we do for thread_locals_initialized.

@Keno
Copy link
Member Author

Keno commented Aug 25, 2016

Ok, try this. Passed tests for me, but I'm running them again just to be sure ;). Also GitHub appears to be confused by me having put a newer commit in front of the older ones, but in the actual git history they should be in proper order.

Keno added 3 commits August 24, 2016 23:51
In preparation of being able to buffer system calls that affect the
signal mask, keep a copy of blocked_sigs in syscallbuf_hdr, save
it whenever modified due to an event not visible to preload, and
reload it whenever queried whether a particular signal is blocked.
…state

A priori, there's nothing wrong with keeping the existing TLS descriptor
if the VM is forked, since the two threads won't clobber each other.
This fixes a performance problem in single threaded processes that
fork (where thread locals get initialized only because of the preload
library), since the forked process would never set a new TLS descriptor.
@Keno
Copy link
Member Author

Keno commented Aug 25, 2016

Found one small thing, but now should be good to go.

@rocallahan
Copy link
Collaborator

Merged. Thanks!!!

@rocallahan rocallahan closed this Aug 25, 2016
@Keno
Copy link
Member Author

Keno commented Aug 25, 2016

My pleasure as always ;).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants