Ship It!

All of my findings: some of them unrelated to c-style.

Unnecessary blank line.

"Never use the boolean negation operator (!) with non-boolean expressions."

Should be:
        if (memcmp(name, pairname, namelen) == 0 && type == pairtype) {

This if...else ladder can be rewritten as a switch...case statement, but is it worth doing?

Example:
            switch (type) {
            case DATA_TYPE_UINT64:
                xdr_uint64_t(&p, (uint64_t *)valuep);
                return (0);
                break;
            case DATA_TYPE_STRING: {
                int len;

                xdr_int(&p, &len);
                (*(const char **)valuep) = (const char *)p;
                return (0);
                break;
            }
            case DATA_TYPE_NVLIST:
            case DATA_TYPE_NVLIST_ARRAY:
                (*(const unsigned char **)valuep) =
                    (const unsigned char *)p;
                return (0);
                break;
            default:
                return (EIO);
                break;
            }

Déjà vu...

Type of found variable should be bool.

Instead of casting, format constant can be used here.
            printf(" = 0x%" PRIx64 "\n", val);

Format string - argument type mismatch: type of j variable is unsigned int.

"Never use the boolean negation operator (!) with non-boolean expressions."

0 vs NULL.

This line should be:
    return (NULL);

Yet another "malloc + memset => calloc" issue?

Type of is_new variable (and also the is_newer argument) should be bool.

switch instead of if...else ladder?

0 vs NULL.

0 vs NULL.

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."
Example:
#include <sys/tem_impl.h>
.
.
.
    char line[TEM_DEFAULT_COLS];

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

Optional, drop this if you think it isn't important:
    buf[0] = '\0';

"A blank line should always be used ... After local variable declarations."

Type of first variable should be bool.

is_newer should be bool.

How about using format constans here instead of casting?

Instead of casting, format constant can be used here.

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."
Example:
#define ZFS_SECSIZE 512
.
.
.
    size = dnode->dn_datablkszsec * ZFS_SECSIZE;

"A blank line should always be used ... After local variable declarations."

Unusual to see variable declarations almost in the middle of a function.

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

    size = dnode->dn_datablkszsec * ZFS_SECSIZE;

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

Example:
#define ZAP_LE_NAME_BUFSIZE 256
.
.
.
        char name[ZAP_LE_NAME_BUFSIZE], *p;

Is it necessary to preserve this commented-out tracing code?
And if it is, how about creating a macro for this purpose?

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

    size_t size = dnode->dn_datablkszsec * ZFS_SECSIZE;

Is it safe to expect that only two types of ZAP can exist?
See the implementation of zap_lookup() in this file.
Also: Lustre feature ideas - ZFS TinyZAP.

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

    size = dnode->dn_datablkszsec * ZFS_SECSIZE;

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

    size_t size = dnode->dn_datablkszsec * ZFS_SECSIZE;

Is it safe to expect that only two types of ZAP can exist?

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

Instead of casting, format constant can be used here.

Possible buffer overrun: component array can hold up to 256 bytes, but zap_rlookup can write into it at most 65535 bytes.

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

Instead of casting, format constant can be used here.

Instead of casting, format constant can be used here.

Instead of casting, format constant can be used here.

Instead of casting, format constant can be used here.

Instead of casting, format constant can be used here.

Instead of casting, format constant can be used here.

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

        child_dir_zap.dn_datablkszsec * ZFS_SECSIZE);

Is it safe to expect that only two types of ZAP can exist?

Instead of casting, format constant can be used here.

Instead of casting, format constant can be used here.

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

    size = dir.dn_datablkszsec * ZFS_SECSIZE);

Is it safe to expect that only two types of ZAP can exist?

"If one arm of an if-else statement contains braces, all arms should contain braces."

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."

"Numerical constants should not be coded directly.

The #define feature of the C preprocessor should

be used to assign a meaningful name."
Example:
#define BOOT_MAXLINK    10
.
.
.
            if (symlinks_followed > BOOT_MAXLINK) {

Note this one is integrated but I keep it visible for list of issues:)