[PATCH] dcache: use QSTR() instead of QSTR_INIT()

[PATCH] dcache: use QSTR() instead of QSTR_INIT()

[Thorsten Blum]

Drop the hard-coded length arguments and use the simpler QSTR().

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 fs/dcache.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index 2c61aeea41f4..c5536da1634d 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -89,11 +89,11 @@ EXPORT_SYMBOL(rename_lock);
 static struct kmem_cache *__dentry_cache __ro_after_init;
 #define dentry_cache runtime_const_ptr(__dentry_cache)
 
-const struct qstr empty_name = QSTR_INIT("", 0);
+const struct qstr empty_name = QSTR("");
 EXPORT_SYMBOL(empty_name);
-const struct qstr slash_name = QSTR_INIT("/", 1);
+const struct qstr slash_name = QSTR("/");
 EXPORT_SYMBOL(slash_name);
-const struct qstr dotdot_name = QSTR_INIT("..", 2);
+const struct qstr dotdot_name = QSTR("..");
 EXPORT_SYMBOL(dotdot_name);
 
 /*

Re: [PATCH] dcache: use QSTR() instead of QSTR_INIT()

[Jan Kara]

On Wed 22-04-26 14:33:46, Thorsten Blum wrote:
> Drop the hard-coded length arguments and use the simpler QSTR().
> 
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>

Sure. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/dcache.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 2c61aeea41f4..c5536da1634d 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -89,11 +89,11 @@ EXPORT_SYMBOL(rename_lock);
>  static struct kmem_cache *__dentry_cache __ro_after_init;
>  #define dentry_cache runtime_const_ptr(__dentry_cache)
>  
> -const struct qstr empty_name = QSTR_INIT("", 0);
> +const struct qstr empty_name = QSTR("");
>  EXPORT_SYMBOL(empty_name);
> -const struct qstr slash_name = QSTR_INIT("/", 1);
> +const struct qstr slash_name = QSTR("/");
>  EXPORT_SYMBOL(slash_name);
> -const struct qstr dotdot_name = QSTR_INIT("..", 2);
> +const struct qstr dotdot_name = QSTR("..");
>  EXPORT_SYMBOL(dotdot_name);
>  
>  /*
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] dcache: use QSTR() instead of QSTR_INIT()

[Al Viro]

On Wed, Apr 22, 2026 at 02:33:46PM +0200, Thorsten Blum wrote:
> Drop the hard-coded length arguments and use the simpler QSTR().

... which is not a constant expression.  NAK.

QSTR_INIT() is an initializer list for struct qstr; QSTR() is a
compound literal for the same.  IOW, its value is an anonymous
local variable with given contents.

C grammar allows both
	struct foo x = {.bar = y};
and
	struct foo x = (struct foo){.bar = y};
for auto variables, and compiler is able to figure out that they
are equivalent.  But the second form is not legal for the static-duration
variables.

Re: [PATCH] dcache: use QSTR() instead of QSTR_INIT()

[Jan Kara]

On Wed 22-04-26 15:34:37, Al Viro wrote:
> On Wed, Apr 22, 2026 at 02:33:46PM +0200, Thorsten Blum wrote:
> > Drop the hard-coded length arguments and use the simpler QSTR().
> 
> ... which is not a constant expression.  NAK.
> 
> QSTR_INIT() is an initializer list for struct qstr; QSTR() is a
> compound literal for the same.  IOW, its value is an anonymous
> local variable with given contents.
> 
> C grammar allows both
> 	struct foo x = {.bar = y};
> and
> 	struct foo x = (struct foo){.bar = y};
> for auto variables, and compiler is able to figure out that they
> are equivalent.  But the second form is not legal for the static-duration
> variables.

Hum, I understand your reasoning but if it isn't legal, I'd expect the
compiler to complain. Which it doesn't and the generated binary of a sample
test program with both constructs is exactly the same...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] dcache: use QSTR() instead of QSTR_INIT()

[Al Viro]

On Wed, Apr 22, 2026 at 05:04:54PM +0200, Jan Kara wrote:
> On Wed 22-04-26 15:34:37, Al Viro wrote:
> > On Wed, Apr 22, 2026 at 02:33:46PM +0200, Thorsten Blum wrote:
> > > Drop the hard-coded length arguments and use the simpler QSTR().
> > 
> > ... which is not a constant expression.  NAK.
> > 
> > QSTR_INIT() is an initializer list for struct qstr; QSTR() is a
> > compound literal for the same.  IOW, its value is an anonymous
> > local variable with given contents.
> > 
> > C grammar allows both
> > 	struct foo x = {.bar = y};
> > and
> > 	struct foo x = (struct foo){.bar = y};
> > for auto variables, and compiler is able to figure out that they
> > are equivalent.  But the second form is not legal for the static-duration
> > variables.
> 
> Hum, I understand your reasoning but if it isn't legal, I'd expect the
> compiler to complain. Which it doesn't and the generated binary of a sample
> test program with both constructs is exactly the same...

gcc is treating that as an extension, without having clearly documented it.  

Again, compound literal is *not* a fancier way to spell the initializer list;
it's equivalent to having an anonymous local variable with initializer list.
It's an l-value, which quite a few uses of QSTR rely upon (and which the
same patch series misses in several places, keeping useless named locals
for no reason).

It really makes no sense for static storage-duration objects; optimization
I've mentioned above is basically a compiler seeing that
	struct foo anon = <initializer>
	struct foo x = anon;
with no uses of anon anywhere else and figuring out that anon can be eliminated.
Doing something similar for global variables is insane - would you expect

static int __x = 1;
int x = __x;
<no other uses of __x>

to be valid C?  Sure, you can prove that the value of __x will be 1 all along -
no stores to it anywhere, so the value of expression used to initialize x could
be deduced at compile time.  Currently gcc doesn't have that (that's *not*
a suggestion for another extension), but if that changed I'd still recommend
not to make use of such.