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
| ||
|
Message-ID: <20100928150524.GD7865@thunk.org> 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
Powered by blists - more mailing lists