* [PATCH] device-mapper snapshot: metadata reading separation
@ 2005-11-18 15:01 Alasdair G Kergon
2005-11-19 2:15 ` Andrew Morton
0 siblings, 1 reply; 2+ messages in thread
From: Alasdair G Kergon @ 2005-11-18 15:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
More snapshot metadata reading into separate function, to prepare
for changing the place it gets called from.
Signed-Off-By: Alasdair G Kergon <agk@redhat.com>
Index: linux-2.6.14/drivers/md/dm-snap.c
===================================================================
--- linux-2.6.14.orig/drivers/md/dm-snap.c 2005-11-17 22:17:55.000000000 +0000
+++ linux-2.6.14/drivers/md/dm-snap.c 2005-11-17 22:18:25.000000000 +0000
@@ -371,6 +371,20 @@ static inline ulong round_up(ulong n, ul
return (n + size) & ~size;
}
+static void read_snapshot_metadata(struct dm_snapshot *s)
+{
+ if (s->have_metadata)
+ return;
+
+ if (s->store.read_metadata(&s->store)) {
+ down_write(&s->lock);
+ s->valid = 0;
+ up_write(&s->lock);
+ }
+
+ s->have_metadata = 1;
+}
+
/*
* Construct a snapshot mapping: <origin_dev> <COW-dev> <p/n> <chunk-size>
*/
@@ -848,16 +862,7 @@ static void snapshot_resume(struct dm_ta
{
struct dm_snapshot *s = (struct dm_snapshot *) ti->private;
- if (s->have_metadata)
- return;
-
- if (s->store.read_metadata(&s->store)) {
- down_write(&s->lock);
- s->valid = 0;
- up_write(&s->lock);
- }
-
- s->have_metadata = 1;
+ read_snapshot_metadata(s);
}
static int snapshot_status(struct dm_target *ti, status_type_t type,
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] device-mapper snapshot: metadata reading separation
2005-11-18 15:01 [PATCH] device-mapper snapshot: metadata reading separation Alasdair G Kergon
@ 2005-11-19 2:15 ` Andrew Morton
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2005-11-19 2:15 UTC (permalink / raw)
To: Alasdair G Kergon; +Cc: linux-kernel
Alasdair G Kergon <agk@redhat.com> wrote:
>
> +static void read_snapshot_metadata(struct dm_snapshot *s)
> +{
> + if (s->have_metadata)
> + return;
> +
> + if (s->store.read_metadata(&s->store)) {
> + down_write(&s->lock);
> + s->valid = 0;
> + up_write(&s->lock);
> + }
> +
> + s->have_metadata = 1;
> +}
> +
I always get suspicious when I see a lock around a plain assignment.
Sometimes it's legitimate, usually when some other user of the LHS expects
its value to be stable across an entire locked region - it is read multiple
times and those reads are expected to return the same thing. (I can't
think of any other case).
Maybe this is such a case?
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-11-19 2:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-18 15:01 [PATCH] device-mapper snapshot: metadata reading separation Alasdair G Kergon
2005-11-19 2:15 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®