Re: [PATCH v2 bpf-next 03/17] bpf: Introduce BPF trampoline

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Song Liu <songliubraving@fb.com>
Cc: Song Liu <liu.song.a23@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"x86@kernel.org" <x86@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 03/17] bpf: Introduce BPF trampoline
Date: Thu, 7 Nov 2019 20:08:13 -0800	[thread overview]
Message-ID: <CAADnVQLz9fWBm3qYWaw9n60WOHFWtzO1RXheHYj6nd+jg--TkA@mail.gmail.com> (raw)
In-Reply-To: <3000B3E1-25DE-4653-B11C-AAF61492B0FF@fb.com>

On Thu, Nov 7, 2019 at 8:06 PM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Nov 7, 2019, at 7:11 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Nov 7, 2019 at 5:10 PM Song Liu <liu.song.a23@gmail.com> wrote:
> >>>>>>>>> +               goto out;
> >>>>>>>>> +       tr->selector++;
> >>>>>>>>
> >>>>>>>> Shall we do selector-- for unlink?
> >>>>>>>
> >>>>>>> It's a bit flip. I think it would be more confusing with --
> >>>>>>
> >>>>>> Right.. Maybe should use int instead of u64 for selector?
> >>>>>
> >>>>> No, since int can overflow.
> >>>>
> >>>> I guess it is OK to overflow, no?
> >>>
> >>> overflow is not ok, since transition 0->1 should use nop->call patching
> >>> whereas 1->2, 2->3 should use call->call.
> >>>
> >>> In my initial implementation (one I didn't share with anyone) I had
> >>> trampoline_mutex taken inside bpf_trampoline_update(). And multiple link()
> >>> operation were allowed. The idea was to attach multiple progs and update
> >>> trampoline once. But then I realized that I cannot do that since 'unlink +
> >>> update' where only 'update' is taking lock will not guarantee success. Since
> >>> other 'link' operations can race and 'update' can potentially fail in
> >>> arch_prepare_bpf_trampoline() due to new things that 'link' brought in. In that
> >>> version (since there several fentry/fexit progs can come in at once) I used
> >>> separate 'selector' ticker to pick the side of the page. Once I realized the
> >>> issue (to guarantee that unlink+update == always success) I moved mutex all the
> >>> way to unlink and link and left 'selector' as-is. Just now I realized that
> >>> 'selector' can be removed.  fentry_cnt + fexit_cnt can be used instead. This
> >>> sum of counters will change 1 bit at a time. Am I right?
> >>
> >> Yeah, I think fentry_cnt + fexit_cnt is cleaner.
> >
> > ... and that didn't work.
> > It's transition that matters. Either need to remember previous sum value
> > or have separate selector. imo selector is cleaner, so I'm back to that.
>
> Hmm.. is this because of the error handling path?

No. Because of transition 1->2 and 2->1 are the same.