2.6.0-t10-dm1

2.6.0-t10-dm1

[Joe Thornber]

Hi,

Here are the latest patches from the stable device-mapper tree.
Please apply.

Thanks,

- Joe

[Patch 1/5] dm: fix block device resizing

[Joe Thornber]

When setting the size of a Device-Mapper device in the gendisk entry,
also try to set the size of the corresponding block_device entry's
inode. This is necessary to allow online device/filesystem resizing to
work correctly.  [Kevin Corry]
--- diff/drivers/md/dm.c	2003-09-30 15:46:14.000000000 +0100
+++ source/drivers/md/dm.c	2003-11-25 15:36:59.000000000 +0000
@@ -666,6 +666,20 @@
 	up_write(&md->lock);
 }
 
+static void __set_size(struct gendisk *disk, sector_t size)
+{
+	struct block_device *bdev;
+
+	set_capacity(disk, size);
+	bdev = bdget_disk(disk, 0);
+	if (bdev) {
+		down(&bdev->bd_inode->i_sem);
+		i_size_write(bdev->bd_inode, size << SECTOR_SHIFT);
+		up(&bdev->bd_inode->i_sem);
+		bdput(bdev);
+	}
+}
+
 static int __bind(struct mapped_device *md, struct dm_table *t)
 {
 	request_queue_t *q = md->queue;
@@ -673,7 +687,7 @@
 	md->map = t;
 
 	size = dm_table_get_size(t);
-	set_capacity(md->disk, size);
+	__set_size(md->disk, size);
 	if (size == 0)
 		return 0;
 
@@ -692,7 +706,6 @@
 	dm_table_event_callback(md->map, NULL, NULL);
 	dm_table_put(md->map);
 	md->map = NULL;
-	set_capacity(md->disk, 0);
 }
 
 /*

[Patch 2/5] dm: remove dynamic table resizing

[Joe Thornber]

The dm table size is always known in advance, so we can specify it in
dm_table_create(), rather than relying on dynamic resizing.
--- diff/drivers/md/dm-ioctl-v1.c	2003-09-30 15:46:14.000000000 +0100
+++ source/drivers/md/dm-ioctl-v1.c	2003-11-25 15:47:38.000000000 +0000
@@ -566,7 +566,7 @@
 	if (r)
 		return r;
 
-	r = dm_table_create(&t, get_mode(param));
+	r = dm_table_create(&t, get_mode(param), param->target_count);
 	if (r)
 		return r;
 
@@ -894,7 +894,7 @@
 	struct mapped_device *md;
 	struct dm_table *t;
 
-	r = dm_table_create(&t, get_mode(param));
+	r = dm_table_create(&t, get_mode(param), param->target_count);
 	if (r)
 		return r;
 
--- diff/drivers/md/dm-ioctl-v4.c	2003-09-30 15:46:14.000000000 +0100
+++ source/drivers/md/dm-ioctl-v4.c	2003-11-25 15:47:38.000000000 +0000
@@ -872,7 +872,7 @@
 	struct hash_cell *hc;
 	struct dm_table *t;
 
-	r = dm_table_create(&t, get_mode(param));
+	r = dm_table_create(&t, get_mode(param), param->target_count);
 	if (r)
 		return r;
 
--- diff/drivers/md/dm-table.c	2003-11-25 15:24:57.000000000 +0000
+++ source/drivers/md/dm-table.c	2003-11-25 15:47:38.000000000 +0000
@@ -202,7 +202,7 @@
 	return 0;
 }
 
-int dm_table_create(struct dm_table **result, int mode)
+int dm_table_create(struct dm_table **result, int mode, unsigned num_targets)
 {
 	struct dm_table *t = kmalloc(sizeof(*t), GFP_NOIO);
 
@@ -213,8 +213,12 @@
 	INIT_LIST_HEAD(&t->devices);
 	atomic_set(&t->holders, 1);
 
-	/* allocate a single nodes worth of targets to begin with */
-	if (alloc_targets(t, KEYS_PER_NODE)) {
+	if (!num_targets)
+		num_targets = KEYS_PER_NODE;
+
+	num_targets = dm_round_up(num_targets, KEYS_PER_NODE);
+
+	if (alloc_targets(t, num_targets)) {
 		kfree(t);
 		t = NULL;
 		return -ENOMEM;
--- diff/drivers/md/dm.h	2003-08-20 14:16:09.000000000 +0100
+++ source/drivers/md/dm.h	2003-11-25 15:47:38.000000000 +0000
@@ -95,7 +95,7 @@
  * Functions for manipulating a table.  Tables are also reference
  * counted.
  *---------------------------------------------------------------*/
-int dm_table_create(struct dm_table **result, int mode);
+int dm_table_create(struct dm_table **result, int mode, unsigned num_targets);
 
 void dm_table_get(struct dm_table *t);
 void dm_table_put(struct dm_table *t);

[Patch 3/5] dm: make v4 of the ioctl interface the default

[Joe Thornber]

Make the version-4 ioctl interface the default kernel configuration option.
If you have out of date tools you will need to use the v1 interface.

--- diff/drivers/md/Kconfig	2003-10-09 09:47:34.000000000 +0100
+++ source/drivers/md/Kconfig	2003-11-25 15:47:48.000000000 +0000
@@ -138,6 +138,7 @@
 config DM_IOCTL_V4
 	bool "ioctl interface version 4"
 	depends on BLK_DEV_DM
+	default y
 	---help---
 	  Recent tools use a new version of the ioctl interface, only
           select this option if you intend using such tools.

[Patch 4/5] dm: set io restriction defaults

[Joe Thornber]

Make sure that a target has a sensible set of default io restrictions.
--- diff/drivers/md/dm-table.c	2003-11-25 15:47:38.000000000 +0000
+++ source/drivers/md/dm-table.c	2003-11-25 15:47:59.000000000 +0000
@@ -630,6 +630,16 @@
 	return 0;
 }
 
+static void set_default_limits(struct io_restrictions *rs)
+{
+	rs->max_sectors = MAX_SECTORS;
+	rs->max_phys_segments = MAX_PHYS_SEGMENTS;
+	rs->max_hw_segments = MAX_HW_SEGMENTS;
+	rs->hardsect_size = 1 << SECTOR_SHIFT;
+	rs->max_segment_size = MAX_SEGMENT_SIZE;
+	rs->seg_boundary_mask = -1;
+}
+
 int dm_table_add_target(struct dm_table *t, const char *type,
 			sector_t start, sector_t len, char *params)
 {
@@ -642,6 +652,7 @@
 
 	tgt = t->targets + t->num_targets;
 	memset(tgt, 0, sizeof(*tgt));
+	set_default_limits(&tgt->limits);
 
 	tgt->type = dm_get_target_type(type);
 	if (!tgt->type) {

[Patch 5/5] dm: dm_table_event() sleep on spinlock bug

[Joe Thornber]

You can no longer call dm_table_event() from interrupt context.
--- diff/drivers/md/dm-table.c	2003-11-25 15:47:59.000000000 +0000
+++ source/drivers/md/dm-table.c	2003-11-25 15:52:15.000000000 +0000
@@ -12,6 +12,7 @@
 #include <linux/namei.h>
 #include <linux/ctype.h>
 #include <linux/slab.h>
+#include <linux/interrupt.h>
 #include <asm/atomic.h>
 
 #define MAX_DEPTH 16
@@ -746,22 +747,28 @@
 	return r;
 }
 
-static spinlock_t _event_lock = SPIN_LOCK_UNLOCKED;
+static DECLARE_MUTEX(_event_lock);
 void dm_table_event_callback(struct dm_table *t,
 			     void (*fn)(void *), void *context)
 {
-	spin_lock_irq(&_event_lock);
+	down(&_event_lock);
 	t->event_fn = fn;
 	t->event_context = context;
-	spin_unlock_irq(&_event_lock);
+	up(&_event_lock);
 }
 
 void dm_table_event(struct dm_table *t)
 {
-	spin_lock(&_event_lock);
+	/*
+	 * You can no longer call dm_table_event() from interrupt
+	 * context, use a bottom half instead.
+	 */
+	BUG_ON(in_interrupt());
+
+	down(&_event_lock);
 	if (t->event_fn)
 		t->event_fn(t->event_context);
-	spin_unlock(&_event_lock);
+	up(&_event_lock);
 }
 
 sector_t dm_table_get_size(struct dm_table *t)

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Kevin P. Fleming]

Joe Thornber wrote:

> Make the version-4 ioctl interface the default kernel configuration option.
> If you have out of date tools you will need to use the v1 interface.

Actually, isn't the proper way to say this "if your tools are older than 
X and/or were _not_ built against recent 2.6 headers you need to use the 
v1 interface"?

Also, if you're going to change the default you should change the help 
text correspondingly.

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Joe Thornber]

On Tue, Nov 25, 2003 at 09:47:28AM -0700, Kevin P. Fleming wrote:
> Joe Thornber wrote:
> 
> >Make the version-4 ioctl interface the default kernel configuration option.
> >If you have out of date tools you will need to use the v1 interface.
> 
> Actually, isn't the proper way to say this "if your tools are older than 
> X and/or were _not_ built against recent 2.6 headers you need to use the 
> v1 interface"?
> 
> Also, if you're going to change the default you should change the help 
> text correspondingly.

I would like to remove v1 support very shortly, making v4 the default
for a bit is just the next phase of this process.

For the last few months the tools have supported both v1 and v4
interfaces, allowing people to roll back to older kernels.  I will
update the Kconfig help as you suggest to be more specific about the
tool versions.

- Joe

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Kevin Corry]

On Tuesday 25 November 2003 10:47, Kevin P. Fleming wrote:
> Joe Thornber wrote:
> > Make the version-4 ioctl interface the default kernel configuration
> > option. If you have out of date tools you will need to use the v1
> > interface.
>
> Actually, isn't the proper way to say this "if your tools are older than
> X and/or were _not_ built against recent 2.6 headers you need to use the
> v1 interface"?
>
> Also, if you're going to change the default you should change the help
> text correspondingly.

How's this look?

-- 
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/


--- a/drivers/md/Kconfig	2003-11-23 19:31:11.000000000 -0600
+++ b/drivers/md/Kconfig	2003-11-25 11:07:00.000000000 -0600
@@ -138,9 +138,11 @@
 config DM_IOCTL_V4
 	bool "ioctl interface version 4"
 	depends on BLK_DEV_DM
+	default y
 	---help---
-	  Recent tools use a new version of the ioctl interface, only
-          select this option if you intend using such tools.
+	  Recent tools use this new version of the ioctl interface. Only
+	  select N for this option if you use out-of-date tools that weren't
+	  compiled for this interface (e.g. LVM2 prior to v2.00.00).
 
 endmenu
 

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Kevin P. Fleming]

Joe Thornber wrote:

> For the last few months the tools have supported both v1 and v4
> interfaces, allowing people to roll back to older kernels.  I will
> update the Kconfig help as you suggest to be more specific about the
> tool versions.

My biggest concern here is that even if someone downloads the latest 
device-mapper tools tarball and compiles it on their system, unless they 
specifically point it at 2.6 kernel headers it won't compile in v4 ioctl 
support, so they could be unpleasantly surprised. Given the prevailing 
sentiment about _not_ updating /usr/include/{linux,asm} to the headers 
with a newly-installed kernel (but rather leaving them the same versions 
that libc was compiled against) this a pretty likely scenario unless I'm 
mistaken...

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Kevin P. Fleming]

Kevin Corry wrote:

  	---help---
-	  Recent tools use a new version of the ioctl interface, only
-          select this option if you intend using such tools.
+	  Recent tools use this new version of the ioctl interface. Only
+	  select N for this option if you use out-of-date tools that weren't
+	  compiled for this interface (e.g. LVM2 prior to v2.00.00).

Actually, I don't think LVM2 uses the device mapper ioctls at all; it 
use libdevmapper which calls the ioctls on its behalf.

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Christoph Hellwig]

On Tue, Nov 25, 2003 at 04:33:13PM +0000, Joe Thornber wrote:
> Make the version-4 ioctl interface the default kernel configuration option.
> If you have out of date tools you will need to use the v1 interface.

So why do we keep the old version at all?

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Kevin Corry]

On Tuesday 25 November 2003 11:16, Kevin P. Fleming wrote:
> Kevin Corry wrote:
>
>   	---help---
> -	  Recent tools use a new version of the ioctl interface, only
> -          select this option if you intend using such tools.
> +	  Recent tools use this new version of the ioctl interface. Only
> +	  select N for this option if you use out-of-date tools that weren't
> +	  compiled for this interface (e.g. LVM2 prior to v2.00.00).
>
> Actually, I don't think LVM2 uses the device mapper ioctls at all; it
> use libdevmapper which calls the ioctls on its behalf.

True. I imagine Joe will know the exact version numbers of LVM2 and 
libdevmapper that require the old interface. I believe the version I 
mentioned is from the appropriate time-frame, though.

-- 
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Wichert Akkerman]

Previously Joe Thornber wrote:
> For the last few months the tools have supported both v1 and v4
> interfaces, allowing people to roll back to older kernels.

'last few months' is extremely short for a migration path. Can't we
ditch the v1 interface in 2.7 and allow people to migrate slowly?

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Joe Thornber]

On Tue, Nov 25, 2003 at 05:20:59PM +0000, Christoph Hellwig wrote:
> On Tue, Nov 25, 2003 at 04:33:13PM +0000, Joe Thornber wrote:
> > Make the version-4 ioctl interface the default kernel configuration option.
> > If you have out of date tools you will need to use the v1 interface.
> 
> So why do we keep the old version at all?

See my earlier email where I said I don't want to keep it.  Both
versions have only been present while people are migrating.

- Joe

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Joe Thornber]

On Tue, Nov 25, 2003 at 10:15:18AM -0700, Kevin P. Fleming wrote:
> Joe Thornber wrote:
> 
> >For the last few months the tools have supported both v1 and v4
> >interfaces, allowing people to roll back to older kernels.  I will
> >update the Kconfig help as you suggest to be more specific about the
> >tool versions.
> 
> My biggest concern here is that even if someone downloads the latest 
> device-mapper tools tarball and compiles it on their system, unless they 
> specifically point it at 2.6 kernel headers it won't compile in v4 ioctl 
> support, so they could be unpleasantly surprised.

The tools build against their own copies of the header files.

- Joe

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Alasdair G Kergon]

On Tue, Nov 25, 2003 at 06:29:49PM +0100, Wichert Akkerman wrote:
> 'last few months' is extremely short for a migration path. Can't we
> ditch the v1 interface in 2.7 and allow people to migrate slowly?

People still using LVM2/device-mapper userspace components that 
don't support v4 really should upgrade them to fix some significant
(unrelated) issues with those old versions.

The v1 interface was broken.
(Not architecture independent.  And used __kernel_dev_t.)

The v4 interface fixed things, and is the only version anyone 
compiling a new kernel should be using.

The v4 interface has been supported officially since mid-July in
device-mapper 1.0 (with LVM 2.0).

Since then, the userspace component that communicates with device-mapper
(libdevmapper.so) has supported *both* versions simultaneously - so you
don't need to change anything in userspace when switching between
kernels running v1 and v4.  (The LVM2 tools talk to libdevmapper.so
which detects and handles the interface version transparently.)

In the current device-mapper tarball that I put on the Sistina FTP site
last Friday v1 support is no longer available by default - it has to be
specifically requested as a configuration option.

Alasdair
-- 
agk@uk.sistina.com

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Adrian Bunk]

On Tue, Nov 25, 2003 at 08:18:25PM +0000, Alasdair G Kergon wrote:
> On Tue, Nov 25, 2003 at 06:29:49PM +0100, Wichert Akkerman wrote:
> > 'last few months' is extremely short for a migration path. Can't we
> > ditch the v1 interface in 2.7 and allow people to migrate slowly?
> 
> People still using LVM2/device-mapper userspace components that 
> don't support v4 really should upgrade them to fix some significant
> (unrelated) issues with those old versions.
>...

The point is IMHO a different one:

Kill the v1 interface before 2.6.0 or in 2.7 .

It's never a good idea to remove something inside a stable kernel series
(e.g. the DRI support for XFree86 4.0 will never be removed from 2.4).

> Alasdair

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [Patch 3/5] dm: make v4 of the ioctl interface the default

[Joe Thornber]

On Wed, Nov 26, 2003 at 12:45:11AM +0100, Adrian Bunk wrote:
> On Tue, Nov 25, 2003 at 08:18:25PM +0000, Alasdair G Kergon wrote:
> > On Tue, Nov 25, 2003 at 06:29:49PM +0100, Wichert Akkerman wrote:
> > > 'last few months' is extremely short for a migration path. Can't we
> > > ditch the v1 interface in 2.7 and allow people to migrate slowly?
> > 
> > People still using LVM2/device-mapper userspace components that 
> > don't support v4 really should upgrade them to fix some significant
> > (unrelated) issues with those old versions.
> >...
> 
> The point is IMHO a different one:
> 
> Kill the v1 interface before 2.6.0 or in 2.7 .
> 
> It's never a good idea to remove something inside a stable kernel series
> (e.g. the DRI support for XFree86 4.0 will never be removed from 2.4).

Agreed, we'd like to do it before 2.6.0.

- Joe