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
| ||
|
Date: Wed, 7 Jan 2009 02:49:15 +0100 From: Nick Piggin <npiggin@...e.de> To: Andi Kleen <andi@...stfloor.org> Cc: Christoph Hellwig <hch@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org Subject: Re: 2.6.29 -mm merge plans On Wed, Jan 07, 2009 at 02:38:45AM +0100, Andi Kleen wrote: > Nick Piggin <npiggin@...e.de> writes: > > > > I can't see a problem with putting a global mutex around sys_sync (almost > > by definition, any app in the last 10+ years that calls sys_sync is not > > performance critical). > > Hmm, but sync() used to (is still?) livelocky and when it takes a It's not livelocky because it no longer has to do repeated passes over the superblock list. It is subject to the single inode syncing issue where it can get stuck behind a process dirtying memory (same as fsync) but we've decided not to add complexity to improve that just yet, and see whether it turns out to be a real problem. > minute or so to flush (and I've seen that) do you really want any > other sync user to block for a minute too? sys_sync B which is invoked *after* sys_sync caller A should not return before A. If you didn't have a global lock, they'd tend to block one another's pages anyway. I think it's OK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists