Compiling a kernel with -Werror fails due to "may be uninitialized" warnings

[steev]

fs/zfs/zfs/zfs_znode.c: In function ‘zfs_obj_to_path_impl’:
fs/zfs/zfs/zfs_znode.c:1757:9: error: ‘pobj’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
fs/zfs/zfs/zfs_znode.c:1738:6: error: ‘is_xattrdir’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

The Chromebook kernel has an option to make all warnings errors by default, and due to this, if you patch it with ZFS support, due to the warnings above, the compile will error out.

The GCC version used is 4.7.3, and this was specifically on an ARM device, but all Chromebook configs will show the same issue.

You can test this via something like:

(on Gentoo)

git clone http://chromium.googlesource.com/chromiumos/third_party/kernel -b chromeos-3.4
cd kernel
./chromeos/scripts/prepareconfig chromeos-exynos5
make prepare scripts
<patch zfs/spl>
make

[behlendorf]

We've been ruthless about squashing warnings so it's a bit surprising to see these pop up now. Regardless, they're legit and for some reason only flagged on ARM. Can you verify that the properly initializing them resolves the issue.

diff --git a/module/zfs/zfs_znode.c b/module/zfs/zfs_znode.c
index aaf17e1..fae32ad 100644
--- a/module/zfs/zfs_znode.c
+++ b/module/zfs/zfs_znode.c
@@ -1716,10 +1716,10 @@ zfs_obj_to_path_impl(objset_t *osp, uint64_t obj, sa_handle_t *hdl,
        sa_hdl = hdl;

        for (;;) {
-               uint64_t pobj;
+               uint64_t pobj = 0;
                char component[MAXNAMELEN + 2];
                size_t complen;
-               int is_xattrdir;
+               int is_xattrdir = 0;

                if (prevdb)
                        zfs_release_sa_handle(prevhdl, prevdb, FTAG);

[steev]

Yes that fixes the warnings. Compile completes without issue.

[chrisrd]

@behlendorf commented: We've been ruthless about squashing warnings so it's a bit surprising to see these pop up now.

Perhaps worth a new ticket to have goal of becoming clang (and other code analysers) clean?

http://thread.gmane.org/gmane.linux.file-systems.zfs.user/1503

[behlendorf]

I'm all for it. It would be ideal to open a generic issue for clang and then a separate issue for each issue it detects.

[chrisrd]

Done: #1721