lkml.org 
[lkml]   [2019]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH bpf-next v3 1/4] bpf: sock ops: add netns ino and dev in bpf context
    On Sat, Apr 27, 2019 at 8:39 PM Jakub Kicinski
    <jakub.kicinski@netronome.com> wrote:
    >
    > On Sat, 27 Apr 2019 12:48:25 +0200, Alban Crequy wrote:
    > > On Fri, Apr 26, 2019 at 11:03 PM Jakub Kicinski
    > > <jakub.kicinski@netronome.com> wrote:
    > > >
    > > > On Fri, 26 Apr 2019 17:48:45 +0200, Alban Crequy wrote:
    > > > > In the unlikely case where network namespaces are not compiled in
    > > > > (CONFIG_NET_NS=n), the verifier will not allow access to ->netns_*.
    > > >
    > > > Naive question - why return an error? init_net should always be there,
    > > > no?
    > >
    > > True for netns_dev. However, without CONFIG_NET_NS, we cannot access netns_ino:
    > >
    > > (struct sock_common).possible_net_t.(struct net *):
    > >
    > > typedef struct {
    > > #ifdef CONFIG_NET_NS
    > > struct net *net;
    > > #endif
    > > } possible_net_t;
    > >
    > > And I don't think it would make much sense to allow access to
    > > netns_dev but not netns_ino.
    >
    > Right, if CONFIG_NET_NS=n we could just take the pointer to init_net
    > directly, and not worry about the field. IMHO it'd be preferable to
    > changing the UAPI based on kernel config, but I don't feel super
    > strongly.

    I see the point about not changing the UAPI. So I will update the patch to:
    - return netns_dev unconditionally, regardless of CONFIG_NET_NS
    - return netns_ino with either the correct value or zero depending on
    CONFIG_NET_NS.

    \
     
     \ /
      Last update: 2019-04-29 17:43    [W:4.822 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site