Also interesting that it appears to show up only in the "linux"
coverity report not the "linux-next" coverity report which have
similar code there.
On Tue, Jun 22, 2021 at 6:11 PM Steve French <smfrench@xxxxxxxxx> wrote:
>
> 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
--
Thanks,
Steve
