[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVURVaqJChL=RwZPe74+JfX-6Zzp9kLR9-mLiownSOexQ@mail.gmail.com>
Date: Fri, 5 Oct 2018 15:09:20 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Alexei Starovoitov <ast@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
Network Development <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
kernel-team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 1/6] bpf: introduce BPF_PROG_TYPE_FILE_FILTER
On Fri, Oct 5, 2018 at 3:05 PM Alexei Starovoitov
<alexei.starovoitov@...il.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.
--Andy
Powered by blists - more mailing lists