On Wednesday May 20, sandeepksinha@xxxxxxxxx wrote: > Hi Neil, > > On Wed, May 20, 2009 at 4:28 AM, Neil Brown <neilb@xxxxxxx> wrote: > > On Tuesday May 19, sandeepksinha@xxxxxxxxx wrote: > >> Hi, > >> > >> In linear_add( ), the mddev is gets changed. > >> Don't we require to lock/unlock around mddev inorder to avoid races? > >> > > > > A good question. > > > > To be able to answer it, we must also ask "what races do we need to > > avoid". Did you have some possible races in mind? > > > > I see mddev being referenced in md.c (md layer) for lot of operations. > Actually for almost all operations we pass through it. i.e get array > info. True. The only field of mddev which linear_add changes, and which md.c looks at would be ->raid_disks. Are there any time where it depends on the value in a way that a race could make dangerous. I think not. > > I suspect in light of this it would be best to: > > 1/ insert a barrier() between setting ->private and setting > > ->raid_disks > > 2/ in which_dev, read ->raid_disks before ->private, and put a > > barrier in between. > > > > Do you suggest implementing barrier functions for linear raid? > Can you elaborate on this a bit more please? I'm not talking about IO request barriers, though I agree the terminology is confusing. I'm talking about memory barriers. See Documentation/memory-barriers.txt If one processor writes new values into two variables, 'a' and 'b'. At about the same time that another processor reads the two variables, then the second process could obviously get the two old values, or the two new values, or the new value of 'a' but the old value of 'b'. What is less obvious is that some times it could get the old value of 'a' and the new value of 'b'. You can remove some of this indeterminism with memory barriers. NeilBrown -- 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
