linux-kernel - Re: 2.6.25.6 raid5 resync oops

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] [day] [month] [year] [list]

Message-Id: <1215665697.7848.15.camel@dwillia2-linux.ch.intel.com>
Date:	Wed, 09 Jul 2008 21:54:57 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Neil Brown <neilb@...e.de>
Cc:	Arkadiusz Miskiewicz <arekm@...en.pl>,
	linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org
Subject: Re: 2.6.25.6 raid5 resync oops

On Wed, 2008-07-09 at 18:07 -0700, Neil Brown wrote:
> Dan:  I think this is your code.  In
>   __handle_issuing_new_read_requests5
> the
>                 } else if ((s->uptodate < disks - 1) &&
>                         test_bit(R5_Insync, &dev->flags)) {
> 
> looks wrong.  We at least want a test on s->syncing in there, maybe:
>                 } else if (((s->uptodate < disks - 1) || s->syncing)
> &&
>                         test_bit(R5_Insync, &dev->flags)) {
> 
> and given that we only compute blocks when a device is failed, (see 15
> lines earlier) I think we probably just want
>                 } else if (test_bit(R5_Insync, &dev->flags)) {
> 
> I notice that is was it in linux-next (though the functions are
> renamed - it is fetch_block5 there).

Yes, I had realized it was obsolete... missed that it was buggy.
> 
> I wonder if there is still time for 2.6.26 .. probably not.  It'll be
> released immediately after lwn.net release their weekly edition :-)

Here is a patch against latest mainline.

---snip--->
md: ensure all blocks are uptodate or locked when syncing

From: Dan Williams <dan.j.williams@...el.com>

Remove the dubious attempt to prefer 'compute' over 'read'.  Not only is it
wrong given commit c337869d (md: do not compute parity unless it is on a failed
drive), but it can trigger a BUG_ON in handle_parity_checks5().

Cc: <stable@...nel.org>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
---

 drivers/md/raid5.c |    7 +------
 1 files changed, 1 insertions(+), 6 deletions(-)


diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 54c8ee2..3b27df5 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2017,12 +2017,7 @@ static int __handle_issuing_new_read_requests5(struct stripe_head *sh,
 			 */
 			s->uptodate++;
 			return 0; /* uptodate + compute == disks */
-		} else if ((s->uptodate < disks - 1) &&
-			test_bit(R5_Insync, &dev->flags)) {
-			/* Note: we hold off compute operations while checks are
-			 * in flight, but we still prefer 'compute' over 'read'
-			 * hence we only read if (uptodate < * disks-1)
-			 */
+		} else if (test_bit(R5_Insync, &dev->flags)) {
 			set_bit(R5_LOCKED, &dev->flags);
 			set_bit(R5_Wantread, &dev->flags);
 			if (!test_and_set_bit(STRIPE_OP_IO, &sh->ops.pending))


--
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/