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