lkml.org 
[lkml]   [2012]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [flame^Wreview] net: netprio_cgroup: rework update socket logic
    On Sun, Aug 12, 2012 at 10:55:17PM -0700, John Fastabend wrote:
    > On 8/12/2012 6:53 PM, Al Viro wrote:
    > > Ladies and gentlemen, who the devil had reviewed that little gem?
    > >
    > >commit 406a3c638ce8b17d9704052c07955490f732c2b8
    > >Author: John Fastabend <john.r.fastabend@intel.com>
    > >Date: Fri Jul 20 10:39:25 2012 +0000
    > >
    > >is a bleeding bogosity that doesn't pass even the most cursory
    > >inspection. It iterates through descriptor tables of a bunch
    > >of processes, doing this:
    > > file = fcheck_files(files, fd);
    > > if (!file)
    > > continue;
    > >
    > > path = d_path(&file->f_path, tmp, PAGE_SIZE);
    > > rv = sscanf(path, "socket:[%lu]", &s);
    > > if (rv <= 0)
    > > continue;
    > >
    > > sock = sock_from_file(file, &err);
    > > if (!err)
    > > sock_update_netprioidx(sock->sk, p);
    > >Note the charming use of sscanf() for pattern-matching. 's' (inode
    > >number of socket) is completely unused afterwards; what happens here
    > >is a very badly written attempt to skip non-sockets. Why, will
    > >sock_from_file() blow up on non-sockets? And isn't there some less
    > >obnoxious way to check that the file is a sockfs one? Let's see:
    > >struct socket *sock_from_file(struct file *file, int *err)
    > >{
    > > if (file->f_op == &socket_file_ops)
    > > return file->private_data; /* set in sock_map_fd */
    > >
    > > *err = -ENOTSOCK;
    > > return NULL;
    > >}
    > >... and the first line is exactly that - a check that we are on sockfs.
    > >_Far_ less expensive one, at that, so it's not even that we are avoiding
    > >a costly test. In other words, all masturbation with d_path() is absolutely
    > >pointless.
    > >
    > >Furthermore, it's racy; had been even more so before the delayed fput series
    > >went in, but even now it's not safe. fcheck_files() does *NOT* guarantee
    > >that file is not getting closed right now. rcu_read_lock() prevents only
    > >freeing and potential reuse of struct file we'd got; it might go all the
    > >way through final fput() just as we look at it. So file->f_path is not
    > >protected by anything. Worse yet, neither is struct socket itself - we
    > >might be going through sock_release() at the same time, so sock->sk might
    > >very well be NULL, leaving us a oops even after we dump d_path() idiocy.
    > >
    > >To make it even funnier, there's such thing as SCM_RIGHTS datagrams and
    > >descriptor passing. In other words, it's *not* going to catch all sockets
    > >that would be caught by the earlier variant.
    > >
    >
    Yes, thank you Al, I should have reviewed this more throughly.

    > OK clearly I screwed it up thanks for reviewing Al. How about this.
    >
    > fdt = files_fdtable(files);
    > for (fd = 0; fd < fdt->max_fds; fd++) {
    > struct socket *sock;
    > int err = 0;
    >
    > sock = sockfd_lookup(fd, &err);
    > if (!sock) {
    > lock_sock(sock->sk);
    What are you protecting with lock_sock here? The other call sites don't make
    use of the socket lock. Arguagbly they could, but I don't think they need to.
    As long as the fd doesn't go away we should be able to update the
    sk_cgrp_prioidx safely.

    Regards
    Neil



    \
     
     \ /
      Last update: 2012-08-13 14:03    [W:0.029 / U:60.068 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site