Messages in this thread | | | Date | Fri, 5 Oct 2018 15:27:54 -0700 | From | Alexei Starovoitov <> | Subject | Re: [PATCH bpf-next 1/6] bpf: introduce BPF_PROG_TYPE_FILE_FILTER |
| |
On Fri, Oct 05, 2018 at 03:09:20PM -0700, Andy Lutomirski wrote: > On Fri, Oct 5, 2018 at 3:05 PM Alexei Starovoitov > <alexei.starovoitov@gmail.com> wrote: > > > > On Fri, Oct 05, 2018 at 05:46:59AM +0100, Al Viro wrote: > > > > > 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. > > > > The patch is not making i_ino directly exposed. > > Only 'struct bpf_file_info' is exposed to user space / bpf programs. > > I think Al is saying that the valie of i_ino is not something that > user code is permitted to know regardless of how you format it because > it may or may not actually match the value returned by stat(). > Another way of saying that is that your patch is digging into an > internal data structure and is doing it wrong.
several fs implementation I've looked at just do generic_fillattr() for these fields. Are you saying some FS don't use inode->i_ino at all? And it's bogus, hence shouldn't be read?
| |