-
Notifications
You must be signed in to change notification settings - Fork 70
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
Fixed coverity issue in acl_kernel_if.cpp #226
Fixed coverity issue in acl_kernel_if.cpp #226
Conversation
The function Investigating the intent behind the discarded read in more detail. |
After some investigation, I found the following:
|
Hi @haoxian2 , I think it's
Kindly let me know if you have more questions of this function. |
98691ac
to
1a7705a
Compare
After a bit of digging, I concluded that Since the subsequent read/write already checks whether or not the previous |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Hao for fixing this. I need a bit more time to review this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@haoxian2 , I reviewed the very first swarm change that introduced the following two lines. It mainly intended to add the kern->cur_segment = segment;
, the rest of two occurrences were just copied from this code.
kern->cur_segment = segment;
acl_kernel_if_read_32b(kern, OFFSET_KERNEL_CRA_SEGMENT,
(unsigned int *)&segment);
I agree with you analysis that the acl_kernel_if_read_32b
can be deleted. The read is going into the local segment
variable which is not propagated to anywhere.
In case we miss anything, can you please rebase your branch to the latest runtime codebase and open a PR against acl repo to do the integration testing?
Thanks,
Zibai
…endianness (INCOMPATIBLE_CAST) In the three instances where this issue happens, the function acl_kernel_if_read_32b is used at the end of the scope to query about what's inside the acl_kernel_if* kern object. However, they don't do anything with the obtained information. I believe this read operation is performed to confirm that the acl_kernel_if* kern has been written properly. So if the read operation successed, then the write operation must have also succeeded as well. The functions employing acl_kernel_if_read_32b are used to return the segment offset. This segment offset is then used to perform another read/write, which return status would then be used for error checking. Therefore, the `acl_kernel_if_read_32b` function is redundant and can be removed from the aformentioned 3 instances.
1a7705a
to
acc86b9
Compare
@haoxian2 , thanks! |
Continuation of discussion featured in #220.
Fixed coverity issue in acl_kernel_if.cpp: Type: Reliance on integer endianness (INCOMPATIBLE_CAST)
In the three instances where this issue happens, the function acl_kernel_if_read_32b is used at the end of the scope to query about what's inside the acl_kernel_if* kern object. However, they don't do anything with the obtained information. I believe this read operation is performed to confirm that the acl_kernel_if* kern has been written properly. So if the read operation successed, then the write operation must have also succeeded as well. The functions employing acl_kernel_if_read_32b are used to return the segment offset. This segment offset is then used to perform another read/write, which return status would then be used for error checking. Therefore, the
acl_kernel_if_read_32b
function is redundant and can be removed from the aformentioned 3 instances.