linux-ext4 - Re: [PATCH v1 19/22] e2fsck: check inline

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]

Message-ID: <20131012091755.GA8117@gmail.com>
Date:	Sat, 12 Oct 2013 17:17:55 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	linux-ext4@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
	Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: [PATCH v1 19/22] e2fsck: check inline_data in pass3

On Sat, Oct 12, 2013 at 02:09:35AM -0700, Darrick J. Wong wrote:
> On Sat, Oct 12, 2013 at 05:06:35PM +0800, Zheng Liu wrote:
> > On Fri, Oct 11, 2013 at 05:54:10PM -0700, Darrick J. Wong wrote:
> > > On Fri, Aug 02, 2013 at 05:49:46PM +0800, Zheng Liu wrote:
> > > > From: Zheng Liu <wenqing.lz@...bao.com>
> > > > 
> > > > In e2fsck_expand_directory() we don't handle a dir with inline data
> > > > because when this function is called the directory inode shouldn't
> > > > contains inline data.
> > > > 
> > > > Signed-off-by: Theodore Ts'o <tytso@....edu>
> > > > Signed-off-by: Zheng Liu <wenqing.lz@...bao.com>
> > > > ---
> > > >  e2fsck/pass3.c  |   12 ++++++++++++
> > > >  e2fsck/rehash.c |    3 ++-
> > > >  2 files changed, 14 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/e2fsck/pass3.c b/e2fsck/pass3.c
> > > > index a379e9b..5052345 100644
> > > > --- a/e2fsck/pass3.c
> > > > +++ b/e2fsck/pass3.c
> > > > @@ -787,6 +787,18 @@ errcode_t e2fsck_expand_directory(e2fsck_t ctx, ext2_ino_t dir,
> > > >  	es.ctx = ctx;
> > > >  	es.dir = dir;
> > > >  
> > > > +	/*
> > > > +	 * 'lost+found' dir shouldn't contains inline data.  So we
> > > > +	 * need to clear this flag.
> > > > +	 */
> > > > +	if (ext2fs_inode_has_inline_data(fs, dir)) {
> > > > +		retval = ext2fs_read_inode(fs, dir, &inode);
> > > > +		if (retval)
> > > > +			return retval;
> > > > +		inode.i_flags &= ~EXT4_INLINE_DATA_FL;
> > > > +		e2fsck_write_inode(ctx, dir, &inode, "clear inline_data flag");
> > > > +	}
> > > > +
> > > >  	retval = ext2fs_block_iterate3(fs, dir, BLOCK_FLAG_APPEND,
> > > >  				       0, expand_dir_proc, &es);
> > > 
> > > Are you saying that lost+found can have inline_data set yet i_blocks is
> > > actually a block map/extent head?  Or are we supposed to zero i_blocks?
> > > 
> > > If we clear EXT4_INLINE_DATA_FL and then try to iterate blocks, are we setting
> > > ourselves up to read (formerly inline) dirents as a block map and iterate it?
> > > 
> > > Shouldn't we care if the inode write fails?
> > 
> > lost+found dir shouldn't have inline_data flag because this is a special
> > directory that it is preallocated some blocks when it is created because
> > we need to avoid to allocate some blocks for it when we check a file
> > system using e2fsck.  So we need to clear inline_data flag if this dir
> > has this flag.
> 
> How does get that flag in the first place?

Technically, it shouldn't get this flag.  Think about it again, it seems
that we don't need to handle this because it couldn't happen.

                                                - Zheng
--
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