Re: [PATCH bpf-next v2 1/3] bpf: sock ops: add netns ino and dev in bpf context

[Y Song <ys114321@gmail.com>]

On Fri, Apr 19, 2019 at 4:51 AM Alban Crequy <alban@kinvolk.io> wrote:
>
> On Thu, Apr 18, 2019 at 11:31 PM Y Song <ys114321@gmail.com> wrote:
> >
> > On Thu, Apr 18, 2019 at 8:58 AM Alban Crequy <alban.crequy@gmail.com> wrote:
> > >
> > > From: Alban Crequy <alban@kinvolk.io>
> > >
> > > sockops programs can now access the network namespace inode and device
> > > via (struct bpf_sock_ops)->netns_ino and ->netns_dev. This can be useful
> > > to apply different policies on different network namespaces.
> > >
> > > In the unlikely case where network namespaces are not compiled in
> > > (CONFIG_NET_NS=n), the verifier will not allow access to ->netns_*.
> > >
> > > The generated BPF bytecode for netns_ino is loading the correct inode
> > > number at the time of execution.
> > >
> > > However, the generated BPF bytecode for netns_dev is loading an
> > > immediate value determined at BPF-load-time by looking at the initial
> > > network namespace. In practice, this works because all netns currently
> > > use the same virtual device. If this was to change, this code would need
> > > to be updated too.
> > >
> > > Signed-off-by: Alban Crequy <alban@kinvolk.io>
> > >
> > > ---
> > >
> > > Changes since v1:
> > > - add netns_dev (review from Alexei)
> > > ---
> > >  include/uapi/linux/bpf.h |  2 ++
> > >  net/core/filter.c        | 70 ++++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 72 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > index eaf2d3284248..f4f841dde42c 100644
> > > --- a/include/uapi/linux/bpf.h
> > > +++ b/include/uapi/linux/bpf.h
> > > @@ -3213,6 +3213,8 @@ struct bpf_sock_ops {
> > >         __u32 sk_txhash;
> > >         __u64 bytes_received;
> > >         __u64 bytes_acked;
> > > +       __u64 netns_dev;
> > > +       __u64 netns_ino;
> >
> > Maybe we can define netns_dev as __u32?
> >    __u64 netns_ino;
> >    __u32 netns_dev;
> >
> > There is a hole at the end which can be used if the next
> > field to be added in the future is a __u32.
> >
> > From
> > static inline u32 new_encode_dev(dev_t dev)
> > {
> >         unsigned major = MAJOR(dev);
> >         unsigned minor = MINOR(dev);
> >         return (minor & 0xff) | (major << 8) | ((minor & ~0xff) << 12);
> > }
> >
> > device num is encoded in a u32.
>
> I could do that but there are already two occurrences of "__u64
> netns_dev" in bpf.h:
> - struct bpf_prog_info
> - struct bpf_map_info
>
> Should I keep it a u64 for consistency with the rest of bpf.h, or
> change it to u32?

Agreed. We probably should keep it to be __u64 to be consistent with others.