lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201004221336.28530.s.L-H@gmx.de>
Date:	Thu, 22 Apr 2010 13:36:26 +0200
From:	"Stefan Lippers-Hollmann" <s.L-H@....de>
To:	Neil Brown <neilb@...e.de>
Cc:	gregkh@...e.de, linux-kernel@...r.kernel.org, king.br@...il.com,
	stable@...nel.org
Subject: Re: patch md-raid5-allow-for-more-than-2-31-chunks.patch added to 2.6.33-stable tree

Hi

On Thursday 22 April 2010, Neil Brown wrote:
> On Thu, 22 Apr 2010 04:08:30 +0200
> "Stefan Lippers-Hollmann" <s.L-H@....de> wrote:
> > On Thursday 22 April 2010, gregkh@...e.de wrote:
[...]
> > > From 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d Mon Sep 17 00:00:00 2001
> > > From: NeilBrown <neilb@...e.de>
> > > Date: Tue, 20 Apr 2010 14:13:34 +1000
> > > Subject: md/raid5: allow for more than 2^31 chunks.
> > > 
> > > From: NeilBrown <neilb@...e.de>
> > > 
> > > commit 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d upstream.
> > > 
> > > With many large drives and small chunk sizes it is possible
> > > to create a RAID5 with more than 2^31 chunks.  Make sure this
> > > works.
> > > 
> > > Reported-by: Brett King <king.br@...il.com>
> > > Signed-off-by: NeilBrown <neilb@...e.de>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
> > 
> > This patch, as part of the current 2.6.33 stable queue, breaks compiling
> > on i386 (CONFIG_LBDAF=y) for me (amd64 builds fine):
> > 
> > [...]
> >   BUILD   arch/x86/boot/bzImage
> > Root device is (254, 6)
> > Setup is 12700 bytes (padded to 12800 bytes).
> > System is 2415 kB
> > CRC db6fa5fa
> > Kernel: arch/x86/boot/bzImage is ready  (#1)
> > ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined!
> > 
> > reverting just this patch fixes the problem for me.
> 
> Thanks for testing and reporting.
> 
> If you could verify that this additional patch fixes the compile error I
> would really appreciate it.

I can confirm that this patch on top of the original 
md-raid5-allow-for-more-than-2-31-chunks.patch fixes the build problem on 
i386 for me (amd64 continues to build fine as well).

Tested-by: Stefan Lippers-Hollmann <s.l-h@....de>

Thank you a lot
	Stefan Lippers-Hollmann

-- 
> Thanks,
> NeilBrown
> 
> 
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 20e4840..58ea0ec 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -1650,7 +1650,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  				     int previous, int *dd_idx,
>  				     struct stripe_head *sh)
>  {
> -	sector_t stripe;
> +	sector_t stripe, stripe2;
>  	sector_t chunk_number;
>  	unsigned int chunk_offset;
>  	int pd_idx, qd_idx;
> @@ -1677,7 +1677,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  	 */
>  	stripe = chunk_number;
>  	*dd_idx = sector_div(stripe, data_disks);
> -
> +	stripe2 = stripe;
>  	/*
>  	 * Select the parity disk based on the user selected algorithm.
>  	 */
> @@ -1689,21 +1689,21 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  	case 5:
>  		switch (algorithm) {
>  		case ALGORITHM_LEFT_ASYMMETRIC:
> -			pd_idx = data_disks - stripe % raid_disks;
> +			pd_idx = data_disks - sector_div(stripe2, raid_disks);
>  			if (*dd_idx >= pd_idx)
>  				(*dd_idx)++;
>  			break;
>  		case ALGORITHM_RIGHT_ASYMMETRIC:
> -			pd_idx = stripe % raid_disks;
> +			pd_idx = sector_div(stripe2, raid_disks);
>  			if (*dd_idx >= pd_idx)
>  				(*dd_idx)++;
>  			break;
>  		case ALGORITHM_LEFT_SYMMETRIC:
> -			pd_idx = data_disks - stripe % raid_disks;
> +			pd_idx = data_disks - sector_div(stripe2, raid_disks);
>  			*dd_idx = (pd_idx + 1 + *dd_idx) % raid_disks;
>  			break;
>  		case ALGORITHM_RIGHT_SYMMETRIC:
> -			pd_idx = stripe % raid_disks;
> +			pd_idx = sector_div(stripe2, raid_disks);
>  			*dd_idx = (pd_idx + 1 + *dd_idx) % raid_disks;
>  			break;
>  		case ALGORITHM_PARITY_0:
> @@ -1723,7 +1723,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  
>  		switch (algorithm) {
>  		case ALGORITHM_LEFT_ASYMMETRIC:
> -			pd_idx = raid_disks - 1 - (stripe % raid_disks);
> +			pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks);
>  			qd_idx = pd_idx + 1;
>  			if (pd_idx == raid_disks-1) {
>  				(*dd_idx)++;	/* Q D D D P */
> @@ -1732,7 +1732,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  				(*dd_idx) += 2; /* D D P Q D */
>  			break;
>  		case ALGORITHM_RIGHT_ASYMMETRIC:
> -			pd_idx = stripe % raid_disks;
> +			pd_idx = sector_div(stripe2, raid_disks);
>  			qd_idx = pd_idx + 1;
>  			if (pd_idx == raid_disks-1) {
>  				(*dd_idx)++;	/* Q D D D P */
> @@ -1741,12 +1741,12 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  				(*dd_idx) += 2; /* D D P Q D */
>  			break;
>  		case ALGORITHM_LEFT_SYMMETRIC:
> -			pd_idx = raid_disks - 1 - (stripe % raid_disks);
> +			pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks);
>  			qd_idx = (pd_idx + 1) % raid_disks;
>  			*dd_idx = (pd_idx + 2 + *dd_idx) % raid_disks;
>  			break;
>  		case ALGORITHM_RIGHT_SYMMETRIC:
> -			pd_idx = stripe % raid_disks;
> +			pd_idx = sector_div(stripe2, raid_disks);
>  			qd_idx = (pd_idx + 1) % raid_disks;
>  			*dd_idx = (pd_idx + 2 + *dd_idx) % raid_disks;
>  			break;
> @@ -1765,7 +1765,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  			/* Exactly the same as RIGHT_ASYMMETRIC, but or
>  			 * of blocks for computing Q is different.
>  			 */
> -			pd_idx = stripe % raid_disks;
> +			pd_idx = sector_div(stripe2, raid_disks);
>  			qd_idx = pd_idx + 1;
>  			if (pd_idx == raid_disks-1) {
>  				(*dd_idx)++;	/* Q D D D P */
> @@ -1780,7 +1780,8 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  			 * D D D P Q  rather than
>  			 * Q D D D P
>  			 */
> -			pd_idx = raid_disks - 1 - ((stripe + 1) % raid_disks);
> +			stripe2 += 1;
> +			pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks);
>  			qd_idx = pd_idx + 1;
>  			if (pd_idx == raid_disks-1) {
>  				(*dd_idx)++;	/* Q D D D P */
> @@ -1792,7 +1793,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  
>  		case ALGORITHM_ROTATING_N_CONTINUE:
>  			/* Same as left_symmetric but Q is before P */
> -			pd_idx = raid_disks - 1 - (stripe % raid_disks);
> +			pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks);
>  			qd_idx = (pd_idx + raid_disks - 1) % raid_disks;
>  			*dd_idx = (pd_idx + 1 + *dd_idx) % raid_disks;
>  			ddf_layout = 1;
> @@ -1800,27 +1801,27 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector,
>  
>  		case ALGORITHM_LEFT_ASYMMETRIC_6:
>  			/* RAID5 left_asymmetric, with Q on last device */
> -			pd_idx = data_disks - stripe % (raid_disks-1);
> +			pd_idx = data_disks - sector_div(stripe2, raid_disks-1);
>  			if (*dd_idx >= pd_idx)
>  				(*dd_idx)++;
>  			qd_idx = raid_disks - 1;
>  			break;
>  
>  		case ALGORITHM_RIGHT_ASYMMETRIC_6:
> -			pd_idx = stripe % (raid_disks-1);
> +			pd_idx = sector_div(stripe2, raid_disks-1);
>  			if (*dd_idx >= pd_idx)
>  				(*dd_idx)++;
>  			qd_idx = raid_disks - 1;
>  			break;
>  
>  		case ALGORITHM_LEFT_SYMMETRIC_6:
> -			pd_idx = data_disks - stripe % (raid_disks-1);
> +			pd_idx = data_disks - sector_div(stripe2, raid_disks-1);
>  			*dd_idx = (pd_idx + 1 + *dd_idx) % (raid_disks-1);
>  			qd_idx = raid_disks - 1;
>  			break;
>  
>  		case ALGORITHM_RIGHT_SYMMETRIC_6:
> -			pd_idx = stripe % (raid_disks-1);
> +			pd_idx = sector_div(stripe2, raid_disks-1);
>  			*dd_idx = (pd_idx + 1 + *dd_idx) % (raid_disks-1);
>  			qd_idx = raid_disks - 1;
>  			break;
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ