linux-ext4 - Re: [PATCH 3/3] ext4: Handle non empty on-disk orphan link

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, 26 Feb 2010 01:55:45 +0300
From:	Dmitry Monakhov <dmonakhov@...nvz.org>
To:	"linux-ext4\@vger.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 3/3] ext4: Handle non empty on-disk orphan link

Dmitry Monakhov <dmonakhov@...nvz.org> writes:

> In case of truncate errors we explicitly remove inode from in-core
> orphan list via orphan_del(NULL, inode) without on-disk list
> modification.
> But later same inode may be inserted in the orphan list again which
> result in on-disk link corruption.
There is another "100% reliable" way to solve the issue.
In case of truncate error instead of cleaning in-core inode's list
we may just reinsert it in to another sb->s_orphan_error list. 
In this case orphan_add() will works without changes because
!list_empty() check will works as expected. And if later it is 
also possible to call orphan_del().
Later we even may try to replay this s_orphan_error list for
example before umount/remount
But this solution has major disadvantage. We can have to pin
inode in to memory to prevent inode pruning.
This is not best choice because usually truncate failed
because of ENOMEM. 

That's why i use this not absolutely reliable but simple approach.
>  If inode i_dtime contains valid
> value let skip on-disk list modification.

>
> Signed-off-by: Dmitry Monakhov <dmonakhov@...nvz.org>
> ---
>  fs/ext4/namei.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index 17a17e1..19ca9bf 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -2020,6 +2020,13 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode)
>  	err = ext4_reserve_inode_write(handle, inode, &iloc);
>  	if (err)
>  		goto out_unlock;
> +	/*
> +	 * Due to previous errors inode may be already a part of on-disk
> +	 * orphan list. If so skipp on-disk list modification.
> +	 */
> +	if (NEXT_ORPHAN(inode) && NEXT_ORPHAN(inode) <=
> +		(le32_to_cpu(EXT4_SB(sb)->s_es->s_inodes_count)))
> +			goto mem_insert;
>  
>  	/* Insert this inode at the head of the on-disk orphan list... */
>  	NEXT_ORPHAN(inode) = le32_to_cpu(EXT4_SB(sb)->s_es->s_last_orphan);
> @@ -2037,6 +2044,7 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode)
>  	 *
>  	 * This is safe: on error we're going to ignore the orphan list
>  	 * anyway on the next recovery. */
> +mem_insert:
>  	if (!err)
>  		list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan);
--
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