[Bugs] [Bug 1714851] New: issues with 'list.h' elements in clang-scan

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1714851

            Bug ID: 1714851
           Summary: issues with 'list.h' elements in clang-scan
           Product: GlusterFS
           Version: mainline
            Status: NEW
         Component: core
          Severity: low
          Priority: low
          Assignee: bugs at gluster.org
          Reporter: atumball at redhat.com
                CC: bugs at gluster.org
  Target Milestone: ---
    Classification: Community



Description of problem:

Visit : https://build.gluster.org/job/clang-scan (and
https://build.gluster.org/job/clang-scan/lastCompletedBuild/clangScanBuildBugs/
if the link still has the bugs listed). There are quite a few of issues listed,
which seems to be false-positive, and are 'list' related.

Shyam's points:

Posting an older context from when I was looking at certain list related clang
scan issues (see below).

There is a class of clang scan related issues where using certain list macros
that are not empty list safe is present in the code. I am going to assume this
maybe one of those cases, if not please ignore this comment.

<snip>

Clang bug type: Result of operation is garbage or undefined
Where: glusterfs/api/src/glfs-fops.c    glfs_recall_lease_fd    5208
Other instances (there are more but not analyzed)
glusterfs/xlators/features/locks/src/clear.c    clrlk_clear_inodelk     257
glusterfs/xlators/features/locks/src/clear.c    clrlk_clear_entrylk     360
glusterfs/xlators/features/locks/src/entrylk.c  pl_entrylk_client_cleanup
1075
glusterfs/xlators/features/locks/src/inodelk.c  pl_inodelk_client_cleanup      
694

Reason: list_for_each_entry_safe is not "Empty list" safe

The places where this is caught is when we use uninitialized stack
variables (for the most part), but in reality the pattern is incorrect
and needs correction.

We need to take a few actions here:
- Review the list macro usage across the code
- Update the list.h to a more later version from the kernel sources?
  - Later kernel sources call out the unsafe nature of the same
    - list_first_entry:
https://github.com/torvalds/linux/blob/cd6c84d8f0cdc911df435bb075ba22ce3c605b07/include/linux/list.h#L473-L476
      - Calls out "Note, that list is expected to be not empty"
    - list_first_entry Called from list_for_each_entry_safe:
https://github.com/torvalds/linux/blob/cd6c84d8f0cdc911df435bb075ba22ce3c605b07/include/linux/list.h#L649-L654
      - Thus making it also needing to adhere to "Note, that list is expected
to be not empty"

</snip>

Version-Release number of selected component (if applicable):


---
Need to think and handle it in a right way.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.