[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200304154757.3tydkiteg3vekyth@ast-mbp>
Date: Wed, 4 Mar 2020 07:47:59 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Alexei Starovoitov <ast@...com>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii.nakryiko@...il.com>,
Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
Networking <netdev@...r.kernel.org>,
Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel
abstraction
On Wed, Mar 04, 2020 at 08:47:44AM +0100, Toke Høiland-Jørgensen wrote:
> >
> >> And what about the case where the link fd is pinned on a bpffs that is
> >> no longer available? I.e., if a netdevice with an XDP program moves
> >> namespaces and no longer has access to the original bpffs, that XDP
> >> program would essentially become immutable?
> >
> > 'immutable' will not be possible.
> > I'm not clear to me how bpffs is going to disappear. What do you mean
> > exactly?
>
> # stat /sys/fs/bpf | grep Device
> Device: 1fh/31d Inode: 1013963 Links: 2
> # mkdir /sys/fs/bpf/test; ls /sys/fs/bpf
> test
> # ip netns add test
> # ip netns exec test stat /sys/fs/bpf/test
> stat: cannot stat '/sys/fs/bpf/test': No such file or directory
> # ip netns exec test stat /sys/fs/bpf | grep Device
> Device: 3fh/63d Inode: 12242 Links: 2
>
> It's a different bpffs instance inside the netns, so it won't have
> access to anything pinned in the outer one...
Toke, please get your facts straight.
> # stat /sys/fs/bpf | grep Device
> Device: 1fh/31d Inode: 1013963 Links: 2
Inode != 1 means that this is not bpffs.
I guess this is still sysfs.
> # mkdir /sys/fs/bpf/test; ls /sys/fs/bpf
> test
> # ip netns add test
> # ip netns exec test stat /sys/fs/bpf/test
> stat: cannot stat '/sys/fs/bpf/test': No such file or directory
> # ip netns exec test stat /sys/fs/bpf | grep Device
> Device: 3fh/63d Inode: 12242 Links: 2
This is your new sysfs after ip netns exec.
netns has nothing do with bpffs despite your claims.
Try this instead:
# mkdir /tmp/bpf
# mount -t bpf bpf /tmp/bpf
# stat /tmp/bpf|grep Device
Device: 1eh/30d Inode: 1 Links: 2
# stat -f /tmp/bpf|grep Type
ID: 0 Namelen: 255 Type: bpf_fs
# mkdir /tmp/bpf/test
# ip netns add my
# ip netns exec my stat /tmp/bpf|grep Device
Device: 1eh/30d Inode: 1 Links: 3
# ip netns exec my stat -f /tmp/bpf|grep Type
ID: 0 Namelen: 255 Type: bpf_fs
# ip netns exec my ls /tmp/bpf/
test
Having said that we do allow remounting bpffs on top of existing one:
# mount -t bpf bpf /var/aa
# mkdir /var/aa/bb
# stat -f /var/aa/bb|grep Type
ID: 0 Namelen: 255 Type: bpf_fs
# mount -t bpf bpf /var/aa
# stat -f /var/aa/bb|grep Type
stat: cannot read file system information for '/var/aa/bb': No such file or directory
# umount /var/aa
# stat -f /var/aa/bb|grep Type
ID: 0 Namelen: 255 Type: bpf_fs
Still that doesn't mean that pinned link is 'immutable'.
Powered by blists - more mailing lists