CI: Add smatch static analysis workflow

[behlendorf]

Motivation and Context

As discussed in #17885 we want to enforce certain cstyle guidelines and catch bugs early in the development process. Adding the smatch code checker to the CI can help with both of these things. This PR automates running the analysis but it will take a concerted effort to resolve all the warnings.

Description

Smatch is an actively maintained kernel-aware static analyzer for C with a low false positive rate. Since the code checker can be run relatively quickly against the entire OpenZFS code base (15 min) it makes sense to add it as a GitHub Actions workflow. Today smatch reports a significant numbers warnings so the workflow is configured to always pass as long as the analysis was run. The results are available for reference. Long term it would ideal to resolve all of the errors/warnings at which point the workflow can be updated to fail when new problems are detected.

How Has This Been Tested?

Lightly tested here, https://github.com/behlendorf/zfs/actions/runs/19380431337

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[tsoome]

Do you have sample output from smatch too?

[AttilaFueloep]

I'd a look at the ICP smatch errors. They're all about uninitialized symbols and caused by the fact that smatch doesn't know about __builtin_unreachable. Haven't done research on how to teach smatch that __builtin_unreachable denotes unreachable code yet. Maybe someone else knows how to handle this.

@tsoome I picked them up below the second Make entry here.

[tsoome]

I'd a look at the ICP smatch errors. They're all about uninitialized symbols and caused by the fact that smatch doesn't know about __builtin_unreachable. Haven't done research on how to teach smatch that __builtin_unreachable denotes unreachable code yet. Maybe someone else knows how to handle this.

@tsoome I picked them up below the second Make entry here.

I see. I think, this is good point to check with Dan Carpenter :)

[behlendorf]

I added a "Smatch results log" section. It simply greps out of the build log any errors or warning.

I can't see any real downside to adding this workflow, so I'm going to pull it in so folks can use it as a starting point and refine as needed to get something we're happy with.

[tsoome]

thanks!