• S
    virtio-9p: Change handling of flags in open() path for 9P2000.L · 630c2689
    Sripathi Kodi 提交于
    This patch applies on top of 9P2000.L patches that we have on the list.
    I took a look at how 9P server is handling open() flags in 9P2000.L path.
    I think we can do away with the valid_flags() function and simplify the
    code. The reasoning is as follows:
    
    O_NOCTTY: (If the file is a terminal, don't make it the controlling
    terminal of the process even though the process does not have a controlling
    terminal) By the time the control reaches 9P client it is clear that what
    we have is not a terminal device. Hence it does not matter what we do with
    this flag. In any case 9P server can filter this flag out before making the
    syscall.
    
    O_NONBLOCK: (Don't block if i) Can't read/write to the file ii) Can't get
    locks) This has an impact on FIFOs, but also on file locks. Hence we can
    pass it down to the system call.
    
    O_ASYNC: From the manpage:
    
       O_ASYNC
              Enable signal-driven I/O: generate a signal (SIGIO by default,  but
              this  can be changed via fcntl(2)) when input or output becomes pos-
              sible on this file descriptor.  This feature is only available  for
              terminals,  pseudo-terminals,  sockets,  and (since Linux 2.6) pipes
              and FIFOs.  See fcntl(2) for further details.
    
    Again, this does not make any impact on regular files handled by 9P. Also,
    we don't want 9P server to receive SIGIO. Hence I think 9P server can
    filter this flag out before making the syscall.
    
    O_CLOEXEC: This flag makes sense only on the client. If guest user space
    sets this flag the guest VFS will take care of calling close() on the fd if
    an exec() happens. Hence 9P client need not be bothered with this flag.
    Also I think QEMU will not do an exec, but if it does, it makes sense to
    close these fds. Hence we can pass this flag down to the syscall.
    
    O_CREAT: Since we are in open() path it means we have confirmed that the file
    exists. Hence there is no need to pass O_CREAT flag down to the system. In fact
    on some versions of glibc this causes problems, because we pass O_CREAT flag,
    but don't have permission bits. Hence we can just mask this flag out.
    
    So in summary:
    
    Mask out:
    O_NOCTTY
    O_ASYNC
    O_CREAT
    
    Pass-through:
    O_NONBLOCK
    O_CLOEXEC
    Signed-off-by: NSripathi Kodi <sripathik@in.ibm.com>
    Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
    630c2689
virtio-9p.c 89.5 KB