[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH v4 1/2] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer redhat com>
- To: device-mapper development <dm-devel redhat com>
- Subject: Re: [dm-devel] [PATCH v4 1/2] dm: prevent table type changes after initial table load
- Date: Tue, 29 Jun 2010 11:07:21 -0400
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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]