[OpenAFS] Re: File locking

Andrew Deason adeason@sinenomine.net
Thu, 17 Jul 2014 10:59:26 -0500

On Thu, 17 Jul 2014 10:07:07 -0400
Todd Lewis <Todd_Lewis@unc.edu> wrote:

> Was there some change in file locking semantics that would make sense
> of this? Does this application tickle a corner case error in openafs's
> file locking, or does more rigorous lock handling in the newer client
> expose a bug in the application? I have tried to replicate the failure
> with a very simple C program with no success, but that mostly
> indicates I'm not sure what I'm testing for.

I assume the path you gave was for an RO volume, yes?

In that case, no, it's just a mistake; specifically, my mistake (sorry).
It's trying to return the error EBADF (9) to you, which is wrong, and
it's returning that code incorrectly, which makes this a bit more

There was some code added a while back to skip some processing for locks
on RO volumes. But for some reason I added some linux-specific check
much earlier before the platform-agnostic check, which makes this fail
for F_GETLK requests in addition to F_SETLK ones. (For F_SETLK, we
should indeed fail with EBADF here.) I'm not sure why I did that, since
this should have been handled by the platform-agnostic code; none of my
notes or comments about this seem to say anything about it.

And in that Linux-specific check, the error is just plain returned
incorrectly (which just happens from time to time, since Linux has a
very specific different way of doing this). I think I just didn't notice
this when running it originally (and almost missed it just now), because
I saw a '9' get returned and assumed that's what was supposed to happen.
But it's not, of course; fcntl is supposed to return -1 and set errno to

A proposed fix is here (gerrit 11316):

If you are able to test code changes in your client, give that a try.

Andrew Deason