linux-kernel - Re: [PATCH 4.19 108/114] Revert "Dont jump to compute_result state from check

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: <20190525120835.GA2975@xo-6d-61-c0.localdomain>
Date:   Sat, 25 May 2019 14:08:35 +0200
From:   Pavel Machek <pavel@....cz>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Dan Williams <dan.j.williams@...el.com>,
        Nigel Croxon <ncroxon@...hat.com>, Xiao Ni <xni@...hat.com>,
        Song Liu <songliubraving@...com>
Subject: Re: [PATCH 4.19 108/114] Revert "Dont jump to compute_result state
 from check_result state"

On Thu 2019-05-23 21:06:47, Greg Kroah-Hartman wrote:
> From: Song Liu <songliubraving@...com>
> 
> commit a25d8c327bb41742dbd59f8c545f59f3b9c39983 upstream.
> 
> This reverts commit 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef.
> 
> Cc: Dan Williams <dan.j.williams@...el.com>
> Cc: Nigel Croxon <ncroxon@...hat.com>
> Cc: Xiao Ni <xni@...hat.com>
> Signed-off-by: Song Liu <songliubraving@...com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

We normally reject patches without changelog, and this has none. Why
make exception here?

									Pavel

> 
> ---
>  drivers/md/raid5.c |   19 +++++++++++++++----
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -4221,15 +4221,26 @@ 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) {
> -			/* Any parity checked was correct */
> -			set_bit(STRIPE_INSYNC, &sh->state);
> +			/* 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
> +				 */
> +			}
>  		} else {
>  			atomic64_add(STRIPE_SECTORS, &conf->mddev->resync_mismatches);
>  			if (test_bit(MD_RECOVERY_CHECK, &conf->mddev->recovery)) {
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html