Re: [GIT PULL] smb3 client fixes

From: Linus Torvalds

Date: Mon Apr 13 2026 - 20:32:52 EST


On Mon, 13 Apr 2026 at 15:06, Steve French <smfrench@xxxxxxxxx> wrote:
>
> git://git.samba.org/sfrench/cifs-2.6.git tags/v7.1-rc1-part1-smb3-client-fixes

I've pulled this, but then looking at the dcache changes I noted the
big forest of BUG_ON() which really isn't valid. Error handling is a
thing - BUG_ON() is *not* error handling.

And then looking at verifying the length of the name - one of the
things checked for in that forest of BUG_ON() calls - the call site is
an unreadable mess.

You have this:

size_t size = CIFS_TMPNAME_LEN + 1;

fifty lines earlier, and then you do

d_mark_tmpfile_name(file, &QSTR_LEN(name, size - 1));

which is not just illegible, it's also illogical. That "size" is just
voodoo. The string is generated by

scnprintf(name, size,
CIFS_TMPNAME_PREFIX "%0*x",
CIFS_TMPNAME_COUNTER_LEN,
atomic_inc_return(&cifs_tmpcounter));

which uses several other magic #define's, and yes, I'm sure it all
adds up to CIFS_TMPNAME_LEN in the end, but this is basically all just
line noise.

PLEASE write this legibly instead, and make that new dentry helper
actually do error handling, not BUG_ON().

Because this kind of mess is simply not acceptable.

I don't even understand why you use a variable for an insane constant.
The code *could* have done something like this:

namelen = scnprintf(name, size,
CIFS_TMPNAME_PREFIX "%0*x",
CIFS_TMPNAME_COUNTER_LEN,
atomic_inc_return(&cifs_tmpcounter));

and it would all have actually made sense. But stating the final size
like that really doesn't - not without at least a big comment on how
those random things are interrelated.

So this is in my tree now, but I expect it to be cleaned up and made sensible.

Linus