[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH2r5mvCOafQpko19fmSTtEdgG7mp2R1+xto=_fkm7A=fqWq5Q@mail.gmail.com>
Date: Tue, 22 Jun 2021 18:11:06 -0500
From: Steve French <smfrench@...il.com>
To: CIFS <linux-cifs@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: coverity problems with certain macros
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
Powered by blists - more mailing lists