| 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: <20091209113016.GG4863@quack.suse.de> Date: Wed, 9 Dec 2009 12:30:16 +0100 From: Jan Kara <jack@...e.cz> To: tytso@....edu Cc: linux-ext4@...r.kernel.org Subject: Re: [PATCH 4/4] ext4: Wait for proper transaction commit on fsync On Tue 08-12-09 22:51:20, tytso@....edu wrote: > On Mon, Nov 16, 2009 at 11:43:31AM +0100, Jan Kara wrote: > > > Why do we need an atomic_t here at all? It's not clear it's > > > necessary. What specific race are you worried about? > > Well, i_[data]sync_tid are set and read from several places which aren't > > currently synchronized against each other and I din't want to introduce any > > synchronization. So atomic_t seemed like a clean way of making clear that > > loads / stores from those fields are atomic, regardless of architecture, > > memory alignment or whatever insanity that might make us see just half > > overwritten field. On all archs where this means just plain stores / loads > > (such as x86), there's no performance hit since the operations are > > implemented as such. > > Sorry for not responding to this one sooner, but see this URL: > > http://digitalvampire.org/blog/index.php/2007/05/13/atomic-cargo-cults/ Thanks for the pointer :) It's a good reading... Honza -- Jan Kara <jack@...e.cz> SUSE Labs, CR -- 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