From: Li Nan <linan666@huaweicloud.com>
To: Ashok Raj <ashok_raj@linux.intel.com>
Cc: axboe@kernel.dk, dan.j.williams@intel.com,
vishal.l.verma@intel.com, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, yukuai3@huawei.com,
yi.zhang@huawei.com, houtao1@huawei.com, yangerkun@huawei.com,
Ashok Raj <ashok.raj@intel.com>,
linan122@huawei.com
Subject: Re: [PATCH v3 1/4] block/badblocks: change some members of badblocks to bool
Date: Sun, 25 Jun 2023 17:11:35 +0800 [thread overview]
Message-ID: <b49f6f7e-16db-e3e0-188a-7ed848a9d43d@huaweicloud.com> (raw)
In-Reply-To: <ZJMC9rWFRqOTYgVk@araj-dh-work>
在 2023/6/21 22:02, Ashok Raj 写道:
> On Thu, Jun 22, 2023 at 01:20:49AM +0800, linan666@huaweicloud.com wrote:
>> From: Li Nan <linan122@huawei.com>
>>
>> "changed" and "unacked_exist" are used as boolean type. Change the type
>> of them to bool. And reorder fields to reduce memory hole.
>
> minor nit: If you use a .gitorderfile to list .h before .c it will help review them in
> order.
>
I will config my git.
> I don't know if its even worth doing this manual compaction unless you are
> storing the entire struct in some flash or its in a sensitive cache
> thrashing structure.
>
Yeah, it is worthless to manual compaction.
> bool is useful that it makes the code easier to read and can eliminate some
> class of bugs that you would otherwise use !! operator.
>
>>
>> No functional changed intended.
>>
>> Signed-off-by: Li Nan <linan122@huawei.com>
>> ---
>> block/badblocks.c | 14 +++++++-------
>> include/linux/badblocks.h | 10 +++++-----
>> 2 files changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/block/badblocks.c b/block/badblocks.c
>> index 3afb550c0f7b..1b4caa42c5f1 100644
>> --- a/block/badblocks.c
>> +++ b/block/badblocks.c
>> @@ -141,7 +141,7 @@ static void badblocks_update_acked(struct badblocks *bb)
>> }
>>
>> if (!unacked)
>> - bb->unacked_exist = 0;
>> + bb->unacked_exist = false;
>> }
>>
>> /**
>> @@ -302,9 +302,9 @@ int badblocks_set(struct badblocks *bb, sector_t s, int sectors,
>> }
>> }
>>
>> - bb->changed = 1;
>> + bb->changed = true;
>> if (!acknowledged)
>> - bb->unacked_exist = 1;
>> + bb->unacked_exist = true;
>> else
>> badblocks_update_acked(bb);
>> write_sequnlock_irqrestore(&bb->lock, flags);
>> @@ -414,7 +414,7 @@ int badblocks_clear(struct badblocks *bb, sector_t s, int sectors)
>> }
>>
>> badblocks_update_acked(bb);
>> - bb->changed = 1;
>> + bb->changed = true;
>> out:
>> write_sequnlock_irq(&bb->lock);
>> return rv;
>> @@ -435,7 +435,7 @@ void ack_all_badblocks(struct badblocks *bb)
>> return;
>> write_seqlock_irq(&bb->lock);
>>
>> - if (bb->changed == 0 && bb->unacked_exist) {
>> + if (bb->changed == false && bb->unacked_exist) {
>
> if (!bb->changed && bb->unacked_exist)
I will change it in next version.
>
>
>> u64 *p = bb->page;
>> int i;
>>
>> @@ -447,7 +447,7 @@ void ack_all_badblocks(struct badblocks *bb)
>> p[i] = BB_MAKE(start, len, 1);
>> }
>> }
>> - bb->unacked_exist = 0;
>> + bb->unacked_exist = false;
>> }
>> write_sequnlock_irq(&bb->lock);
>> }
>> @@ -493,7 +493,7 @@ ssize_t badblocks_show(struct badblocks *bb, char *page, int unack)
>> length << bb->shift);
>> }
>> if (unack && len == 0)
>> - bb->unacked_exist = 0;
>> + bb->unacked_exist = false;
>>
>> if (read_seqretry(&bb->lock, seq))
>> goto retry;
>> diff --git a/include/linux/badblocks.h b/include/linux/badblocks.h
>> index 2426276b9bd3..c2723f97d22d 100644
>> --- a/include/linux/badblocks.h
>> +++ b/include/linux/badblocks.h
>> @@ -27,15 +27,15 @@
>> struct badblocks {
>> struct device *dev; /* set by devm_init_badblocks */
>> int count; /* count of bad blocks */
>> - int unacked_exist; /* there probably are unacknowledged
>> - * bad blocks. This is only cleared
>> - * when a read discovers none
>> - */
>> int shift; /* shift from sectors to block size
>> * a -ve shift means badblocks are
>> * disabled.*/
>> + bool unacked_exist; /* there probably are unacknowledged
>> + * bad blocks. This is only cleared
>> + * when a read discovers none
>
> read of what?
"... when a read of unacknowledged bad blocks discovers none"
Would this be better?
Thank for your suggestion.
>
>> + */
>> + bool changed;
>> u64 *page; /* badblock list */
>> - int changed;
>> seqlock_t lock;
>> sector_t sector;
>> sector_t size; /* in sectors */
>> --
>> 2.39.2
>>
>
> .
--
Thanks,
Nan
next prev parent reply other threads:[~2023-06-25 9:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-21 17:20 [PATCH v3 0/4] block/badblocks: fix badblocks setting error linan666
2023-06-21 13:32 ` Ashok Raj
2023-06-25 8:13 ` Li Nan
2023-06-21 17:20 ` [PATCH v3 1/4] block/badblocks: change some members of badblocks to bool linan666
2023-06-21 14:02 ` Ashok Raj
2023-06-25 9:11 ` Li Nan [this message]
2023-06-21 17:20 ` [PATCH v3 2/4] block/badblocks: only set bb->changed/unacked_exist when badblocks changes linan666
2023-06-21 17:20 ` [PATCH v3 3/4] block/badblocks: fix badblocks loss when badblocks combine linan666
2023-06-21 14:09 ` Ashok Raj
2023-06-25 9:16 ` Li Nan
2023-06-21 17:20 ` [PATCH v3 4/4] block/badblocks: fix the bug of reverse order linan666
2023-06-21 14:15 ` Ashok Raj
2023-06-25 9:22 ` Li Nan
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=b49f6f7e-16db-e3e0-188a-7ed848a9d43d@huaweicloud.com \
--to=linan666@huaweicloud.com \
--cc=ashok.raj@intel.com \
--cc=ashok_raj@linux.intel.com \
--cc=axboe@kernel.dk \
--cc=dan.j.williams@intel.com \
--cc=houtao1@huawei.com \
--cc=linan122@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.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).