On 01/22/2018 04:12 AM, Guoqing Jiang wrote: > The previous patch provides protection for other modes > such as CREATE, MANAGE, GROW and INCREMENTAL. And for > ASSEMBLE mode, we also need to protect during the process > of assemble clustered raid. > > However, we can only know the array is clustered or not > when the metadata is ready, so the lock_cluster is called > after select_devices(). And we could re-read the metadata > when doing auto-assembly, so refresh the locking. > > Reviewed-by: NeilBrown <neilb@xxxxxxxx> > Signed-off-by: Guoqing Jiang <gqjiang@xxxxxxxx> > --- > Assemble.c | 32 +++++++++++++++++++++++++++++++- > 1 file changed, 31 insertions(+), 1 deletion(-) > > diff --git a/Assemble.c b/Assemble.c > index 3c10b6cd27c2..894ff361cf30 100644 > --- a/Assemble.c > +++ b/Assemble.c > @@ -1326,6 +1326,9 @@ int Assemble(struct supertype *st, char *mddev, > char chosen_name[1024]; > struct map_ent *map = NULL; > struct map_ent *mp; > + int locked = 0; > + struct mdp_superblock_1 *sb; > + bitmap_super_t *bms; > > /* > * If any subdevs are listed, then any that don't > @@ -1356,6 +1359,12 @@ try_again: > * set of devices failed. Those are now marked as ->used==2 and > * we ignore them and try again > */ > + if (locked) > + /* > + * if come back try_again is called, then need to unlock first, > + * and lock again since the metadate is re-read. > + */ > + cluster_release_dlmlock(); I am applying this for now, however I don't really love it. It seems to me it would be cleaner to just let cluster_release_dlmlock() do nothing if the cluster isn't locked. That way we could avoid the 217 cases of if (locked) Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
