So why return instead of break ?

Why do this twice ?

And you are trying to remove this macro in other review ? Why do you put incomplete change to review ?

Because that's the end of the fast path for this function. The set_syscall_retval() does the same. It makes actual sense there, since it doesn't need PCB_FULL_IRET, but I've tried to keep two routines as similar as possible.

This one is needed; the ones we do unconditionally are to be removed (eventually). Again, same as with set_syscall_retval().

It is complete - it applies to CURRENT. Otherwise this patch would depend on the other one, otherwise unrelated.

But you still set FULL_IRET, which completely undermines the meaning of the 'fast path'.

I do not see this patch as committable until the 'eventually' part is resolved. set_syscall_retval() does not set FULL_IRET twice.

I do not understand this: you cannot get proper review until one of the patches is resolved.

True. The plan was to keep it as close to set_syscall_retval() as possible, and later just remove the problematic calls to set_pcb_flags(). But you're probably right that the code should fit the current state of things, not the one we'd like to have in the future.

This paragraph does not make much sense in the context of linux_set_syscall_retval.

Isn't this half of the comment relevant to all paths ending in set(FULL_IRET) ? I suggest to move it right above set_pcb_flags() instead of the wishful thinking that is currently at lines 2490250.

True. I've reworded this somewhat; it still gives a useful hint.

Why is this assignment needed ?

It's not; I just didn't quite understood what it did and wanted to be extra safe there. Removed.