On Fri, 2016-06-10 at 14:29 +0000, David Laight wrote: > From: Eric Dumazet > > Sent: 09 June 2016 22:17 > > On Thu, 2016-06-09 at 23:50 +0300, Saeed Mahameed wrote: > > > From: Matthew Finlay <matt@xxxxxxxxxxxx> > > > > > > > diff --git a/net/socket.c b/net/socket.c > > > index a1bd161..67de200 100644 > > > --- a/net/socket.c > > > +++ b/net/socket.c > > > @@ -382,6 +382,7 @@ struct file *sock_alloc_file(struct socket *sock, int flags, const char *dname) > > > } > > > > > > sock->file = file; > > > + file->f_owner.sock_pid = find_get_pid(task_pid_nr(current)); > > > file->f_flags = O_RDWR | (flags & O_NONBLOCK); > > > file->private_data = sock; > > > return file; > > > > Wow, that is a serious memory leak weapon (of struct pid) > > > > Why don't you store the pid value, instead of a pointer ? > > Since the numeric 'pid' values can be reused (with no grace time) you'd > need to hold a reference to the pid structure (added in about 2.6.27) instead. > Which is just a smaller memory leak! Smaller than what ? I fail to see how keeping a reference on the pid structure of the process who created a socket can be useful, other than some optional LSM. A socket can be given via af_unix to another process. Original process might have died. Keeping a ref on the pid wont prevent this. So the 'pid' here looks as a pure hint/info. Better store it directly and avoid all the ref counting and indirection games that are going to slow down nfnetlink quite a lot with all these extra cache line misses and locks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
