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.
