Re: Prevent inconsistent CPU state after sequence of dlclose/dlopen

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 10/01/25 12:55, Mathieu Desnoyers wrote:
> Hi,
> 
> I was discussing with Mark Rutland recently, and he pointed out that a
> sequence of dlclose/dlopen mapping new code at the same addresses in
> multithreaded environments is an issue on ARM, and possibly on Intel/AMD
> with the newer TLB broadcast maintenance.
> 
> I maintain the membarrier(2) system call, which provides a
> MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE command for this
> purpose. It's been there since Linux 4.16. It can be configured
> out (CONFIG_MEMBARRIER=n), but it's enabled by default.
> 
> Calling this after dlclose() in glibc would prevent this issue.
> 
> Is it handled in some other way, or should we open a bugzilla
> entry to track this ?

Yes please, it would be helpful if you can add some information on 
what kind of hardware and kernel version this is an issue.  

Also, could you add some detail of the issue and why kernel itself does
not or can not guarantee memory consistent after the mmap call?

Is is because this would be an extra non-required overhead on
mmap that userland should handle?