[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3635951.1763995018@warthog.procyon.org.uk>
Date: Mon, 24 Nov 2025 14:36:58 +0000
From: David Howells <dhowells@...hat.com>
To: Stefan Metzmacher <metze@...ba.org>
Cc: dhowells@...hat.com, Steve French <sfrench@...ba.org>,
Paulo Alcantara <pc@...guebit.org>,
Shyam Prasad N <sprasad@...rosoft.com>, linux-cifs@...r.kernel.org,
netfs@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Tom Talpey <tom@...pey.com>
Subject: Re: [PATCH v4 07/11] cifs: Clean up some places where an extra kvec[] was required for rfc1002
Hi Stefan,
Stefan Metzmacher <metze@...ba.org> wrote:
> I had to squash this into the patch
>
> I'm using smatch when building and got the following error
> with this change:
>
> client/transport.c:1073 compound_send_recv() error: we previously assumed 'resp_iov' could be null (see line 1051)
> ...
> if ((ses->ses_status == SES_NEW) || (optype & CIFS_NEG_OP) || (optype & CIFS_SESS_OP)) {
In this case smatch is wrong, though it can't work this out as the context
spans more than one file. This clause applies only to certain operations
(such as session setup and negotiate) that will always have a response buffer.
But I've no objection to adding this warning to splat the warning.
> > + if (resp_iov) {
>
> Is it really possible that resp_iov is NULL here?
>
> I guess it is for things with CIFS_NO_RSP_BUF, correct?
It probably can't be NULL; even those things that provide CIFS_NO_RSP_BUF seem
to pass a resp_iov, though they tend not to actually initialise it.
Hopefully, this will go away in future and stuff will be attached to the
smb_message struct which will be allocated and passed down from the likes of
smb2pdu.c or cifssmb.c to transport.c.
David
Powered by blists - more mailing lists