Messages in this thread | | | Date | Thu, 30 Mar 2006 11:19:17 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] splice support #2 |
| |
Jens Axboe <axboe@suse.de> wrote: > > On Thu, Mar 30 2006, Jens Axboe wrote: > > On Thu, Mar 30 2006, Andrew Morton wrote: > > > Jens Axboe <axboe@suse.de> wrote: > > > > > > > > > > +static void *page_cache_pipe_buf_map(struct file *file, > > > > > > + struct pipe_inode_info *info, > > > > > > + struct pipe_buffer *buf) > > > > > > +{ > > > > > > + struct page *page = buf->page; > > > > > > + > > > > > > + lock_page(page); > > > > > > + > > > > > > + if (!PageUptodate(page)) { > > > > > > > > > > || page->mapping == NULL > > > > > > > > Fixed > > > > > > Actually that wasn't right. If the page was truncated then we shouldn't > > > return -EIO to userspace. We should return zero, as this is the first > > > page. > > > > _if_ this is the first page, then agree. > > > > > Which means either returning an ERR_PTR here for -EIO or re-checking i_size > > > in the caller. Maybe the latter? > > > > The latter sounds better, I'll add that. > > Actually that's a little hard, since you don't know what state buf->page > is in - it might be page cache, it might not be. So I opted for the > ERR_PTR approach, just returning -ENODATA on !page->mapping. >
That's good, because the recheck-i_size idea was racy too. If another thread were to do a quick truncate-then-extend then there's a window where we'd see a truncated page, return NULL from page_cache_pipe_buf_map() and then by the time i_size is re-checked, i_size has grown again so we end up deciding it must have been an IO error.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |