lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 2 Feb 2023 16:14:15 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Mike Christie <michael.christie@...cle.com> Cc: hch@...radead.org, stefanha@...hat.com, jasowang@...hat.com, mst@...hat.com, sgarzare@...hat.com, virtualization@...ts.linux-foundation.org, brauner@...nel.org, ebiederm@...ssion.com, konrad.wilk@...cle.com, linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de> Subject: Re: [PATCH v11 1/8] fork: Make IO worker options flag based On Thu, Feb 2, 2023 at 3:25 PM Mike Christie <michael.christie@...cle.com> wrote: > > struct kernel_clone_args { > u64 flags; > + u32 worker_flags; > int __user *pidfd; > int __user *child_tid; > int __user *parent_tid; Minor nit: please put this next to "exit_signal". As it is, you've put a new 32-bit field in between two 64-bit fields and are generating extra pointless padding. We have that padding by "exit_signal" already, so let's just use it. Also, I like moving those flags to a "flags" field, but can we please make it consistent? We have that "args->kthread" field too, which is 100% analogous to args->io_thread. So don't make a bit field for io_thread, and then not do the same for kthread. Finally, why isn't this all just a bitfield - every single case would seem to prefer something like if (args->user_worker) .. instead of if (args->worker_flags & USER_WORKER) which would seem to make everything simpler still? Linus
Powered by blists - more mailing lists