On Thu, 11 Aug 2016, Greg Hudson wrote:
> I do not understand the kernel behavior reflected in this trace
> output. For fd 3 (principal.ok), we see:
Yes, it would be good to get the kernel version from the reporter on the
affected machine (and the unaffected ones, too, for comparison).
(Using reportbug instead of manual mail to sub...@bugs.debian.org would
include that information automatically.)
(Including full text from Greg's message since it looks like it did not
make it to Michael originally.)
-Ben
> fcntl64(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
> l_len=6950411022381350912}) = -1 EINVAL (Invalid argument)
> fcntl64(3, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0})
> = 0
> fcntl64(3, F_OFD_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0,
> l_len=6950411022381350912}) = 0
> fcntl64(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
> l_len=6950411022381350912}
>
> So it tries to acquire an OFD lock and fails, then falls back to a POSIX
> lock. When it releases the lock, releasing it as an OFD lock succeeds,
> so it doesn't fall back to releasing a POSIX lock. It then tries to
> acquire an OFD lock and deadlocks against its POSIX lock.
>
> For fd 5 (kadm5.lock), it also falls back to acquiring a POSIX lock.
> Releasing the lock as an OFD lock fails, so it correctly falls back to
> releasing its POSIX lock:
>
> fcntl64(5, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
> l_len=6950411022381350912}) = -1 EINVAL (Invalid argument)
> fcntl64(5, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0})
> = 0
> fcntl64(5, F_OFD_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0,
> l_len=6950411022381350912}) = -1 EINVAL (Invalid argument)
> fcntl64(5, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0})
> = 0
>
> From the code, l_len should clearly be 0 (see lib/krb5/os/lock_file.c
> line 131), but strace is displaying a large number instead. I don't
> know if this is an strace display bug or something else, and whether it
> is related to the EINVAL results. The large value appears in both
> successful and failed F_OFD_SETLKW/F_UNLCK calls.
>
>
