Re: [PATCH v2 bpf-next 1/4] bpf: introduce task_vma bpf_iter

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Song Liu <songliubraving@fb.com>
Cc: Yonghong Song <yhs@fb.com>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"ast@kernel.org" <ast@kernel.org>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"andrii@kernel.org" <andrii@kernel.org>,
	"john.fastabend@gmail.com" <john.fastabend@gmail.com>,
	"kpsingh@chromium.org" <kpsingh@chromium.org>,
	Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 1/4] bpf: introduce task_vma bpf_iter
Date: Tue, 5 Jan 2021 08:27:08 -0800	[thread overview]
Message-ID: <CAADnVQJ5eKCnkoUV-K-S80-0CGLNstNw50OX2tndLM+Or+CSHQ@mail.gmail.com> (raw)
In-Reply-To: <6E122A14-0F77-46F9-8891-EDF4DB494E37@fb.com>

On Mon, Jan 4, 2021 at 9:47 PM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Jan 4, 2021, at 5:46 PM, Alexei Starovoitov <alexei.starovoitov@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 <yhs@fb.com> wrote:
> >>>
> >>>
> >>>
> >>> On 12/17/20 9:23 PM, Alexei Starovoitov wrote:
> >>>> On Thu, Dec 17, 2020 at 8:33 PM Song Liu <songliubraving@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.