lkml.org 
[lkml]   [2004]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Unnecessary barrier in sync_page()?
Andrea Arcangeli <andrea@suse.de> wrote:
>
> 'm thinking, does handle_write_error() holds a ref on the inode? that's
> the VM and it finds the page without passing through the inode. I'm
> afraid the VM isn't safe calling lock_page, or am I overlooking
> something here?

Yes, that's buggy - the caller has a ref on the page, but not on the inode.

I'm not sure what's worth doing in there - maybe just trylock it and if
that fails, lose the I/O error. Combine that with propagation of the page
error flags into the address_space within truncate_complete_page() and
invalidate_complete_page() and in shrink_list(). Does that cover
everything?

Or just kill handle_write_error() altogether and push the responsibility
for setting the address_space error bits into writepage() -
block_write_full_page() and mpage_writepage() do it already.

Let me think about it a bit.
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:1.138 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site