On Wed, 9 Jul 2025 09:58:26 +0200 Jens Remus <jremus@xxxxxxxxxxxxx> wrote: > I think Mathieu has a point, as unwind_user_next() calls the optional > architecture-specific arch_unwind_user_next() at the end. The x86 > implementation does state->type specific processing (for > UNWIND_USER_TYPE_COMPAT_FP). I'm not too comfortable with the compat patches at this stage. I'm thinking of separating out the compat patches, and just reject the deferred unwind if the task is in compat mode (forcing perf or other tracers to use whatever it uses today). I'll take Mathieu's patches and merge them with Josh's, but make them a separate series. I'm aiming to get the core series into this merge window, and the less complexity we have, the better. Then everything can be worked on simultaneously in the next merge window as all the other patches will not have any dependency on each other. They all have dependency on the core set. -- Steve
