On Fri, Jul 03, 2026 at 11:48:49AM +0200, Thomas Gleixner wrote:

On Fri, Jul 03 2026 at 09:51, Michal Suchánek wrote:

quoted

On Mon, Jun 29, 2026 at 09:05:59PM +0800, Jinjie Ruan wrote:

quoted

-	if (secure_computing())
+	if (!secure_computing())
 		return -1;

Hello,

I am not fond of this logic inversion. The boolean is meaningless in
itself.

Previously -1 was used to indicate that the syscall was filtered but you
chose to invert the logic choosing true to mean syscall was not filtered.

You could choose true to mean that syscall was fitered avoiding this
inversion.

That's just wrong. Boolean logic makes more sense with having
(!condition()). Just because the old 0/-1 nonsense had it the other way
round does not mean it has to stay that way.

100% agreed!

Bikeshedding below; sorry.

I think the bigger problem is just that secure_computing() is a terrible
name that does not express the intended semantic -- it's not clear
whether "secure computing" means "seccomp permit the syscall" or
"seccomp is enabled and some special rules now apply" or something else
entirely.

If we're changing the return type, it might be worth renaming the
function something like:

	seccomp_permits_syscall()

... so for the code quoted at the start of the mail, we'd have:

	if (!seccomp_permits_syscall())
		return -1;

... or for arm64, where we have NO_SYSCALL:

	 if (!seccomp_permits_syscall())
	 	return NO_SYSCALL.

Thomas, any thoughts on that?

It's also odd that seccomp aquires the syscall number itself via , rather
than than being passed down explicitly by the arch code. That completely
obscures what seccomp is doing, vs having:

	if (!seccomp_permis_syscall(syscall))
		...

... but I guess that saves some duplication in the ptrace code.

Mark.