public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Yu Kuai <yukuai1@huaweicloud.com>,
	axboe@kernel.dk, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, yukuai3@huawei.com,
	yi.zhang@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH v3 2/3] block: introduce new field bd_flags in block_device
Date: Wed, 22 Nov 2023 16:19:40 +0800	[thread overview]
Message-ID: <ZV25nGGMYQuyclK6@fedora> (raw)
In-Reply-To: <ZV2zbTPTZ0qC2F1U@infradead.org>

On Tue, Nov 21, 2023 at 11:53:17PM -0800, Christoph Hellwig wrote:
> On Wed, Nov 22, 2023 at 03:45:24PM +0800, Ming Lei wrote:
> > All the existed 'bool' flags are not atomic RW, so I think it isn't
> > necessary to define 'bd_flags' as 'unsigned long' for replacing them.
> 
> So because the old code wasn't correct we'll never bother?  The new
> flag and the new placement certainly make this more critical as well.

Can you explain why the old code was wrong?

1) ->bd_read_only and ->bd_make_it_fail

- set from userspace interface(ioctl or sysfs)
- check in IO code path

so changing it into atomic bit doesn't make difference from user
viewpoint.

2) ->bd_write_holder

disk->open_mutex is held for read & write this flag

3) ->bd_has_submit_bio

This flag is setup as oneshot before adding disk, and check in FS io code
path.

Of course, defining it as 'unsigned long' can extend its future usage, but
it depends on the atomic requirement of each flag itself.


Thanks, 
Ming


  reply	other threads:[~2023-11-22  8:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22 10:31 [PATCH v3 0/3] block: warn once for each partition in bio_check_ro() Yu Kuai
2023-11-22 10:31 ` [PATCH v3 1/3] block: move .bd_inode into 1st cacheline of block_device Yu Kuai
2023-11-22  7:23   ` Christoph Hellwig
2023-11-22 11:17   ` Yu Kuai
2023-11-22 10:31 ` [PATCH v3 2/3] block: introduce new field bd_flags in block_device Yu Kuai
2023-11-22  3:30   ` Ming Lei
2023-11-22  6:15     ` Yu Kuai
2023-11-22  3:52   ` Michael Kelley
2023-11-22  7:06     ` Yu Kuai
2023-11-22  7:28   ` Christoph Hellwig
2023-11-22  7:45     ` Ming Lei
2023-11-22  7:53       ` Christoph Hellwig
2023-11-22  8:19         ` Ming Lei [this message]
2023-11-22 12:47           ` Christoph Hellwig
2023-11-23  2:19             ` Ming Lei
2023-11-22 10:31 ` [PATCH v3 3/3] block: warn once for each partition in bio_check_ro() 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=ZV25nGGMYQuyclK6@fedora \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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