[release/8.0-staging] Fix #91958: use mach_timebase_info to determine process time coefficient on macOS by jeffhandley · Pull Request #100122 · dotnet/runtime

jeffhandley · 2024-03-22T06:15:00Z

Backport of #92185 to release/8.0-staging

Customer Impact

Customer reported
Found internally

This has been reported by 2 customers. The first report was in September 2023 by @ForNeVeR in #91958, and they also provided the fix and tests. The issue was reported again by @huntharo in February with #98121. In that issue, @huntharo requested that this fix be backported to 8.0. As @huntharo stated:

On Mac OS X, with Apple Silicon, the System.Diagnostics.Process class returns incorrect (substantially underreported - ms when it should be seconds) CPU usage times for the process (and probably for the thread-level stats too).
I discovered this while writing a function to tune the max # of worker threads in the ThreadPool as it reduces CPU usage from 700% to 120% while increasing throughput for my project (pwrdrvr/lambda-dispatch#109). I was always computing that 0 threads would be needed because CPU usage was only going up by 20 ms per 5 seconds despite using 700% CPU.

Regression

Yes
No

While this isn't a product regression, it's behavior that became incorrect with Apple Silicon.

Testing

@ForNeVeR included a new test with their fix that is part of this backport. The test performs a native call and compares the API's results against the native results. As stated in the original PR:

I have compared the results of the process timing functions to the results of ps on my M2 MacBook device, and they seem to work properly after the changes.
The new tests were properly failing before the change (since we were returning values 42 times lower than the native results), and are, of course, green after the changes.

Risk

Low. This is a targeted fix that only affects PrivilegedProcessorTime, TotalProcessorTime, and UserProcessorTime on macOS. While the fix had been in main since September, a race condition bug in the original fix was found during the review of this backport. That bug was fixed in main on March 25 and cherry-picked to this backport.

The automatic backport of this fix failed due to a merge conflict in src/libraries/Common/src/Interop/OSX/Interop.Libraries.cs. That conflict arose because the preceding line to the change here was removed in 20a3350. Otherwise, the rest of the merge was clean.

…efficient on macOS

…_timebase_info

dotnet-policy-service · 2024-03-22T06:15:23Z

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

adamsitnik

LGTM, thank you for backporting the fix @jeffhandley !

Without this fix, it was possible for another thread to see an incorrect (zero) value of s_timeBase_numer because of a race condition.

jozkee · 2024-04-29T16:08:36Z

@jeffhandley should this be marked as servicing consider now that #100122 (comment) got resolved? If so, do we need to email tactics?

carlossanlop · 2024-04-30T17:12:56Z

@jozkee I didn't find a Tactics email, so assuming this is ready (pending @jeffhandley 's or @adamsitnik 's confirmation), then yes, please send an email to Tactics and add the servicing-consider label.

jeffhandley · 2024-04-30T18:54:21Z

This was approved in email and needs an approval for merge. @jkotas -- you can ignore the re-review request as this can now be merged.

jeffhandley · 2024-03-22T06:15:00Z

Backport of #92185 to release/8.0-staging

Customer Impact

Customer reported
Found internally

This has been reported by 2 customers. The first report was in September 2023 by @ForNeVeR in #91958, and they also provided the fix and tests. The issue was reported again by @huntharo in February with #98121. In that issue, @huntharo requested that this fix be backported to 8.0. As @huntharo stated:

On Mac OS X, with Apple Silicon, the System.Diagnostics.Process class returns incorrect (substantially underreported - ms when it should be seconds) CPU usage times for the process (and probably for the thread-level stats too).
I discovered this while writing a function to tune the max # of worker threads in the ThreadPool as it reduces CPU usage from 700% to 120% while increasing throughput for my project (pwrdrvr/lambda-dispatch#109). I was always computing that 0 threads would be needed because CPU usage was only going up by 20 ms per 5 seconds despite using 700% CPU.

Regression

Yes
No

While this isn't a product regression, it's behavior that became incorrect with Apple Silicon.

Testing

@ForNeVeR included a new test with their fix that is part of this backport. The test performs a native call and compares the API's results against the native results. As stated in the original PR:

I have compared the results of the process timing functions to the results of ps on my M2 MacBook device, and they seem to work properly after the changes.
The new tests were properly failing before the change (since we were returning values 42 times lower than the native results), and are, of course, green after the changes.

Risk

Low. This is a targeted fix that only affects PrivilegedProcessorTime, TotalProcessorTime, and UserProcessorTime on macOS. While the fix had been in main since September, a race condition bug in the original fix was found during the review of this backport. That bug was fixed in main on March 25 and cherry-picked to this backport.

The automatic backport of this fix failed due to a merge conflict in src/libraries/Common/src/Interop/OSX/Interop.Libraries.cs. That conflict arose because the preceding line to the change here was removed in 20a3350. Otherwise, the rest of the merge was clean.

…efficient on macOS

…_timebase_info

dotnet-policy-service · 2024-03-22T06:15:23Z

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

adamsitnik

LGTM, thank you for backporting the fix @jeffhandley !

Without this fix, it was possible for another thread to see an incorrect (zero) value of s_timeBase_numer because of a race condition.

jozkee · 2024-04-29T16:08:36Z

@jeffhandley should this be marked as servicing consider now that #100122 (comment) got resolved? If so, do we need to email tactics?

carlossanlop · 2024-04-30T17:12:56Z

@jozkee I didn't find a Tactics email, so assuming this is ready (pending @jeffhandley 's or @adamsitnik 's confirmation), then yes, please send an email to Tactics and add the servicing-consider label.

jeffhandley · 2024-04-30T18:54:21Z

This was approved in email and needs an approval for merge. @jkotas -- you can ignore the re-review request as this can now be merged.

jeffhandley · 2024-03-22T06:15:00Z

Backport of #92185 to release/8.0-staging

Customer Impact

Customer reported
Found internally

This has been reported by 2 customers. The first report was in September 2023 by @ForNeVeR in #91958, and they also provided the fix and tests. The issue was reported again by @huntharo in February with #98121. In that issue, @huntharo requested that this fix be backported to 8.0. As @huntharo stated:

On Mac OS X, with Apple Silicon, the System.Diagnostics.Process class returns incorrect (substantially underreported - ms when it should be seconds) CPU usage times for the process (and probably for the thread-level stats too).
I discovered this while writing a function to tune the max # of worker threads in the ThreadPool as it reduces CPU usage from 700% to 120% while increasing throughput for my project (pwrdrvr/lambda-dispatch#109). I was always computing that 0 threads would be needed because CPU usage was only going up by 20 ms per 5 seconds despite using 700% CPU.

Regression

Yes
No

While this isn't a product regression, it's behavior that became incorrect with Apple Silicon.

Testing

@ForNeVeR included a new test with their fix that is part of this backport. The test performs a native call and compares the API's results against the native results. As stated in the original PR:

I have compared the results of the process timing functions to the results of ps on my M2 MacBook device, and they seem to work properly after the changes.
The new tests were properly failing before the change (since we were returning values 42 times lower than the native results), and are, of course, green after the changes.

Risk

Low. This is a targeted fix that only affects PrivilegedProcessorTime, TotalProcessorTime, and UserProcessorTime on macOS. While the fix had been in main since September, a race condition bug in the original fix was found during the review of this backport. That bug was fixed in main on March 25 and cherry-picked to this backport.

The automatic backport of this fix failed due to a merge conflict in src/libraries/Common/src/Interop/OSX/Interop.Libraries.cs. That conflict arose because the preceding line to the change here was removed in 20a3350. Otherwise, the rest of the merge was clean.

…efficient on macOS

…_timebase_info

dotnet-policy-service · 2024-03-22T06:15:23Z

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

adamsitnik

LGTM, thank you for backporting the fix @jeffhandley !

Without this fix, it was possible for another thread to see an incorrect (zero) value of s_timeBase_numer because of a race condition.

jozkee · 2024-04-29T16:08:36Z

@jeffhandley should this be marked as servicing consider now that #100122 (comment) got resolved? If so, do we need to email tactics?

carlossanlop · 2024-04-30T17:12:56Z

@jozkee I didn't find a Tactics email, so assuming this is ready (pending @jeffhandley 's or @adamsitnik 's confirmation), then yes, please send an email to Tactics and add the servicing-consider label.

jeffhandley · 2024-04-30T18:54:21Z

This was approved in email and needs an approval for merge. @jkotas -- you can ignore the re-review request as this can now be merged.

jeffhandley · 2024-03-22T06:15:00Z

Backport of #92185 to release/8.0-staging

Customer Impact

Customer reported
Found internally

This has been reported by 2 customers. The first report was in September 2023 by @ForNeVeR in #91958, and they also provided the fix and tests. The issue was reported again by @huntharo in February with #98121. In that issue, @huntharo requested that this fix be backported to 8.0. As @huntharo stated:

On Mac OS X, with Apple Silicon, the System.Diagnostics.Process class returns incorrect (substantially underreported - ms when it should be seconds) CPU usage times for the process (and probably for the thread-level stats too).
I discovered this while writing a function to tune the max # of worker threads in the ThreadPool as it reduces CPU usage from 700% to 120% while increasing throughput for my project (pwrdrvr/lambda-dispatch#109). I was always computing that 0 threads would be needed because CPU usage was only going up by 20 ms per 5 seconds despite using 700% CPU.

Regression

Yes
No

While this isn't a product regression, it's behavior that became incorrect with Apple Silicon.

Testing

@ForNeVeR included a new test with their fix that is part of this backport. The test performs a native call and compares the API's results against the native results. As stated in the original PR:

I have compared the results of the process timing functions to the results of ps on my M2 MacBook device, and they seem to work properly after the changes.
The new tests were properly failing before the change (since we were returning values 42 times lower than the native results), and are, of course, green after the changes.

Risk

Low. This is a targeted fix that only affects PrivilegedProcessorTime, TotalProcessorTime, and UserProcessorTime on macOS. While the fix had been in main since September, a race condition bug in the original fix was found during the review of this backport. That bug was fixed in main on March 25 and cherry-picked to this backport.

The automatic backport of this fix failed due to a merge conflict in src/libraries/Common/src/Interop/OSX/Interop.Libraries.cs. That conflict arose because the preceding line to the change here was removed in 20a3350. Otherwise, the rest of the merge was clean.

…efficient on macOS

…_timebase_info

dotnet-policy-service · 2024-03-22T06:15:23Z

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

adamsitnik

LGTM, thank you for backporting the fix @jeffhandley !

Without this fix, it was possible for another thread to see an incorrect (zero) value of s_timeBase_numer because of a race condition.

jozkee · 2024-04-29T16:08:36Z

@jeffhandley should this be marked as servicing consider now that #100122 (comment) got resolved? If so, do we need to email tactics?

carlossanlop · 2024-04-30T17:12:56Z

@jozkee I didn't find a Tactics email, so assuming this is ready (pending @jeffhandley 's or @adamsitnik 's confirmation), then yes, please send an email to Tactics and add the servicing-consider label.

jeffhandley · 2024-04-30T18:54:21Z

This was approved in email and needs an approval for merge. @jkotas -- you can ignore the re-review request as this can now be merged.

jeffhandley · 2024-03-22T06:15:00Z

Backport of #92185 to release/8.0-staging

Customer Impact

Customer reported
Found internally

This has been reported by 2 customers. The first report was in September 2023 by @ForNeVeR in #91958, and they also provided the fix and tests. The issue was reported again by @huntharo in February with #98121. In that issue, @huntharo requested that this fix be backported to 8.0. As @huntharo stated:

On Mac OS X, with Apple Silicon, the System.Diagnostics.Process class returns incorrect (substantially underreported - ms when it should be seconds) CPU usage times for the process (and probably for the thread-level stats too).
I discovered this while writing a function to tune the max # of worker threads in the ThreadPool as it reduces CPU usage from 700% to 120% while increasing throughput for my project (pwrdrvr/lambda-dispatch#109). I was always computing that 0 threads would be needed because CPU usage was only going up by 20 ms per 5 seconds despite using 700% CPU.

Regression

Yes
No

While this isn't a product regression, it's behavior that became incorrect with Apple Silicon.

Testing

@ForNeVeR included a new test with their fix that is part of this backport. The test performs a native call and compares the API's results against the native results. As stated in the original PR:

I have compared the results of the process timing functions to the results of ps on my M2 MacBook device, and they seem to work properly after the changes.
The new tests were properly failing before the change (since we were returning values 42 times lower than the native results), and are, of course, green after the changes.

Risk

Low. This is a targeted fix that only affects PrivilegedProcessorTime, TotalProcessorTime, and UserProcessorTime on macOS. While the fix had been in main since September, a race condition bug in the original fix was found during the review of this backport. That bug was fixed in main on March 25 and cherry-picked to this backport.

The automatic backport of this fix failed due to a merge conflict in src/libraries/Common/src/Interop/OSX/Interop.Libraries.cs. That conflict arose because the preceding line to the change here was removed in 20a3350. Otherwise, the rest of the merge was clean.

…efficient on macOS

…_timebase_info

dotnet-policy-service · 2024-03-22T06:15:23Z

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

adamsitnik

LGTM, thank you for backporting the fix @jeffhandley !

Without this fix, it was possible for another thread to see an incorrect (zero) value of s_timeBase_numer because of a race condition.

jozkee · 2024-04-29T16:08:36Z

@jeffhandley should this be marked as servicing consider now that #100122 (comment) got resolved? If so, do we need to email tactics?

carlossanlop · 2024-04-30T17:12:56Z

@jozkee I didn't find a Tactics email, so assuming this is ready (pending @jeffhandley 's or @adamsitnik 's confirmation), then yes, please send an email to Tactics and add the servicing-consider label.

jeffhandley · 2024-04-30T18:54:21Z

This was approved in email and needs an approval for merge. @jkotas -- you can ignore the re-review request as this can now be merged.

jeffhandley · 2024-03-22T06:15:00Z

Backport of #92185 to release/8.0-staging

Customer Impact

Customer reported
Found internally

This has been reported by 2 customers. The first report was in September 2023 by @ForNeVeR in #91958, and they also provided the fix and tests. The issue was reported again by @huntharo in February with #98121. In that issue, @huntharo requested that this fix be backported to 8.0. As @huntharo stated:

On Mac OS X, with Apple Silicon, the System.Diagnostics.Process class returns incorrect (substantially underreported - ms when it should be seconds) CPU usage times for the process (and probably for the thread-level stats too).
I discovered this while writing a function to tune the max # of worker threads in the ThreadPool as it reduces CPU usage from 700% to 120% while increasing throughput for my project (pwrdrvr/lambda-dispatch#109). I was always computing that 0 threads would be needed because CPU usage was only going up by 20 ms per 5 seconds despite using 700% CPU.

Regression

Yes
No

While this isn't a product regression, it's behavior that became incorrect with Apple Silicon.

Testing

@ForNeVeR included a new test with their fix that is part of this backport. The test performs a native call and compares the API's results against the native results. As stated in the original PR:

I have compared the results of the process timing functions to the results of ps on my M2 MacBook device, and they seem to work properly after the changes.
The new tests were properly failing before the change (since we were returning values 42 times lower than the native results), and are, of course, green after the changes.

Risk

Low. This is a targeted fix that only affects PrivilegedProcessorTime, TotalProcessorTime, and UserProcessorTime on macOS. While the fix had been in main since September, a race condition bug in the original fix was found during the review of this backport. That bug was fixed in main on March 25 and cherry-picked to this backport.

The automatic backport of this fix failed due to a merge conflict in src/libraries/Common/src/Interop/OSX/Interop.Libraries.cs. That conflict arose because the preceding line to the change here was removed in 20a3350. Otherwise, the rest of the merge was clean.

…efficient on macOS

…_timebase_info

dotnet-policy-service · 2024-03-22T06:15:23Z

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

adamsitnik

LGTM, thank you for backporting the fix @jeffhandley !

Without this fix, it was possible for another thread to see an incorrect (zero) value of s_timeBase_numer because of a race condition.

jozkee · 2024-04-29T16:08:36Z

@jeffhandley should this be marked as servicing consider now that #100122 (comment) got resolved? If so, do we need to email tactics?

carlossanlop · 2024-04-30T17:12:56Z

@jozkee I didn't find a Tactics email, so assuming this is ready (pending @jeffhandley 's or @adamsitnik 's confirmation), then yes, please send an email to Tactics and add the servicing-consider label.

jeffhandley · 2024-04-30T18:54:21Z

This was approved in email and needs an approval for merge. @jkotas -- you can ignore the re-review request as this can now be merged.

jeffhandley · 2024-03-22T06:15:00Z

Backport of #92185 to release/8.0-staging

Customer Impact

Customer reported
Found internally

This has been reported by 2 customers. The first report was in September 2023 by @ForNeVeR in #91958, and they also provided the fix and tests. The issue was reported again by @huntharo in February with #98121. In that issue, @huntharo requested that this fix be backported to 8.0. As @huntharo stated:

On Mac OS X, with Apple Silicon, the System.Diagnostics.Process class returns incorrect (substantially underreported - ms when it should be seconds) CPU usage times for the process (and probably for the thread-level stats too).
I discovered this while writing a function to tune the max # of worker threads in the ThreadPool as it reduces CPU usage from 700% to 120% while increasing throughput for my project (pwrdrvr/lambda-dispatch#109). I was always computing that 0 threads would be needed because CPU usage was only going up by 20 ms per 5 seconds despite using 700% CPU.

Regression

Yes
No

While this isn't a product regression, it's behavior that became incorrect with Apple Silicon.

Testing

@ForNeVeR included a new test with their fix that is part of this backport. The test performs a native call and compares the API's results against the native results. As stated in the original PR:

I have compared the results of the process timing functions to the results of ps on my M2 MacBook device, and they seem to work properly after the changes.
The new tests were properly failing before the change (since we were returning values 42 times lower than the native results), and are, of course, green after the changes.

Risk

Low. This is a targeted fix that only affects PrivilegedProcessorTime, TotalProcessorTime, and UserProcessorTime on macOS. While the fix had been in main since September, a race condition bug in the original fix was found during the review of this backport. That bug was fixed in main on March 25 and cherry-picked to this backport.

The automatic backport of this fix failed due to a merge conflict in src/libraries/Common/src/Interop/OSX/Interop.Libraries.cs. That conflict arose because the preceding line to the change here was removed in 20a3350. Otherwise, the rest of the merge was clean.

…efficient on macOS

…_timebase_info

dotnet-policy-service · 2024-03-22T06:15:23Z

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

adamsitnik

LGTM, thank you for backporting the fix @jeffhandley !

Without this fix, it was possible for another thread to see an incorrect (zero) value of s_timeBase_numer because of a race condition.

jozkee · 2024-04-29T16:08:36Z

@jeffhandley should this be marked as servicing consider now that #100122 (comment) got resolved? If so, do we need to email tactics?

carlossanlop · 2024-04-30T17:12:56Z

@jozkee I didn't find a Tactics email, so assuming this is ready (pending @jeffhandley 's or @adamsitnik 's confirmation), then yes, please send an email to Tactics and add the servicing-consider label.

jeffhandley · 2024-04-30T18:54:21Z

This was approved in email and needs an approval for merge. @jkotas -- you can ignore the re-review request as this can now be merged.

jeffhandley · 2024-03-22T06:15:00Z

Backport of #92185 to release/8.0-staging

Customer Impact

Customer reported
Found internally

This has been reported by 2 customers. The first report was in September 2023 by @ForNeVeR in #91958, and they also provided the fix and tests. The issue was reported again by @huntharo in February with #98121. In that issue, @huntharo requested that this fix be backported to 8.0. As @huntharo stated:

On Mac OS X, with Apple Silicon, the System.Diagnostics.Process class returns incorrect (substantially underreported - ms when it should be seconds) CPU usage times for the process (and probably for the thread-level stats too).
I discovered this while writing a function to tune the max # of worker threads in the ThreadPool as it reduces CPU usage from 700% to 120% while increasing throughput for my project (pwrdrvr/lambda-dispatch#109). I was always computing that 0 threads would be needed because CPU usage was only going up by 20 ms per 5 seconds despite using 700% CPU.

Regression

Yes
No

While this isn't a product regression, it's behavior that became incorrect with Apple Silicon.

Testing

@ForNeVeR included a new test with their fix that is part of this backport. The test performs a native call and compares the API's results against the native results. As stated in the original PR:

I have compared the results of the process timing functions to the results of ps on my M2 MacBook device, and they seem to work properly after the changes.
The new tests were properly failing before the change (since we were returning values 42 times lower than the native results), and are, of course, green after the changes.

Risk

Low. This is a targeted fix that only affects PrivilegedProcessorTime, TotalProcessorTime, and UserProcessorTime on macOS. While the fix had been in main since September, a race condition bug in the original fix was found during the review of this backport. That bug was fixed in main on March 25 and cherry-picked to this backport.

The automatic backport of this fix failed due to a merge conflict in src/libraries/Common/src/Interop/OSX/Interop.Libraries.cs. That conflict arose because the preceding line to the change here was removed in 20a3350. Otherwise, the rest of the merge was clean.

…efficient on macOS

…_timebase_info

dotnet-policy-service · 2024-03-22T06:15:23Z

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

adamsitnik

LGTM, thank you for backporting the fix @jeffhandley !

Without this fix, it was possible for another thread to see an incorrect (zero) value of s_timeBase_numer because of a race condition.

jozkee · 2024-04-29T16:08:36Z

@jeffhandley should this be marked as servicing consider now that #100122 (comment) got resolved? If so, do we need to email tactics?

carlossanlop · 2024-04-30T17:12:56Z

@jozkee I didn't find a Tactics email, so assuming this is ready (pending @jeffhandley 's or @adamsitnik 's confirmation), then yes, please send an email to Tactics and add the servicing-consider label.

jeffhandley · 2024-04-30T18:54:21Z

This was approved in email and needs an approval for merge. @jkotas -- you can ignore the re-review request as this can now be merged.

ForNeVeR added 7 commits March 21, 2024 22:52

Fixdotnet#91958: use mach_timebase_info to determine process time co…
5e07e66
…efficient on macOS

(dotnet#91958) Process.OSX: fallback for non-zero exit code from mach…
ead7ef8
…_timebase_info

(dotnet#91958) Process: move OSX-specific tests to a separate file
eaa1b63

(dotnet#91958) Process.OSX: calculate times lazily
2449f6f

(dotnet#91958) Process: include string resources properly in tests
d7f0abc

(dotnet#91958) Process: more overflow-safe logic
988689b

(dotnet#91958) Minimize diff
73064c3

jeffhandley added Servicing-consider Issue for next servicing release review area-System.Diagnostics.Process os-mac-os-x macOS aka OSX labels Mar 22, 2024

jeffhandley added this to the 8.0.x milestone Mar 22, 2024

jeffhandley requested a review from adamsitnik March 22, 2024 06:15

jeffhandley self-assigned this Mar 22, 2024

adamsitnik approved these changes Mar 22, 2024
View reviewed changes

jkotas reviewed Mar 24, 2024
View reviewed changes

Comment threadsrc/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.OSX.cs Outdated

ForNeVeR mentioned this pull request Mar 25, 2024
Process.OSX: fix thread safety #100260
Merged

jeffhandley removed the Servicing-consider Issue for next servicing release review label Mar 26, 2024

Process.OSX: fix thread safety (dotnet#100260)
a4bf228
Without this fix, it was possible for another thread to see an incorrect (zero) value of s_timeBase_numer because of a race condition.

build-analysisBot mentioned this pull request Mar 26, 2024
riscv64 builds fail with "No usable version of clang found." error #100215
Closed

jozkee added Servicing-consider Issue for next servicing release review and removed Servicing-consider Issue for next servicing release review labels Apr 29, 2024

jeffhandley added the Servicing-consider Issue for next servicing release review label Apr 30, 2024

jeffhandley requested a review from jkotas April 30, 2024 18:51

jeffhandley added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Apr 30, 2024

jeffhandley merged commit 8acc1b5 into dotnet:release/8.0-stagingApr 30, 2024

jeffhandley deleted the jeffhandley/backport-92185/8.0-staging branch April 30, 2024 18:55

github-actionsBot locked and limited conversation to collaborators May 31, 2024