[release/8.0] [NativeAOT] Missing memory fence before bulk move of objects

[github-actions]

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Per our memory model making objects available to other threads requires that all modifications to the object made prior to publishing are observable by other threads. This is normally guaranteed either by the strong memory ordering (i.e. x64) or via fences in GC barriers (ARM64).
The helper that performs bulk copying of objects is one of the scenarios that needs to ensure the invariant above and thus needs to have a fence on weak memory architectures. The NativeAOT version of the helper is missing the fence.
(similar helper on CoreCLR does have the fence).

The customer impact of the missing fence could be an occasional race or a GC hole on ARM64 in multithreaded apps. The frequency of the problem could depend on how far the memory weakness is exploited and thus hardware-dependent.

It is unclear if we have seen this kind of issues already and how often, since attributing such races to the cause could be challenging.
The issue was found by reviewing the code.

Testing

Regular tests indicate no regressions.

Risk

Very low. The added fence matches the pattern used in CoreCLR for many releases.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jeffschwMSFT]

approved. once you have a code review and green ci we can merge.

[IDisposable]

[VSadov]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

[carlossanlop]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

Yes, unfortunately it's a protection that is causing confusion to a lot of people. If a rebase is not needed (for example, your change does not depend on something already merged), then the button should not be clicked, otherwise it restarts the CI. You can just ask me to merge it for you, I can bypass the protection.

[VSadov]

Makes sense.

I can bypass the protection.

I did not know about that. :-)

Thanks!!

[github-actions]

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Per our memory model making objects available to other threads requires that all modifications to the object made prior to publishing are observable by other threads. This is normally guaranteed either by the strong memory ordering (i.e. x64) or via fences in GC barriers (ARM64).
The helper that performs bulk copying of objects is one of the scenarios that needs to ensure the invariant above and thus needs to have a fence on weak memory architectures. The NativeAOT version of the helper is missing the fence.
(similar helper on CoreCLR does have the fence).

The customer impact of the missing fence could be an occasional race or a GC hole on ARM64 in multithreaded apps. The frequency of the problem could depend on how far the memory weakness is exploited and thus hardware-dependent.

It is unclear if we have seen this kind of issues already and how often, since attributing such races to the cause could be challenging.
The issue was found by reviewing the code.

Testing

Regular tests indicate no regressions.

Risk

Very low. The added fence matches the pattern used in CoreCLR for many releases.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jeffschwMSFT]

approved. once you have a code review and green ci we can merge.

[IDisposable]

[VSadov]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

[carlossanlop]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

Yes, unfortunately it's a protection that is causing confusion to a lot of people. If a rebase is not needed (for example, your change does not depend on something already merged), then the button should not be clicked, otherwise it restarts the CI. You can just ask me to merge it for you, I can bypass the protection.

[VSadov]

Makes sense.

I can bypass the protection.

I did not know about that. :-)

Thanks!!

[github-actions]

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Per our memory model making objects available to other threads requires that all modifications to the object made prior to publishing are observable by other threads. This is normally guaranteed either by the strong memory ordering (i.e. x64) or via fences in GC barriers (ARM64).
The helper that performs bulk copying of objects is one of the scenarios that needs to ensure the invariant above and thus needs to have a fence on weak memory architectures. The NativeAOT version of the helper is missing the fence.
(similar helper on CoreCLR does have the fence).

The customer impact of the missing fence could be an occasional race or a GC hole on ARM64 in multithreaded apps. The frequency of the problem could depend on how far the memory weakness is exploited and thus hardware-dependent.

It is unclear if we have seen this kind of issues already and how often, since attributing such races to the cause could be challenging.
The issue was found by reviewing the code.

Testing

Regular tests indicate no regressions.

Risk

Very low. The added fence matches the pattern used in CoreCLR for many releases.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jeffschwMSFT]

approved. once you have a code review and green ci we can merge.

[IDisposable]

[VSadov]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

[carlossanlop]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

Yes, unfortunately it's a protection that is causing confusion to a lot of people. If a rebase is not needed (for example, your change does not depend on something already merged), then the button should not be clicked, otherwise it restarts the CI. You can just ask me to merge it for you, I can bypass the protection.

[VSadov]

Makes sense.

I can bypass the protection.

I did not know about that. :-)

Thanks!!

[github-actions]

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Per our memory model making objects available to other threads requires that all modifications to the object made prior to publishing are observable by other threads. This is normally guaranteed either by the strong memory ordering (i.e. x64) or via fences in GC barriers (ARM64).
The helper that performs bulk copying of objects is one of the scenarios that needs to ensure the invariant above and thus needs to have a fence on weak memory architectures. The NativeAOT version of the helper is missing the fence.
(similar helper on CoreCLR does have the fence).

The customer impact of the missing fence could be an occasional race or a GC hole on ARM64 in multithreaded apps. The frequency of the problem could depend on how far the memory weakness is exploited and thus hardware-dependent.

It is unclear if we have seen this kind of issues already and how often, since attributing such races to the cause could be challenging.
The issue was found by reviewing the code.

Testing

Regular tests indicate no regressions.

Risk

Very low. The added fence matches the pattern used in CoreCLR for many releases.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jeffschwMSFT]

approved. once you have a code review and green ci we can merge.

[IDisposable]

[VSadov]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

[carlossanlop]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

Yes, unfortunately it's a protection that is causing confusion to a lot of people. If a rebase is not needed (for example, your change does not depend on something already merged), then the button should not be clicked, otherwise it restarts the CI. You can just ask me to merge it for you, I can bypass the protection.

[VSadov]

Makes sense.

I can bypass the protection.

I did not know about that. :-)

Thanks!!

[github-actions]

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Per our memory model making objects available to other threads requires that all modifications to the object made prior to publishing are observable by other threads. This is normally guaranteed either by the strong memory ordering (i.e. x64) or via fences in GC barriers (ARM64).
The helper that performs bulk copying of objects is one of the scenarios that needs to ensure the invariant above and thus needs to have a fence on weak memory architectures. The NativeAOT version of the helper is missing the fence.
(similar helper on CoreCLR does have the fence).

The customer impact of the missing fence could be an occasional race or a GC hole on ARM64 in multithreaded apps. The frequency of the problem could depend on how far the memory weakness is exploited and thus hardware-dependent.

It is unclear if we have seen this kind of issues already and how often, since attributing such races to the cause could be challenging.
The issue was found by reviewing the code.

Testing

Regular tests indicate no regressions.

Risk

Very low. The added fence matches the pattern used in CoreCLR for many releases.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jeffschwMSFT]

approved. once you have a code review and green ci we can merge.

[IDisposable]

[VSadov]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

[carlossanlop]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

Yes, unfortunately it's a protection that is causing confusion to a lot of people. If a rebase is not needed (for example, your change does not depend on something already merged), then the button should not be clicked, otherwise it restarts the CI. You can just ask me to merge it for you, I can bypass the protection.

[VSadov]

Makes sense.

I can bypass the protection.

I did not know about that. :-)

Thanks!!

[github-actions]

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Per our memory model making objects available to other threads requires that all modifications to the object made prior to publishing are observable by other threads. This is normally guaranteed either by the strong memory ordering (i.e. x64) or via fences in GC barriers (ARM64).
The helper that performs bulk copying of objects is one of the scenarios that needs to ensure the invariant above and thus needs to have a fence on weak memory architectures. The NativeAOT version of the helper is missing the fence.
(similar helper on CoreCLR does have the fence).

The customer impact of the missing fence could be an occasional race or a GC hole on ARM64 in multithreaded apps. The frequency of the problem could depend on how far the memory weakness is exploited and thus hardware-dependent.

It is unclear if we have seen this kind of issues already and how often, since attributing such races to the cause could be challenging.
The issue was found by reviewing the code.

Testing

Regular tests indicate no regressions.

Risk

Very low. The added fence matches the pattern used in CoreCLR for many releases.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jeffschwMSFT]

approved. once you have a code review and green ci we can merge.

[IDisposable]

[VSadov]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

[carlossanlop]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

Yes, unfortunately it's a protection that is causing confusion to a lot of people. If a rebase is not needed (for example, your change does not depend on something already merged), then the button should not be clicked, otherwise it restarts the CI. You can just ask me to merge it for you, I can bypass the protection.

[VSadov]

Makes sense.

I can bypass the protection.

I did not know about that. :-)

Thanks!!

[github-actions]

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Per our memory model making objects available to other threads requires that all modifications to the object made prior to publishing are observable by other threads. This is normally guaranteed either by the strong memory ordering (i.e. x64) or via fences in GC barriers (ARM64).
The helper that performs bulk copying of objects is one of the scenarios that needs to ensure the invariant above and thus needs to have a fence on weak memory architectures. The NativeAOT version of the helper is missing the fence.
(similar helper on CoreCLR does have the fence).

The customer impact of the missing fence could be an occasional race or a GC hole on ARM64 in multithreaded apps. The frequency of the problem could depend on how far the memory weakness is exploited and thus hardware-dependent.

It is unclear if we have seen this kind of issues already and how often, since attributing such races to the cause could be challenging.
The issue was found by reviewing the code.

Testing

Regular tests indicate no regressions.

Risk

Very low. The added fence matches the pattern used in CoreCLR for many releases.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jeffschwMSFT]

approved. once you have a code review and green ci we can merge.

[IDisposable]

[VSadov]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

[carlossanlop]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

Yes, unfortunately it's a protection that is causing confusion to a lot of people. If a rebase is not needed (for example, your change does not depend on something already merged), then the button should not be clicked, otherwise it restarts the CI. You can just ask me to merge it for you, I can bypass the protection.

[VSadov]

Makes sense.

I can bypass the protection.

I did not know about that. :-)

Thanks!!

[github-actions]

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Per our memory model making objects available to other threads requires that all modifications to the object made prior to publishing are observable by other threads. This is normally guaranteed either by the strong memory ordering (i.e. x64) or via fences in GC barriers (ARM64).
The helper that performs bulk copying of objects is one of the scenarios that needs to ensure the invariant above and thus needs to have a fence on weak memory architectures. The NativeAOT version of the helper is missing the fence.
(similar helper on CoreCLR does have the fence).

The customer impact of the missing fence could be an occasional race or a GC hole on ARM64 in multithreaded apps. The frequency of the problem could depend on how far the memory weakness is exploited and thus hardware-dependent.

It is unclear if we have seen this kind of issues already and how often, since attributing such races to the cause could be challenging.
The issue was found by reviewing the code.

Testing

Regular tests indicate no regressions.

Risk

Very low. The added fence matches the pattern used in CoreCLR for many releases.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #90890 to release/8.0

/cc @VSadov

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jeffschwMSFT]

approved. once you have a code review and green ci we can merge.

[IDisposable]

[VSadov]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

[carlossanlop]

It asked me to rebase the changes (after all tests have passed). Now it is running tests again.

Yes, unfortunately it's a protection that is causing confusion to a lot of people. If a rebase is not needed (for example, your change does not depend on something already merged), then the button should not be clicked, otherwise it restarts the CI. You can just ask me to merge it for you, I can bypass the protection.

[VSadov]

Makes sense.

I can bypass the protection.

I did not know about that. :-)

Thanks!!