From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH bpf-next 1/6] bpf: introduce BPF_PROG_TYPE_FILE_FILTER Date: Fri, 5 Oct 2018 05:46:59 +0100 Message-ID: <20181005044659.GU32577@ZenIV.linux.org.uk> References: <20181004025750.498303-1-ast@kernel.org> <20181004025750.498303-2-ast@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "David S . Miller" , daniel@iogearbox.net, luto@amacapital.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com To: Alexei Starovoitov Return-path: Content-Disposition: inline In-Reply-To: <20181004025750.498303-2-ast@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Wed, Oct 03, 2018 at 07:57:45PM -0700, Alexei Starovoitov wrote: > @@ -15,6 +15,7 @@ > #include > #include > #include > +#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.