[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4Bza__VNwyqNdyy-aKS_eiPRThMv2SZaYRvnwr5DXzgqG3g@mail.gmail.com>
Date: Fri, 11 Oct 2024 12:41:28 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Namhyung Kim <namhyung@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
Jiri Olsa <jolsa@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
bpf <bpf@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>,
Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>, Vlastimil Babka <vbabka@...e.cz>,
Roman Gushchin <roman.gushchin@...ux.dev>, Hyeonggon Yoo <42.hyeyoo@...il.com>,
linux-mm <linux-mm@...ck.org>, Arnaldo Carvalho de Melo <acme@...nel.org>, Kees Cook <kees@...nel.org>,
"Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH v5 bpf-next 1/3] bpf: Add kmem_cache iterator
On Fri, Oct 11, 2024 at 11:44 AM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Thu, Oct 10, 2024 at 4:25 PM Namhyung Kim <namhyung@...nel.org> wrote:
> >
> > +struct bpf_iter__kmem_cache {
> > + __bpf_md_ptr(struct bpf_iter_meta *, meta);
> > + __bpf_md_ptr(struct kmem_cache *, s);
> > +};
>
> Just noticed this.
> Not your fault. You're copy pasting from bpf_iter__*.
> It looks like tech debt.
>
> Andrii, Song,
>
> do you remember why all iters are using this?
I don't *know*, but I suspect we are doing this because of 32-bit host
architecture. BPF-side is always 64-bit, so to make memory layout
inside the kernel and in BPF programs compatible we have to do this
for pointers, no?
> __bpf_md_ptr() wrap was necessary in uapi/bpf.h,
> but this is kernel iters that go into vmlinux.h
> It should be fine to remove them all and
> progs wouldn't need to do the ugly dance of:
>
> #define bpf_iter__ksym bpf_iter__ksym___not_used
> #include "vmlinux.h"
> #undef bpf_iter__ksym
I don't think __bpf_md_ptr is why we are doing this ___not_used dance.
At some point we probably didn't want to rely on having the very
latest vmlinux.h available in BPF selftests, so we chose to define
local versions of all relevant context types.
I think we can drop all that ___not_used dance regardless (and remove
local definitions in progs/bpf_iter.h).
Powered by blists - more mailing lists