Skip to content

Fall back to alternative membarrier command on aarch64 to support older kernels.#4987

Closed
cfallin wants to merge 1 commit into
bytecodealliance:mainfrom
cfallin:aarch64-membarrier-cmd-shared
Closed

Fall back to alternative membarrier command on aarch64 to support older kernels.#4987
cfallin wants to merge 1 commit into
bytecodealliance:mainfrom
cfallin:aarch64-membarrier-cmd-shared

Conversation

@cfallin
Copy link
Copy Markdown
Member

@cfallin cfallin commented Sep 30, 2022

This is an attempt to fix #4972 by adding a fallback syscall that older kernels should support. The fallback is invoked only if the more specific membarrier fails.

rustix::process::MembarrierCommand::RegisterPrivateExpeditedSyncCore,
)
// Fallback for older kernels that don't support the above command.
.or_else(|_| rustix::process::membarrier(rustix::process::MembarrierCommand::Global))
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RegisterPrivateExpeditedSyncCore registers intent to use PrivateExpeditedSyncCore later on in the publish method. Global should be used in publish and doesn't have an associated register command.

rustix::process::MembarrierCommand::RegisterPrivateExpeditedSyncCore,
)
// Fallback for older kernels that don't support the above command.
.or_else(|_| rustix::process::membarrier(rustix::process::MembarrierCommand::Global))
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change should be applied to line 171 instead, and I think that here you can just use unwrap_or_default().

Since the EXPEDITED commands have additional overhead (according to the documentation), the process must opt in explicitly to use them via the corresponding REGISTER command (e.g. MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE); the call here is precisely that registration.

BTW in hindsight when I implemented this initially, adding this call here was probably not the best idea because the registration should happen only once for the whole lifetime of the process (instead of whenever a CodeMemory object is created, though subsequent registrations are harmless); perhaps the moment of the Engine creation is a better time? Of course, that assumes that no one is going to use a CodeMemory object without creating an Engine first.

Copy link
Copy Markdown
Contributor

@akirilov-arm akirilov-arm Sep 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ninja'd by @bjorn3 😃.

P.S. There is another option that I have come up with in #4997 - just run MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE. If it fails with an EPERM error, execute MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE and retry. If it fails with EINVAL instead, fall back to MEMBARRIER_CMD_GLOBAL/MEMBARRIER_CMD_SHARED. In all other cases fail.

@cfallin
Copy link
Copy Markdown
Member Author

cfallin commented Oct 4, 2022

Subsumed by @afonso360 's work in #4997 before I could get back to this -- thanks :-)

@cfallin cfallin closed this Oct 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unable to load modules on aarch64 linux machine via a rust based host app

3 participants