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: <20091116104331.GB23231@duck.suse.cz>
Date:	Mon, 16 Nov 2009 11:43:31 +0100
From:	Jan Kara <jack@...e.cz>
To:	Theodore Tso <tytso@....edu>
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 4/4] ext4: Wait for proper transaction commit on fsync

On Sun 15-11-09 19:46:41, Theodore Tso wrote:
> On Tue, Oct 27, 2009 at 01:48:49PM +0100, Jan Kara wrote:
> > +	/*
> > +	 * Transactions that contain inode's metadata needed to complete
> > +	 * fsync and fdatasync, respectively.
> > +	 */
> > +	atomic_t i_sync_tid;
> > +	atomic_t i_datasync_tid;
> 
> 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.

									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

Powered by Openwall GNU/*/Linux Powered by OpenVZ