On Wed, Sep 8, 2021 at 6:10 PM Yonghong Song <yhs@xxxxxx> wrote:
>
>
>
> On 9/8/21 8:12 AM, Liam Howlett wrote:
> > * Luigi Rizzo <lrizzo@xxxxxxxxxx> [210908 10:44]:
> >> On Wed, Sep 8, 2021 at 4:16 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >>>
> >>> On Wed, Sep 08, 2021 at 10:53:26AM -0300, Jason Gunthorpe wrote:
> >>>> On Wed, Sep 08, 2021 at 02:20:17PM +0200, Daniel Borkmann wrote:
> >>>>
> >>>>>> The warning is due to commit 5b78ed24e8ec("mm/pagemap: add mmap_assert_locked() annotations to find_vma*()")
> >>>>>> which added mmap_assert_locked() in find_vma() function. The mmap_assert_locked() function
> >>>>>> asserts that mm->mmap_lock needs to be held. But this is not the case for
> >>>>>> bpf_get_stack() or bpf_get_stackid() helper (kernel/bpf/stackmap.c), which
> >>>>>> uses mmap_read_trylock_non_owner() instead. Since mm->mmap_lock is not held
> >>>>>> in bpf_get_stack[id]() use case, the above warning is emitted during test run.
> >> ...
> >>>>> Luigi / Liam / Andrew, if the below looks reasonable to you, any objections to route the
> >>>>> fix with your ACKs via bpf tree to Linus (or strong preference via -mm fixes)?
> >>>>
> >>>> Michel added this remark along with the mmap_read_trylock_non_owner:
> >>>>
> >>>> It's still not ideal that bpf/stackmap subverts the lock ownership in this
> >>>> way. Thanks to Peter Zijlstra for suggesting this API as the least-ugly
> >>>> way of addressing this in the short term.
> >>>>
> >>>> Subverting lockdep and then adding more and more core MM APIs to
> >>>> support this seems quite a bit more ugly than originally expected.
> >>>>
> >>>> Michel's original idea to split out the lockdep abuse and put it only
> >>>> in BPF is probably better. Obtain the mmap_read_trylock normally as
> >>>> owner and then release ownership only before triggering the work. At
> >>>> least lockdep will continue to work properly for the find_vma.
> >>>
> >>> The only right solution to all of this is the below. That function
> >>> downright subverts all the locking rules we have. Spreading the hacks
> >>> any further than that one function is absolutely unacceptable.
> >>
> >> I'd be inclined to agree that we should not introduce hacks around
> >> locking rules. I don't know enough about the constraints of
> >> bpf/stackmap, how much of a performance penalty do we pay with Peter's
> >> patch,
> >> and ow often one is expected to call this function ?
> >>
> >> cheers
> >> luigi
> >
> > The hack already exists. The symptom of the larger issue is that
> > lockdep now catches the hack when using find_vma().
> >
> > If Peter's solution is acceptable to the bpf folks, then we can go ahead
> > and drop the option of using the non_owner variant - which would be
> > best. Otherwise the hack around the locking rule still exists as long
> > as the find_vma() interface isn't used.
>
> Hi, Peter, Luigi, Liam, Jason,
>
> Peter's solution will definitely break user applications using
> BPF_F_USER_BUILD_ID feature
Again I am ignorant on the details so if you can clarify the following
it may help me and others to better understand the problem:
1. Peter's patch appears to just take the same "fallback" path
that would be taken if the trylock failed.
Is this really a breakage or just loss of performance ?
I would expect the latter, since it is called "fallback".
2. Assuming it is just loss of performance, it becomes important to
clarify how much we are losing, and whether this is something to
worry about, or it is only some rarely used function. Things like:
- total CPU cost + latency difference (including deferred work, if any)
in the "trylock ok" and "trylock failed" cases.
I have no idea but since there is a trylock involved, I suppose
we are in O(500ns) territory (when cold or contended)
- how often we'd expect calls to the bpf helpers involved
(BPF_F_USER_BUILD_ID in bpf_get_stack() or bpf_get_stack_pe()) ?
thanks
luigi
