On Wed, Feb 22, 2017 at 1:25 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> On Wed, 2017-02-22 at 07:13 -0500, Jeff Layton wrote:
>> On Tue, 2017-02-21 at 10:39 -0500, Benjamin Coddington wrote:
>> > Set FL_CLOSE in fl_flags as in locks_remove_posix() when clearing locks.
>> > NFS will check for this flag to ensure an unlock is sent in a following
>> > patch.
>> >
>> > Signed-off-by: Benjamin Coddington <bcodding@xxxxxxxxxx>
>> > ---
>> > fs/locks.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/fs/locks.c b/fs/locks.c
>> > index 26811321d39b..af2031a1fcff 100644
>> > --- a/fs/locks.c
>> > +++ b/fs/locks.c
>> > @@ -2504,7 +2504,7 @@ locks_remove_flock(struct file *filp, struct file_lock_context *flctx)
>> > .fl_owner = filp,
>> > .fl_pid = current->tgid,
>> > .fl_file = filp,
>> > - .fl_flags = FL_FLOCK,
>> > + .fl_flags = FL_FLOCK | FL_CLOSE,
>> > .fl_type = F_UNLCK,
>> > .fl_end = OFFSET_MAX,
>> > };
>>
>> Looks good. I'm fine with merging this one via the NFS tree, btw...
>>
>> Reviewed-by: Jeff Layton <jlayton@xxxxxxxxxx>
>>
>
> (cc'ing linux-fsdevel and Miklos)
>
> Hmm, that said, this potentially may affect other filesystems. If you do
> any more postings of this set, please cc linux-fsdevel.
>
> In particular, I'll note that fuse has this:
>
> /* Unlock on close is handled by the flush method */
> if (fl->fl_flags & FL_CLOSE)
> return 0;
>
> I don't see any lock handling in fuse_flush (though it does pass down a
> lockowner). I guess the expectation is that the userland driver should
> close down POSIX locks when the flush method is called.
Right.
>
> Miklos, does this also apply to flock locks? Would Ben's patch cause any
> grief here?
Yes, it would make the final close of file not unlock flocks on that open file.
Simple fix is to change that condition to
#define FL_CLOSE_POSIX (FL_POSIX | FL_CLOSE)
if (fl->fl_flags & FL_CLOSE_POSIX == FL_CLOSE_POSIX)
return 0;
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
