On Mon, Jan 4, 2021 at 9:47 PM Song Liu <songliubraving@xxxxxx> wrote: > > > > > On Jan 4, 2021, at 5:46 PM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Fri, Dec 18, 2020 at 05:23:25PM +0000, Song Liu wrote: > >> > >> > >>> On Dec 18, 2020, at 8:38 AM, Yonghong Song <yhs@xxxxxx> wrote: > >>> > >>> > >>> > >>> On 12/17/20 9:23 PM, Alexei Starovoitov wrote: > >>>> On Thu, Dec 17, 2020 at 8:33 PM Song Liu <songliubraving@xxxxxx> 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.
