Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp436066yba; Wed, 15 May 2019 04:04:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqzGrc5yIedGlwmAZEWobKPSVcNof4rE+VhXmT2E8msZwdpGR8KaLVEiEnO58rqxM9H2IUqf X-Received: by 2002:a17:902:54f:: with SMTP id 73mr43699300plf.140.1557918291014; Wed, 15 May 2019 04:04:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557918291; cv=none; d=google.com; s=arc-20160816; b=GXHRcU+iCfBYjMbkCCYyxIwnYkVSlLIHHsfkQ5ct4yeeQwazk0s5qBLL7vVf7bgEuY C5sFypusg/Ie5tltqptr91HCfhU41CMlflghyAak0CCCKduG6HeC3jZGDyjuRLUcmVBW GqxKJeeUt18fTuIFyH0xB2EfilYQdVUmQK+Ifxpy502U1u6D3UtBxBHTSLV13hkmperE uVGWQbxiF0O8/VG0a2VkQRqkcak8ZBMtFJoFqTpynkN5/z4K0s126rBbg28xxC1Mmgcc r1c0dXfSkkf8CMpfaCZn0L+6kJvHG8d7oM1u08HMQ5XFrmfqNxPKOczeSzadb2dWYTzL Fuhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Urn34uVqyfag3C4EqtE0BUlRdTbuVx8ViCE0f+u9iWg=; b=UmpDO3XV9DOM1wCPibDncEL3h7lY/ifVZQCj1vV1yrkYtfpoiOI9oO+uvu1nMdNRps 6wadsj16DddmMepfhNXmFHpB0bT3zkFj7N0Rn43dGJrSy4OocoInHkZbGLD9dq2jrR4x FZVMyitKOSU8Vcd+9nxKEWJUmEY0gx9oE8lJy1hrMi+fQChJQPTcy+BL7fzVFw/8xm6U 4bbpX7/pZVUFttAUyDij90pknCVfGyMNLoUgMfDgtODT72inkhpVi6LFFuMUVf8uFdwW i29ltvaaRWoCRYKIk1lbQWVqVf5ax4GlNKdelPSsT1KMbPk+xgazdfcAfqwNfAeDY/0M U6QA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=N55s6WcE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f71si1552706pgc.150.2019.05.15.04.04.33; Wed, 15 May 2019 04:04:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=N55s6WcE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727572AbfEOLA4 (ORCPT + 99 others); Wed, 15 May 2019 07:00:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:57786 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727561AbfEOLAy (ORCPT ); Wed, 15 May 2019 07:00:54 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A34FE20881; Wed, 15 May 2019 11:00:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557918053; bh=yXFz8Jb4gM2zZgZ8zF5ausH5jyUvMlQMcMzdpIuepTI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N55s6WcE6dPc89dYfQdTIZn0hEkYYn8y+eIzUCHbWuRsT4qI7eedkuIbPsS3VdCL2 f97MMcWK14Xwn83IOHqja4tmkGsuBK0Ab6nLVyliiQJBv+9ZUCBw7rqlThpgv/vbdT V8MJ4zQYhWcWuJrMk7jtOzRIxJuy21Yb7+FHge9A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiao Ni , David Jeffery , Nigel Croxon , Song Liu , Jens Axboe Subject: [PATCH 3.18 75/86] Dont jump to compute_result state from check_result state Date: Wed, 15 May 2019 12:55:52 +0200 Message-Id: <20190515090655.383852971@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190515090642.339346723@linuxfoundation.org> References: <20190515090642.339346723@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Nigel Croxon commit 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef upstream. Changing state from check_state_check_result to check_state_compute_result not only is unsafe but also doesn't appear to serve a valid purpose. A raid6 check should only be pushing out extra writes if doing repair and a mis-match occurs. The stripe dev management will already try and do repair writes for failing sectors. This patch makes the raid6 check_state_check_result handling work more like raid5's. If somehow too many failures for a check, just quit the check operation for the stripe. When any checks pass, don't try and use check_state_compute_result for a purpose it isn't needed for and is unsafe for. Just mark the stripe as in sync for passing its parity checks and let the stripe dev read/write code and the bad blocks list do their job handling I/O errors. Repro steps from Xiao: These are the steps to reproduce this problem: 1. redefined OPT_MEDIUM_ERR_ADDR to 12000 in scsi_debug.c 2. insmod scsi_debug.ko dev_size_mb=11000 max_luns=1 num_tgts=1 3. mdadm --create /dev/md127 --level=6 --raid-devices=5 /dev/sde1 /dev/sde2 /dev/sde3 /dev/sde5 /dev/sde6 sde is the disk created by scsi_debug 4. echo "2" >/sys/module/scsi_debug/parameters/opts 5. raid-check It panic: [ 4854.730899] md: data-check of RAID array md127 [ 4854.857455] sd 5:0:0:0: [sdr] tag#80 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 4854.859246] sd 5:0:0:0: [sdr] tag#80 Sense Key : Medium Error [current] [ 4854.860694] sd 5:0:0:0: [sdr] tag#80 Add. Sense: Unrecovered read error [ 4854.862207] sd 5:0:0:0: [sdr] tag#80 CDB: Read(10) 28 00 00 00 2d 88 00 04 00 00 [ 4854.864196] print_req_error: critical medium error, dev sdr, sector 11656 flags 0 [ 4854.867409] sd 5:0:0:0: [sdr] tag#100 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 4854.869469] sd 5:0:0:0: [sdr] tag#100 Sense Key : Medium Error [current] [ 4854.871206] sd 5:0:0:0: [sdr] tag#100 Add. Sense: Unrecovered read error [ 4854.872858] sd 5:0:0:0: [sdr] tag#100 CDB: Read(10) 28 00 00 00 2e e0 00 00 08 00 [ 4854.874587] print_req_error: critical medium error, dev sdr, sector 12000 flags 4000 [ 4854.876456] sd 5:0:0:0: [sdr] tag#101 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 4854.878552] sd 5:0:0:0: [sdr] tag#101 Sense Key : Medium Error [current] [ 4854.880278] sd 5:0:0:0: [sdr] tag#101 Add. Sense: Unrecovered read error [ 4854.881846] sd 5:0:0:0: [sdr] tag#101 CDB: Read(10) 28 00 00 00 2e e8 00 00 08 00 [ 4854.883691] print_req_error: critical medium error, dev sdr, sector 12008 flags 4000 [ 4854.893927] sd 5:0:0:0: [sdr] tag#166 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 4854.896002] sd 5:0:0:0: [sdr] tag#166 Sense Key : Medium Error [current] [ 4854.897561] sd 5:0:0:0: [sdr] tag#166 Add. Sense: Unrecovered read error [ 4854.899110] sd 5:0:0:0: [sdr] tag#166 CDB: Read(10) 28 00 00 00 2e e0 00 00 10 00 [ 4854.900989] print_req_error: critical medium error, dev sdr, sector 12000 flags 0 [ 4854.902757] md/raid:md127: read error NOT corrected!! (sector 9952 on sdr1). [ 4854.904375] md/raid:md127: read error NOT corrected!! (sector 9960 on sdr1). [ 4854.906201] ------------[ cut here ]------------ [ 4854.907341] kernel BUG at drivers/md/raid5.c:4190! raid5.c:4190 above is this BUG_ON: handle_parity_checks6() ... BUG_ON(s->uptodate < disks - 1); /* We don't need Q to recover */ Cc: # v3.16+ OriginalAuthor: David Jeffery Cc: Xiao Ni Tested-by: David Jeffery Signed-off-by: David Jeffy Signed-off-by: Nigel Croxon Signed-off-by: Song Liu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- drivers/md/raid5.c | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -3414,26 +3414,15 @@ static void handle_parity_checks6(struct case check_state_check_result: sh->check_state = check_state_idle; + if (s->failed > 1) + break; /* handle a successful check operation, if parity is correct * we are done. Otherwise update the mismatch count and repair * parity if !MD_RECOVERY_CHECK */ if (sh->ops.zero_sum_result == 0) { - /* both parities are correct */ - if (!s->failed) - set_bit(STRIPE_INSYNC, &sh->state); - else { - /* in contrast to the raid5 case we can validate - * parity, but still have a failure to write - * back - */ - sh->check_state = check_state_compute_result; - /* Returning at this point means that we may go - * off and bring p and/or q uptodate again so - * we make sure to check zero_sum_result again - * to verify if p or q need writeback - */ - } + /* Any parity checked was correct */ + set_bit(STRIPE_INSYNC, &sh->state); } else { atomic64_add(STRIPE_SECTORS, &conf->mddev->resync_mismatches); if (test_bit(MD_RECOVERY_CHECK, &conf->mddev->recovery))