Messages in this thread | | | Date | Tue, 8 Mar 2005 15:11:59 +0530 | From | Suparna Bhattacharya <> | Subject | Re: [PATCH] 2.6.10 - direct-io async short read bug |
| |
On Tue, Mar 08, 2005 at 01:18:14AM -0800, Andrew Morton wrote: > Suparna Bhattacharya <suparna@in.ibm.com> wrote: > > > > ... > > > > Bugs in this area seem never-ending don't they - plug one, open up > > another - hard to be confident/verify :( - someday we'll have to > > rewrite a part of this code. > > It's solving a complex problem. Any rewrite would probably end up just as > hairy once all the new bugs and corner cases are fixed. Maybe. > > > > Hmm, shouldn't dio->result ideally have been adjusted to be within > > i_size at the time of io submission, so we don't have to deal with > > this during completion ? We are creating bios with the right size > > after all. > > > > We have this: > > if (!buffer_mapped(map_bh)) { > > .... > > if (dio->block_in_file >= > > i_size_read(dio->inode)>>blkbits) { > > /* We hit eof */ > > page_cache_release(page); > > goto out; > > } > > > > and > > dio->result += iov[seg].iov_len - > > ((dio->final_block_in_request - dio->block_in_file) << > > blkbits); > > > > > > can you spot what is going wrong here that we have to try and > > workaround this later ? > > Good question. Do we have the i_sem coverage to prevent a concurrent > truncate? > > But from Sebastien's description it doesn't soound as if a concurrent > truncate is involved.
Daniel McNeil has a testcase that reproduces the problem - seemed like a single thread thing - that's what puzzles me.
Regards Suparna
-- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Lab, India
- 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/
| |