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
next prev parent 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