On Wed, 2024-08-21 at 13:45 +0100, Mark Brown wrote: > On Wed, Aug 21, 2024 at 01:45:16AM +0000, Edgecombe, Rick P wrote: > > On Wed, 2024-08-21 at 01:19 +0100, Mark Brown wrote: > > > > I think it's going to be strange one way or another, either you specify > > > a size that we don't currently really use or you have two things both > > > called stacks which are described differently. > > > I would guess users of raw clone3 calls would be able to handle that kind of > > variation. > > Oh, I'm sure people could cope either way - it's more a question of > clarity and not causing people go do needless investigations to try to > figure out what's going on than anything else. Yes, it won't be a disaster either way. > > > I was just trying to figure out why there is both the pointer and size for > > normal stacks. It seems that one usage is that you don't have to worry about > > whether your arch's stack grows up or down. But otherwise, the previous > > clone's > > didn't need the size. Before clone3 the stack size users seem to be kernel > > threads, so when they unified the infrastructure behind kernel_clone_args, > > stack_size was needed for the struct. Could it be that it just leaked to > > userspace for that reason? I don't know, but I would think a tweak to such a > > fundamental syscall should have some purposeful design behind it. > > It's entirely possible it just leaked. My own attempts to dig through > the archives haven't turned up anything on the subjecti either, it seems > to have been there from the get go and just gone in without comment. > Equally it could just be that people felt that this was a more tasteful > way of specifying stacks, or that some future use was envisioned. Ok, well I'm suspicious, but won't object over it. The rest seems settled from my side. I may try to attract some other x86 attention to that CMPXCHG helper, but otherwise. > > > > I suppose we could call > > > a single parameter shadow_stack_pointer? Though I do note that as you > > > indicated we've been going for some time and this is the first time it > > > came up... > > > Sorry for that. I looked through all the old threads expecting to find > > discussion, but couldn't find an answer. Is clone3 support a dependency for > > arm > > shadow stacks? > > Catalin didn't want to merge the arm64 support without clone3(), and > there's code dependencies as a result. I could unpick it and reverse > the ordering so long as the arm64 maintainers are OK with that since the > overlap is in the implementation of copy_thread() and some of the > dependency patches.
