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
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 <[email protected]> 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
Steve French <[email protected]> writes:
> 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.
It could be from some implementation details of the pr_ functions that
got fixed...
Cheers,
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)