All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: [RFC] dm-raid1: not to add newly-allocated RH_CLEAN region to clean_regions
Date: Tue, 10 Jan 2006 18:11:40 -0500	[thread overview]
Message-ID: <43C43F2C.6050704@ce.jp.nec.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

Hi,

I would like to know whether the attached patch is something
acceptable or not.

In dm-raid1.c, 'clean_regions' in region hash is a list used
to link regions which are clean AND no longer interested (freeable).
So I think it's safe not to add newly-allocated RH_CLEAN entry
to the list because someone who allocates it has interest
on the region.

In the current code, rh_alloc()/rh_find() is called from:
  - rh_inc(), which makes the state RH_DIRTY if it's RH_CLEAN
  - __rh_recovery_prepare(), which makes the state RH_RECOVERING
  - rh_delay(), which is called when the region is RH_RECOVERING

So none uses the newly allocated RH_CLEAN region as-is.
RH_DIRTY region is changed back to RH_CLEAN and then connected
to clean_regions when pending I/O completes.
RH_RECOVERING region is reclaimed when the recovery on the
region completes.

If this patch is acceptable, we can also merge RH_CLEAN and
RH_DIRTY into one state.

Comments are welcome.

Thanks,
Jun'ichi "Nick" Nomura

[-- Attachment #2: dm-mirror-dont-add-clean.patch --]
[-- Type: text/x-patch, Size: 1208 bytes --]

[RFC] dm-raid1: not to add newly-allocated RH_CLEAN region to clean_regions

The clean_regions list is used to maintain reclaimable hash entries.
If the region is known to be marked RH_DIRTY or RH_RECOVERING later,
it's not necessarily connected to clean_regions even if it's clean.

OTOH, region hash entries are allocated only when the region is going
to be written (RH_DIRTY) or recoverred (RH_RECOVERING).

So it's safe not to add RH_CLEAN region to clean_regions in __rh_alloc().
Not adding to clean_regions protects the region from potential race
condition that the hash entry is reclaimed by rh_update_states()
before use.

Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>

diff -urp linux.orig/drivers/md/dm-raid1.c linux/drivers/md/dm-raid1.c
--- linux.orig/drivers/md/dm-raid1.c	2005-12-26 05:25:04.000000000 -0500
+++ linux/drivers/md/dm-raid1.c	2006-01-06 11:47:03.000000000 -0500
@@ -255,11 +254,6 @@ static struct region *__rh_alloc(struct 
 
 	else {
 		__rh_insert(rh, nreg);
-		if (nreg->state == RH_CLEAN) {
-			spin_lock(&rh->region_lock);
-			list_add(&nreg->list, &rh->clean_regions);
-			spin_unlock(&rh->region_lock);
-		}
 		reg = nreg;
 	}
 	write_unlock_irq(&rh->hash_lock);

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



                 reply	other threads:[~2006-01-10 23:11 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43C43F2C.6050704@ce.jp.nec.com \
    --to=j-nomura@ce.jp.nec.com \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.