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

blkid: Explicitly use C int variable for numParts #930

Merged
merged 1 commit into from
Mar 4, 2020

Conversation

Prashanth684
Copy link
Contributor

This was an issue I encountered while testing partition creation on s390x, where the
number of partitions returned by numParts was a bogus number. At first I thought it was
an endianness issue with blkid, but turned out that the C compiler's int variable size and
the Go compiler's int variable sizes are different (on s390x at least) which caused this bug.

The fix is to make numParts a C int variable to be consistent with what is returned by blkid

This was an issue I encountered while testing partition creation on s390x, where the
number of partitions returned by numParts was a bogus number. At first I thought it was
an endianness issue with blkid, but turned out that the C compiler's int variable size and
the Go compiler's int variable sizes are different (on s390x at least) which caused this bug.

The fix is to make numParts a C int variable to be consistent with what is returned by blkid
@coreosbot
Copy link
Contributor

Can one of the admins verify this patch?

Copy link
Member

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. It must be that Go is 64 bits, C is 32 - and that's AFAIK true across all of our 64 bit architectures. Probably the reason this wasn't failing elsewhere is endianness.

@Prashanth684
Copy link
Contributor Author

LGTM. It must be that Go is 64 bits, C is 32 - and that's AFAIK true across all of our 64 bit architectures. Probably the reason this wasn't failing elsewhere is endianness.

yes...that must be it..i don't see this anywhere else

@ashcrow
Copy link
Member

ashcrow commented Mar 4, 2020

/lgtm

@ashcrow ashcrow merged commit c48bcf9 into coreos:master Mar 4, 2020
Prashanth684 added a commit to Prashanth684/coreos-assembler that referenced this pull request Mar 4, 2020
…tions test

As with mounting disks, the same change is needed for mounting partitions for s390x. A little
delay in pushing this because of this issue in ignition: coreos/ignition#930
which is now fixed
openshift-merge-robot pushed a commit to coreos/coreos-assembler that referenced this pull request Mar 5, 2020
…tions test

As with mounting disks, the same change is needed for mounting partitions for s390x. A little
delay in pushing this because of this issue in ignition: coreos/ignition#930
which is now fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants