DynamoRIO / DynamoRIO/dynamorio

handle 2 different signalfd fd's with different but overlapping sets of signals

Open
#1,189 0 comments 0 reactions 0 assignees View on GitHub
Migrated OpSys-Linux Priority-Low
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 15h
Merged PRs (30d)
31

Description

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on June 13, 2013 14:24:36_

My pipe emulation solution for signalfd ( issue #1138 ) has a problem: it can't
properly handle the app creating 2 different fd's that each cover a
different but overlapping set of signals! I don't see how we can support
that without watching all the SYS_read, SYS_poll, SYS_select, and related
system calls and looking for these fd's so we know which pipe to write to.
We'd create a new pipe per signalfd fd. We'd map each signalfd fd to a
dcontext,sigmask pair, and then prior to the read/poll/select syscall we'd
check the target thread's pending queue for each signal in the sigmask: if
one is present, we'd go and write to the pipe.

How about punting on that for now. Seems better to err on the side of
sending too many signals, instead of having the app hang. Also, let's
avoid the complexity of multiple pipe storage. If there's any overlap w/
an existing signal covered by an existing pipe, a new signalfd request
simply uses that pipe (conflating the two) and expands it to the union of
all prior requests. If the app has multiple signals in its mask and
doesn't even check which signal it got then we'll break the app: but if it
checks this should be ok.

This issue covers properly handling it though we may wait until we see an
app that actually hits this corner case as it's not simple to handle.

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1189_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.