[OpenAFS] Re: File locking

[Andrew Deason]

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
confusing.

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
9.

A proposed fix is here (gerrit 11316):
<http://git.openafs.org/?p=openafs.git;a=commitdiff_plain;h=93451d74474bcd8ed9e0f59cf690d3d61c3022f9>

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

-- 
Andrew Deason
adeason@sinenomine.net