Re: [PATCH v2 3/4] arch: copy_thread: pass clone_flags as u64
Paul Walmsley <[email protected]>
| Newsgroups | gmane.linux.ports.alpha,gmane.linux.kernel.mm,gmane.linux.kernel,gmane.linux.ports.riscv,gmane.linux.block,gmane.linux.file-systems,gmane.linux.kernel.cgroups,gmane.linux.kernel.lsm,gmane.linux.network,gmane.linux.kernel.perf.user,gmane.comp.security.apparmor,gmane.linux.kernel.arc,gmane.linux.ports.arm.kernel,gmane.linux.ports.hexagon,gmane.linux.ports.mips,gmane.linux.ports.parisc,gmane.linux.ports.ppc64.devel,gmane.linux.ports.sh.devel,gmane.linux.ports.sparc,gmane.linux.uml.devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 1 Sep 2025, Simon Schuster via B4 Relay wrote: > From: Simon Schuster <[email protected]> > > With the introduction of clone3 in commit 7f192e3cd316 ("fork: add > clone3") the effective bit width of clone_flags on all architectures was > increased from 32-bit to 64-bit, with a new type of u64 for the flags. > However, for most consumers of clone_flags the interface was not > changed from the previous type of unsigned long. > > While this works fine as long as none of the new 64-bit flag bits > (CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP) are evaluated, this is still > undesirable in terms of the principle of least surprise. > > Thus, this commit fixes all relevant interfaces of the copy_thread > function that is called from copy_process to consistently pass > clone_flags as u64, so that no truncation to 32-bit integers occurs on > 32-bit architectures. > > Signed-off-by: Simon Schuster <[email protected]> Acked-by: Paul Walmsley <[email protected]> # for RISC-V Thanks! - Paul