Use the shorter variants will improves further maintainability. 
Convenient for subsequent code updates or refactoring.

In addition, there are some places in the code where variables
are simply named 'i', which can be confused with count variables
in loops and have low readability. Perhaps I can help gradually
standardize variable naming in the future.

Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
---
 fs/bcachefs/async_objs.c  | 2 +-
 fs/bcachefs/btree_cache.c | 2 +-
 fs/bcachefs/debug.c       | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/bcachefs/async_objs.c b/fs/bcachefs/async_objs.c
index a7cd1f0f0964..9fa09ac3f583 100644
--- a/fs/bcachefs/async_objs.c
+++ b/fs/bcachefs/async_objs.c
@@ -45,7 +45,7 @@ static int bch2_async_obj_list_open(struct inode *inode, struct file *file)
 	struct async_obj_list *list = inode->i_private;
 	struct dump_iter *i;
 
-	i = kzalloc(sizeof(struct dump_iter), GFP_KERNEL);
+	i = kzalloc(sizeof(*i), GFP_KERNEL);
 	if (!i)
 		return -ENOMEM;
 
diff --git a/fs/bcachefs/btree_cache.c b/fs/bcachefs/btree_cache.c
index 83c9860e6b82..d04ddf3072c1 100644
--- a/fs/bcachefs/btree_cache.c
+++ b/fs/bcachefs/btree_cache.c
@@ -173,7 +173,7 @@ static struct btree *__btree_node_mem_alloc(struct bch_fs *c, gfp_t gfp)
 {
 	struct btree *b;
 
-	b = kzalloc(sizeof(struct btree), gfp);
+	b = kzalloc(sizeof(*b), gfp);
 	if (!b)
 		return NULL;
 
diff --git a/fs/bcachefs/debug.c b/fs/bcachefs/debug.c
index 07c2a0f73cc2..b056a37dbba4 100644
--- a/fs/bcachefs/debug.c
+++ b/fs/bcachefs/debug.c
@@ -335,7 +335,7 @@ static int bch2_dump_open(struct inode *inode, struct file *file)
 	struct btree_debug *bd = inode->i_private;
 	struct dump_iter *i;
 
-	i = kzalloc(sizeof(struct dump_iter), GFP_KERNEL);
+	i = kzalloc(sizeof(*i), GFP_KERNEL);
 	if (!i)
 		return -ENOMEM;
 
@@ -721,7 +721,7 @@ static int btree_transaction_stats_open(struct inode *inode, struct file *file)
 	struct bch_fs *c = inode->i_private;
 	struct dump_iter *i;
 
-	i = kzalloc(sizeof(struct dump_iter), GFP_KERNEL);
+	i = kzalloc(sizeof(*i), GFP_KERNEL);
 	if (!i)
 		return -ENOMEM;
 
-- 
2.34.1

> Use the shorter variants will improves further maintainability. 
> Convenient for subsequent code updates or refactoring.

Please improve such a change description.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.16#n45
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.16#n941

Regards,
Markus

On Thu, Jul 31, 2025 at 08:52:44PM +0200, Markus Elfring wrote:
> > Use the shorter variants will improves further maintainability. 
> > Convenient for subsequent code updates or refactoring.
> 
> Please improve such a change description.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.16#n45
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.16#n941

The commit message is reasonable, it communicates the intent.

I haven't decided if I want to apply it; the dereference approach is
better in principle but it's very far off into the weeds of "things that
will never, ever cause an actual problem".

>>> Use the shorter variants will improves further maintainability. 
>>> Convenient for subsequent code updates or refactoring.
>>
>> Please improve such a change description.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.16#n45
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.16#n941
> 
> The commit message is reasonable, it communicates the intent.

* I would wonder about the relevance of a shorter item here.

* Would you like to avoid wording weaknesses?


Another example for previous contributions:
https://lore.kernel.org/all/?q=%22Improve%20size%20determinations%22


> I haven't decided if I want to apply it; the dereference approach is
> better in principle but it's very far off into the weeds of "things that
> will never, ever cause an actual problem".

Have you got development views which might be in contradiction
to the preferred Linux coding style?

Regards,
Markus

On Thu, Jul 31, 2025 at 10:00:31PM +0200, Markus Elfring wrote:
> >>> Use the shorter variants will improves further maintainability. 
> >>> Convenient for subsequent code updates or refactoring.
> >>
> >> Please improve such a change description.
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.16#n45
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.16#n941
> > 
> > The commit message is reasonable, it communicates the intent.
> 
> * I would wonder about the relevance of a shorter item here.
> 
> * Would you like to avoid wording weaknesses?
> 
> 
> Another example for previous contributions:
> https://lore.kernel.org/all/?q=%22Improve%20size%20determinations%22
> 
> 
> > I haven't decided if I want to apply it; the dereference approach is
> > better in principle but it's very far off into the weeds of "things that
> > will never, ever cause an actual problem".
> 
> Have you got development views which might be in contradiction
> to the preferred Linux coding style?

Marcus, I believe you've been warned in other subsystems, by other
maintainers - you need to cut this out. I decide what's acceptable for
patches to bcachefs, not you :)