[OpenAFS] Re: File locking

[Stephan Wiesand]

Todd,

unless there's a problem found with it, this patch will be part of the =
next ordinary stable release.

Thanks a lot for reporting your problems with 1.6 and reporting back on =
the proposed fix. And Kudos to Andrew for whipping that up so swiftly.

	Stephan

On Jul 17, 2014, at 21:20 , Todd Lewis wrote:

> Andrew,
>=20
> The suggested patch was applied, installed, and our application now =
works correctly again with the new client.
>=20
> Thank you very much for your timely response. Looking forward to this =
patch making its way to release soon.
> --
> Todd_Lewis@unc.edu
>=20
> On 07/17/2014 11:59 AM, Andrew Deason sent:
>> On Thu, 17 Jul 2014 10:07:07 -0400
>> Todd Lewis <Todd_Lewis@unc.edu> wrote:
>>=20
>>> 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.
>>=20
>> I assume the path you gave was for an RO volume, yes?
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> A proposed fix is here (gerrit 11316):
>> =
<http://git.openafs.org/?p=3Dopenafs.git;a=3Dcommitdiff_plain;h=3D93451d74=
474bcd8ed9e0f59cf690d3d61c3022f9>
>>=20
>> If you are able to test code changes in your client, give that a try.

--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany