linux-ext4 - Re: [PATCH v0 RFC] ext4: Fix a bug in ext4_journal_start

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] [day] [month] [year] [list]

Message-ID: <BANLkTimFwK+S7Y1crVdtDtir5qHTSCz85g@mail.gmail.com>
Date:	Tue, 5 Apr 2011 13:45:33 +0800
From:	Yongqiang Yang <xiaoqiangnk@...il.com>
To:	Jan Kara <jack@...e.cz>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH v0 RFC] ext4: Fix a bug in ext4_journal_start_sb().

On Mon, Apr 4, 2011 at 10:09 PM, Jan Kara <jack@...e.cz> wrote:
> On Mon 04-04-11 20:31:41, Yongqiang Yang wrote:
>> >> Reported-by: Amir Goldstein <amir73il@...rs.sf.net>
>> >> Signed-off-by: Yongqiang Yang <xiaoqiangnk@...il.com>
>> >> ---
>> >>  fs/ext4/super.c |   49 ++++++++++++++++++++++++++++++++++++++-----------
>> >>  1 files changed, 38 insertions(+), 11 deletions(-)
>> >>
>> >> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> >> index ccfa686..f35b53e 100644
>> >> --- a/fs/ext4/super.c
>> >> +++ b/fs/ext4/super.c
>> >> @@ -242,27 +242,49 @@ static void ext4_put_nojournal(handle_t *handle)
>> >>   * journal_end calls result in the superblock being marked dirty, so
>> >>   * that sync() will call the filesystem's write_super callback if
>> >>   * appropriate.
>> >> + *
>> >> + * To avoid j_barrier hold in userspace when a user calls freeze(),
>> >> + * ext4 prevents a new handle from being started by s_frozen, which
>> >> + * is in an upper layer.
>> >>   */
>> >>  handle_t *ext4_journal_start_sb(struct super_block *sb, int nblocks)
>> >>  {
>> >>       journal_t *journal;
>> >> +     handle_t  *handle;
>> >>
>> >>       if (sb->s_flags & MS_RDONLY)
>> >>               return ERR_PTR(-EROFS);
>> >>
>> >> -     vfs_check_frozen(sb, SB_FREEZE_TRANS);
>> >> -     /* Special case here: if the journal has aborted behind our
>> >> -      * backs (eg. EIO in the commit thread), then we still need to
>> >> -      * take the FS itself readonly cleanly. */
>> >>       journal = EXT4_SB(sb)->s_journal;
>> >> -     if (journal) {
>> >> -             if (is_journal_aborted(journal)) {
>> >> -                     ext4_abort(sb, "Detected aborted journal");
>> >> -                     return ERR_PTR(-EROFS);
>> >> -             }
>> >> -             return jbd2_journal_start(journal, nblocks);
>> >> +     if (!journal)
>> >> +             /*
>> >> +              * Under no-journal mode, vfs_check_frozen() is not neeed.
>> >> +              */
>> >  Why is this? Previously we waited also in the nojournal case and I don't
>> > see anything that would stop modifications in the nojournal case after your
>> > change...
>>
>> I think that ext4 in the nojournal case should do as filesystems
>> without journal, such as ext2.   ext4_ext_truncate() upwrite
>  But ext2 does not support filesystem freezing...
>
>> i_data_sem only if ext4_journal_extend() fails before
>> ext4_journal_restart() is called, ext4_journal_extend() however always
>> succeeds in nojournal case.
>  OK, but again, I'm failing to see how i_data_sem behavior is relevant
> for waiting if a filesystem is frozen... So to be clear I believe we must
> do vfs_check_frozen() even in nojournal case if and only if the handle
> reference count is 0 (it's stored directly in current->journal_info in
> nojournal mode).

My ignorance,  I made analysis on i_data_sem under the assumption that
ext3 supports filesystem freezing.


>
>                                                                        Honza
> --
> Jan Kara <jack@...e.cz>
> SUSE Labs, CR
>



-- 
Best Wishes
Yongqiang Yang
--
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