[go] runtime: fix bitmap marking to exclude ASAN redzone
Gerrit Bot (Gerrit)
Gerrit Bot has uploaded the change for review![]( "Open in Gerrit")
Commit message
runtime: fix bitmap marking to exclude ASAN redzone
When ASAN is enabled, a redzone is appended to allocation size by the compiler-rt.
This causes dataSize to be larger than the actual user data size, which affects
bitmap calculation when the redzone size is comparable to or larger than typ.Size_.
To fix this, use actualSize() to subtract the redzone size before computing the
bitmap mask and scanSize, ensuring only the actual user data region is reflected
in the bitmap.
Fixes #80136
Change diff
diff --git a/src/runtime/malloc.go b/src/runtime/malloc.go
index 8c5ec38..b62b56c 100644
--- a/src/runtime/malloc.go
+++ b/src/runtime/malloc.go
@@ -2483,3 +2483,29 @@
return 16 << 7
}
}
+
+// actualSize computes the user allocation size from the total size including redzone.
+// Refer to the implementation of the compiler-rt.
+func actualSize(allocSize uintptr) uintptr {
+ if !asanenabled{
+ return allocSize
+ }
+ switch {
+ case allocSize > (1<<16) - 1024 + 16<<6:
+ return allocSize - 16<<7
+ case allocSize > (1<<15) - 512 + 16<<5:
+ return allocSize - 16<<6
+ case allocSize > (1<<14) - 256 + 16<<4:
+ return allocSize - 16<<5
+ case allocSize > 4096 - 128 + 16<<3:
+ return allocSize - 16<<4
+ case allocSize > 512 - 64 + 16<<2:
+ return allocSize - 16<<3
+ case allocSize > 128 - 32 + 16<<1:
+ return allocSize - 16<<2
+ case allocSize > 64 - 16 + 16<<0:
+ return allocSize - 16<<1
+ default:
+ return allocSize - 16<<0
+ }
+}
diff --git a/src/runtime/mbitmap.go b/src/runtime/mbitmap.go
index 7c05cd6..ac1ab9d 100644
--- a/src/runtime/mbitmap.go
+++ b/src/runtime/mbitmap.go
@@ -625,6 +625,12 @@
// The objects here are always really small, so a single load is sufficient.
src0 := readUintptr(getGCMask(typ))
+ // When ASAN is enabled, a redzone is appended to the data, and the redzone would affect
+ // bitmap calculation by being incorrectly marked as pointers.
+ srcDataSize := dataSize
+ if asanenabled {
+ dataSize = actualSize(srcDataSize)
+ }
// Create repetitions of the bitmap if we have a small slice backing store.
src := src0
if typ.Size_ == goarch.PtrSize {
@@ -635,7 +641,7 @@
// N.B. We rely on dataSize being an exact multiple of the type size.
// The alternative is to be defensive and mask out src to the length
// of dataSize. The purpose is to save on one additional masking operation.
- if doubleCheckHeapSetType && !asanenabled && dataSize%typ.Size_ != 0 {
+ if doubleCheckHeapSetType && dataSize%typ.Size_ != 0 {
throw("runtime: (*mspan).writeHeapBitsSmall: dataSize is not a multiple of typ.Size_")
}
scanSize = typ.PtrBytes
@@ -643,13 +649,11 @@
src |= src0 << (i / goarch.PtrSize)
scanSize += typ.Size_
}
- if asanenabled {
- // Mask src down to dataSize. dataSize is going to be a strange size because of
- // the redzone required for allocations when asan is enabled.
- src &= (1 << (dataSize / goarch.PtrSize)) - 1
- }
}
+ if asanenabled {
+ scanSize += srcDataSize - dataSize
+ }
// Since we're never writing more than one uintptr's worth of bits, we're either going
// to do one or two writes.
dstBase, _ := spanHeapBitsRange(span.base(), pageSize, span.elemsize)
@@ -810,6 +814,9 @@
maxIterBytes := span.elemsize
if header == nil {
maxIterBytes = dataSize
+ if asanenabled {
+ maxIterBytes = actualSize(dataSize)
+ }
}
off := alignUp(uintptr(cheaprand())%dataSize, goarch.PtrSize)
size := dataSize - off
@@ -836,6 +843,9 @@
maxIterBytes := span.elemsize
if header == nil {
maxIterBytes = dataSize
+ if asanenabled {
+ maxIterBytes = actualSize(dataSize)
+ }
}
bad := false
for i := uintptr(0); i < maxIterBytes; i += goarch.PtrSize {
Change information
- M src/runtime/malloc.go
- M src/runtime/mbitmap.go
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gopher Robot (Gerrit)
Gopher Robot added 1 comment![]( "Open in Gerrit")
I spotted some possible problems with your PR:
1. You have a long 83 character line in the commit message body. Please add line breaks to long lines that should be wrapped. Lines in the commit message body should be wrapped at ~76 characters unless needed for things like URLs or tables. (Note: GitHub might render long lines as soft-wrapped, so double-check in the Gerrit commit message shown above.)
Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
- [how to update commit messages](https://go.dev/wiki/GerritBot/#how-does-gerritbot-determine-the-final-commit-message) for PRs imported into Gerrit.
- the Go project's [conventions for commit messages](https://go.dev/doc/contribute#commit_messages) that you should follow.
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
Related details
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
秦龙 (Gerrit)
秦龙 voted and added 2 comments![]( "Open in Gerrit")
Votes added by 秦龙
| Code-Review | +1 |
2 comments
I spotted some possible problems with your PR:
1. You have a long 83 character line in the commit message body. Please add line breaks to long lines that should be wrapped. Lines in the commit message body should be wrapped at ~76 characters unless needed for things like URLs or tables. (Note: GitHub might render long lines as soft-wrapped, so double-check in the Gerrit commit message shown above.)Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
- [how to update commit messages](https://go.dev/wiki/GerritBot/#how-does-gerritbot-determine-the-final-commit-message) for PRs imported into Gerrit.
- the Go project's [conventions for commit messages](https://go.dev/doc/contribute#commit_messages) that you should follow.
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
Done
done
Related details
- Ian Lance Taylor
- Keith Randall
- Michael Pratt
Code-Review
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |