linux-ext4 - Re: [PATCH] fs/jbd2: t_updates should increase when start_this_handle() failed in jbd2__journal

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

Date:	Sun, 23 Jun 2013 13:36:28 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Younger Liu <younger.liu@...wei.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-ext4@...r.kernel.org,
	Ocfs2-Devel <ocfs2-devel@....oracle.com>,
	Li Zefan <lizefan@...wei.com>, jack@...e.cz
Subject: Re: [PATCH] fs/jbd2: t_updates should increase when
 start_this_handle() failed in jbd2__journal_restart()

On Fri, Jun 21, 2013 at 09:29:31PM +0800, Younger Liu wrote:
> 
> This bug was triggered by the following scenario:
> In ocfs2 file system, allocate a very large disk space for a small file
> with ocfs2_fallocate(), while the journal file size is 32M. 
> 
> Because there are much many journal blocks needed by jbd2_journal_restart(), 
> so that nblocks is greater than journal->j_max_transaction_buffers 
> in start_this_handle(), and then return -ENOSPC.

Ah, I see.  I have a patch that should prevent the kernel from
crashing in this situation, and which adds some additional checks to
make sure no one tries to use the handle after jbd2_journal_restart()
fails in this circumstance.

However, you may want to further pursue a fix in ocfs2 so you don't
actually return ENOSPC to userspace, since it is a very misleading
error message --- it's not that the file system is out of space, but
that the journal is too small for the amount of space that you are
trying to allocate using fallocate().

I would think a better way of handling this situation would be to log
a warning message that the journal is probably too small, and then to
break up the fallocate into smaller chunks, so that it can
successfully complete despite the fact that the journal was
unfortunately missized.

I'll be sending the proposed fix in a moment; could you check and see
if the patch prevents ocfs2/jbd2 from tripping over the assertion
given your test case?

Thanks,

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