Cleanup suggested by Linux kernel's coccicheck

[ryao]

Motivation and Context

Upon reading an article discussing the PVS Studio's developers most recent analysis of the Linux kernel, I noticed that it spoke well of Linux's "Coccinelle analyzer":

https://pvs-studio.com/en/blog/posts/cpp/0858/

I had not considered Coccinelle to be a static analyzer since its primarily purpose is semantic patching, but it appears that the Linux kernel has adopted it as a QA tool for detecting patterns in the kernel source code that probably merit cleanup:

https://www.kernel.org/doc/html/latest/dev-tools/coccinelle.html

Inspired by that, I tried running it on the OpenZFS kernel modules. Its devm_free.cocci, pci_free_consistent.cocci and of_table.cocci checks caused the spatch tool to crash. However, the rest of the checks worked. It only succeeded in identifying various cleanup opportunities. It tried to find some actual bugs, since it claimed to have caught 3 NULL pointer dereferences, but it was unsuccessful since the reports were false positives. In specific, it reported three NULL pointer dereferences on this:

                        IMPLY(lwb != NULL, 
                            lwb->lwb_state == LWB_STATE_ISSUED ||
                            lwb->lwb_state == LWB_STATE_WRITE_DONE ||
                            lwb->lwb_state == LWB_STATE_FLUSH_DONE);

However, it reported none on this:

IMPLY(lwb != NULL, lwb->lwb_state != LWB_STATE_CLOSED);

Interestingly, it scanned the FreeBSD code in the tree, and reported a few cleanup possibilities in it.

I have addressed most of the reports that it made. The ones that I did not address were:

• 9 suggestions to use swap() - that is not cross platform compatible
• 7 suggestions to use ARRAY_SIZE() - this appears to be cross platform compatible, but I wanted to double check the safety of our ARRAY_SIZE macro in the contexts it identified and was busy with other things.
• 4 suggestions that a NULL check before some freeing functions is not needed. - I am not sure if this is cross platform compatible
• 1 suggestion to use kvfree() in the SPL - this is not compatible with Linux 3.10; we might as well continue doing the equivalent of kvfree() to avoid unnecessary code bloat.
• 5 nonsensical suggestions from ./scripts/coccinelle/api/stream_open.cocci that are likely a bug in either the .cocci file or in spatch.
• 1 suggestion to use MIN() - 2 of these suggestions were taken elsewhere, but not in the zstd code since the headers currently used do not provide MIN(). More details are in the relevant commit message.
• 1 suggestion to use kmem_cache_zalloc() instead of kmem_cache_alloc()+memset() - kmem_cache_zalloc() is non-portable and while we could use a constructor, we might as well just continue using memset() to zero memory since that avoids a pointer indirection.
• 1 suggestion to convert ->i_count in struct inode from atomic_t to refcount_t - this is up to mainline Linux. I would not be surprised if they change this at some point.
• The 3 false positives where it claimed IMPLY had 3 NULL pointer dereferences.

Description

The changes are documented in the patch commit messages.

How Has This Been Tested?

A local build test has been done.

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)
• 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.

[behlendorf]

This cleanup all looks reasonable to me.