All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Ed Tomlinson <tomlins@CAM.ORG>
Cc: linux-lvm@sistina.com
Subject: [linux-lvm] Re: [OOPS] full snapshot (with test vfs locking patch for reiserfs snapshots in 11-pre)
Date: Mon, 08 Oct 2001 22:29:24 -0400	[thread overview]
Message-ID: <175160000.1002594564@tiny> (raw)
In-Reply-To: <20011009015759.BF5E472AE3@oscar.casa.dyndns.org>


On Monday, October 08, 2001 09:57:59 PM -0400 Ed Tomlinson <tomlins@CAM.ORG> wrote:

> Hi Chris
> 
>> Ok, that first patch won't quite fix it, as we can still oops
>> in lvm_snapshot_COW.  This one works better for me:
> 
> Looks like this one has problems too.  Here is the oops I get with it:
>>> EIP; d680b178 <[lvm-mod]_disable_snapshot+10/44>   <=====
> Trace; d680a50a <[lvm-mod]lvm_drop_snapshot+22/94>
> Trace; d680aafc <[lvm-mod]lvm_snapshot_COW+3b4/3f4>
> Trace; d680d3ca <[lvm-mod]lvm_name+8c2/e76>

Hmmm, this should be the same as the bug fixed by the second patch.  We know the snapshot hasn't been released yet when lvm_snapshot_COW is called, so _disable_snapshot should not oops.

We've got a write lock on the lv semaphore, so nobody else should be calling lvm_drop_snapshot on us.  I hate to ask, but are you sure you did an rmmod before the modules_install?

Regardless, we can fix the oops in _disable_snapshot, I just don't see how the locking allows it to happen.  This incremental fix should do it:

--- 0.21/drivers/md/lvm-snap.c Sat, 06 Oct 2001 00:07:22 -0400 
+++ 0.21(w)/drivers/md/lvm-snap.c Mon, 08 Oct 2001 22:39:54 -0400 
@@ -687,6 +694,10 @@
 
 static void _disable_snapshot(vg_t *vg, lv_t *lv) {
 	const char *err;
+	if (!lv->lv_block_exception) {
+		printk(KERN_ERR "%s -- snapshot already disabled\n", lvm_name);
+		return ;
+	}
 	lv->lv_block_exception[0].rsector_org = LVM_SNAPSHOT_DROPPED_SECTOR;
 	if(_write_COW_table_block(vg, lv, 0, &err) < 0) {
 		printk(KERN_ERR "%s -- couldn't disable snapshot: %s\n",

  reply	other threads:[~2001-10-09  2:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-03 23:03 [BUG] opps in 2.4.11-pre2 + prempt patch Ed Tomlinson
2001-10-04 13:12 ` [reiserfs-list] " Chris Mason
     [not found] ` <20011008012906.D790A11069@oscar.casa.dyndns.org>
     [not found]   ` <77260000.1002507094@tiny>
2001-10-08 15:53     ` [linux-lvm] [OOPS] full snapshot (with test vfs locking patch for reiserfs snapshots in 11-pre) Ed Tomlinson
2001-10-08 16:54       ` [linux-lvm] " Chris Mason
2001-10-08 17:05         ` Ed Tomlinson
2001-10-08 17:40           ` Chris Mason
2001-10-08 19:51           ` Chris Mason
2001-10-09  1:57             ` Ed Tomlinson
2001-10-09  2:29               ` Chris Mason [this message]
2001-10-09 11:42                 ` Ed Tomlinson
2001-10-10 21:28                 ` Ed Tomlinson
2001-10-10 23:21                   ` Chris Mason
2001-10-11  0:37                     ` Ed Tomlinson
2001-10-11  1:27                       ` Chris Mason

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=175160000.1002594564@tiny \
    --to=mason@suse.com \
    --cc=linux-lvm@sistina.com \
    --cc=tomlins@CAM.ORG \
    /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.