From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4EB722126C for ; Tue, 10 Mar 2026 01:15:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773105341; cv=none; b=YcK3waGQwP/zepGgHyYTXJlvC8yiYqV3W6rTQh6OSSxJMQxqY5B1OxELrpdEjkD/stHR96/0UEFd9f686UVf/beAFp1mtTkn2rxz66b0uhYp05nyIBK6Jg7nDTja0Ed2PpcpPxCpEVCc/Dil3oMMWcFVROvMqt7EDLiUmNysFo8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773105341; c=relaxed/simple; bh=7wrF06tMNqdNnhfEAakD0Muy3T8Fh+S0910Jsdn1iEA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nwpJAIFs1rrw5yHL6k4/g3CtUkTgxZXZxoJfGN9vlaqaEWtglHOYJd9fNxhRS6bYI7Jv1sMmK240Rj+Iuay/3zruxfeivqG9RKUCekGVf8SLL3m8O1KvfmNsgYt1BXzTBc3lnH4XCLGuus8763JvZUSIpP6yNJrorr4mS/yrRHY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Pvuk5JpK; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=sZnG8CYa; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Pvuk5JpK"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="sZnG8CYa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773105338; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AeuzWAzKQxgExrZB0lyoCkQxoP+PEP3FNmCEkoiiVXs=; b=Pvuk5JpKopUHgc5VDUOPMdeRAZxVQKYyCqs5ON9Nj1gRTxy1KoBx7MwlpnJ9+j+8zc+30/ rkrREOZyPxBU0hH4QFHxDSGxK4WhroDnKu3Dfbss0a/10bmbLm5Jh9fNPH6p7hbalQZ8u0 R7h8uESMFOVPdNyRhh5Cs0cQUg7VVqk= Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-664-8auFUSj7MuiST8uMDYp2fA-1; Mon, 09 Mar 2026 21:15:37 -0400 X-MC-Unique: 8auFUSj7MuiST8uMDYp2fA-1 X-Mimecast-MFC-AGG-ID: 8auFUSj7MuiST8uMDYp2fA_1773105337 Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-3594620fe97so62559450a91.1 for ; Mon, 09 Mar 2026 18:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1773105336; x=1773710136; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=AeuzWAzKQxgExrZB0lyoCkQxoP+PEP3FNmCEkoiiVXs=; b=sZnG8CYa+jZyiZDX4CNP85oZgaLt9s4cfEbFJrP4bgwiB2xfzCCcwrLXo3jTi6XWlO 3Gsq8JNvSaxYQgqY+L0hI0L7eCpkny1PdhmD2+zcD8HUAb2MP1kjnWKowzfJ994i7A1n HFDfp+6rwq81ZadWyNTNtttv+vGtrukZVjQ8x/WX2EchWJxQcS+ixpEQQQ8X+lEH+iOc sKUmddlIvub7JBl9Zbqf1NtFq+rRD2/biYZMCy6PhqzXPkb1lPaZ2O0BzffR287aYeg2 CWqZLMVSqjeeUhh6jM4UNWNLMRju14xaTBJqvvDTG3iW8eWLo53M+8zusMnflQuQUqU1 Olig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773105336; x=1773710136; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=AeuzWAzKQxgExrZB0lyoCkQxoP+PEP3FNmCEkoiiVXs=; b=l8VexpwRZDiXnay/e3Alzt6VVhkATEAcxFGBRPTqGuQmJ1tmZsU78Fm++GP8E6ASlQ 4khA6oA9ETofo8S1nU4NcRs2CQdHdU02CUCeAJ8IVg0qnPU83Po0Hzof6Z0Hs8KpH9Kj e4xwtgqaab0kj1J+9cawQMuq5J1QMwGJpH7UXUrmqQKsiOE3u6+io3r/rWxpJmkXmj+E zi9t498xN0KS5XkZm0NQIMhm9GQcN30SOWiOBafVUHODBR5CiVxz7tc87Mfupocy2veG DBI+/sI9h//2XOz3MMR3YCVWOQVBi36OnRP0pYE9VZQmGKXDBSzapBTRTZNQcdsQ+hj/ H9yQ== X-Forwarded-Encrypted: i=1; AJvYcCVd3giBVmZhJ9V7KFiV6NjBgu6Vnc+rXIbUbY2yqr7dKl9GwMLKGVfl+tJ68fPMesfkRnmL1SZidpxszPc=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6o4Yxnp+VLvJMNLpIxJ5nElvU0OucNEhEEW1cWT6RaRkVfSAB rU/KeF1jU0Mp/cLqrQB8UiPTDkvdTb/Lwe4ygfkQ03vJ0zTY9OoRB7gfKCV5LAbu5Tm3ylGmmVq nWH8Tn6RTFqBFTcaq1PJ0BMSYGVCWuE07H/a1BFROgJpZ+QNyqtNxmjlkAxGjyzX8+A== X-Gm-Gg: ATEYQzympVevY/1dgt9J3UphH1s6R9JGiL6QHX8P6tJr0j4QLKvPWvwauR0Z2f8GnwY 82YP2tLbZwkfoWuytkwjngzEj8mHG1OTnSLISW6TsFRMHPdzBBTq4kQAKeL4/QT0f/uTeafCck2 JiJLgvcbL7kjsBp0ScES+avLtvWJTAv3ZgRW/S7qYh02bH8dIJhOD2fv902sh0ztz0mcP4YVhq5 kCBYjzjud1AgD3U/jiZugE2hyGUS7WfCEio9lqD2SJwNiiRAyfW+rIJux4pcnTBno63yu0PcjAx DM9MF6ik3zf1oLUzhcxEnAdWoMRIBtn0Asp+pGfdTrM5iFMPFF4CEmPCAZ7/6mDtwCR5tl94g50 NEEKGScqDOSzNQx3W6Zj4csYlnU3IHPzXOwzr/+y0+z5tlfsq/ERH9ddQvkw07/xSrQ/Taq7OxL 740X+yPILPcbkTx0lYZDJ0BHbBZwbvgjdt X-Received: by 2002:a17:90b:2507:b0:359:c770:9f46 with SMTP id 98e67ed59e1d1-359c770a2c1mr6398717a91.10.1773105336489; Mon, 09 Mar 2026 18:15:36 -0700 (PDT) X-Received: by 2002:a17:90b:2507:b0:359:c770:9f46 with SMTP id 98e67ed59e1d1-359c770a2c1mr6398580a91.10.1773105331299; Mon, 09 Mar 2026 18:15:31 -0700 (PDT) Received: from [10.72.112.96] ([209.132.188.88]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-359f05ee152sm1173460a91.2.2026.03.09.18.15.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 18:15:30 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 09:15:26 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/5] md: add fallback to correct bitmap_ops on version mismatch To: Su Yue , Yu Kuai Cc: song@kernel.org, linan122@huawei.com, colyli@fnnas.com, linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260214061013.2335604-1-yukuai@fnnas.com> <20260214061013.2335604-4-yukuai@fnnas.com> From: Xiao Ni In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 在 2026/2/24 09:52, Su Yue 写道: > On Mon 23 Feb 2026 at 10:22, "Yu Kuai" wrote: > >> Hi, >> >> 在 2026/2/17 16:54, Su Yue 写道: >>> On Sat 14 Feb 2026 at 14:10, Yu Kuai wrote: >>> >>>> If default bitmap version and on-disk version doesn't match, and mdadm >>>> is not the latest version to set bitmap_type, set bitmap_ops based on >>>> the disk version. >>>> >>> Why not just let old version mdadm fails  since llbitmap is a new >>> feature. >> >> The original use case is that we found llbitmap array fails to >> assemble in >> some corner cases, and with the respect I'm not quite familiar with >> mdadm >> code, so I think this patch is the best solution for now. >> > Would you please elaborate which corner cases that llbitmap array > fails to assemble > in? Do they happen in mdadm <= 4.5? > >> On the other hand, this should also be helpful if we decide to make >> llbitmap >> the default option in the future. >> > But it's so far, right? llbitmap support is still on the way(mdadm 4.6 > is not released). > > I am not opposed to the patch. It just looks strange to me that > changing kernel code to > let old userspace work with *new* feature. > Maybe the mdadm maintainers have words in another angles? Yes. Is it better to upgrade mdadm to the version which supports llbitmap? Regards Xiao > > -- > Su >> >>> >>>> Signed-off-by: Yu Kuai >>>> --- >>>>  drivers/md/md.c | 103 >>>>  +++++++++++++++++++++++++++++++++++++++++++++++- >>>>  1 file changed, 102 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/md/md.c b/drivers/md/md.c >>>> index 59cd303548de..d2607ed5c2e9 100644 >>>> --- a/drivers/md/md.c >>>> +++ b/drivers/md/md.c >>>> @@ -6447,15 +6447,116 @@ static void md_safemode_timeout(struct >>>> timer_list *t) >>>> >>>>  static int start_dirty_degraded; >>>> >>>> +/* >>>> + * Read bitmap superblock and return the bitmap_id based on disk >>>> version. >>>> + * This is used as fallback when default bitmap version and on-disk >>>> version >>>> + * doesn't match, and mdadm is not the latest version to set >>>> bitmap_type. >>>> + */ >>>> +static enum md_submodule_id md_bitmap_get_id_from_sb(struct mddev >>>> *mddev) >>>> +{ >>>> +    struct md_rdev *rdev; >>>> +    struct page *sb_page; >>>> +    bitmap_super_t *sb; >>>> +    enum md_submodule_id id = ID_BITMAP_NONE; >>>> +    sector_t sector; >>>> +    u32 version; >>>> + >>>> +    if (!mddev->bitmap_info.offset) >>>> +        return ID_BITMAP_NONE; >>>> + >>>> +    sb_page = alloc_page(GFP_KERNEL); >>>> +    if (!sb_page) >>>> +        return ID_BITMAP_NONE; >>>> + >>>> >>> Personally I don't like the way treating error as ID_BITMAP_NONE. >>> When wrong things happen everything looks fine, no error code, no >>> error message. >> >> Ok, sounds reasonable. >> >>> >>>> +    sector = mddev->bitmap_info.offset; >>>> + >>>> +    rdev_for_each(rdev, mddev) { >>>> +        u32 iosize; >>>> + >>>> +        if (!test_bit(In_sync, &rdev->flags) || >>>> +            test_bit(Faulty, &rdev->flags) || >>>> +            test_bit(Bitmap_sync, &rdev->flags)) >>>> +            continue; >>>> + >>>> +        iosize = roundup(sizeof(bitmap_super_t), >>>> +                 bdev_logical_block_size(rdev->bdev)); >>>> +        if (sync_page_io(rdev, sector, iosize, sb_page, REQ_OP_READ, >>>> +                 true)) >>>> +            goto read_ok; >>>> +    } >>>> >>> And here. >>> >>>> +    goto out; >>>> + >>>> +read_ok: >>>> +    sb = kmap_local_page(sb_page); >>>> +    if (sb->magic != cpu_to_le32(BITMAP_MAGIC)) >>>> +        goto out_unmap; >>>> + >>>> +    version = le32_to_cpu(sb->version); >>>> +    switch (version) { >>>> +    case BITMAP_MAJOR_LO: >>>> +    case BITMAP_MAJOR_HI: >>>> +    case BITMAP_MAJOR_CLUSTERED: >>>> >>> For BITMAP_MAJOR_CLUSTERED, why not ID_CLUSTER ? >> >> Because there is no optional bitmap_ops for md-cluster, it's still >> the old bitmap, and llbitmap does not support md-cluster for now. >> >>> >>> -- >>> Su >>>> +        id = ID_BITMAP; >>>> +        break; >>>> +    case BITMAP_MAJOR_LOCKLESS: >>>> +        id = ID_LLBITMAP; >>>> +        break; >>>> +    default: >>>> +        pr_warn("md: %s: unknown bitmap version %u\n", >>>> +            mdname(mddev), version); >>>> +        break; >>>> +    } >>>> + >>>> +out_unmap: >>>> +    kunmap_local(sb); >>>> +out: >>>> +    __free_page(sb_page); >>>> +    return id; >>>> +} >>>> + >>>>  static int md_bitmap_create(struct mddev *mddev) >>>>  { >>>> +    enum md_submodule_id orig_id = mddev->bitmap_id; >>>> +    enum md_submodule_id sb_id; >>>> +    int err; >>>> + >>>>      if (mddev->bitmap_id == ID_BITMAP_NONE) >>>>          return -EINVAL; >>>> >>>>      if (!mddev_set_bitmap_ops(mddev)) >>>>          return -ENOENT; >>>> >>>> -    return mddev->bitmap_ops->create(mddev); >>>> +    err = mddev->bitmap_ops->create(mddev); >>>> +    if (!err) >>>> +        return 0; >>>> >>>> + >>>> +    /* >>>> +     * Create failed, if default bitmap version and on-disk version >>>> +     * doesn't match, and mdadm is not the latest version to set >>>> +     * bitmap_type, set bitmap_ops based on the disk version. >>>> +     */ >>>> +    mddev_clear_bitmap_ops(mddev); >>>> + >>>> +    sb_id = md_bitmap_get_id_from_sb(mddev); >>>> +    if (sb_id == ID_BITMAP_NONE || sb_id == orig_id) >>>> +        return err; >>>> + >>>> +    pr_info("md: %s: bitmap version mismatch, switching from %d to >>>> %d\n", >>>> +        mdname(mddev), orig_id, sb_id); >>>> + >>>> +    mddev->bitmap_id = sb_id; >>>> +    if (!mddev_set_bitmap_ops(mddev)) { >>>> +        mddev->bitmap_id = orig_id; >>>> +        return -ENOENT; >>>> +    } >>>> + >>>> +    err = mddev->bitmap_ops->create(mddev); >>>> +    if (err) { >>>> +        mddev_clear_bitmap_ops(mddev); >>>> +        mddev->bitmap_id = orig_id; >>>> +    } >>>> + >>>> +    return err; >>>>  } >>>> >>>>  static void md_bitmap_destroy(struct mddev *mddev) >