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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cb2c26e4-1c1f-8a0a-040e-0c25d0c37e6c@huaweicloud.com>
Date: Mon, 29 Jul 2024 09:30:39 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Mateusz Jończyk <mat.jonczyk@...pl>,
 linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: Song Liu <song@...nel.org>, stable@...r.kernel.org,
 "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH] [DEBUG] md/raid1: check recovery_offset in
 raid1_check_read_range

Hi,

在 2024/07/28 18:36, Mateusz Jończyk 写道:
> This should fix the filesystem corruption during RAID resync.
> 
> Checking this condition in raid1_check_read_range is not ideal, but this
> is only a debug patch.
> 
> Link: https://lore.kernel.org/lkml/20240724141906.10b4fc4e@peluse-desk5/T/#m671d6d3a7eda44d39d0882864a98824f52c52917
> Signed-off-by: Mateusz Jończyk <mat.jonczyk@...pl>
> Cc: Yu Kuai <yukuai3@...wei.com>
> Cc: Song Liu <song@...nel.org>
> Cc: stable@...r.kernel.org
> ---
>   drivers/md/raid1-10.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/md/raid1-10.c b/drivers/md/raid1-10.c
> index 2ea1710a3b70..4ab896e8cb12 100644
> --- a/drivers/md/raid1-10.c
> +++ b/drivers/md/raid1-10.c
> @@ -252,6 +252,10 @@ static inline int raid1_check_read_range(struct md_rdev *rdev,
>   	sector_t first_bad;
>   	int bad_sectors;
>   
> +	if (!test_bit(In_sync, &rdev->flags) &&
> +	    rdev->recovery_offset < this_sector + *len)
> +		return 0;
> +

It's right this check is necessary, which means should not read from
rdev that the array is still in recovery and the read range is not
recoveried yet.

However, choose_first_rdev() is called during array resync, hence
the array will not be in recovery, and this is just dead code and not
needed.

And choose_bb_rdev() will only be called when the read range has bb,
which means the read range msut be accessed before and IO error must
occur first, and which indicates this rdev can't still be in recovery
for the read range.

So I think this check is only needed for slow disks.

BTW, looks like we don't have much tests for the case slow disks in
raid1.

Thanks,
Kuai

>   	/* no bad block overlap */
>   	if (!is_badblock(rdev, this_sector, *len, &first_bad, &bad_sectors))
>   		return *len;
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ