[PATCH] D120073: [LLD] Fix for race condition.
Fangrui Song via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 17 10:40:32 PST 2022
MaskRay added a comment.
In D120073#3330269 <https://reviews.llvm.org/D120073#3330269>, @ayermolo wrote:
> In D120073#3330235 <https://reviews.llvm.org/D120073#3330235>, @MaskRay wrote:
>
>> This will harm performance. If only `elf::getErrorPlace` is problematic, we can add a mutex there.
>>
>>> There is a potential race condition when getErrPlace is invoked in multithreaded context
>>
>> How?
>
> Well problem fundamentally in uncompress. It already has a mutex. Which tells to me there was some thought that was put into making it multi threading safe, but check is not complete, as it doesn't handle uncompressedSize/rawData pointer.
> As for how. Eh... There is some internal code I inherited that exposes this issue, and zlib error hid the real error of relocation overflow.
If it's your internal code and not upstream code, I feel uneasy to make the change since it will hurt performance.
If your internal code needs to call `data()` on one input section concurrently, consider adding a separate pass (undo D52917 <https://reviews.llvm.org/D52917>) uncompressing section contents upfront?
For an upstreamable patch, there are many directions:
- just undo D52917 <https://reviews.llvm.org/D52917> (if the original performance claim can be mitigated via other means)
- figure out whether `isec->data()` for uncompressed buffers in getErrorPlace can be avoided
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D120073/new/
https://reviews.llvm.org/D120073
More information about the llvm-commits
mailing list