linux-ext4 - Re: [PATCH 0/6 v4] Lazy itable initialization for Ext4

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:	Tue, 28 Sep 2010 11:05:24 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Lukas Czerner <lczerner@...hat.com>
Cc:	linux-ext4@...r.kernel.org, rwheeler@...hat.com,
	sandeen@...hat.com, adilger@...ger.ca, snitzer@...il.com
Subject: Re: [PATCH 0/6 v4] Lazy itable initialization for Ext4

On Tue, Sep 28, 2010 at 12:01:42AM -0400, Ted Ts'o wrote:
> Why are they strange?  Because this was running under KVM, and there
> were no underlying hardware problems in the host OS.
> 
> The other two times I got a hard hang at XFStests 219 and 83, and the
> system was caught in such a type look that magic-sysrq wasn't working
> correctly.
> 
> I've XFStests in this setup before applying these patches, and things
> worked fine.  I'm currently rolling back the patches and trying
> another xfstests runs just to make sure the problem wasn't introduced
> by some patch, but for now, it looks there might be a problem
> somewhere.  And unfortunately, since it's not happening in a regular
> location or test, and the system is so badly locked up sysrq doesn't
> work, finding it may be intersting....

I've just tried bisecting the patches, and tried applying the first
three (well, two since I combined patches #2 and #3).  Simply enabling
the init_itables code wasn't enough to trigger the problem.  It looks
like the problem is in the last three patches (probably in one of the
patches where we convert ext4 to use sb_issue_zeroout, either the
extent or the resize code).

What I'll probably do (unless we find the problem very quickly) is to
reorder things so that we take the init_itable patch and the sysfs
feature patch, and put the rest into the unstable portion of the patch
queue.  That way I can work on the rest of the ext4 patches for the
merge window, without getting blocked on this patch series.  And if we
don't manage to figure out what went wrong, while it would be nice to
simplify the code for 2.6.36, it won't be the end of the world if they
need to wait until the next cycle.

				- 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