Re: [PATCH v4 1/2] dm: prevent table type changes after initial table load

[Mike Snitzer <snitzer@redhat.com>]

On Tue, Jun 29 2010 at 10:19am -0400,
Alasdair G Kergon <agk@redhat.com> 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