On Tue, Oct 03, 2023 at 09:45:56AM +0100, Szabolcs Nagy wrote: > clone3 seems to have features that are only available in clone3 and > not exposed (reasonably) in libc apis so ppl will use clone3 directly > and those will be hard to fix for gcs (you have to convince upstream > to add future arm64 arch specific changes that they cannot test). Ah, I hadn't realised that there were things that weren't available via libc - that does change the calculation a bit here. I would hope that anything we do for clone3() would work just as well for x86 so the test side should be a bit easier there than if it were a future arm64 thing, though obviously it wouldn't be mandatory on x86 in the way that Catalin wanted it for arm64. > where this analysis might be wrong is that raw clone3 is more likely > used as fork/vfork without a new stack and thus no gcs issue. > even if we have time to fix code, we don't want too many ifdef hacks > just for gcs so it matters how many projects are affected. My impression was that raw usage of the APIs was a specialist enough thing that this was viable, ICBW though - I might not have been searching well enough (clone is an annoying term to search for!).
Attachment:
signature.asc
Description: PGP signature
