aboutsummaryrefslogtreecommitdiffstats
path: root/fs/splice.c
Commit message (Collapse)AuthorAge
* [PATCH] splice: fix page stealing LRU handling.Jens Axboe2006-04-02
| | | | | | | | | | | | Originally from Nick Piggin, just adapted to the newer branch. You can't check PageLRU without holding zone->lru_lock. The page release code can get away with it only because the page refcount is 0 at that point. Also, you can't reliably remove pages from the LRU unless the refcount is 0. Ever. Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: Jens Axboe <axboe@suse.de>
* [PATCH] splice: page stealing needs to wait_on_page_writeback()Jens Axboe2006-04-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Thanks to Andrew for the good explanation of why this is so. akpm writes: If a page is under writeback and we remove it from pagecache, it's still going to get written to disk. But the VFS no longer knows about that page, nor that this page is about to modify disk blocks. So there might be scenarios in which those blocks-which-are-about-to-be-written-to get reused for something else. When writeback completes, it'll scribble on those blocks. This won't happen in ext2/ext3-style filesystems in normal mode because the page has buffers and try_to_release_page() will fail. But ext2 in nobh mode doesn't attach buffers at all - it just sticks the page in a BIO, finds some new blocks, points the BIO at those blocks and lets it rip. While that write IO's in flight, someone could truncate the file. Truncate won't block on the writeout because the page isn't in pagecache any more. So truncate will the free the blocks from the file under the page's feet. Then something else can reallocate those blocks. Then write data to them. Now, the original write completes, corrupting the filesystem. Signed-off-by: Jens Axboe <axboe@suse.de>
* [PATCH] splice: export generic_splice_sendpageJens Axboe2006-04-02
| | | | | | | Forgot that one, thanks Jeff. Also move the other EXPORT_SYMBOL to right below the functions. Signed-off-by: Jens Axboe <axboe@suse.de>
* [PATCH] splice: add a SPLICE_F_MORE flagJens Axboe2006-04-02
| | | | | | | This lets userspace indicate whether more data will be coming in a subsequent splice call. Signed-off-by: Jens Axboe <axboe@suse.de>
* [PATCH] splice: add comments documenting more of the codeJens Axboe2006-04-02
| | | | | | Hopefully this will make Andrew a little more happy. Signed-off-by: Jens Axboe <axboe@suse.de>
* [PATCH] splice: improve writeback and clean up page stealingJens Axboe2006-04-02
| | | | | | | | | | By cleaning up the writeback logic (killing write_one_page() and the manual set_page_dirty()), we can get rid of ->stolen inside the pipe_buffer and just keep it local in pipe_to_file(). This also adds dirty page balancing logic and O_SYNC handling. Signed-off-by: Jens Axboe <axboe@suse.de>
* [PATCH] splice: fix shadow[] filling logicJens Axboe2006-04-02
| | | | | | | | | Clear the entire range, and don't increment pidx or we keep filling the same position again and again. Thanks to KAMEZAWA Hiroyuki. Signed-off-by: Jens Axboe <axboe@suse.de>
* splice: add SPLICE_F_NONBLOCK flagLinus Torvalds2006-04-02
| | | | | | | | | It doesn't make the splice itself necessarily nonblocking (because the actual file descriptors that are spliced from/to may block unless they have the O_NONBLOCK flag set), but it makes the splice pipe operations nonblocking. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] splice exportsJeff Garzik2006-03-31
| | | | | | | | Woe be unto he who builds their filesystems as modules. Signed-off-by: Jeff Garzik <jeff@garzik.org> [ Obscure quote from the infamous geek bible? ] Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] splice: add support for SPLICE_F_MOVE flagJens Axboe2006-03-30
| | | | | | | | | This enables the caller to migrate pages from one address space page cache to another. In buzz word marketing, you can do zero-copy file copies! Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Introduce sys_splice() system callJens Axboe2006-03-30
This adds support for the sys_splice system call. Using a pipe as a transport, it can connect to files or sockets (latter as output only). From the splice.c comments: "splice": joining two ropes together by interweaving their strands. This is the "extended pipe" functionality, where a pipe is used as an arbitrary in-memory buffer. Think of a pipe as a small kernel buffer that you can use to transfer data from one end to the other. The traditional unix read/write is extended with a "splice()" operation that transfers data buffers to or from a pipe buffer. Named by Larry McVoy, original implementation from Linus, extended by Jens to support splicing to files and fixing the initial implementation bugs. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>