From: Mike Rapoport > Sent: 07 March 2022 18:57 ... > > The sigframe thing, OTOH, seems genuinely useful if CRIU would actually use > > it to save the full register state. Generating a signal frame from scratch > > is a pain. That being said, if CRIU isn't excited, then don't bother. > > CRIU is excited :) > > I just was looking for the minimal possible interface that will allow us to > call sigreturn. Rick is right and CRIU does try to expose as little as > possible and handle the pain in the userspace. > > The SIGFRAME approach is indeed very helpful, especially if we can make it > work on other architectures eventually. I thought the full sigframe layout depends very much on what the kernel decides it needs to save? Some parts are exposed to the signal handler, but there are large blocks of data that XSAVE (etc) save that have to be put onto the signal stack. Is it even vaguely feasible to replicate what a specific kernel generates on specific hardware in a userspace library? The size of this data is getting bigger and bigger - causing issues with the SIGALTSTACK (and even thread stack) minimum sizes. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
