Re: [PATCH] md: be careful not lot leak internal curr_resync value into metadata.

[Shaohua Li <shli@kernel.org>]

On Fri, Oct 28, 2016 at 03:59:41PM +1100, Neil Brown wrote:
> 
> 
> mddev->curr_resync usually records where the current resync is up to,
> but during the starting phase it has some "magic" values.
> 
>  1 - means that the array is trying to start a resync, but has yielded
>      to another array which shares physical devices, and also needs to
>      start a resync
>  2 - means the array is trying to start resync, but has found another
>      array which shares physical devices and has already started resync.
> 
>  3 - means that resync has commensed, but it is possible that nothing
>      has actually been resynced yet.
> 
> It is important that this value not be visible to user-space and
> particularly that it doesn't get written to the metadata, as the
> resync or recovery checkpoint.  In part, this is because it may be
> slightly higher than the correct value, though this is very rare.
> In part, because it is not a multiple of 4K, and some devices only
> support 4K aligned accesses.
> 
> There are two places where this value is propagates into either
> ->curr_resync_completed or ->recovery_cp or ->recovery_offset.
> These currently avoid the propagation of values 1 and 3, but will
> allow 3 to leak through.
> 
> Change them to only propagate the value if it is > 3.
> 
> As this can cause an array to fail, the patch is suitable for -stable.
> 
> Cc: stable@vger.kernel.org
> Reported-by: Viswesh <viswesh.vichu@gmail.com>
> Signed-off-by: NeilBrown <neilb@suse.com>

Good catch, applied, thanks!