Re: [PATCH v16 01/18] seccomp: Convert __secure_computing() to return boolean
Thomas Gleixner <[email protected]> Fri, 03 Jul 2026 11:48:49 +0200
| Newsgroups | org.kernel.vger.linux-alpha,dev.linux.lists.loongarch,org.infradead.lists.linux-riscv,org.infradead.lists.linux-um,org.kernel.vger.linux-csky,org.kernel.vger.linux-kernel,org.kernel.vger.linux-m68k,org.kernel.vger.linux-mips,org.kernel.vger.linux-parisc,org.kernel.vger.linux-s390,org.kernel.vger.linux-sh,org.kvack.linux-mm,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <87cxx4mmim.ffs@fw13> |
On Fri, Jul 03 2026 at 09:51, Michal Suchánek wrote: > On Mon, Jun 29, 2026 at 09:05:59PM +0800, Jinjie Ruan wrote: >> - 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. > Sashiko points out some places in existing code where it supposedly > explodes which might or might not be true The vsyscall one is correct, but that's a bug like any other one and should be caught in review. The blurb about bypass is AI halluzination nonsense. > but any in-flight patches that use secure_computing would also be > affected. Maintainers know how to deal with collisions of that kind. Stop making problems up.