On Tue, Jun 29 2010 at 10:19am -0400, Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > On Tue, Jun 29, 2010 at 09:52:17AM -0400, Mike Snitzer wrote: > > As we talked about on irc. There is potential for do_resume() to > > destage the "inactive" table slot, in the process of making the table > > "live", and in parallel another table load can arrive to stage another > > "inactive" table (which can have a conflicting type). > > But the type already got set earlier and, once set, is an immutable table > property. There cannot be conflicts with do_resume - it doesn't touch > this. Yes, do_resume doesn't operate with any concern for md->type or md->queue changing because table_load safely sets these immutable properties. That safety comes at the expense of protecting a critical section in table_load. And that protection must span the access to both md->type and md->queue. Would you rather I ignore do_resume entirely? I'm not understanding why you keep going back to this notion that do_resume doesn't matter. The only reason it doesn't matter is because table_load takes care to make it that way. Without appropriate table_load serialization do_resume would be prone to the races I explained above. That's all I've been trying to convey. Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
