> On Jan 5, 2021, at 8:27 AM, Alexei Starovoitov <alexei.starovoi...@gmail.com>
> wrote:
>
> On Mon, Jan 4, 2021 at 9:47 PM Song Liu <songliubrav...@fb.com> wrote:
>>
>>
>>
>>> On Jan 4, 2021, at 5:46 PM, Alexei Starovoitov
>>> <alexei.starovoi...@gmail.com> wrote:
>>>
>>> On Fri, Dec 18, 2020 at 05:23:25PM +0000, Song Liu wrote:
>>>>
>>>>
>>>>> On Dec 18, 2020, at 8:38 AM, Yonghong Song <y...@fb.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 12/17/20 9:23 PM, Alexei Starovoitov wrote:
>>>>>> On Thu, Dec 17, 2020 at 8:33 PM Song Liu <songliubrav...@fb.com> wrote:
>>>>>>>>
>>>>>>>> ahh. I missed that. Makes sense.
>>>>>>>> vm_file needs to be accurate, but vm_area_struct should be accessed as
>>>>>>>> ptr_to_btf_id.
>>>>>>>
>>>>>>> Passing pointer of vm_area_struct into BPF will be tricky. For example,
>>>>>>> shall we
>>>>>>> allow the user to access vma->vm_file? IIUC, with ptr_to_btf_id the
>>>>>>> verifier will
>>>>>>> allow access of vma->vm_file as a valid pointer to struct file.
>>>>>>> However, since the
>>>>>>> vma might be freed, vma->vm_file could point to random data.
>>>>>> I don't think so. The proposed patch will do get_file() on it.
>>>>>> There is actually no need to assign it into a different variable.
>>>>>> Accessing it via vma->vm_file is safe and cleaner.
>>>>>
>>>>> I did not check the code but do you have scenarios where vma is freed but
>>>>> old vma->vm_file is not freed due to reference counting, but
>>>>> freed vma area is reused so vma->vm_file could be garbage?
>>>>
>>>> AFAIK, once we unlock mmap_sem, the vma could be freed and reused. I guess
>>>> ptr_to_btf_id
>>>> or probe_read would not help with this?
>>>
>>> Theoretically we can hack the verifier to treat some ptr_to_btf_id as "less
>>> valid" than the other ptr_to_btf_id, but the user experience will not be
>>> great.
>>> Reading such bpf prog will not be obvious. I think it's better to run bpf
>>> prog
>>> in mmap_lock then and let it access vma->vm_file. After prog finishes the
>>> iter
>>> bit can do if (mmap_lock_is_contended()) before iterating. That will deliver
>>> better performance too. Instead of task_vma_seq_get_next() doing
>>> mmap_lock/unlock at every vma. No need for get_file() either. And no
>>> __vm_area_struct exposure.
>>
>> I think there might be concern calling BPF program with mmap_lock,
>> especially that
>> the program is sleepable (for bpf_d_path). It shouldn't be a problem for
>> common
>> cases, but I am not 100% sure for corner cases (many instructions in BPF +
>> sleep).
>> Current version is designed to be very safe for the workload, which might be
>> too
>> conservative.
>
> I know and I agree with all that, but how do you propose to fix the
> vm_file concern
> without holding the lock while prog is running? I couldn't come up with a way.
I guess the gap here is that I don't see why __vm_area_struct exposure is an
issue.
It is similar to __sk_buff, and simpler (though we had more reasons to introduce
__sk_buff back when there wasn't BTF).
If we can accept __vm_area_struct, current version should work, as it doesn't
have
problem with vm_file.
Thanks,
Song
