Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Steve French <smfrench@gmail.com>
Date:   Tue, 22 Jun 2021 18:11:06 -0500
Message-ID: <CAH2r5mvCOafQpko19fmSTtEdgG7mp2R1+xto=_fkm7A=fqWq5Q@mail.gmail.com>
Subject: coverity problems with certain macros
To:     CIFS <linux-cifs@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Looks like coverity's scan of the Linux kernel has problems with
analyzing locks across some debug print macros (which ironically don't
use any locks related to this component)

e.g. Coverity Linux issues: 1484748, 1484736, 1475751, 1475743 and 1475726

as an example it flags the section of code below, and others with
calls to "cifs_dbf(VFS, ...) " in them (and note that the debug macros
don't take a lock) starting with the cifs_dbg(VFS, ...) call.  It
says:

"May result in deadlock if there is another attempt to acquire the lock.
In find_cifs_entry: Missing a release of a lock on a path"

Oddly it doesn't flag "cifs_dbg(FYI, ...") calls, and even more
strangely the calls they flag are simply wrappers around calls to
"pr_err__ ## ratefunc ..."

See below snippet from fs/cifs/readdir.c e.g.

                        cifs_dbg(VFS, "reached end of buf searching
for pos in buf %d index to find %lld rc %d\n",
                                 pos_in_buf, index_to_find, rc);
                }
                rc = 0;
                *current_entry = cur_ent;
        } else {
                cifs_dbg(FYI, "index not in buffer - could not
findnext into it\n");
                return 0;
        }

        if (pos_in_buf >= cfile->srch_inf.entries_in_buffer) {
                cifs_dbg(FYI, "can not return entries pos_in_buf
beyond last\n");
                *num_to_ret = 0;
        } else
                *num_to_ret = cfile->srch_inf.entries_in_buffer - pos_in_buf;

        return rc;
}

-- 
Thanks,

Steve