Page MenuHomeFreeBSD

kern: don't make pointer/int casting fatal
Needs ReviewPublic

Authored by imp on Wed, Apr 15, 2:39 PM.
Tags
None
Referenced Files
F152940862: D56409.id175570.diff
Sat, Apr 18, 5:25 AM
F152940795: D56409.id175570.diff
Sat, Apr 18, 5:25 AM
F152901859: D56409.diff
Fri, Apr 17, 10:05 PM
Unknown Object (File)
Fri, Apr 17, 10:31 AM
Unknown Object (File)
Fri, Apr 17, 3:14 AM
Subscribers
None

Details

Reviewers
jhb
Summary

gcc seems to warn too much, so don't make it an error.

Sponsored by: Netflix

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 72225
Build 69108: arc lint + arc unit

Event Timeline

imp requested review of this revision.Wed, Apr 15, 2:39 PM
imp created this revision.

CHERI is about to break all these anyway. What actual errors are you seeing with the kernel now? When I get armv7 building for GCC we probably want to fix all these properly anyway? So far I'm still trying to get armv7 world building so haven't even looked at the kernel.

In D56409#1291371, @jhb wrote:

CHERI is about to break all these anyway. What actual errors are you seeing with the kernel now? When I get armv7 building for GCC we probably want to fix all these properly anyway? So far I'm still trying to get armv7 world building so haven't even looked at the kernel.

Bogus complaints in the iflib code that masks off the lower bits of the pointer using: (struct mbuf *)((uintptr_t)m & mask). for pointer-to-int and I forget for the int-to-pointer. It's totally fine. Of course, marking the pointer this way to avoid a de-reference before invalidating / finishing the transaction seems like too much of a micro-optimization to be worth it.

I don't understand how the (struct mbuf *)((uintptr_t)m & mask)) would trigger this? The warnings I had in stand/ with EFI were all legit "casting uint64_t to pointer" or vice versa without a uintptr_t cast, and I fixed those by adding a uintptr_t cast. Presumably the result of the inner expression should be of type uintptr_t and not int? Of course, I'd rewrite those today to use __align_down, then you can do something like: __align_down(m, (~mask + 1)) (but probably the latter is easily to-hand as a constant, e.g. __align_down(m, 16) or the like) without needing any casts (align_down and align_up are type preserving).