lkml.org 
[lkml]   [2004]   [Oct]   [1]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 1 Oct 2004 12:18:22 +0200
FromPavel Machek <>
SubjectRe: [Patch 7/10]: ext3 online resize: SMP locking for group metadata
Hi!

> Fix the SMP locking for group metadata in online resize.
> 
> Most of the resize is simply not dangerous from an SMP point of view, as
> we're adding new data beyond the end of the device and so we're
> guaranteed that no existing CPUs can already be using that data.  But we
> need to be extremely careful about the ordering when enabling that new
> data.
> 
> The key to this is sb->s_groups_count; when that is raised, it enables
> new space on a filesystem, and the kernel will suddenly start accessing
> all of the newly-created tables for that space.
> 
> The precise rules we use are:
> 
> * Writers of s_groups_count *must* hold lock_super
> AND
> * Writers must perform a smp_wmb() after updating all dependent
>   data and before modifying the groups count
> 
> * Readers must hold lock_super() over the access
> OR
> * Readers must perform an smp_rmb() after reading the groups count
>   and before reading any dependent data.
> 
> This leaves the hot path, where s_groups_count is referenced, requiring
> an smp_rmb(); but no other locking on that hot path is required.

Should not s_groups_count be atomic_t, then? Is it possible that
normal read sees only half-updated value?

[I know this is non-issue at least on i386, and probably on most
architectures as long as s_groups_count is aligned...

							Pavel


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [from the cache]
©2003-2008