On Mon, Jun 15, 2009 at 07:59:54PM +0200, Jan Kara wrote:
> When we do delayed allocation of some buffer, we want to signal to VFS that
> the buffer is new (set buffer_new) so that it properly zeros out everything.
> But we don't have the buffer mapped yet so we cannot really unmap underlying
> metadata in this state. Make VFS avoid doing unmapping of metadata when the
> buffer is not yet mapped.
Is this a seperate bugfix for delalloc filesystems? What is the error
case of attempting to unmap underlying metadata of non mapped buffer?
Won't translate to a serious bug will it?
>
> Signed-off-by: Jan Kara <jack@xxxxxxx>
> ---
> fs/buffer.c | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 80e2630..7eb1710 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1683,8 +1683,9 @@ static int __block_write_full_page(struct inode *inode, struct page *page,
> if (buffer_new(bh)) {
> /* blockdev mappings never come here */
> clear_buffer_new(bh);
> - unmap_underlying_metadata(bh->b_bdev,
> - bh->b_blocknr);
> + if (buffer_mapped(bh))
> + unmap_underlying_metadata(bh->b_bdev,
> + bh->b_blocknr);
> }
> }
> bh = bh->b_this_page;
> @@ -1869,8 +1870,9 @@ static int __block_prepare_write(struct inode *inode, struct page *page,
> if (err)
> break;
> if (buffer_new(bh)) {
> - unmap_underlying_metadata(bh->b_bdev,
> - bh->b_blocknr);
> + if (buffer_mapped(bh))
> + unmap_underlying_metadata(bh->b_bdev,
> + bh->b_blocknr);
> if (PageUptodate(page)) {
> clear_buffer_new(bh);
> set_buffer_uptodate(bh);
> @@ -2683,7 +2685,7 @@ int nobh_write_begin(struct file *file, struct address_space *mapping,
> goto failed;
> if (!buffer_mapped(bh))
> is_mapped_to_disk = 0;
> - if (buffer_new(bh))
> + if (buffer_new(bh) && buffer_mapped(bh))
> unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr);
> if (PageUptodate(page)) {
> set_buffer_uptodate(bh);
> --
> 1.6.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
