On Tue, Oct 29, 2019 at 04:20:37PM +0100, Jann Horn wrote:

On Tue, Oct 29, 2019 at 3:26 PM Christian Brauner
[off-list ref] wrote:

quoted

On Tue, Oct 29, 2019 at 12:27:07PM +0100, Christian Brauner wrote:

quoted

On Mon, Oct 28, 2019 at 08:09:13PM +0100, Jann Horn wrote:

quoted

On Mon, Oct 28, 2019 at 6:21 PM Christian Brauner
[off-list ref] wrote:

quoted

where stack + stack_size is addition on a void pointer which usually
clang and gcc are not very happy about.
I wanted to bring this up on the mailing list soon: If possible, I don't
want userspace to need to know about stack direction and just have stack
point to the beginning and then have the kernel do the + stack_size
after the copy_clone_args_from_user() if the arch needs it. For example,
by having a dumb helder similar to copy_thread_tls()/coyp_thread() that
either does the + stack_size or not. Right now, clone3() is supported on
parisc and afaict, the stack grows upwards for it. I'm not sure if there
are obvious reasons why that won't work or it would be a bad idea...

That would mean adding a new clone flag that redefines how those
parameters work and describing the current behavior in the manpage as
the behavior without the flag (which doesn't exist on 5.3), right?

I would break API and if someone reports breakage we'll revert and go
the more complicated route you outlined (see [1]).

@Jann, I think the following patch might even be enough?...

[...]

quoted

+static inline void clone3_prepare_stack(struct kernel_clone_args *kargs)
+{
+#if !defined(CONFIG_STACK_GROWSUP) && !defined(CONFIG_IA64)
+       kargs->stack += kargs->stack_size;
+#endif
+}

I guess it might work as long as nobody is actually using clone3 yet
and you can get this patch into the 5.3 stable tree and any distro
kernels on 5.3 before people do start using clone3?

Yes, that would be my preferred approach. As I said doing it this way is
pretty common. A recent example where we did this is the file_max
sysctl.

Christian