Suparna Bhattacharya <[EMAIL PROTECTED]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
