Received-SPF: pass (google.com: domain of linux-kernel+bounces-170834-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Jiri Olsa <olsajiri@gmail.com>
Date: Tue, 7 May 2024 09:47:00 +0200
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>, linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	linux-man@vger.kernel.org, x86@kernel.org, bpf@vger.kernel.org,
	Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Borislav Petkov (AMD)" <bp@alien8.de>,
	Ingo Molnar <mingo@redhat.com>, Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCHv4 bpf-next 0/7] uprobe: uretprobe speed up
Message-ID: <ZjncdFBtsZnABvva@krava>
References: <20240502122313.1579719-1-jolsa@kernel.org>
 <CAEf4BzYxsRMx9M_AiLavTHFpndSmZqOM8QcYhDTbBviSpv1r+A@mail.gmail.com>
 <ZjPx0fncg-8brFBk@krava>
 <CAEf4Bzb-dM+464JvW96KuxwOTfRQA1pxZRWM+pA7AfSWtWwqZw@mail.gmail.com>
 <ZjVLedyQFBoHh-T_@krava>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZjVLedyQFBoHh-T_@krava>

On Fri, May 03, 2024 at 10:39:21PM +0200, Jiri Olsa wrote:
> On Fri, May 03, 2024 at 11:03:24AM -0700, Andrii Nakryiko wrote:
> > On Thu, May 2, 2024 at 1:04 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > >
> > > On Thu, May 02, 2024 at 09:43:02AM -0700, Andrii Nakryiko wrote:
> > > > On Thu, May 2, 2024 at 5:23 AM Jiri Olsa <jolsa@kernel.org> wrote:
> > > > >
> > > > > hi,
> > > > > as part of the effort on speeding up the uprobes [0] coming with
> > > > > return uprobe optimization by using syscall instead of the trap
> > > > > on the uretprobe trampoline.
> > > > >
> > > > > The speed up depends on instruction type that uprobe is installed
> > > > > and depends on specific HW type, please check patch 1 for details.
> > > > >
> > > > > Patches 1-6 are based on bpf-next/master, but path 1 and 2 are
> > > > > apply-able on linux-trace.git tree probes/for-next branch.
> > > > > Patch 7 is based on man-pages master.
> > > > >
> > > > > v4 changes:
> > > > >   - added acks [Oleg,Andrii,Masami]
> > > > >   - reworded the man page and adding more info to NOTE section [Masami]
> > > > >   - rewrote bpf tests not to use trace_pipe [Andrii]
> > > > >   - cc-ed linux-man list
> > > > >
> > > > > Also available at:
> > > > >   https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> > > > >   uretprobe_syscall
> > > > >
> > > >
> > > > It looks great to me, thanks! Unfortunately BPF CI build is broken,
> > > > probably due to some of the Makefile additions, please investigate and
> > > > fix (or we'll need to fix something on BPF CI side), but it looks like
> > > > you'll need another revision, unfortunately.
> > > >
> > > > pw-bot: cr
> > > >
> > > >   [0] https://github.com/kernel-patches/bpf/actions/runs/8923849088/job/24509002194
> > >
> > > yes, I think it's missing the 32-bit libc for uprobe_compat binary,
> > > probably it needs to be added to github.com:libbpf/ci.git setup-build-env/action.yml ?
> > > hm but I'm not sure how to test it, need to check
> > 
> > You can create a custom PR directly against Github repo
> > (kernel-patches/bpf) and BPF CI will run all the tests on your custom
> > code. This way you can iterate without spamming the mailing list.
> 
> I'm running CI tests like that, but I think I need to change the action
> which is in other repo (github.com:libbpf/ci.git)
> 
> > 
> > But I'm just wondering if it's worth complicating setup just for
> > testing this x32 compat mode. So maybe just dropping one of those
> > patches would be better?
> 
> well, we had compat process crashing on uretprobe because of this change,
> so I rather keep the test.. or it can go in later on when the CI stuff is
> figured out.. I got busy with the shadow stack issue today, will check on
> the CI PR next week

ok, it's not as easy as just adding the package.. I don't want to delay
this on my missing github skills, I'll skip the test in next version and
submit it separately when the github ci is ready for that

jirka