Re: The file_lock_operatoins.lock API seems to be a BAD API.

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

On Thu, May 28 2020, J. Bruce Fields wrote:

> On Thu, May 28, 2020 at 04:14:44PM +1000, NeilBrown wrote:
>> I don't think we should just fix all those bugs in those filesystems.
>> I think that F_UNLCK should *always* remove the lock/lease.
>> I imaging this happening by  *always* calling posix_lock_file() (or
>> similar) in the unlock case - after calling f_op->lock() first if that
>> is appropriate.
>> 
>> What do people think?  It there on obvious reason that is a non-starter?
>
> Isn't NFS unlock like close, in that it may be our only chance to return
> IO errors?

Is it?  fcntl() isn't documented as returning ENOSPC, EDQUOT or EIO.

>
> But I guess you're not saying that unlock can't return errors, just that
> it should always remove the lock whether it returns 0 or not.

No I wasn't, but I might.
One approach that I was considering for making the API more robust was
to propose a separate "unlock" file_operation.  All unlock requests
would go through this, and it would have a 'void' return type.
Would that be sufficient to encourage programmers to handle their own
errors and not think they can punt?

But yes - even if unlock returns an error, it should (locally) remove
any locks - much as 'close()' will always close the fd (if it was
actually open) even if it reports an error.

Thanks,
NeilBrown

>
> Hm.
>
> --b.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]