On Tue, May 21, 2024 at 1:49 PM Deepak Gupta wrote:
>
> On Tue, May 21, 2024 at 12:48:16PM +0200, Jiri Olsa 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.
>
> I
On Tue, May 14, 2024 at 12:33 AM Ubisectech Sirius
wrote:
>
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel 6.7. Attached to
> the email were a PoC file of the issue.
Jiri,
please take a look.
>
_LAYOUT)
> void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
> {
> mm->mmap_base = TASK_UNMAPPED_BASE;
> - mm->get_unmapped_area = arch_get_unmapped_area;
> + clear_bit(MMF_TOPDOWN, >flags);
> }
> #endif
Makes sense to me.
Acked-by: Alexei Starovoitov
for the idea and for bpf bits.
Hi Andrii,
syzbot found UAF in raw_tp cookie series in bpf-next.
Reverting the whole merge
2e244a72cd48 ("Merge branch 'bpf-raw-tracepoint-support-for-bpf-cookie'")
fixes the issue.
Pls take a look.
See C reproducer below. It splats consistently with CONFIG_KASAN=y
Thanks.
On Sun, Mar 24,
On Thu, Sep 28, 2023 at 6:21 PM Masami Hiramatsu wrote:
>
>
> Thus, what I need is to make fprobe to use function-graph tracer's shadow
> stack and trampoline instead of rethook. This may need to generalize its
> interface so that we can share it between fprobe and function-graph tracer,
> but we
On Tue, Apr 20, 2021 at 5:35 AM Florent Revest wrote:
>
> On Tue, Apr 20, 2021 at 12:54 AM Alexei Starovoitov
> wrote:
> >
> > On Mon, Apr 19, 2021 at 05:52:39PM +0200, Florent Revest wrote:
> > > This type provides the guarantee that an argument is going to be a co
On Sat, Apr 17, 2021 at 1:16 AM Christophe Leroy
wrote:
>
>
>
> Le 16/04/2021 à 01:49, Alexei Starovoitov a écrit :
> > On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet
> > wrote:
> >>
> >> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann
&
On Wed, Apr 14, 2021 at 4:20 AM Tiezhu Yang wrote:
>
> There exist some errors "404 Not Found" when I click the link
> of "MAINTAINERS" [1], "samples/bpf/" [2] and "selftests" [3]
> in the documentation "HOWTO interact with BPF subsystem" [4].
>
> Use correct link of "MAINTAINERS" and just remove
On Mon, Apr 19, 2021 at 05:52:39PM +0200, Florent Revest wrote:
> This type provides the guarantee that an argument is going to be a const
> pointer to somewhere in a read-only map value. It also checks that this
> pointer is followed by a zero character before the end of the map value.
>
>
On Mon, Apr 19, 2021 at 6:52 AM Pedro Tammela wrote:
>
> Em dom., 18 de abr. de 2021 às 19:56, Alexei Starovoitov
> escreveu:
> >
> > On Sun, Apr 18, 2021 at 1:03 PM Pedro Tammela wrote:
> > >
> > > ENOTSUPP is not a valid userland errno[1], which is a
On Sun, Apr 18, 2021 at 1:03 PM Pedro Tammela wrote:
>
> ENOTSUPP is not a valid userland errno[1], which is annoying for
> userland applications that implement a fallback to iterative, report
> errors via 'strerror()' or both.
>
> The batched ops return this errno whenever an operation
> is not
On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet wrote:
>
> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann
> > On 4/15/21 11:32 AM, Jianlin Lv wrote:
> >> For debugging JITs, dumping the JITed image to kernel log is discouraged,
> >> "bpftool prog dump jited" is much better way to examine JITed
On Tue, Apr 13, 2021 at 9:32 AM wrote:
>
> > -Original Message-
> > From: Alexei Starovoitov
> >
> > On Tue, Apr 13, 2021 at 9:19 AM wrote:
> > >
> > > > -Original Message-
> > > > From: Alexei Starovo
On Tue, Apr 13, 2021 at 9:19 AM wrote:
>
> > -Original Message-
> > From: Alexei Starovoitov
> >
> > On Tue, Apr 13, 2021 at 9:10 AM wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > Fro
On Tue, Apr 13, 2021 at 9:10 AM wrote:
>
>
>
> > -Original Message-
> > From: Alexei Starovoitov
> >
> > On Tue, Apr 13, 2021 at 2:52 AM Yang Li wrote:
> > >
> > > Fix the following coccicheck warnings:
> > > ./tools/
On Tue, Apr 13, 2021 at 2:52 AM Yang Li wrote:
>
> Fix the following coccicheck warnings:
> ./tools/testing/selftests/bpf/progs/profiler.inc.h:189:7-11: WARNING
> comparing pointer to 0, suggest !E
> ./tools/testing/selftests/bpf/progs/profiler.inc.h:361:7-11: WARNING
> comparing pointer to 0,
On Mon, Apr 12, 2021 at 12:11 AM Hao Sun wrote:
>
> Besides, another similar bug occurred while fault injection was enabled.
>
> BUG: unable to handle kernel paging request in bpf_prog_alloc_no_stats
>
> RAX: ffda RBX:
On Sat, Apr 03, 2021 at 12:38:06AM +0530, Kumar Kartikeya Dwivedi wrote:
> On Sat, Apr 03, 2021 at 12:02:14AM IST, Alexei Starovoitov wrote:
> > On Fri, Apr 2, 2021 at 8:27 AM Kumar Kartikeya Dwivedi
> > wrote:
> > > [...]
> >
> > All of these things are m
On Fri, Apr 2, 2021 at 8:27 AM Kumar Kartikeya Dwivedi wrote:
>
> This would be fine, because it's not a fast path or anything, but right now we
> return the id using the netlink response, otherwise for query we have to open
> the socket, prepare the msg, send and recv again. So it's a minor
>
On Tue, Mar 30, 2021 at 2:26 PM Daniel Borkmann wrote:
>
> On 3/30/21 10:39 PM, Andrii Nakryiko wrote:
> > On Sun, Mar 28, 2021 at 1:11 AM Kumar Kartikeya Dwivedi
> > wrote:
> >> On Sun, Mar 28, 2021 at 10:12:40AM IST, Andrii Nakryiko wrote:
> >>> Is there some succinct but complete enough
On Tue, Mar 30, 2021 at 1:28 PM Andrii Nakryiko
wrote:
> >
> > In the other thread you've proposed to copy paste hash implemenation
> > into pahole. That's not ideal. If we had libbpfutil other projects
> > could have used that without copy-paste.
>
> I know it's not ideal. But I don't think
On Tue, Mar 30, 2021 at 3:54 PM Pedro Tammela wrote:
>
> BPF_CALL_2(bpf_ringbuf_submit, void *, sample, u64, flags)
> {
> + if (unlikely(flags & ~(BPF_RB_NO_WAKEUP | BPF_RB_FORCE_WAKEUP)))
> + return -EINVAL;
> +
> bpf_ringbuf_commit(sample, flags, false /* discard
On Sun, Mar 28, 2021 at 07:38:42PM -0700, Andrii Nakryiko wrote:
>
> See above. I don't know which hassle is libbpf for users today. You
> were implying code size used for functionality users might not use
> (e.g., linker). Libbpf is a very small library, <300KB. There are
> users building tools
On Sat, Mar 27, 2021 at 09:32:58PM -0700, Andrii Nakryiko wrote:
> > I think it's better to start with new library for tc/xdp and have
> > libbpf as a dependency on that new lib.
> > For example we can add it as subdir in tools/lib/bpf/.
> >
> > Similarly I think integerating static linking into
On Sat, Mar 27, 2021 at 04:17:16PM +0100, Toke Høiland-Jørgensen wrote:
> Alexei Starovoitov writes:
>
> > On Thu, Mar 25, 2021 at 05:30:03PM +0530, Kumar Kartikeya Dwivedi wrote:
> >> This adds some basic tests for the low level bpf_tc_* API and its
> >> bpf_progr
On Sun, Mar 28, 2021 at 5:05 AM Atul Gopinathan
wrote:
>
> Currently, building the bpf-next source with the CONFIG_BPF_SYSCALL
> enabled is causing a compilation error:
>
> "net/ipv4/bpf_tcp_ca.c:209:28: error: expected identifier or '(' before
> ',' token"
>
> Fix this by removing an unnecessary
On Sat, Mar 27, 2021 at 1:19 AM Jianlin Lv wrote:
>
> > On Fri, Mar 26, 2021 at 5:40 AM Jianlin Lv wrote:
> > >
> > > When CONFIG_BPF_JIT_ALWAYS_ON is enabled, the value of
> > bpf_jit_enable
> > > in /proc/sys is limited to SYSCTL_ONE. This is not convenient for
> > > debugging.
> > > This
On Thu, Mar 25, 2021 at 05:30:03PM +0530, Kumar Kartikeya Dwivedi wrote:
> This adds some basic tests for the low level bpf_tc_* API and its
> bpf_program__attach_tc_* wrapper on top.
*_block() apis from patch 3 and 4 are not covered by this selftest.
Why were they added ? And how were they
On Fri, Mar 26, 2021 at 5:40 AM Jianlin Lv wrote:
>
> When CONFIG_BPF_JIT_ALWAYS_ON is enabled, the value of bpf_jit_enable in
> /proc/sys is limited to SYSCTL_ONE. This is not convenient for debugging.
> This patch modifies the value of extra2 (max) to 2 that support developers
> to emit traces
On Wed, Mar 10, 2021 at 11:02:08PM +0100, Florent Revest wrote:
>
> +struct bpf_snprintf_buf {
> + char buf[MAX_SNPRINTF_MEMCPY][MAX_SNPRINTF_STR_LEN];
> +};
> +static DEFINE_PER_CPU(struct bpf_snprintf_buf, bpf_snprintf_buf);
> +static DEFINE_PER_CPU(int, bpf_snprintf_buf_used);
> +
>
On Fri, Mar 19, 2021 at 8:17 AM Yonghong Song wrote:
>
>
>
> On 3/19/21 12:21 AM, Daniel Borkmann wrote:
> > On 3/19/21 3:11 AM, Piotr Krysiuk wrote:
> >> Hi Daniel,
> >>
> >> On Fri, Mar 19, 2021 at 12:16 AM Stephen Rothwell
> >> wrote:
> >>
> >>> diff --cc kernel/bpf/verifier.c
> >>> index
On Wed, Mar 17, 2021 at 5:52 AM Jianlin Lv wrote:
> return BPF_CLASS(meta->insn.code);
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 2d3036e292a9..5d77675e7112 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -21,6 +21,7 @@
>
On Tue, Mar 16, 2021 at 4:29 AM Zhang, Qiang wrote:
>
> Hello Alexei Starovoitov Daniel Borkmann
> Please review this patch.
Please don't top post.
On Wed, Mar 10, 2021 at 6:29 AM Peter Zijlstra wrote:
>
> On Wed, Mar 10, 2021 at 09:13:24AM -0500, Steven Rostedt wrote:
> > On Wed, 10 Mar 2021 11:22:48 +0100
> > Peter Zijlstra wrote:
> >
> > > After this FEATURE_NOPL is unused except for required-features for
> > > x86_64. FEATURE_K8 is only
On Tue, Mar 9, 2021 at 12:37 PM Steven Rostedt wrote:
>
> The size of the fields and order changes all the time in various events. I
> recommend doing so *all the time*. If you upgrade a kernel, then all the bpf
> programs you have for that kernel should also be updated. You can't rely on
>
On Tue, Mar 9, 2021 at 12:18 PM David Ahern wrote:
>
> On 3/9/21 1:02 PM, Steven Rostedt wrote:
> > On Tue, 9 Mar 2021 12:53:37 -0700
> > David Ahern wrote:
> >
> >> Changing the order of the fields will impact any bpf programs expecting
> >> the existing format
> >
> > I thought bpf programs
On Tue, Mar 9, 2021 at 12:03 PM Steven Rostedt wrote:
>
> On Tue, 9 Mar 2021 12:53:37 -0700
> David Ahern wrote:
>
> > Changing the order of the fields will impact any bpf programs expecting
> > the existing format
>
> I thought bpf programs were not API.
That is correct.
On Fri, Mar 5, 2021 at 7:01 AM Peter Zijlstra wrote:
>
> On Fri, Mar 05, 2021 at 09:36:30AM +0100, Peter Zijlstra wrote:
> > On Thu, Mar 04, 2021 at 07:45:44PM -0800, Linus Torvalds wrote:
> > > That cacheline_aligned goes back many years, this is not new, it
> > > seems to come from back in
On Tue, Mar 2, 2021 at 5:46 PM Andy Lutomirski wrote:
>
>
> > On Mar 2, 2021, at 5:22 PM, Alexei Starovoitov
> > wrote:
> >
> > On Tue, Mar 2, 2021 at 1:02 PM Andy Lutomirski wrote:
> >>
> >>
> >>>> On Mar 2, 2021, at 12:24 PM
On Tue, Mar 2, 2021 at 1:02 PM Andy Lutomirski wrote:
>
>
> > On Mar 2, 2021, at 12:24 PM, Alexei Starovoitov
> > wrote:
> >
> > On Tue, Mar 2, 2021 at 10:38 AM Andy Lutomirski wrote:
> >>
> >> Is there something like a uprobe test suite
On Tue, Mar 2, 2021 at 10:38 AM Andy Lutomirski wrote:
>
> Is there something like a uprobe test suite? How maintained /
> actively used is uprobe?
uprobe+bpf is heavily used in production.
selftests/bpf has only one test for it though.
Why are you asking?
On Thu, Feb 25, 2021 at 4:04 PM Martin KaFai Lau wrote:
>
> On Thu, Feb 25, 2021 at 03:43:13PM -0800, Song Liu wrote:
> > This set enables task local storage for non-BPF_LSM programs.
> >
> > It is common for tracing BPF program to access per-task data. Currently,
> > these data are stored in
On 2/22/21 11:19 PM, Andrii Nakryiko wrote:
+ bpf_task_storage_lock();
sdata = bpf_local_storage_update(
task, (struct bpf_local_storage_map *)map, value, map_flags);
this should probably be container_of() instead of casting
bpf_task_storage.c uses casting in
On Wed, Feb 10, 2021 at 3:14 AM Florent Revest wrote:
>
> +BPF_CALL_1(bpf_get_socket_ptr_cookie, struct sock *, sk)
> +{
> + return sk ? sock_gen_cookie(sk) : 0;
> +}
> +
> +const struct bpf_func_proto bpf_get_socket_ptr_cookie_proto = {
> + .func =
On Wed, Feb 10, 2021 at 5:57 AM Peter Zijlstra wrote:
>
>
> Somewhat related.. I had this pending.
>
> ---
> Subject: kprobes: Remove kprobe::fault_handler
> From: Peter Zijlstra
> Date: Tue Feb 2 10:43:41 CET 2021
>
> The reason for kprobe::fault_handler(), as given by their comment:
>
> * We
On Tue, Feb 9, 2021 at 6:49 AM Steven Rostedt wrote:
>
> On Tue, 9 Feb 2021 09:32:34 +0100 (CET)
> Miroslav Benes wrote:
>
> > powerpc has this
> >
> > static inline unsigned long klp_get_ftrace_location(unsigned long faddr)
> > {
> > /*
> > * Live patch works only with
On Sun, Feb 7, 2021 at 10:21 AM Dave Hansen wrote:
>
> On 2/7/21 9:58 AM, Borislav Petkov wrote:
> > On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote:
> >> On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov wrote:
> >>> - Disable CET instrumentation in the kernel so that gcc doesn't
On Thu, Feb 4, 2021 at 5:40 PM Xu Jia wrote:
>
> Prefer 'static const' over 'const static' here
>
> Signed-off-by: Xu Jia
> ---
> kernel/bpf/bpf_lsm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c
> index
On Wed, Feb 3, 2021 at 9:07 AM Yonghong Song wrote:
>
>
>
> On 2/2/21 5:50 AM, Brendan Jackman wrote:
> > When BPF_FETCH is set, atomic instructions load a value from memory
> > into a register. The current verifier code first checks via
> > check_mem_access whether we can access the memory, and
On Mon, Feb 1, 2021 at 7:00 AM Brendan Jackman wrote:
> +
> +SEC("fentry/bpf_fentry_test1")
> +int BPF_PROG(sub, int x)
> +{
> + int a = 0;
> + int b = __sync_fetch_and_add(, 1);
It probably needs ENABLE_ATOMICS_TESTS ?
Otherwise clang without -mcpu=v3 will complain:
"fatal error:
On Mon, Feb 1, 2021 at 2:32 PM Daniel Borkmann wrote:
>
> On 1/30/21 12:45 PM, Florent Revest wrote:
> > On Fri, Jan 29, 2021 at 1:49 PM Daniel Borkmann
> > wrote:
> >> On 1/29/21 11:57 AM, Daniel Borkmann wrote:
> >>> On 1/27/21 10:01 PM, Andrii Nakryiko wrote:
> On Tue, Jan 26, 2021 at
On Sat, Jan 30, 2021 at 11:02:49AM +0900, Masami Hiramatsu wrote:
> On Fri, 29 Jan 2021 18:59:43 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Jan 29, 2021 at 09:45:48AM -0800, Alexei Starovoitov wrote:
> > > Same things apply to bpf side. We can statically prove safety for
On Fri, Jan 29, 2021 at 02:01:03PM -0500, Steven Rostedt wrote:
> On Fri, 29 Jan 2021 18:59:43 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Jan 29, 2021 at 09:45:48AM -0800, Alexei Starovoitov wrote:
> > > Same things apply to bpf side. We can statically prove safety for
On Fri, Jan 29, 2021 at 8:24 AM Peter Zijlstra wrote:
>
> On Fri, Jan 29, 2021 at 10:59:52AM -0500, Steven Rostedt wrote:
> > On Fri, 29 Jan 2021 22:40:11 +0900
> > Masami Hiramatsu wrote:
> >
> > > > So what, they can all happen with random locks held. Marking them as NMI
> > > > enables a
On Thu, Jan 28, 2021 at 07:24:14PM +0100, Peter Zijlstra wrote:
> On Thu, Jan 28, 2021 at 06:45:56PM +0200, Nikolay Borisov wrote:
> > it would be placed on the __fentry__ (and not endbr64) hence it works.
> > So perhaps a workaround outside of bpf could essentially detect this
> > scenario and
On Thu, Jan 21, 2021 at 10:54 AM Jonathan Corbet wrote:
>
> On Wed, 20 Jan 2021 13:39:44 +
> Brendan Jackman wrote:
>
> > Difference from v2->v3 [1]:
> >
> > * Just fixed a commite message, rebased, and added Lukas' review tag -
> > thanks
> >Lukas!
> >
> > Difference from v1->v2 [1]:
On Wed, Jan 20, 2021 at 11:57 AM Lukas Bulwahn wrote:
>
> On Wed, Jan 20, 2021 at 2:39 PM Brendan Jackman wrote:
> >
> > Alexei pointed out [1] that this wording is pretty confusing. Here's
> > an attempt to be more explicit and clear.
> >
> > [1]
> >
On Mon, Jan 18, 2021 at 04:06:13PM +, Brendan Jackman wrote:
> When BPF_FETCH is set, atomic instructions load a value from memory
> into a register. The current verifier code first checks via
> check_mem_access whether we can access the memory, and then checks
> via check_reg_arg whether we
On Wed, Jan 20, 2021 at 6:22 AM angkery wrote:
>
> From: Junlin Yang
>
> Change 'exeeds' to 'exceeds'.
>
> Signed-off-by: Junlin Yang
The patch didn't reach patchwork.
Please reduce cc list and resubmit to bpf@vger only.
Also pls mention [PATCH bpf-next] in the subject.
> ---
>
On Tue, Jan 19, 2021 at 4:03 AM Pan Bian wrote:
>
> Put file f if inode_storage_ptr() returns NULL.
>
> Signed-off-by: Pan Bian
> ---
> kernel/bpf/bpf_inode_storage.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/bpf_inode_storage.c
tun_prog __rcu **prog_p,
> > > prog = NULL;
> > > } else {
> > > prog = bpf_prog_get_type(fd, BPF_PROG_TYPE_SOCKET_FILTER);
> > > + if (IS_ERR(prog))
> > > + prog = bpf_prog_get_type(fd,
>
On Wed, Jan 20, 2021 at 9:08 AM KP Singh wrote:
>
> On Tue, Jan 19, 2021 at 5:00 PM Florent Revest wrote:
> >
> > This builds up on the existing socket cookie test which checks whether
> > the bpf_get_socket_cookie helpers provide the same value in
> > cgroup/connect6 and sockops programs for a
On Tue, Jan 19, 2021 at 4:22 AM Qais Yousef wrote:
>
> Changes in v3:
> * Fix not returning error value correctly in
> trigger_module_test_write() (Yonghong)
> * Add Yonghong acked-by to patch 1.
Applied. Thanks
Adding appropriate mailing list to cc...
My wild guess is that as soon as socket got created:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
the packets were already queued to it.
So later setsockopt() is too late to filter.
Eric, thoughts?
On Wed, Jan 6, 2021 at 6:55 AM Tom Cook wrote:
>
>
On Thu, Jan 14, 2021 at 3:44 PM Yonghong Song wrote:
>
>
>
> On 1/14/21 2:02 PM, Jiri Olsa wrote:
> > On Thu, Jan 14, 2021 at 01:05:33PM -0800, Yonghong Song wrote:
> >>
> >>
> >> On 1/14/21 12:01 PM, Jiri Olsa wrote:
> >>> On Thu, Jan 14, 2021 at 10:56:33AM -0800, Yonghong Song wrote:
>
>
On Thu, Jan 14, 2021 at 10:18 AM Brendan Jackman wrote:
>
> There's still one unresolved review comment from John[3] which I
> will resolve with a followup patch.
>
> Differences from v6->v7 [1]:
>
> * Fixed riscv build error detected by 0-day robot.
Applied.
Thanks a lot.
Please address John's
On Wed, Jan 13, 2021 at 2:29 PM KP Singh wrote:
>
> On Wed, Jan 13, 2021 at 6:38 AM Gilad Reti wrote:
> >
> > Add support for pointer to mem register spilling, to allow the verifier
> > to track pointers to valid memory addresses. Such pointers are returned
> > for example by a successful call
On Tue, Jan 12, 2021 at 1:19 AM Jiri Olsa wrote:
>
> On Mon, Jan 11, 2021 at 06:49:58PM -0800, Alexei Starovoitov wrote:
> > On Mon, Jan 11, 2021 at 10:38:19PM +0100, Jiri Olsa wrote:
> > > hi,
> > > adding the support to have buildid stored in mmap2 event,
> &g
On Tue, Jan 12, 2021 at 03:42:24PM +, Brendan Jackman wrote:
> Happy new year everyone, and thanks once again for the reviews.
>
> There's still one unresolved review comment from John[3] but I don't
> think it needs to block the patchset as it stands, it can be a
> separate patch. Hope
On Tue, Jan 12, 2021 at 11:42 AM Yuri Benditovich
wrote:
>
> This program type can set skb hash value. It will be useful
> when the tun will support hash reporting feature if virtio-net.
>
> Signed-off-by: Yuri Benditovich
> ---
> drivers/net/tun.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>
On Mon, Jan 11, 2021 at 10:38:19PM +0100, Jiri Olsa wrote:
> hi,
> adding the support to have buildid stored in mmap2 event,
> so we can bypass the final perf record hunt on build ids.
>
> This patchset allows perf to record build ID in mmap2 event,
> and adds perf tooling to store/download
On Mon, Jan 11, 2021 at 05:32:51PM +, Alan Maguire wrote:
> The BPF Type Format (BTF) can be used in conjunction with the helper
> bpf_snprintf_btf() to display kernel data with type information.
>
> This series generalizes that support and shares it with libbpf so
> that libbpf can display
On Tue, Jan 5, 2021 at 12:00 AM Xichen Lin wrote:
>
> From: Xichen Lin
>
> Check the signature of a BPF program against the same set of keys for
> module signature checking.
>
> Currently the format of a signed BPF program is similar to that of
> a signed kernel module, composed of BPF bytecode,
On Tue, Jan 05, 2021 at 02:24:12PM +0200, Yuri Benditovich wrote:
> This program type can set skb hash value. It will be useful
> when the tun will support hash reporting feature if virtio-net.
>
> Signed-off-by: Yuri Benditovich
> ---
> drivers/net/tun.c | 2 ++
> 1 file changed, 2
On Tue, Jan 5, 2021 at 3:39 AM Qais Yousef wrote:
>
> On 01/04/21 10:59, Alexei Starovoitov wrote:
> > > > > I did have a patch that allowed that. It might be worth trying to
> > > > > upstream it.
> > > > > It just required a new macro wh
On Mon, Jan 04, 2021 at 03:26:31PM +, Alan Maguire wrote:
>
> ksnoop can be used to show function signatures; for example:
>
> $ ksnoop info ip_send_skb
> int ip_send_skb(struct net * net, struct sk_buff * skb);
>
> Then we can trace the function, for example:
>
> $ ksnoop trace
On Mon, Jan 4, 2021 at 10:29 AM Qais Yousef wrote:
>
> On 09/08/20 09:19, Phil Auld wrote:
> > Hi Quais,
> >
> > On Mon, Sep 07, 2020 at 12:02:24PM +0100 Qais Yousef wrote:
> > > On 09/02/20 09:54, Phil Auld wrote:
> > > > >
> > > > > I think this decoupling is not necessary. The natural place
On Wed, Dec 23, 2020 at 7:54 AM Christoph Hellwig wrote:
>
> On Wed, Dec 23, 2020 at 12:11:36PM +, Matthew Wilcox wrote:
> > On Wed, Dec 23, 2020 at 08:31:26AM +, Christoph Hellwig wrote:
> > > Can we please make the eBPF code stop referencing this function instead
> > > of papering over
On Fri, Dec 18, 2020 at 10:53:57AM -0800, Andrii Nakryiko wrote:
> On Thu, Dec 17, 2020 at 7:20 PM Alexei Starovoitov
> wrote:
> >
> > On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
> > >
> > >
> > > On 12/17/20 7:31 AM, Florent Reves
On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
>
>
> On 12/17/20 7:31 AM, Florent Revest wrote:
> > On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
> > > On 12/11/20 6:40 AM, Florent Revest wrote:
> > > > On Wed, Dec 2, 2020 at 10:18
On Wed, Dec 16, 2020 at 10:07:37AM +, Christophe Leroy wrote:
> Implement Extended Berkeley Packet Filter on Powerpc 32
>
> Test result with test_bpf module:
>
> test_bpf: Summary: 378 PASSED, 0 FAILED, [354/366 JIT'ed]
nice!
> Registers mapping:
>
> [BPF_REG_0] = r11-r12
>
On Wed, Dec 9, 2020 at 6:31 PM Steven Rostedt wrote:
>
> On Wed, 9 Dec 2020 17:12:43 -0800
> Alexei Starovoitov wrote:
>
> > > > > > FWIW, I intend to do some consolidation/renaming in this area. I
> > > > > > trust that will not be a problem?
&
On Wed, Dec 9, 2020 at 2:32 PM Steven Rostedt wrote:
>
> On Wed, Dec 09, 2020 at 06:05:52PM +, Christoph Hellwig wrote:
> > On Wed, Dec 09, 2020 at 04:51:48PM +0100, Stanislaw Gruszka wrote:
> > > On Wed, Dec 09, 2020 at 03:08:26PM +, Matthew Wilcox wrote:
> > > > On Wed, Dec 09, 2020 at
On Mon, Dec 7, 2020 at 2:59 PM Alexei Starovoitov
wrote:
>
> On Mon, Dec 7, 2020 at 2:53 PM Michal Kubecek wrote:
> >
> > On Mon, Dec 07, 2020 at 02:44:22PM -0800, Alexei Starovoitov wrote:
> > > On Mon, Dec 7, 2020 at 10:36 AM Justin Forbes
> > > wrote:
On Mon, Dec 7, 2020 at 2:53 PM Michal Kubecek wrote:
>
> On Mon, Dec 07, 2020 at 02:44:22PM -0800, Alexei Starovoitov wrote:
> > On Mon, Dec 7, 2020 at 10:36 AM Justin Forbes wrote:
> > >
> > > On Mon, Dec 7, 2020 at 2:16 AM Michal Kubecek wrote:
> > >
On Mon, Dec 7, 2020 at 10:36 AM Justin Forbes wrote:
>
> On Mon, Dec 7, 2020 at 2:16 AM Michal Kubecek wrote:
> >
> > On Thu, Nov 12, 2020 at 08:18:57AM +0800, Alex Shi wrote:
> > >
> > >
> > > 在 2020/11/11 上午3:50, Andrew Morton 写道:
> > > > On Tue, 10 Nov 2020 08:39:24 +0530 Souptick Joarder
>
On Thu, Dec 03, 2020 at 10:22:34AM +, Brendan Jackman wrote:
> Add missing newlines and fix polarity of strerror argument.
>
> Signed-off-by: Brendan Jackman
Applied, Thanks
On Tue, Dec 1, 2020 at 1:59 PM Roman Gushchin wrote:
>
> 5) Cryptic -EPERM is returned on exceeding the limit. Libbpf even had
>a function to "explain" this case for users.
...
> v9:
> - always charge the saved memory cgroup, by Daniel, Toke and Alexei
> - added bpf_map_kzalloc()
> -
On Wed, Dec 2, 2020 at 12:32 PM Florent Revest wrote:
>
> On Tue, 2020-12-01 at 16:55 -0800, Andrii Nakryiko wrote:
> > On Fri, Nov 27, 2020 at 8:09 AM Yonghong Song wrote:
> > >
> > >
> > > On 11/27/20 3:20 AM, KP Singh wrote:
> > > > On Fri, Nov 27, 2020 at 8:35 AM Yonghong Song wrote:
> > >
On Wed, Dec 2, 2020 at 2:52 AM Brendan Jackman wrote:
>
> Tue, Dec 01, 2020 at 09:50:00PM -0800, Alexei Starovoitov wrote:
> > On Tue, Dec 1, 2020 at 4:14 AM Brendan Jackman wrote:
> > >
> > > On Sat, Nov 28, 2020 at 05:15:52PM -0800, Alexei Starovoitov wrote:
>
On Tue, Dec 1, 2020 at 4:38 AM Brendan Jackman wrote:
>
> I guess it's also worth remembering other archs might have an atomic
> subtract.
which one?
arm64 LSE implements atomic_fetch_sub as neg+ldadd.
imo x64 and arm64 example outweighs choices by other archs if there are such.
Even without LSE
On Tue, Dec 1, 2020 at 4:12 AM Brendan Jackman wrote:
>
> On Sat, Nov 28, 2020 at 05:14:05PM -0800, Alexei Starovoitov wrote:
> > On Fri, Nov 27, 2020 at 05:57:27PM +, Brendan Jackman wrote:
> > > The JIT case for encoding atomic ops is about to get more
> > >
On Tue, Dec 1, 2020 at 4:14 AM Brendan Jackman wrote:
>
> On Sat, Nov 28, 2020 at 05:15:52PM -0800, Alexei Starovoitov wrote:
> > On Fri, Nov 27, 2020 at 05:57:26PM +, Brendan Jackman wrote:
> > > +/* Emit the ModR/M byte for addressing *(r1 + off) and r2
On Mon, Nov 30, 2020 at 05:23:22PM +0100, Florent Revest wrote:
> On Sat, 2020-11-28 at 17:07 -0800, Alexei Starovoitov wrote:
> > On Thu, Nov 26, 2020 at 05:57:47PM +0100, Florent Revest wrote:
> > > This helper exposes the kallsyms_lookup function to eBPF tracing
> > >
On Fri, Nov 27, 2020 at 09:53:05PM -0800, Yonghong Song wrote:
>
>
> On 11/27/20 9:57 AM, Brendan Jackman wrote:
> > Status of the patches
> > =
> >
> > Thanks for the reviews! Differences from v1->v2 [1]:
> >
> > * Fixed mistakes in the netronome driver
> >
> > * Addd
On Fri, Nov 27, 2020 at 09:39:10PM -0800, Yonghong Song wrote:
>
>
> On 11/27/20 9:57 AM, Brendan Jackman wrote:
> > This adds instructions for
> >
> > atomic[64]_[fetch_]and
> > atomic[64]_[fetch_]or
> > atomic[64]_[fetch_]xor
> >
> > All these operations are isomorphic enough to implement
On Fri, Nov 27, 2020 at 09:35:07PM -0800, Yonghong Song wrote:
>
>
> On 11/27/20 9:57 AM, Brendan Jackman wrote:
> > Including only interpreter and x86 JIT support.
> >
> > x86 doesn't provide an atomic exchange-and-subtract instruction that
> > could be used for BPF_SUB | BPF_FETCH, however we
On Fri, Nov 27, 2020 at 05:57:33PM +, Brendan Jackman wrote:
>
> /* atomic op type fields (stored in immediate) */
> -#define BPF_FETCH0x01/* fetch previous value into src reg */
> +#define BPF_XCHG (0xe0 | BPF_FETCH) /* atomic exchange */
> +#define BPF_CMPXCHG (0xf0 |
On Fri, Nov 27, 2020 at 05:57:26PM +, Brendan Jackman wrote:
> +/* Emit the ModR/M byte for addressing *(r1 + off) and r2 */
> +static void emit_modrm_dstoff(u8 **pprog, u32 r1, u32 r2, int off)
same concern as in the another patch. If you could avoid intel's puzzling names
like above it will
On Fri, Nov 27, 2020 at 05:57:27PM +, Brendan Jackman wrote:
> The JIT case for encoding atomic ops is about to get more
> complicated. In order to make the review & resulting code easier,
> let's factor out some shared helpers.
>
> Signed-off-by: Brendan Jackman
> ---
>
1 - 100 of 4144 matches
Mail list logo
