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?
Updated by Greg Farnum over 12 years ago
- Status changed from New to Rejected
Eh, I forgot that I wrote the only wait locking in xfstests. This is probably just how it goes and I corrected my work there.
Updated by Greg Farnum over 12 years ago
- Status changed from Rejected to Resolved
Aha! This was actually introduced by Sage in his fix for wait lock removal.
I fixed it by removing the locking layer's auto-locking of wait locks, since that was sort of pointless anyway.
Actions