Thomas, On Mon, Jul 20, 2026 at 9:21 PM Thomas Gleixner <[email protected]> wrote: > > > Similar to what Peter and me suggested in the related discussion > vs. s390 which has a similar issue, you can just have a dedicated > syscall_return member in your pt_regs struct, which is preset to -ENOSYS > and operate on that. You have an unused padding entry there which means > it won't even change the size. >
Thanks, that makes sense in principle. One complication is that my Alpha GENERIC_ENTRY branch already reuses that former pt_regs padding slot, while keeping the pt_regs size and stack alignment unchanged. The extra syscall-entry bookkeeping I needed so far lives in thread_info rather than adding more fields to pt_regs. So the padding slot is not free in my current branch. I can still look at whether a dedicated syscall_return scratch value would be cleaner, but the tested version currently handles this by setting the default -ENOSYS result only on the no-dispatch path, after generic entry processing, and only if ptrace/seccomp/BPF did not already provide a return value. > > You were on CC for the V2, no? > Sorry, I must have missed that. > The whole pile including Jinjie's seccomp bypass fix is in > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/entry > > and is targeted for the 7.3 merge window. > Great! > If you want to base your stuff on that for 7.3, I can add a tag which > makes it immutable so it can be pulled into the alpha tree. > Yes, please. There is still some ongoing testing/review of my Alpha GENERIC_ENTRY series, but assuming it is ready in time for the 7.3 merge window, an immutable tag would be very helpful. Magnus
