From: Al Viro <viro@ZenIV.linux.org.uk>
To: Alexei Starovoitov <ast@kernel.org>
Cc: "David S . Miller" <davem@davemloft.net>,
daniel@iogearbox.net, luto@amacapital.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com
Subject: Re: [PATCH bpf-next 1/6] bpf: introduce BPF_PROG_TYPE_FILE_FILTER
Date: Fri, 5 Oct 2018 05:46:59 +0100 [thread overview]
Message-ID: <20181005044659.GU32577@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20181004025750.498303-2-ast@kernel.org>
On Wed, Oct 03, 2018 at 07:57:45PM -0700, Alexei Starovoitov wrote:
> @@ -15,6 +15,7 @@
> #include <linux/bpf.h>
> #include <linux/bpf-cgroup.h>
> #include <net/sock.h>
> +#include <../fs/mount.h>
No.
> + struct file *file = NULL;
> + struct inode *inode;
> + struct super_block *sb;
> + struct mount *mnt;
Fuck, no.
> + case offsetof(struct bpf_file_info, mnt_id):
> + /* dst = real_mount(file->f_path.mnt)->mnt_id */
> + mnt = real_mount(LD_1(file->f_path.mnt));
> + LD_n(mnt->mnt_id);
NAK. Anything in struct mount is private to just a couple of
files in fs/*.c. Don't do that. And keep in mind that internal
details can and will be changed at zero notice, so be careful
with adding such stuff.
Another problem is your direct poking in ->i_ino. It's not
something directly exposed to userland at the moment and it should
not become such. Filesystem has every right to have ->getattr()
set ->ino (== ->st_ino value) in whichever way it likes; the same
goes for ->dev.
next prev parent reply other threads:[~2018-10-05 5:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-04 2:57 [PATCH bpf-next 0/6] bpf: introduce BPF_CGROUP_FILE_OPEN Alexei Starovoitov
2018-10-04 2:57 ` [PATCH bpf-next 1/6] bpf: introduce BPF_PROG_TYPE_FILE_FILTER Alexei Starovoitov
2018-10-04 19:41 ` Roman Gushchin
2018-10-04 19:51 ` Andy Lutomirski
2018-10-04 22:23 ` Alexei Starovoitov
2018-10-05 4:46 ` Al Viro [this message]
2018-10-05 22:05 ` Alexei Starovoitov
2018-10-05 22:09 ` Andy Lutomirski
2018-10-05 22:27 ` Alexei Starovoitov
2018-10-05 23:47 ` Al Viro
2018-10-06 0:22 ` Alexei Starovoitov
2018-10-08 0:56 ` Jann Horn
2018-10-08 2:22 ` Alexei Starovoitov
2018-10-08 9:06 ` Mickaël Salaün
2018-10-04 2:57 ` [PATCH bpf-next 2/6] fs: wire in BPF_CGROUP_FILE_OPEN hook Alexei Starovoitov
2018-10-04 2:57 ` [PATCH bpf-next 3/6] tools/bpf: sync uapi/bpf.h Alexei Starovoitov
2018-10-04 2:57 ` [PATCH bpf-next 4/6] trace/bpf: allow %o modifier in bpf_trace_printk Alexei Starovoitov
2018-10-04 2:57 ` [PATCH bpf-next 5/6] libbpf: support BPF_CGROUP_FILE_OPEN in libbpf Alexei Starovoitov
2018-10-04 2:57 ` [PATCH bpf-next 6/6] selftests/bpf: add a test for BPF_CGROUP_FILE_OPEN Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181005044659.GU32577@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.