Re: [Patch 7/10]: ext3 online resize: SMP locking for group metadata

[Pavel Machek]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/