Actions
Bug #1475
closedOur wait lock implementation is EINTR-happy
% Done:
0%
Source:
Tags:
Backport:
Regression:
Severity:
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Description
So according to the fcntl man page,
F_SETLKW This command shall be equivalent to F_SETLK except that if a shared or exclusive lock is blocked by other locks, the thread shall wait until the request can be satisfied. If a signal that is to be caught is received while fcntl() is waiting for a region, fcntl() shall be interrupted. Upon return from the signal handler, fcntl() shall return -1 with errno set to [EINTR], and the lock operation shall not be done.
I'm getting EINTR a lot in testing, when it doesn't seem like I should be. Today it's busting up xfstests' locktest exeutable. I could wrap it in an EINTR loop (and most users will), but I'd really like to know what's actually happening. Is our code tossing signals out overmuch?
Actions