[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161116101837.GA23902@kroah.com>
Date: Wed, 16 Nov 2016 11:18:37 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Kees Cook <keescook@...omium.org>,
Will Deacon <will.deacon@....com>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
Arnd Bergmann <arnd@...db.de>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
David Windsor <dave@...gbits.org>,
LKML <linux-kernel@...r.kernel.org>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [RFC][PATCH 2/7] kref: Add kref_read()
On Wed, Nov 16, 2016 at 11:10:42AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 16, 2016 at 09:21:51AM +0100, Greg KH wrote:
> > > What should we do about things like this (bpf_prog_put() and callbacks
> > > from kernel/bpf/syscall.c):
> > >
> > >
> > > static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
> > > {
> > > struct user_struct *user = prog->aux->user;
> > >
> > > atomic_long_sub(prog->pages, &user->locked_vm);
> >
> > Oh that's scary. Let's just make one reference count rely on another
> > one and not check things...
>
> Its not a reference count, its a resource limit thingy. Also, isn't
> stacking, or in general building an object graph, the entire point of
> reference counts?
Ah, that wasn't obvious, but yes, you are correct here, sorry for the
noise.
greg k-h
Powered by blists - more mailing lists