[PATCH 1/4] mm: introduce vma_set_file function v2

[John Hubbard]

On 10/9/20 12:33 AM, Christian König wrote:
> Am 08.10.20 um 23:49 schrieb John Hubbard:
>> On 10/8/20 4:23 AM, Christian König wrote:
>> ...
>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>> index 3d69e51f3e4d..c9d5f1a38af3 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>> @@ -893,8 +893,8 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
>>>        * requires avoiding extraneous references to their filp, hence why
>>>        * we prefer to use an anonymous file for their mmaps.
>>>        */
>>> -    fput(vma->vm_file);
>>> -    vma->vm_file = anon;
>>> +    vma_set_file(vma, anon);
>>> +    fput(anon);
>>
>> That's one fput() too many, isn't it?
> 
> No, the other cases were replacing the vm_file with something pre-allocated and also grabbed a new 
> reference.
> 
> But this case here uses the freshly allocated anon file and so vma_set_file() grabs another extra 
> reference which we need to drop.
> 
> The alternative is to just keep it as it is. Opinions?
> 

I think just a small comment for these cases, is probably about right.

>> ...
>>
>>> diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
>>> index 10b4be1f3e78..a51dc089896e 100644
>>> --- a/drivers/staging/android/ashmem.c
>>> +++ b/drivers/staging/android/ashmem.c
>>> @@ -450,9 +450,8 @@ static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
>>>           vma_set_anonymous(vma);
>>>       }
>>>   -    if (vma->vm_file)
>>> -        fput(vma->vm_file);
>>> -    vma->vm_file = asma->file;
>>> +    vma_set_file(vma, asma->file);
>>> +    fput(asma->file);
>>
>> Same here: that fput() seems wrong, as it was already done within vma_set_file().
> 
> No, that case is correct as well. The Android code here has the matching get_file() a few lines up, 
> see the surrounding code.
> 
> I didn't wanted to replace that since it does some strange error handling here, so the result is 
> that we need to drop the extra reference as again.
> 
> We could also keep it like it is or maybe better put a TODO comment on it.
> 

Yeah, I think a comment is a good way to go.


thanks,
-- 
John Hubbard
NVIDIA