linux-ext4 - Re: ext4: journal has aborted

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: <20140711114359.GA433@thunk.org>
Date:	Fri, 11 Jul 2014 07:43:59 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Whitney <enwlinux@...il.com>
Cc:	"Darrick J. Wong" <darrick.wong@...cle.com>,
	Matteo Croce <technoboy85@...il.com>,
	David Jander <david@...tonic.nl>,
	Dmitry Monakhov <dmonakhov@...nvz.org>,
	linux-ext4@...r.kernel.org, Azat Khuzhin <a3at.mail@...il.com>
Subject: Re: ext4: journal has aborted

On Thu, Jul 10, 2014 at 08:45:08PM -0400, Eric Whitney wrote:
> 
> Reverting the suspect patch - 007649375f - on 3.16-rc3 and running on the
> Panda yielded 10 successive "successful" generic/068 failures (no block
> bitmap trouble on reboot).  So, it looks like that patch is all of it.

Thanks again Eric, for finding this!!

> Running the same test scenario on Darrick's patch (CONFIG_EXT4FS_DEBUG =>
> CONFIG_EXT4_DEBUG) applied to 3.16-rc3 lead to exactly the same result.
> No panics, BUGS, or other misbehavior whether generic/068 completed 
> successfully or failed (and that test used here simply because it was
> convenient) and no trouble on boot, etc.

I've been looking more closely at the changes in line, and I suspect
the real fix is that we should move these lines:

	ext4_free_blocks_count_set(sbi->s_es,
				   EXT4_C2B(sbi, ext4_count_free_clusters(sb)));
	sbi->s_es->s_free_inodes_count =cpu_to_le32(ext4_count_free_inodes(sb));

after the journal is run.  Not that it really matters since so very
little (and nothing for normal file system operation, including the
statfs(2) system call) actually depends on the free blocks count in
the superblock --- instead we the percpu "s_freeclusters_count" and
"s_dirtyclusters_counter" fields for scalability reasons --- but if we
*are* going to set these fields in the on-disk superblock, we should
wait until *after* we have updated the allocation bitmaps before we
start counting the free blocks in those bitmaps.

Cheers,

					- 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