[PATCH md 000 of 2] Introduction

[PATCH md 000 of 2] Introduction

[NeilBrown]

Two patches against 2.6.12-rc2 for md.
(patches apply to 2.6.12-rc2-mm1 with various offsets).

The first closes an extreme small race in md thread deregistration.
This race was actually lost by someone who, due to a different bug
which has since been fixed, has md threads being created and destroyed
at a very high rate.

The second removes a number of MD_BUG calls that that are either
completely pointless, or misleading (i.e. the report a bug when it is
just an unusual condition that is handled correctly).

NeilBrown


 [PATCH md 001 of 2] Close a small race in md thread deregistration
 [PATCH md 002 of 2] Remove a number of misleading calls to MD_BUG

[PATCH md 001 of 2] Close a small race in md thread deregistration

[NeilBrown]

There is a tiny race when de-registering an MD thread, in that the
thread could disappear before it is set a SIGKILL, causing
send_sig to have problems.  
This is most easily closed by holding tasklist_lock between
enabling the thread to exit (setting ->run to NULL) and telling 
it to exit.

Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>

### Diffstat output
 ./drivers/md/md.c |   20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)

diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~	2005-04-08 11:36:35.000000000 +1000
+++ ./drivers/md/md.c	2005-04-08 11:36:35.000000000 +1000
@@ -2840,16 +2840,6 @@ mdk_thread_t *md_register_thread(void (*
 	return thread;
 }
 
-static void md_interrupt_thread(mdk_thread_t *thread)
-{
-	if (!thread->tsk) {
-		MD_BUG();
-		return;
-	}
-	dprintk("interrupting MD-thread pid %d\n", thread->tsk->pid);
-	send_sig(SIGKILL, thread->tsk, 1);
-}
-
 void md_unregister_thread(mdk_thread_t *thread)
 {
 	struct completion event;
@@ -2857,9 +2847,15 @@ void md_unregister_thread(mdk_thread_t *
 	init_completion(&event);
 
 	thread->event = &event;
+
+	/* As soon as ->run is set to NULL, the task could disappear,
+	 * so we need to hold tasklist_lock until we have sent the signal
+	 */
+	dprintk("interrupting MD-thread pid %d\n", thread->tsk->pid);
+	read_lock(&tasklist_lock);
 	thread->run = NULL;
-	thread->name = NULL;
-	md_interrupt_thread(thread);
+	send_sig(SIGKILL, thread->tsk, 1);
+	read_unlock(&tasklist_lock);
 	wait_for_completion(&event);
 	kfree(thread);
 }

[PATCH md 002 of 2] Remove a number of misleading calls to MD_BUG

[NeilBrown]

The conditions that cause these calls to MD_BUG are
not kernel bugs, just oddities in what userspace is
asking for.

Also convert analyze_sbs to return void, and the value
it returned was always 0.


Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>

### Diffstat output
 ./drivers/md/md.c |   30 ++++++++----------------------
 1 files changed, 8 insertions(+), 22 deletions(-)

diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~	2005-04-08 11:36:35.000000000 +1000
+++ ./drivers/md/md.c	2005-04-08 11:36:47.000000000 +1000
@@ -1387,7 +1387,7 @@ abort_free:
  */
 
 
-static int analyze_sbs(mddev_t * mddev)
+static void analyze_sbs(mddev_t * mddev)
 {
 	int i;
 	struct list_head *tmp;
@@ -1441,7 +1441,6 @@ static int analyze_sbs(mddev_t * mddev)
 		       " -- starting background reconstruction\n",
 		       mdname(mddev));
 
-	return 0;
 }
 
 int mdp_major = 0;
@@ -1508,10 +1507,9 @@ static int do_md_run(mddev_t * mddev)
 	struct gendisk *disk;
 	char b[BDEVNAME_SIZE];
 
-	if (list_empty(&mddev->disks)) {
-		MD_BUG();
+	if (list_empty(&mddev->disks))
+		/* cannot run an array with no devices.. */
 		return -EINVAL;
-	}
 
 	if (mddev->pers)
 		return -EBUSY;
@@ -1519,10 +1517,8 @@ static int do_md_run(mddev_t * mddev)
 	/*
 	 * Analyze all RAID superblock(s)
 	 */
-	if (!mddev->raid_disks && analyze_sbs(mddev)) {
-		MD_BUG();
-		return -EINVAL;
-	}
+	if (!mddev->raid_disks)
+		analyze_sbs(mddev);
 
 	chunk_size = mddev->chunk_size;
 	pnum = level_to_pers(mddev->level);
@@ -1548,7 +1544,7 @@ static int do_md_run(mddev_t * mddev)
 		 * chunk-size has to be a power of 2 and multiples of PAGE_SIZE
 		 */
 		if ( (1 << ffz(~chunk_size)) != chunk_size) {
-			MD_BUG();
+			printk(KERN_ERR "chunk_size of %d not valid\n", chunk_size);
 			return -EINVAL;
 		}
 		if (chunk_size < PAGE_SIZE) {
@@ -1573,11 +1569,6 @@ static int do_md_run(mddev_t * mddev)
 		}
 	}
 
-	if (pnum >= MAX_PERSONALITY) {
-		MD_BUG();
-		return -EINVAL;
-	}
-
 #ifdef CONFIG_KMOD
 	if (!pers[pnum])
 	{
@@ -1762,10 +1753,8 @@ static void autorun_array(mddev_t *mddev
 	struct list_head *tmp;
 	int err;
 
-	if (list_empty(&mddev->disks)) {
-		MD_BUG();
+	if (list_empty(&mddev->disks))
 		return;
-	}
 
 	printk(KERN_INFO "md: running: ");
 
@@ -3128,7 +3117,6 @@ int register_md_personality(int pnum, md
 	spin_lock(&pers_lock);
 	if (pers[pnum]) {
 		spin_unlock(&pers_lock);
-		MD_BUG();
 		return -EBUSY;
 	}
 
@@ -3140,10 +3128,8 @@ int register_md_personality(int pnum, md
 
 int unregister_md_personality(int pnum)
 {
-	if (pnum >= MAX_PERSONALITY) {
-		MD_BUG();
+	if (pnum >= MAX_PERSONALITY)
 		return -EINVAL;
-	}
 
 	printk(KERN_INFO "md: %s personality unregistered\n", pers[pnum]->name);
 	spin_lock(&pers_lock);

Re: [PATCH md 001 of 2] Close a small race in md thread deregistration

[Andrew Morton]

NeilBrown <neilb@cse.unsw.edu.au> wrote:
>
>  There is a tiny race when de-registering an MD thread, in that the
>  thread could disappear before it is set a SIGKILL, causing
>  send_sig to have problems.  
>  This is most easily closed by holding tasklist_lock between
>  enabling the thread to exit (setting ->run to NULL) and telling 
>  it to exit.

That code all seems a bit crufty to me.  Sometime it would be good to stop
using signals in-kernel and to use the kthread API for thread startup and
shutdown.

Re: [PATCH md 001 of 2] Close a small race in md thread deregistration

[Neil Brown]

On Thursday April 7, akpm@osdl.org wrote:
> 
> That code all seems a bit crufty to me.  Sometime it would be good to stop
> using signals in-kernel and to use the kthread API for thread startup and
> shutdown.

I've just added that to my TODO list... thanks for the suggestion.

NeilBrown

[PATCH md 000 of 2] Introduction

[NeilBrown]

Hi again,
 two more patches for md follow.  Both raid1 related.
 These are happy to sit in the queue for after 2.6.12.

Thanks,
NeilBrown

 [PATCH md 001 of 2] Cause md/raid1 to "repack" working devices when number of drives is changed.
 [PATCH md 002 of 2] Make sure recovery happens when add_new_disk is used for hot_add

[PATCH md 000 of 2] Introduction

[NeilBrown]

Following are two very trivial patches against 2.6.13-rc6.
If 2.6.13 is still open for such trivial fixes, it would be good for
them to go in, but if not, I won't loose any sleep over it.

The first arranges that the first open of /dev/mdX will auto-load the
md modules (I don't know when that functionality disappeared).
The second fixes a possibly problem where-by if you stop an array and
create a new one on the same md device, it might not start any resync
that might be needed.

Thanks,
NeilBrown


 [PATCH md 001 of 2] Create a MODULE_ALIAS for md corresponding to it's block major number.
 [PATCH md 002 of 2] Clear the 'recovery' flags when starting an md array.

[PATCH md 000 of 2] Introduction

[NeilBrown]

Two patches for md in 2.6.14-rc5-mm1 (First one depends on -mm stuff,
second should apply to most recent 2.6 kernels).

I'd like to review the sysfs a bit more before it goes to Linus, but
the rest can go anytime.
Thanks,
NeilBrown


 [PATCH md 001 of 2] Remove attempt to use dynamic names in sysfs for component devices on an MD array.
 [PATCH md 002 of 2] Allow md arrays to be started read-only (module parameter).

Re: [PATCH md 000 of 2] Introduction

[Neil Brown]

On Sunday October 30, akpm@osdl.org wrote:
> NeilBrown <neilb@suse.de> wrote:
> >
> > 
> >  I'd like to review the sysfs a bit more before it goes to Linus, but
> >  the rest can go anytime.
> 
> umm, what does "the sysfs" refer to?

Sorry.. "the sysfs related patches".

Those marked as 'THIS' below.  

However I think a couple that come after those won't simple move
backwards (largely due to
md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field).

I'll make sure you have a full set that I am happy to go to Linus by
the end of the week.

Thanks,
NeilBrown


> 
> Current md patches in -mm:
> 
> md-better-handling-of-readerrors-with-raid5.patch
THIS > md-initial-sysfs-support-for-md.patch
THIS > md-extend-md-sysfs-support-to-component-devices.patch
THIS > md-add-kobject-sysfs-support-to-raid5.patch
THIS > md-allow-a-manual-resync-with-md.patch
THIS > md-teach-raid5-the-difference-between-check-and-repair.patch
> md-provide-proper-rcu_dereference--rcu_assign_pointer-annotations-in-md.patch
THIS > md-fix-ref-counting-problems-with-kobjects-in-md.patch
THIS > md-minor-md-fixes.patch
THIS > md-change-raid5-sysfs-attribute-to-not-create-a-new-directory.patch
> md-improvements-to-raid5-handling-of-read-errors.patch
> md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field.patch
> md-make-md-on-disk-bitmaps-not-host-endian.patch
> md-support-bio_rw_barrier-for-md-raid1.patch
> drivers-md-fix-up-schedule_timeout-usage.patch
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH md 000 of 2] Introduction

[Andrew Morton]

NeilBrown <neilb@suse.de> wrote:
>
> 
>  I'd like to review the sysfs a bit more before it goes to Linus, but
>  the rest can go anytime.

umm, what does "the sysfs" refer to?

Current md patches in -mm:

md-better-handling-of-readerrors-with-raid5.patch
md-initial-sysfs-support-for-md.patch
md-extend-md-sysfs-support-to-component-devices.patch
md-add-kobject-sysfs-support-to-raid5.patch
md-allow-a-manual-resync-with-md.patch
md-teach-raid5-the-difference-between-check-and-repair.patch
md-provide-proper-rcu_dereference--rcu_assign_pointer-annotations-in-md.patch
md-fix-ref-counting-problems-with-kobjects-in-md.patch
md-minor-md-fixes.patch
md-change-raid5-sysfs-attribute-to-not-create-a-new-directory.patch
md-improvements-to-raid5-handling-of-read-errors.patch
md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field.patch
md-make-md-on-disk-bitmaps-not-host-endian.patch
md-support-bio_rw_barrier-for-md-raid1.patch
drivers-md-fix-up-schedule_timeout-usage.patch

Re: [PATCH md 000 of 2] Introduction

[Andrew Morton]

Neil Brown <neilb@suse.de> wrote:
>
> On Sunday October 30, akpm@osdl.org wrote:
> > NeilBrown <neilb@suse.de> wrote:
> > >
> > > 
> > >  I'd like to review the sysfs a bit more before it goes to Linus, but
> > >  the rest can go anytime.
> > 
> > umm, what does "the sysfs" refer to?
> 
> Sorry.. "the sysfs related patches".
> 
> Those marked as 'THIS' below.  
> 
> However I think a couple that come after those won't simple move
> backwards (largely due to
> md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field).
> 
> I'll make sure you have a full set that I am happy to go to Linus by
> the end of the week.

hm, OK, that's a bit late in the process to be introducing new material, so
no later please.

Also, please make sure that Greg is copied on sysfs things - save me an
email ;)

Re: [PATCH md 000 of 2] Introduction

[Mr. James W. Laferriere]

	Hello Neil ,  The original '[PATCH md 000 of 2] Introduction' never hit 
	the list afaict .  Could you please re-send or if you did & only I am 
	without it send privately .  Tia ,  JimL

On Mon, 31 Oct 2005, Neil Brown wrote:
> On Sunday October 30, akpm@osdl.org wrote:
> > NeilBrown <neilb@suse.de> wrote:
> > >  I'd like to review the sysfs a bit more before it goes to Linus, but
> > >  the rest can go anytime.
> > umm, what does "the sysfs" refer to?
> Sorry.. "the sysfs related patches".
> Those marked as 'THIS' below.  
> However I think a couple that come after those won't simple move
> backwards (largely due to
> md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field).
> I'll make sure you have a full set that I am happy to go to Linus by
> the end of the week.
> Thanks,
> NeilBrown
> > Current md patches in -mm:
> > md-better-handling-of-readerrors-with-raid5.patch
> THIS > md-initial-sysfs-support-for-md.patch
> THIS > md-extend-md-sysfs-support-to-component-devices.patch
> THIS > md-add-kobject-sysfs-support-to-raid5.patch
> THIS > md-allow-a-manual-resync-with-md.patch
> THIS > md-teach-raid5-the-difference-between-check-and-repair.patch
> > md-provide-proper-rcu_dereference--rcu_assign_pointer-annotations-in-md.patch
> THIS > md-fix-ref-counting-problems-with-kobjects-in-md.patch
> THIS > md-minor-md-fixes.patch
> THIS > md-change-raid5-sysfs-attribute-to-not-create-a-new-directory.patch
> > md-improvements-to-raid5-handling-of-read-errors.patch
> > md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field.patch
> > md-make-md-on-disk-bitmaps-not-host-endian.patch
> > md-support-bio_rw_barrier-for-md-raid1.patch
> > drivers-md-fix-up-schedule_timeout-usage.patch
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

Re: [PATCH md 000 of 2] Introduction

[Neil Brown]

On Monday October 31, babydr@baby-dragons.com wrote:
> 	Hello Neil ,  The original '[PATCH md 000 of 2] Introduction' never hit 
> 	the list afaict .  Could you please re-send or if you did & only I am 
> 	without it send privately .  Tia ,  JimL

I cannot knot who else is without it :-), but you can find it here.


http://marc.theaimsgroup.com/?l=linux-raid&m=113073839213484&w=2


NeilBrown

[PATCH md 000 of 2] Introduction

[NeilBrown]

Following are two patches for md in 2.6.14-mm2 that are suitable to go
into the 2.6.15-rc series.

The first adds a date to the deprecation of START_ARRAY ioctl.

The second fixes a recently introduced problem that causes md threads
to permanently add to the load average (other than that, every works
fine).

 [PATCH md 001 of 2] Mark START_ARRAY deprecated with a date.
 [PATCH md 002 of 2] Make md threads interruptible again.

Re: [PATCH md 000 of 2] Introduction

[Mr. James W. Laferriere]

 	Hello Neil ,

On Tue, 15 Nov 2005, NeilBrown wrote:
> Following are two patches for md in 2.6.14-mm2 that are suitable to go
> into the 2.6.15-rc series.
>
> The first adds a date to the deprecation of START_ARRAY ioctl.
>
> The second fixes a recently introduced problem that causes md threads
> to permanently add to the load average (other than that, every works
> fine).
>
> [PATCH md 001 of 2] Mark START_ARRAY deprecated with a date.
> [PATCH md 002 of 2] Make md threads interruptible again.

> diff ./Documentation/feature-removal-schedule.txt~current~ /Documentation/feature-removal-schedule.txt
> --- ./Documentation/feature-removal-schedule.txt~current~       2005-11-15 10:25:30.000000000 +1100
> +++ ./Documentation/feature-removal-schedule.txt        2005-11-15 10:25:30.000000000 +1100
> @@ -131,3 +131,12 @@ What:      EXPORT_SYMBOL(lookup_hash)
>  When:  January 2006
>  Why:   Too low-level interface.  Use lookup_one_len or lookup_create instead.
>  Who:   Christoph Hellwig <hch@lst.de>
> +
> +---------------------------
> +
> +What:  START_ARRAY ioctl for md
> +When:  July 2006
> +Files: drivers/md/md.c
> +Why:   Not reliable by design - can fail when most needed.
> +       Alternatives exist
> +Who:   NeilBrown <neilb@suse.de>

 	Would some please update Documentation/md.txt with the alternates
 	that exist to replace START_ARRAY ?  Or for that matter any kernel
 	related document that covers the md driver &/or its tools .
 		Tia ,  JimL

-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

Re: [PATCH md 000 of 2] Introduction

[Neil Brown]

On Tuesday November 15, babydr@baby-dragons.com wrote:
>  	Hello Neil ,
> 
> On Tue, 15 Nov 2005, NeilBrown wrote:
> > +
> > +---------------------------
> > +
> > +What:  START_ARRAY ioctl for md
> > +When:  July 2006
> > +Files: drivers/md/md.c
> > +Why:   Not reliable by design - can fail when most needed.
> > +       Alternatives exist
> > +Who:   NeilBrown <neilb@suse.de>
> 
>  	Would some please update Documentation/md.txt with the alternates
>  	that exist to replace START_ARRAY ?  Or for that matter any kernel
>  	related document that covers the md driver &/or its tools .
>  		Tia ,  JimL
> 

Are you just asking "What are the 'Alternatives' that are claimed to
exist?"?
If so, then it is  'mdadm -A'.  I guess I could make that more
explicit.

Or are you asking something else?

NeilBrown

Re: [PATCH md 000 of 2] Introduction

[Mr. James W. Laferriere]

  	Hello Neil ,

On Thu, 17 Nov 2005, Neil Brown wrote:
> On Tuesday November 15, babydr@baby-dragons.com wrote:
>> On Tue, 15 Nov 2005, NeilBrown wrote:
>>> +
>>> +---------------------------
>>> +
>>> +What:  START_ARRAY ioctl for md
>>> +When:  July 2006
>>> +Files: drivers/md/md.c
>>> +Why:   Not reliable by design - can fail when most needed.
>>> +       Alternatives exist
>>> +Who:   NeilBrown <neilb@suse.de>
>>
>>  	Would some please update Documentation/md.txt with the alternates
>>  	that exist to replace START_ARRAY ?  Or for that matter any kernel
>>  	related document that covers the md driver &/or its tools .
>>  		Tia ,  JimL
> Are you just asking "What are the 'Alternatives' that are claimed to
> exist?"?
 	Yes ,  And to have them documented .

> If so, then it is  'mdadm -A'.  I guess I could make that more
> explicit.
 	Hmm ,  Where is mdadm documented as linux-raid tool(set) IN the
 	kernel tree ?  It's not in md.txt ..
# grep mdadm /usr/src/linux/Documentation/md.txt
#
 	Please help me(us) here .

> Or are you asking something else?
 	No ,  You got it right .  Tia ,  JimL
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

[PATCH md 000 of 2] Introduction

[NeilBrown]

Following are two patches for md in 2.6.15-rc what should get into
2.6.15-final if possible.

The first refines a newly created interface (/sys/block/mdX/md/level).
I've decided that 'raid5' is better than 'RAID-5' after all.

The second removes some limits that shouldn't really be imposed in the kernel.

Thanks,
NeilBrown



 [PATCH md 001 of 2] Change case of raid level reported in sys/mdX/md/level
 [PATCH md 002 of 2] Remove inappropriate limits in md/bitmap configuration.