[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190906154647.GA19707@ZenIV.linux.org.uk>
Date: Fri, 6 Sep 2019 16:46:47 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Carlos Neira <cneirabustos@...il.com>
Cc: netdev@...r.kernel.org, yhs@...com, ebiederm@...ssion.com,
brouer@...hat.com, bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v10 2/4] bpf: new helper to obtain namespace
data from current task New bpf helper bpf_get_current_pidns_info.
On Fri, Sep 06, 2019 at 04:24:35PM +0100, Al Viro wrote:
> > + tmp = kmalloc(fnamesize, GFP_ATOMIC);
> > + if (unlikely(!tmp)) {
> > + __putname(fname);
> > + ret = -ENOMEM;
> > + goto clear;
> > + }
> > +
> > + tmp->name = (char *)fname;
> > + fname = tmp;
> > + len = strlen(pidns_path) + 1;
> > + memcpy((char *)fname->name, pidns_path, len);
> > + fname->uptr = NULL;
> > + fname->aname = NULL;
> > + fname->refcnt = 1;
> > +
> > + ret = filename_lookup(AT_FDCWD, fname, 0, &kp, NULL);
> > + if (ret)
> > + goto clear;
>
> Where do I begin?
> * getname_kernel() is there for purpose
> * so's kern_path(), damnit
Oh, and filename_lookup() *CAN* sleep, obviously. So that
GFP_ATOMIC above is completely pointless.
> > +
> > + inode = d_backing_inode(kp.dentry);
> > + pidns_info->dev = (u32)inode->i_rdev;
Why are plaing with device number, anyway? And why would it
be anything other than 0?
Powered by blists - more mailing lists