linux/fs/pipe.c, branch v3.19

new helper: copy_page_from_iter()

2014-05-06T21:39:42Z

parallel to copy_page_to_iter(). pipe_write() switched to it (and became ->write_iter()). Signed-off-by: Al Viro

pipe: switch to ->read_iter()

2014-05-06T21:37:58Z

Signed-off-by: Al Viro

start adding the tag to iov_iter

2014-05-06T21:32:49Z

For now, just use the same thing we pass to ->direct_IO() - it's all iovec-based at the moment. Pass it explicitly to iov_iter_init() and account for kvec vs. iovec in there, by the same kludge NFS ->direct_IO() uses. Signed-off-by: Al Viro

switch pipe_read() to copy_page_to_iter()

2014-04-02T03:19:22Z

Signed-off-by: Al Viro

pipe: kill ->map() and ->unmap()

2014-04-02T03:19:19Z

all pipe_buffer_operations have the same instances of those... Signed-off-by: Al Viro

fs/pipe.c: skip file_update_time on frozen fs

2014-01-24T00:37:00Z

Pipe has no data associated with fs so it is not good idea to block pipe_write() if FS is frozen, but we can not update file's time on such filesystem. Let's use same idea as we use in touch_time(). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=65701 Signed-off-by: Dmitry Monakhov Reviewed-by: Jan Kara Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vfs: fix subtle use-after-free of pipe_inode_info

2013-12-02T17:44:51Z

The pipe code was trying (and failing) to be very careful about freeing the pipe info only after the last access, with a pattern like: spin_lock(&inode->i_lock); if (!--pipe->files) { inode->i_pipe = NULL; kill = 1; } spin_unlock(&inode->i_lock); __pipe_unlock(pipe); if (kill) free_pipe_info(pipe); where the final freeing is done last. HOWEVER. The above is actually broken, because while the freeing is done at the end, if we have two racing processes releasing the pipe inode info, the one that *doesn't* free it will decrement the ->files count, and unlock the inode i_lock, but then still use the "pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)". This is *very* hard to trigger in practice, since the race window is very small, and adding debug options seems to just hide it by slowing things down. Simon originally reported this way back in July as an Oops in kmem_cache_allocate due to a single bit corruption (due to the final "spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different allocation that had re-used the free'd pipe-info), it's taken this long to figure out. Since the 'pipe->files' accesses aren't even protected by the pipe lock (we very much use the inode lock for that), the simple solution is to just drop the pipe lock early. And since there were two users of this pattern, create a helper function for it. Introduced commit ba5bb147330a ("pipe: take allocation and freeing of pipe_inode_info out of ->i_mutex"). Reported-by: Simon Kirby Reported-by: Ian Applegate Acked-by: Al Viro Cc: stable@kernel.org # v3.10+ Signed-off-by: Linus Torvalds

aio: don't include aio.h in sched.h

2013-05-08T03:16:25Z

Faster kernel compiles by way of fewer unnecessary includes. [akpm@linux-foundation.org: fix fallout] [akpm@linux-foundation.org: fix build] Signed-off-by: Kent Overstreet Cc: Zach Brown Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Mark Fasheh Cc: Joel Becker Cc: Rusty Russell Cc: Jens Axboe Cc: Asai Thambi S P Cc: Selvan Mani Cc: Sam Bradshaw Cc: Jeff Moyer Cc: Al Viro Cc: Benjamin LaHaise Reviewed-by: "Theodore Ts'o" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

get rid of the last free_pipe_info() callers

2013-04-09T18:13:02Z

and rename __free_pipe_info() to free_pipe_info() Signed-off-by: Al Viro

get rid of alloc_pipe_info() argument

2013-04-09T18:13:01Z

not used anymore Signed-off-by: Al Viro