![]() | |||||||||||||
Messages in this thread |
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 | |||||||||||||