linux-kernel - Re: Bug in drivers/md/md.c ?

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: <17845.9760.806387.670182@notabene.brown>
Date:	Tue, 23 Jan 2007 08:01:20 +1100
From:	Neil Brown <neilb@...e.de>
To:	noah <noah123@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Bug in drivers/md/md.c ?

On Tuesday January 16, noah123@...il.com wrote:
> Hi!
> 
> I'm getting "md: bug in file drivers/md/md.c, line 1652" (see below) after
> writing data to a md-device using dd.
> Is it really a bug or am I just using mdadm in the wrong way? I'm unsure
> about the --assume-clean flag when creating the raid5 volume.

It is a bug, not an incorrect usage.

This patch (against 2.6.19-rcX) should fix it.

Thanks,
NeilBrown

Make sure the events count in an md array never returns to zero.

Now that we sometimes step the array events count backwards
(when transitioning dirty->clean where nothing else interesting
has happened - so that we don't need to write to spares all the time),
it is possible for the event count to return to zero, which is
potentially confusing and triggers and MD_BUG.

We could possibly remove the MD_BUG, but is just as easy, and
probably safer, to make sure we never return to zero.

Signed-off-by: Neil Brown <neilb@...e.de>

### Diffstat output
 ./drivers/md/md.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c	2007-01-22 09:08:17.000000000 +1100
+++ ./drivers/md/md.c	2007-01-23 07:53:32.000000000 +1100
@@ -1633,7 +1633,8 @@ repeat:
 	 * and 'events' is odd, we can roll back to the previous clean state */
 	if (nospares
 	    && (mddev->in_sync && mddev->recovery_cp == MaxSector)
-	    && (mddev->events & 1))
+	    && (mddev->events & 1)
+	    && mddev->events != 1)
 		mddev->events--;
 	else {
 		/* otherwise we have to go forward and ... */
-
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/