Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix LZ4 endianness autodetection #2264

Closed
wants to merge 1 commit into from
Closed

Conversation

nedbass
Copy link
Contributor

@nedbass nedbass commented Apr 18, 2014

Endianness detection in LZ4 is broken in user-space builds. This
bug corrupts compressed data and manifests itself in several ztest
failures. When LZ4 was originally ported to Illumos ZFS, the proper
checks for Linux were stripped out. The Linux port then inherited
the remaining detection code that works on Illumos but not on Linux.

The current LZ4 endianness check misuses the condition
defined(__BIG_ENDIAN) to indicate a big-endian system. On Linux
__BIG_ENDIAN is defined uncondtionally in the user-space header
/usr/include/endian.h, regardless of the endianness of the system.
The kernel does not use this header, so only user-space builds are
affected.

While we could fix this by restoring the upstream LZ4 endianness
detection code, reliable checks already exist in
libspl/include/sys/isa_defs.h. This change uses the libspl results
to replace the word-size and endianness checks in LZ4, simplifying
the code and reducing duplication.

Fixes #1963
Fixes #1964
Fixes #1965

Signed-off-by: Ned Bass bass6@llnl.gov

Endianness detection in LZ4 is broken in user-space builds.  This
bug corrupts compressed data and manifests itself in several ztest
failures.  When LZ4 was originally ported to Illumos ZFS, the proper
checks for Linux were stripped out. The Linux port then inherited
the remaining detection code that works on Illumos but not on Linux.

The current LZ4 endianness check misuses the condition
defined(__BIG_ENDIAN) to indicate a big-endian system.  On Linux
__BIG_ENDIAN is defined uncondtionally in the user-space header
/usr/include/endian.h, regardless of the endianness of the system.
The kernel does not use this header, so only user-space builds are
affected.

While we could fix this by restoring the upstream LZ4 endianness
detection code, reliable checks already exist in
libspl/include/sys/isa_defs.h. This change uses the libspl results
to replace the word-size and endianness checks in LZ4, simplifying
the code and reducing duplication.

Fixes openzfs#1963
Fixes openzfs#1964
Fixes openzfs#1965

Signed-off-by: Ned Bass <bass6@llnl.gov>
@behlendorf behlendorf added this to the 0.6.3 milestone Apr 18, 2014
@behlendorf behlendorf added the Bug label Apr 18, 2014
@behlendorf
Copy link
Contributor

Thanks Ned this looks like a nice simplification. Early test results look good but I'll let ztest run all weekend just to make sure. This issue neatly explains all three test issues you mentioned in the commit message.

@DeHackEd
Copy link
Contributor

Looks okay to me. I'm running my own modified ztest along with this patch and not getting any problems.

The #undef strikes me as superfluous but that's no big deal.

Signed-off-by: DHE git@dehacked.net

@prakashsurya
Copy link
Member

I ran ztest for 8 hours last night with this patch and saw no failures! Nice!

$ ./cmd/ztest/ztest -V -T $((8*60*60)) -f /var/tmp

@tuxoko
Copy link
Contributor

tuxoko commented Apr 20, 2014

This looks good, but as @DeHackEd said, I don't think #undef is necessary.

@nedbass
Copy link
Contributor Author

nedbass commented Apr 20, 2014

The #undef isn't needed, but I added it as a form of documentation. I want to make it explicit that we're using the defined state of LZ4_BIG_ENDIAN to indicate big-endianess, as opposed to a boolean 0 or 1 value. Especially since it is inconsistent with LZ4_ARCH64 above.

@behlendorf
Copy link
Contributor

Thanks everybody, this has been merged to master.

de39ec1 Fix LZ4 endianness autodetection

@behlendorf behlendorf closed this Apr 21, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants