On Fri, Feb 17, 2017 at 05:09:29PM +0100, Miklos Szeredi wrote: > A file is opened for read-only, opened read-write (resulting in a copy up) > and modified. The data read back from the the read-only fd will be stale > in this case (the read-only file descriptor still refers to the lower, > unmodified file). > > This patchset fixes issues related to this corner case. This is a > requirement from various parties for accepting overlayfs as a "POSIX" > filesystem. > > When an operation (read, mmap, fsync) is done on an overlay fd opened > read-only that is referring to a lower file, check if it has been copied up > in the mean time. If so, open the upper file and use that for the operation. > > To make the performance impact minimal for non-overlay case, use a flag in > file->f_mode to indicate that this is an overlay file. This is one hell of a DoS vector - it's really easy to eat tons of struct file that way. Preparatory parts of that series make sense on their own, but your "let's allocate a struct file, call ->open() and schedule that struct file for closing upon the exit to userland on each kernel_read()" is not.
