Re: [PATCH 1/3] CIFS: Fix the VFS brlock cache usage in posix locking case

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 30, 2011 at 4:26 AM, Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote:
> 2011/10/30 Jeff Layton <jlayton@xxxxxxxxx>:
>> On Sat, 29 Oct 2011 17:17:57 +0400
>> Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote:
>>
>>> Request to the cache in FL_POSIX case only.
>>>
>>> Signed-off-by: Pavel Shilovsky <piastry@xxxxxxxxxxx>
>>> ---
>>>  fs/cifs/file.c |   10 ++++++++--
>>>  1 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
>>> index 91e05f2..c1f063c 100644
>>> --- a/fs/cifs/file.c
>>> +++ b/fs/cifs/file.c
>>> @@ -793,6 +793,9 @@ cifs_posix_lock_test(struct file *file, struct file_lock *flock)
>>>       struct cifsInodeInfo *cinode = CIFS_I(file->f_path.dentry->d_inode);
>>>       unsigned char saved_type = flock->fl_type;
>>>
>>> +     if ((flock->fl_flags & FL_POSIX) == 0)
>>> +             return 1;
>>> +
>>>       mutex_lock(&cinode->lock_mutex);
>>>       posix_test_lock(file, flock);
>>>
>>> @@ -809,12 +812,15 @@ static int
>>>  cifs_posix_lock_set(struct file *file, struct file_lock *flock)
>>>  {
>>>       struct cifsInodeInfo *cinode = CIFS_I(file->f_path.dentry->d_inode);
>>> -     int rc;
>>> +     int rc = 1;
>>> +
>>> +     if ((flock->fl_flags & FL_POSIX) == 0)
>>> +             return rc;
>>>
>>>       mutex_lock(&cinode->lock_mutex);
>>>       if (!cinode->can_cache_brlcks) {
>>>               mutex_unlock(&cinode->lock_mutex);
>>> -             return 1;
>>> +             return rc;
>>>       }
>>>       rc = posix_lock_file_wait(file, flock);
>>>       mutex_unlock(&cinode->lock_mutex);
>>
>> Hmm... I do have an open samba.org bug to allow flock() to work on cifs
>> as well. Would that be doable with your new locking code? In any case,
>> this seems ok:
>>
>> Reviewed-by: Jeff Layton <jlayton@xxxxxxxxx>
>
> Thanks for the review.
>
> Do you mean https://bugzilla.samba.org/show_bug.cgi?id=6843 ?
>
> I don't see any problems with implementing flock() on top of the new
> locking code. We will treat it as usual brlock from 0 to offset_max -
> the only difference is when we negotiate posix locking we should call
> flock_lock_file_wait rather than posix_lock_file_wait (add such a
> check in cifs_posix_lock_test and cifs_posix_lock_set).

yes


-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux