From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCHv5 04/16] VFS: add memory barrier to sb_mark_clean and sb_mark_dirty
Date: Wed, 09 Jun 2010 19:36:50 +0300 [thread overview]
Message-ID: <1276101410.5677.158.camel@localhost> (raw)
In-Reply-To: <1275835829-1478-5-git-send-email-dedekind1@gmail.com>
On Sun, 2010-06-06 at 17:50 +0300, Artem Bityutskiy wrote:
> From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
>
> The proper way for file-systems to synchronize the superblock
> should be as follows:
>
> 1. when modifying the SB, first modify it, then mark it as dirty;
> 2. when synchronizing the SB, first mark as clean, then start
> synchronizing.
>
> And to make ensure the order, we need memory barriers in 'sb_mark_clean()'
> and 'sb_mark_dirty()'.
I believe this stuff is a separate story, and should be handled
separately. I'll keep this separately from the 'sync_supers()' wakes up
optimization.
I actually now cannot prove myself whether these smp_mb()'s I added in
this patch make sense or not, and whether the races in FSes I was trying
to address can be addressed without spinlocks. Really dunno - but I will
keep trying to get better understanding. Reading
Documentation/memory-barriers.txt and some McKenny's docs only did not
help so far :-)
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-06-09 16:39 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-06 14:50 [PATCHv5 00/16] kill unnecessary SB sync wake-ups + cleanups Artem Bityutskiy
2010-06-06 14:50 ` Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 01/16] VFS: introduce helpers for the s_dirt flag Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 02/16] VFS: rename s_dirt to s_dirty Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 03/16] writeback: lessen sync_supers wakeup count Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 04/16] VFS: add memory barrier to sb_mark_clean and sb_mark_dirty Artem Bityutskiy
2010-06-06 17:16 ` Artem Bityutskiy
2010-06-06 17:16 ` Artem Bityutskiy
2010-06-06 19:22 ` Artem Bityutskiy
2010-06-06 19:22 ` Artem Bityutskiy
2010-06-09 16:36 ` Artem Bityutskiy [this message]
2010-06-06 14:50 ` [PATCHv5 05/16] AFFS: clean up dirty flag usage Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 06/16] AFFS: wait for sb synchronization when needed Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 07/16] AFFS: fix race condition in marking SB dirty Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 08/16] BFS: clean up the superblock usage Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 09/16] btrfs: remove junk sb_mark_dirty call Artem Bityutskiy
2010-06-12 7:36 ` Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 10/16] exofs: fix race condition in marking SB dirty Artem Bityutskiy
2010-06-06 16:12 ` Boaz Harrosh
2010-06-06 14:50 ` [PATCHv5 11/16] ext2: " Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 12/16] ext4: " Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 13/16] HFS: " Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 14/16] HFS: kill hfs_buffer_sync Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 15/16] HFS: wait for sb synchronization when needed Artem Bityutskiy
2010-06-06 14:50 ` [PATCHv5 16/16] HFSPLUS: wait for synchronization Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1276101410.5677.158.camel@localhost \
--to=artem.bityutskiy@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.