linux-ext4 - Re: one question about jbd, please look into it

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20080617124216.GC12527@duck.suse.cz>
Date:	Tue, 17 Jun 2008 14:42:16 +0200
From:	Jan Kara <jack@...e.cz>
To:	dingdinghua <dingdinghua85@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: one question about jbd, please look into it

  Hello,

On Tue 17-06-08 17:09:26, dingdinghua wrote:
>      I'm a graduate student from china, I have a question about JBD, my
>      kernel version is 2.6.17, and our jbd version is some version
>      between jbd and jbd2, since I only need the 64bit-bno feature, jbd
>      was not fully patched to jbd2.  My question is, "what will happen if
>      too many block need revoke in a transaction" or "can this situation
>      happen?" In order to investigate it, I did an experiment, I modified
  Hmm, in theory you are right that this could happen, in practice it does
not because if we delete metadata blocks (or directory blocks), we modify
them before. Hence, because number of blocks in a transaction is limited,
the number of revoke records is limited as well and fits into the safety
margin...

>      ext3 as follows:
> 
> fs/ext3/inode.c >> ext3_forget
> 
> <       if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA ||
> <        (!is_metadata && !ext3_should_journal_data(inode))) {
> ---
> >       //if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA ||
> >        if(!is_metadata && !ext3_should_journal_data(inode)) { 
  Yes, after this modification you may be able to trigger the problem - but
note that when everything is journaled no revoke records are needed (they
are only needed because some block can contain journaled metadata and later
be reallocated for non-journaled data).

>      I mount a partition as ext3, using data=journal mode, then we create
>      a reg file, about 2G, when unlinking the file, jbd will get into
>      mistake, the log:
> 
>  Assertion failure in journal_next_log_block() at fs/jbd/journal.c:561: "journal->j_free > 1"
  <snip>

>      This situation(i don't know if it can be called "bug") can easily
>      reappear in situation above.  When I read jbd code,  I found that
>      jbd doesn't make any guarantee that there are enough block in
>      jornal-device which can be used as revoke block. The major job
>      "journal_revoke" do is insert [sequence, blocknr] into hash link,
>      when this transaction commit, the entries in hash link will be
>      flushed to journal by "journal_write_revoke_records", this function
>      call "write_one_revoke_record", then "journal_get_descriptor_buffer"
>      when needing an new block, then "journal_next_log_block", since jbd
>      can't guarantee there are enough block, assertion
>      J_ASSERT(journal->j_free > 1); may fail, just as the log above.
>      Certainly, If I haven't modified the ext3 code, this situation
>      couldn't happen, but what about remove a very large directory?
  Yes, as I wrote above, you are right that there's a gap. Maybe with big
enough directory you may be able to trigger the problem. The question is
how to fix this without a too big hassle. Probably we should account for
revoke record block when requesting credits for a handle in
journal_start(), track number of revokes already added by a handle and
account for credits really used by revoke blocks so that we don't return
them on journal_stop(). This should be reasonably easy. Will you do the
fix?

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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