[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181005044659.GU32577@ZenIV.linux.org.uk>
Date: Fri, 5 Oct 2018 05:46:59 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Alexei Starovoitov <ast@...nel.org>
Cc: "David S . Miller" <davem@...emloft.net>, daniel@...earbox.net,
luto@...capital.net, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH bpf-next 1/6] bpf: introduce BPF_PROG_TYPE_FILE_FILTER
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.
Powered by blists - more mailing lists