lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 18 Dec 2009 15:11:54 -0800
From:	Curt Wohlgemuth <curtw@...gle.com>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext4: Ensure zeroout blocks have no dirty metadata

On Fri, Dec 18, 2009 at 4:10 AM, Aneesh Kumar K.V
<aneesh.kumar@...ux.vnet.ibm.com> wrote:
> On Fri, Dec 18, 2009 at 05:19:46PM +0530, Aneesh Kumar K.V wrote:
>> On Thu, Dec 10, 2009 at 09:28:28AM -0800, Curt Wohlgemuth wrote:
>> > This fixes a bug in which new blocks returned from an extent created with
>> > ext4_ext_zeroout() can have dirty metadata still associated with them.
>> >
>> >     Signed-off-by: Curt Wohlgemuth <curtw@...gle.com>
>
> A better option would be to do the unmap during fallocate.

The problem here is that we'll also call unmap_underlying_metadata()
on these same blocks when they get written to, and the extents become
initialized.  At that point, the buffers are marked as 'new' and so
__block_write_full_page() and friends will again try to clear out any
old metadata.

You could argue that since there won't be any metadata that this
second call will be fast, but still...

Curt

>
> commit 87b3121fd9d1223acb08326fc0c9711b0bc3cfeb
> Author: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
> Date:   Fri Dec 18 17:38:15 2009 +0530
>
>    ext4: unmap the underlying metadata when allocating blocks via fallocate
>
>    This become important when we are running with nojournal mode. We
>    may end up allocating recently freed metablocks for fallocate. We
>    want to make sure we unmap the old mapping so that when we convert
>    the fallocated uninitialized extent to initialized extent we don't
>    have the old mapping around. Leaving the old mapping can cause
>    file system corruption
>
>    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index ab31e65..7c0fcae 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1768,6 +1768,20 @@ static inline void set_bitmap_uptodate(struct buffer_head *bh)
>        set_bit(BH_BITMAP_UPTODATE, &(bh)->b_state);
>  }
>
> +/*
> + * __unmap_underlying_bh_blocks - just a helper function to unmap
> + * set of blocks described by @bh
> + */
> +static inline void __unmap_underlying_bh_blocks(struct inode *inode,
> +                                            struct buffer_head *bh)
> +{
> +       struct block_device *bdev = inode->i_sb->s_bdev;
> +       int blocks, i;
> +
> +       blocks = bh->b_size >> inode->i_blkbits;
> +       for (i = 0; i < blocks; i++)
> +               unmap_underlying_metadata(bdev, bh->b_blocknr + i);
> +}
>  #endif /* __KERNEL__ */
>
>  #endif /* _EXT4_H */
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index 3a7928f..4e646a5 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -3508,6 +3508,8 @@ retry:
>                        ret2 = ext4_journal_stop(handle);
>                        break;
>                }
> +               if (buffer_new(&map_bh))
> +                       __unmap_underlying_bh_blocks(inode, &map_bh);
>                if ((block + ret) >= (EXT4_BLOCK_ALIGN(offset + len,
>                                                blkbits) >> blkbits))
>                        new_size = offset + len;
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 5352db1..7b44737 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -2073,22 +2073,6 @@ static void mpage_put_bnr_to_bhs(struct mpage_da_data *mpd, sector_t logical,
>        }
>  }
>
> -
> -/*
> - * __unmap_underlying_blocks - just a helper function to unmap
> - * set of blocks described by @bh
> - */
> -static inline void __unmap_underlying_blocks(struct inode *inode,
> -                                            struct buffer_head *bh)
> -{
> -       struct block_device *bdev = inode->i_sb->s_bdev;
> -       int blocks, i;
> -
> -       blocks = bh->b_size >> inode->i_blkbits;
> -       for (i = 0; i < blocks; i++)
> -               unmap_underlying_metadata(bdev, bh->b_blocknr + i);
> -}
> -
>  static void ext4_da_block_invalidatepages(struct mpage_da_data *mpd,
>                                        sector_t logical, long blk_cnt)
>  {
> @@ -2243,7 +2227,7 @@ static int mpage_da_map_blocks(struct mpage_da_data *mpd)
>        new.b_size = (blks << mpd->inode->i_blkbits);
>
>        if (buffer_new(&new))
> -               __unmap_underlying_blocks(mpd->inode, &new);
> +               __unmap_underlying_bh_blocks(mpd->inode, &new);
>
>        /*
>         * If blocks are delayed marked, we need to
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ