linux-kernel - Re: 2.6.29 -mm merge plans

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: <20090107011448.GB3390@wotan.suse.de>
Date:	Wed, 7 Jan 2009 02:14:48 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.29 -mm merge plans

On Tue, Jan 06, 2009 at 06:24:18PM -0500, Christoph Hellwig wrote:
> On Tue, Jan 06, 2009 at 03:11:31PM -0800, Andrew Morton wrote:
> > > I'm not sure this is a good idea.  Concurrent syncs are a bad idea
> > > to start with and we should just synchronyze do_sync completely.
> > > sync_filesystems as one of the main components of do_sync already
> > > is synchronized in that way, and taking that to a higher level would
> > > get rid of all the worries about concurrent syncs.
> > 
> > Yes, single-threading sys_sync() would fix the problem which that patch
> > addresses.
> > 
> > However there are a lot of performance and correctness issues around
> > sys_sync()-versus-fsync(), etc for which such a simple fix won't be
> > acceptable.
> 
> fsync should really not much interac with sync at that level.  While
> they both end up at same primitives at the lowest level those aren't
> the ones we're trying to protect against.  I'm currently in the process
> of a major rework of sys_sync/do_sync to make it work properly for
> modern filesystems and the global synchronization was one of the first
> things I did..
> 
> So if you have any workloads where that causes a problem please send
> them my way.  Not that I can really thing of them, given the global
> nature of sys_sync I can't see any benefit of doing multiple of these
> in parallel.

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).

But this patch fixes a correctness problem, so I think it is OK to go
upstream now.

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