netdev - Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5621371C.2000507@plumgrid.com>
Date:	Fri, 16 Oct 2015 10:42:52 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Daniel Borkmann <daniel@...earbox.net>, davem@...emloft.net
Cc:	viro@...IV.linux.org.uk, ebiederm@...ssion.com, tgraf@...g.ch,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alexei Starovoitov <ast@...nel.org>
Subject: Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs

On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote:
> Another question:
> Should multiple mount of the filesystem result in an empty fs (a new
> instance) or in one were one can see other ebpf-fs entities? I think
> Daniel wanted to already use the mountpoint as some kind of hierarchy
> delimiter. I would have used directories for that and multiple mounts
> would then have resulted in the same content of the filesystem. IMHO
> this would remove some ambiguity but then the question arises how this
> is handled in a namespaced environment. Was there some specific reason
> to do so?

That's an interesting question!
I think all mounts should be independent.
I can see tracing using one and networking using another one
with different hierarchies suitable for their own use cases.
What's an advantage to have the same content everywhere?
Feels harder to manage, since different users would need to
coordinate.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html