Re: coverity problems with certain macros

[Steve French]

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