linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Yu Kuai <yukuai1@huaweicloud.com>,
	hch@lst.de, xni@redhat.com, colyli@kernel.org, song@kernel.org,
	yukuai3@huawei.com
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-raid@vger.kernel.org, yi.zhang@huawei.com,
	yangerkun@huawei.com, johnny.chenyi@huawei.com
Subject: Re: [PATCH 06/23] md/md-bitmap: add a new sysfs api bitmap_type
Date: Tue, 27 May 2025 08:10:10 +0200	[thread overview]
Message-ID: <23b75e25-fa2f-4d12-8d96-6de01e43ad49@suse.de> (raw)
In-Reply-To: <20250524061320.370630-7-yukuai1@huaweicloud.com>

On 5/24/25 08:13, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.com>
> 
> The api will be used by mdadm to set bitmap_ops while creating new array
> or assemble array, prepare to add a new bitmap.
> 
> Currently available options are:
> 
> cat /sys/block/md0/md/bitmap_type
> none [bitmap]
> 
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
>   Documentation/admin-guide/md.rst | 73 ++++++++++++++----------
>   drivers/md/md.c                  | 96 ++++++++++++++++++++++++++++++--
>   drivers/md/md.h                  |  2 +
>   3 files changed, 135 insertions(+), 36 deletions(-)
> 
[ .. ]
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 311e52d5173d..4eb0c6effd5b 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -672,13 +672,18 @@ static void active_io_release(struct percpu_ref *ref)
>   
>   static void no_op(struct percpu_ref *r) {}
>   
> -static void mddev_set_bitmap_ops(struct mddev *mddev, enum md_submodule_id id)
> +static bool mddev_set_bitmap_ops(struct mddev *mddev)
>   {
>   	xa_lock(&md_submodule);
> -	mddev->bitmap_ops = xa_load(&md_submodule, id);
> +	mddev->bitmap_ops = xa_load(&md_submodule, mddev->bitmap_id);
>   	xa_unlock(&md_submodule);
> -	if (!mddev->bitmap_ops)
> -		pr_warn_once("md: can't find bitmap id %d\n", id);
> +
> +	if (!mddev->bitmap_ops) {
> +		pr_warn_once("md: can't find bitmap id %d\n", mddev->bitmap_id);
> +		return false;
> +	}
> +
> +	return true;
>   }
>   
>   static void mddev_clear_bitmap_ops(struct mddev *mddev)
> @@ -688,8 +693,10 @@ static void mddev_clear_bitmap_ops(struct mddev *mddev)
>   
>   int mddev_init(struct mddev *mddev)
>   {
> -	/* TODO: support more versions */
> -	mddev_set_bitmap_ops(mddev, ID_BITMAP);
> +	mddev->bitmap_id = ID_BITMAP;
> +
> +	if (!mddev_set_bitmap_ops(mddev))
> +		return -EINVAL;
>   
>   	if (percpu_ref_init(&mddev->active_io, active_io_release,
>   			    PERCPU_REF_ALLOW_REINIT, GFP_KERNEL)) {
> @@ -4155,6 +4162,82 @@ new_level_store(struct mddev *mddev, const char *buf, size_t len)
>   static struct md_sysfs_entry md_new_level =
>   __ATTR(new_level, 0664, new_level_show, new_level_store);
>   
> +static ssize_t
> +bitmap_type_show(struct mddev *mddev, char *page)
> +{
> +	struct md_submodule_head *head;
> +	unsigned long i;
> +	ssize_t len = 0;
> +
> +	if (mddev->bitmap_id == ID_BITMAP_NONE)
> +		len += sprintf(page + len, "[none] ");
> +	else
> +		len += sprintf(page + len, "none ");
> +
> +	xa_lock(&md_submodule);
> +	xa_for_each(&md_submodule, i, head) {
> +		if (head->type != MD_BITMAP)
> +			continue;
> +
> +		if (mddev->bitmap_id == head->id)
> +			len += sprintf(page + len, "[%s] ", head->name);
> +		else
> +			len += sprintf(page + len, "%s ", head->name);
> +	}
> +	xa_unlock(&md_submodule);
> +
> +	len += sprintf(page + len, "\n");
> +	return len;
> +}
> +
> +static ssize_t
> +bitmap_type_store(struct mddev *mddev, const char *buf, size_t len)
> +{
> +	struct md_submodule_head *head;
> +	enum md_submodule_id id;
> +	unsigned long i;
> +	int err;
> +
> +	if (mddev->bitmap_ops)
> +		return -EBUSY;
> +
Why isn't this protected by md_submodule lock?
The lock is taken when updating ->bitmap_ops, so I would
have expected it to be taken when checking it ...

> +	err = kstrtoint(buf, 10, &id);
> +	if (!err) {
> +		if (id == ID_BITMAP_NONE) {
> +			mddev->bitmap_id = id;
> +			return len;
> +		}
> +
> +		xa_lock(&md_submodule);
> +		head = xa_load(&md_submodule, id);
> +		xa_unlock(&md_submodule);
> +
> +		if (head && head->type == MD_BITMAP) {
> +			mddev->bitmap_id = id;
> +			return len;
> +		}
> +	}
> +
> +	if (cmd_match(buf, "none")) {
> +		mddev->bitmap_id = ID_BITMAP_NONE;
> +		return len;
> +	}
> +
That is odd coding. The 'if (!err)' condition above might
fall through to here, but then we already now that it cannot
match 'none'.
Please invert the logic, first check for 'none', and only
call kstroint if the match failed.

> +	xa_lock(&md_submodule);
> +	xa_for_each(&md_submodule, i, head) {
> +		if (head->type == MD_BITMAP && cmd_match(buf, head->name)) {
> +			mddev->bitmap_id = head->id;
> +			xa_unlock(&md_submodule);
> +			return len;
> +		}
> +	}
> +	xa_unlock(&md_submodule);
> +	return -ENOENT;
> +}
> +
> +static struct md_sysfs_entry md_bitmap_type =
> +__ATTR(bitmap_type, 0664, bitmap_type_show, bitmap_type_store);
> +
>   static ssize_t
>   layout_show(struct mddev *mddev, char *page)
>   {
> @@ -5719,6 +5802,7 @@ __ATTR(serialize_policy, S_IRUGO | S_IWUSR, serialize_policy_show,
>   static struct attribute *md_default_attrs[] = {
>   	&md_level.attr,
>   	&md_new_level.attr,
> +	&md_bitmap_type.attr,
>   	&md_layout.attr,
>   	&md_raid_disks.attr,
>   	&md_uuid.attr,
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index 13e3f9ce1b79..bf34c0a36551 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -40,6 +40,7 @@ enum md_submodule_id {
>   	ID_CLUSTER,
>   	ID_BITMAP,
>   	ID_LLBITMAP,	/* TODO */
> +	ID_BITMAP_NONE,
>   };
>   
>   struct md_submodule_head {
> @@ -565,6 +566,7 @@ struct mddev {
>   	struct percpu_ref		writes_pending;
>   	int				sync_checkers;	/* # of threads checking writes_pending */
>   
> +	enum md_submodule_id		bitmap_id;
>   	void				*bitmap; /* the bitmap for the device */
>   	struct bitmap_operations	*bitmap_ops;
>   	struct {

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

  parent reply	other threads:[~2025-05-27  6:10 UTC|newest]

Thread overview: 108+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-24  6:12 [PATCH 00/23] md/llbitmap: md/md-llbitmap: introduce a new lockless bitmap Yu Kuai
2025-05-24  6:12 ` [PATCH 01/23] md: add a new parameter 'offset' to md_super_write() Yu Kuai
2025-05-25 15:50   ` Xiao Ni
2025-05-26  6:28   ` Christoph Hellwig
2025-05-26  7:28     ` Yu Kuai
2025-05-27  5:54   ` Hannes Reinecke
2025-05-24  6:12 ` [PATCH 02/23] md: factor out a helper raid_is_456() Yu Kuai
2025-05-25 15:50   ` Xiao Ni
2025-05-26  6:28   ` Christoph Hellwig
2025-05-27  5:55   ` Hannes Reinecke
2025-05-24  6:13 ` [PATCH 03/23] md/md-bitmap: cleanup bitmap_ops->startwrite() Yu Kuai
2025-05-25 15:51   ` Xiao Ni
2025-05-26  6:29   ` Christoph Hellwig
2025-05-27  5:56   ` Hannes Reinecke
2025-05-24  6:13 ` [PATCH 04/23] md/md-bitmap: support discard for bitmap ops Yu Kuai
2025-05-25 15:53   ` Xiao Ni
2025-05-26  6:29   ` Christoph Hellwig
2025-05-27  6:01   ` Hannes Reinecke
2025-05-28  7:04   ` Glass Su
2025-05-24  6:13 ` [PATCH 05/23] md/md-bitmap: remove parameter slot from bitmap_create() Yu Kuai
2025-05-25 16:09   ` Xiao Ni
2025-05-26  6:30   ` Christoph Hellwig
2025-05-27  6:01   ` Hannes Reinecke
2025-05-24  6:13 ` [PATCH 06/23] md/md-bitmap: add a new sysfs api bitmap_type Yu Kuai
2025-05-25 16:32   ` Xiao Ni
2025-05-26  1:13     ` Yu Kuai
2025-05-26  5:11       ` Xiao Ni
2025-05-26  8:02         ` Yu Kuai
2025-05-26  6:32   ` Christoph Hellwig
2025-05-26  7:45     ` Yu Kuai
2025-05-27  8:21       ` Christoph Hellwig
2025-05-27  6:10   ` Hannes Reinecke [this message]
2025-05-27  7:43     ` Yu Kuai
2025-05-24  6:13 ` [PATCH 07/23] md/md-bitmap: delay registration of bitmap_ops until creating bitmap Yu Kuai
2025-05-26  6:32   ` Christoph Hellwig
2025-05-26  6:52   ` Xiao Ni
2025-05-26  7:57     ` Yu Kuai
2025-05-27  2:15       ` Xiao Ni
2025-05-27  2:49         ` Yu Kuai
2025-05-27  6:13   ` Hannes Reinecke
2025-05-27  7:53     ` Yu Kuai
2025-05-27  8:54       ` Hannes Reinecke
2025-05-24  6:13 ` [PATCH 08/23] md/md-bitmap: add a new method skip_sync_blocks() in bitmap_operations Yu Kuai
2025-05-26  7:03   ` Xiao Ni
2025-05-27  6:14   ` Hannes Reinecke
2025-05-24  6:13 ` [PATCH 09/23] md/md-bitmap: add a new method blocks_synced() " Yu Kuai
2025-05-27  2:35   ` Xiao Ni
2025-05-27  2:48     ` Yu Kuai
2025-05-27  6:16   ` Hannes Reinecke
2025-05-24  6:13 ` [PATCH 10/23] md: add a new recovery_flag MD_RECOVERY_LAZY_RECOVER Yu Kuai
2025-05-27  6:17   ` Hannes Reinecke
2025-05-27  8:00     ` Yu Kuai
2025-05-24  6:13 ` [PATCH 11/23] md/md-bitmap: make method bitmap_ops->daemon_work optional Yu Kuai
2025-05-26  6:34   ` Christoph Hellwig
2025-05-27  6:19   ` Hannes Reinecke
2025-05-27  8:03     ` Yu Kuai
2025-05-27  8:55       ` Hannes Reinecke
2025-05-24  6:13 ` [PATCH 12/23] md/md-bitmap: add macros for lockless bitmap Yu Kuai
2025-05-26  6:40   ` Christoph Hellwig
2025-05-26  8:12     ` Yu Kuai
2025-05-27  8:22       ` Christoph Hellwig
2025-05-27  6:21   ` Hannes Reinecke
2025-05-28  4:53   ` Xiao Ni
2025-05-24  6:13 ` [PATCH 13/23] md/md-bitmap: fix dm-raid max_write_behind setting Yu Kuai
2025-05-26  6:40   ` Christoph Hellwig
2025-05-27  6:21   ` Hannes Reinecke
2025-05-24  6:13 ` [PATCH 14/23] md/dm-raid: remove max_write_behind setting limit Yu Kuai
2025-05-26  6:41   ` Christoph Hellwig
2025-05-27  6:26   ` Hannes Reinecke
2025-05-28  4:58   ` Xiao Ni
2025-05-24  6:13 ` [PATCH 15/23] md/md-llbitmap: implement llbitmap IO Yu Kuai
2025-05-27  8:27   ` Christoph Hellwig
2025-05-27  8:55     ` Yu Kuai
2025-05-27  8:58       ` Yu Kuai
2025-06-06  3:21   ` Xiao Ni
2025-06-06  3:48     ` Yu Kuai
2025-06-06  6:24       ` Xiao Ni
2025-06-06  8:56         ` Yu Kuai
2025-06-30  2:07   ` Xiao Ni
2025-06-30  2:17     ` Yu Kuai
2025-05-24  6:13 ` [PATCH 16/23] md/md-llbitmap: implement bit state machine Yu Kuai
2025-06-30  2:14   ` Xiao Ni
2025-06-30  2:25     ` Yu Kuai
2025-06-30  8:25       ` Xiao Ni
2025-06-30 11:05         ` Yu Kuai
2025-06-30 11:30           ` Yu Kuai
2025-07-01  1:55           ` Xiao Ni
2025-07-01  2:02             ` Yu Kuai
2025-07-01  2:31               ` Xiao Ni
2025-05-24  6:13 ` [PATCH 17/23] md/md-llbitmap: implement APIs for page level dirty bits synchronization Yu Kuai
2025-05-24  6:13 ` [PATCH 18/23] md/md-llbitmap: implement APIs to mange bitmap lifetime Yu Kuai
2025-05-29  7:03   ` Xiao Ni
2025-05-29  9:03     ` Yu Kuai
2025-05-24  6:13 ` [PATCH 19/23] md/md-llbitmap: implement APIs to dirty bits and clear bits Yu Kuai
2025-05-24  6:13 ` [PATCH 20/23] md/md-llbitmap: implement APIs for sync_thread Yu Kuai
2025-05-24  6:13 ` [PATCH 21/23] md/md-llbitmap: implement all bitmap operations Yu Kuai
2025-05-24  6:13 ` [PATCH 22/23] md/md-llbitmap: implement sysfs APIs Yu Kuai
2025-05-24  6:13 ` [PATCH 23/23] md/md-llbitmap: add Kconfig Yu Kuai
2025-05-27  8:29   ` Christoph Hellwig
2025-05-27  9:00     ` Yu Kuai
2025-05-24  7:07 ` [PATCH 00/23] md/llbitmap: md/md-llbitmap: introduce a new lockless bitmap Yu Kuai
2025-05-30  6:45 ` Yu Kuai
2025-06-30  1:59 ` Xiao Ni
2025-06-30  2:34   ` Yu Kuai
2025-06-30  3:25     ` Xiao Ni
2025-06-30  3:46       ` Yu Kuai
2025-06-30  5:38         ` Xiao Ni
2025-06-30  6:09           ` Yu Kuai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=23b75e25-fa2f-4d12-8d96-6de01e43ad49@suse.de \
    --to=hare@suse.de \
    --cc=colyli@kernel.org \
    --cc=hch@lst.de \
    --cc=johnny.chenyi@huawei.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=song@kernel.org \
    --cc=xni@redhat.com \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai1@huaweicloud.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).