* [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
@ 2019-09-10 11:57 Eugene Syromiatnikov
2019-09-10 12:20 ` Dmitry V. Levin
2019-09-10 12:44 ` Oleg Nesterov
0 siblings, 2 replies; 10+ messages in thread
From: Eugene Syromiatnikov @ 2019-09-10 11:57 UTC (permalink / raw)
To: linux-kernel, Christian Brauner
Cc: Andrew Morton, Peter Zijlstra (Intel),
Ingo Molnar, Dmitry V. Levin, Eric Biederman, Oleg Nesterov
Previously, higher 32 bits of exit_signal fields were lost when
copied to the kernel args structure (that uses int as a type for the
respective field). Fail with EINVAL if these are set as it looks like
there's no sane reason to accept them.
* kernel/fork.c (copy_clone_args_from_user): Fail with -EINVAL if
args.exit_signal converted to unsigned int is not equal to the original
value.
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
---
kernel/fork.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index 2852d0e..fcbc4d5 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2562,6 +2562,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
if (copy_from_user(&args, uargs, size))
return -EFAULT;
+ if (unlikely(((unsigned int)args.exit_signal) != args.exit_signal))
+ return -EINVAL;
+
*kargs = (struct kernel_clone_args){
.flags = args.flags,
.pidfd = u64_to_user_ptr(args.pidfd),
--
2.1.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
2019-09-10 11:57 [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal Eugene Syromiatnikov
@ 2019-09-10 12:20 ` Dmitry V. Levin
2019-09-10 12:44 ` Oleg Nesterov
1 sibling, 0 replies; 10+ messages in thread
From: Dmitry V. Levin @ 2019-09-10 12:20 UTC (permalink / raw)
To: Eugene Syromiatnikov, Christian Brauner
Cc: linux-kernel, Andrew Morton, Peter Zijlstra (Intel),
Ingo Molnar, Eric Biederman, Oleg Nesterov
On Tue, Sep 10, 2019 at 12:57:11PM +0100, Eugene Syromiatnikov wrote:
> Previously, higher 32 bits of exit_signal fields were lost when
> copied to the kernel args structure (that uses int as a type for the
> respective field). Fail with EINVAL if these are set as it looks like
> there's no sane reason to accept them.
>
> * kernel/fork.c (copy_clone_args_from_user): Fail with -EINVAL if
> args.exit_signal converted to unsigned int is not equal to the original
> value.
>
> Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
Reviewed-by: Dmitry V. Levin <ldv@altlinux.org>
--
ldv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
2019-09-10 11:57 [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal Eugene Syromiatnikov
2019-09-10 12:20 ` Dmitry V. Levin
@ 2019-09-10 12:44 ` Oleg Nesterov
2019-09-10 13:09 ` Christian Brauner
1 sibling, 1 reply; 10+ messages in thread
From: Oleg Nesterov @ 2019-09-10 12:44 UTC (permalink / raw)
To: Eugene Syromiatnikov
Cc: linux-kernel, Christian Brauner, Andrew Morton,
Peter Zijlstra (Intel),
Ingo Molnar, Dmitry V. Levin, Eric Biederman
On 09/10, Eugene Syromiatnikov wrote:
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2562,6 +2562,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> if (copy_from_user(&args, uargs, size))
> return -EFAULT;
>
> + if (unlikely(((unsigned int)args.exit_signal) != args.exit_signal))
> + return -EINVAL;
Hmm. Unless I am totally confused you found a serious bug...
Without CLONE_THREAD/CLONE_PARENT copy_process() blindly does
p->exit_signal = args->exit_signal;
the valid_signal(sig) check in do_notify_parent() mostly saves us, but we
must not allow child->exit_signal < 0, if nothing else this breaks
thread_group_leader().
And afaics this patch doesn't fix this? I think we need the valid_signal()
check...
Oleg.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
2019-09-10 12:44 ` Oleg Nesterov
@ 2019-09-10 13:09 ` Christian Brauner
2019-09-10 13:10 ` Christian Brauner
0 siblings, 1 reply; 10+ messages in thread
From: Christian Brauner @ 2019-09-10 13:09 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Eugene Syromiatnikov, linux-kernel, Christian Brauner,
Andrew Morton, Peter Zijlstra (Intel),
Ingo Molnar, Dmitry V. Levin, Eric Biederman
On Tue, Sep 10, 2019 at 02:44:41PM +0200, Oleg Nesterov wrote:
> On 09/10, Eugene Syromiatnikov wrote:
> >
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -2562,6 +2562,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> > if (copy_from_user(&args, uargs, size))
> > return -EFAULT;
> >
> > + if (unlikely(((unsigned int)args.exit_signal) != args.exit_signal))
> > + return -EINVAL;
>
> Hmm. Unless I am totally confused you found a serious bug...
>
> Without CLONE_THREAD/CLONE_PARENT copy_process() blindly does
>
> p->exit_signal = args->exit_signal;
>
> the valid_signal(sig) check in do_notify_parent() mostly saves us, but we
> must not allow child->exit_signal < 0, if nothing else this breaks
> thread_group_leader().
>
> And afaics this patch doesn't fix this? I think we need the valid_signal()
> check...
Thanks for sending this patch so quickly after our conversation
yesterday, Eugene!
We definitely want valid_signal() to verify the signal is ok.
Eugene, can you please update the patch to use valid signal and keep it
as a separate patch from the cleanup and selftest patches?
Christian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
2019-09-10 13:09 ` Christian Brauner
@ 2019-09-10 13:10 ` Christian Brauner
2019-09-10 13:27 ` Christian Brauner
0 siblings, 1 reply; 10+ messages in thread
From: Christian Brauner @ 2019-09-10 13:10 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Eugene Syromiatnikov, linux-kernel, Christian Brauner,
Andrew Morton, Peter Zijlstra (Intel),
Ingo Molnar, Dmitry V. Levin, Eric Biederman
On Tue, Sep 10, 2019 at 03:09:35PM +0200, Christian Brauner wrote:
> On Tue, Sep 10, 2019 at 02:44:41PM +0200, Oleg Nesterov wrote:
> > On 09/10, Eugene Syromiatnikov wrote:
> > >
> > > --- a/kernel/fork.c
> > > +++ b/kernel/fork.c
> > > @@ -2562,6 +2562,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> > > if (copy_from_user(&args, uargs, size))
> > > return -EFAULT;
> > >
> > > + if (unlikely(((unsigned int)args.exit_signal) != args.exit_signal))
> > > + return -EINVAL;
> >
> > Hmm. Unless I am totally confused you found a serious bug...
> >
> > Without CLONE_THREAD/CLONE_PARENT copy_process() blindly does
> >
> > p->exit_signal = args->exit_signal;
> >
> > the valid_signal(sig) check in do_notify_parent() mostly saves us, but we
> > must not allow child->exit_signal < 0, if nothing else this breaks
> > thread_group_leader().
> >
> > And afaics this patch doesn't fix this? I think we need the valid_signal()
> > check...
>
> Thanks for sending this patch so quickly after our conversation
> yesterday, Eugene!
> We definitely want valid_signal() to verify the signal is ok.
>
> Eugene, can you please update the patch to use valid signal and keep it
> as a separate patch from the cleanup and selftest patches?
I'll then pick this up quickly so we can get this in before 5.3 is out.
Thanks!
Christian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
2019-09-10 13:10 ` Christian Brauner
@ 2019-09-10 13:27 ` Christian Brauner
2019-09-10 14:27 ` Eugene Syromiatnikov
2019-09-10 14:39 ` Oleg Nesterov
0 siblings, 2 replies; 10+ messages in thread
From: Christian Brauner @ 2019-09-10 13:27 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Eugene Syromiatnikov, linux-kernel, Christian Brauner,
Andrew Morton, Peter Zijlstra (Intel),
Ingo Molnar, Dmitry V. Levin, Eric Biederman
On Tue, Sep 10, 2019 at 03:10:48PM +0200, Christian Brauner wrote:
> On Tue, Sep 10, 2019 at 03:09:35PM +0200, Christian Brauner wrote:
> > On Tue, Sep 10, 2019 at 02:44:41PM +0200, Oleg Nesterov wrote:
> > > On 09/10, Eugene Syromiatnikov wrote:
> > > >
> > > > --- a/kernel/fork.c
> > > > +++ b/kernel/fork.c
> > > > @@ -2562,6 +2562,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> > > > if (copy_from_user(&args, uargs, size))
> > > > return -EFAULT;
> > > >
> > > > + if (unlikely(((unsigned int)args.exit_signal) != args.exit_signal))
> > > > + return -EINVAL;
> > >
> > > Hmm. Unless I am totally confused you found a serious bug...
> > >
> > > Without CLONE_THREAD/CLONE_PARENT copy_process() blindly does
> > >
> > > p->exit_signal = args->exit_signal;
> > >
> > > the valid_signal(sig) check in do_notify_parent() mostly saves us, but we
> > > must not allow child->exit_signal < 0, if nothing else this breaks
> > > thread_group_leader().
> > >
> > > And afaics this patch doesn't fix this? I think we need the valid_signal()
> > > check...
> >
> > Thanks for sending this patch so quickly after our conversation
> > yesterday, Eugene!
> > We definitely want valid_signal() to verify the signal is ok.
So we could do your check in copy_clone_args_from_user(), and then we do
another valid_signal() check in clone3_args_valid()? We could do the
latter in copy_clone_args_from_user() too but it's nicer to do it along
the other checks in clone3_args_valid().
Christian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
2019-09-10 13:27 ` Christian Brauner
@ 2019-09-10 14:27 ` Eugene Syromiatnikov
2019-09-10 14:39 ` Oleg Nesterov
1 sibling, 0 replies; 10+ messages in thread
From: Eugene Syromiatnikov @ 2019-09-10 14:27 UTC (permalink / raw)
To: Christian Brauner
Cc: Oleg Nesterov, linux-kernel, Christian Brauner, Andrew Morton,
Peter Zijlstra (Intel),
Ingo Molnar, Dmitry V. Levin, Eric Biederman
On Tue, Sep 10, 2019 at 03:27:02PM +0200, Christian Brauner wrote:
> On Tue, Sep 10, 2019 at 03:10:48PM +0200, Christian Brauner wrote:
> > On Tue, Sep 10, 2019 at 03:09:35PM +0200, Christian Brauner wrote:
> > > On Tue, Sep 10, 2019 at 02:44:41PM +0200, Oleg Nesterov wrote:
> > > > On 09/10, Eugene Syromiatnikov wrote:
> > > > >
> > > > > --- a/kernel/fork.c
> > > > > +++ b/kernel/fork.c
> > > > > @@ -2562,6 +2562,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> > > > > if (copy_from_user(&args, uargs, size))
> > > > > return -EFAULT;
> > > > >
> > > > > + if (unlikely(((unsigned int)args.exit_signal) != args.exit_signal))
> > > > > + return -EINVAL;
> > > >
> > > > Hmm. Unless I am totally confused you found a serious bug...
> > > >
> > > > Without CLONE_THREAD/CLONE_PARENT copy_process() blindly does
> > > >
> > > > p->exit_signal = args->exit_signal;
> > > >
> > > > the valid_signal(sig) check in do_notify_parent() mostly saves us, but we
> > > > must not allow child->exit_signal < 0, if nothing else this breaks
> > > > thread_group_leader().
> > > >
> > > > And afaics this patch doesn't fix this? I think we need the valid_signal()
> > > > check...
> > >
> > > Thanks for sending this patch so quickly after our conversation
> > > yesterday, Eugene!
> > > We definitely want valid_signal() to verify the signal is ok.
>
> So we could do your check in copy_clone_args_from_user(), and then we do
> another valid_signal() check in clone3_args_valid()? We could do the
> latter in copy_clone_args_from_user() too but it's nicer to do it along
> the other checks in clone3_args_valid().
There's also a discrepancy between CSIGNAL (0xff) and _NSIG, used
in valid_signal (which is between 32 and 128, depending on architecture),
it seems it doesn't break thread_group_leader, but definitely allows
passing some invalid signal numbers via legacy clone-like syscalls—I'm
not sure if that's important.
> Christian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
2019-09-10 13:27 ` Christian Brauner
2019-09-10 14:27 ` Eugene Syromiatnikov
@ 2019-09-10 14:39 ` Oleg Nesterov
2019-09-10 14:46 ` Christian Brauner
1 sibling, 1 reply; 10+ messages in thread
From: Oleg Nesterov @ 2019-09-10 14:39 UTC (permalink / raw)
To: Christian Brauner
Cc: Eugene Syromiatnikov, linux-kernel, Christian Brauner,
Andrew Morton, Peter Zijlstra (Intel),
Ingo Molnar, Dmitry V. Levin, Eric Biederman
On 09/10, Christian Brauner wrote:
> On Tue, Sep 10, 2019 at 03:10:48PM +0200, Christian Brauner wrote:
> > On Tue, Sep 10, 2019 at 03:09:35PM +0200, Christian Brauner wrote:
> > > On Tue, Sep 10, 2019 at 02:44:41PM +0200, Oleg Nesterov wrote:
> > > > On 09/10, Eugene Syromiatnikov wrote:
> > > > >
> > > > > --- a/kernel/fork.c
> > > > > +++ b/kernel/fork.c
> > > > > @@ -2562,6 +2562,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> > > > > if (copy_from_user(&args, uargs, size))
> > > > > return -EFAULT;
> > > > >
> > > > > + if (unlikely(((unsigned int)args.exit_signal) != args.exit_signal))
> > > > > + return -EINVAL;
> > > >
> > > > Hmm. Unless I am totally confused you found a serious bug...
> > > >
> > > > Without CLONE_THREAD/CLONE_PARENT copy_process() blindly does
> > > >
> > > > p->exit_signal = args->exit_signal;
> > > >
> > > > the valid_signal(sig) check in do_notify_parent() mostly saves us, but we
> > > > must not allow child->exit_signal < 0, if nothing else this breaks
> > > > thread_group_leader().
> > > >
> > > > And afaics this patch doesn't fix this? I think we need the valid_signal()
> > > > check...
> > >
> > > Thanks for sending this patch so quickly after our conversation
> > > yesterday, Eugene!
> > > We definitely want valid_signal() to verify the signal is ok.
>
> So we could do your check in copy_clone_args_from_user(), and then we do
> another valid_signal() check in clone3_args_valid()? We could do the
> latter in copy_clone_args_from_user() too but it's nicer to do it along
> the other checks in clone3_args_valid().
I am fine either way. Sure, we can add valid_signal() into clone3_args_valid(),
but then I'd ask to simplify the "overflow" check above. Something like
if (args.exit_signal > UINT_MAX)
return -EINVAL;
looks much more readable to me.
Or we can simply do
if (args.exit_signal & ~((u64)CSIGNAL))
return -EINVAL;
in copy_clone_args_from_user() and forget about all problems.
Up to Eugene and you.
Oleg.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
2019-09-10 14:39 ` Oleg Nesterov
@ 2019-09-10 14:46 ` Christian Brauner
2019-09-10 15:18 ` Eugene Syromiatnikov
0 siblings, 1 reply; 10+ messages in thread
From: Christian Brauner @ 2019-09-10 14:46 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Eugene Syromiatnikov, linux-kernel, Christian Brauner,
Andrew Morton, Peter Zijlstra (Intel),
Ingo Molnar, Dmitry V. Levin, Eric Biederman
On Tue, Sep 10, 2019 at 04:39:44PM +0200, Oleg Nesterov wrote:
> On 09/10, Christian Brauner wrote:
> > On Tue, Sep 10, 2019 at 03:10:48PM +0200, Christian Brauner wrote:
> > > On Tue, Sep 10, 2019 at 03:09:35PM +0200, Christian Brauner wrote:
> > > > On Tue, Sep 10, 2019 at 02:44:41PM +0200, Oleg Nesterov wrote:
> > > > > On 09/10, Eugene Syromiatnikov wrote:
> > > > > >
> > > > > > --- a/kernel/fork.c
> > > > > > +++ b/kernel/fork.c
> > > > > > @@ -2562,6 +2562,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> > > > > > if (copy_from_user(&args, uargs, size))
> > > > > > return -EFAULT;
> > > > > >
> > > > > > + if (unlikely(((unsigned int)args.exit_signal) != args.exit_signal))
> > > > > > + return -EINVAL;
> > > > >
> > > > > Hmm. Unless I am totally confused you found a serious bug...
> > > > >
> > > > > Without CLONE_THREAD/CLONE_PARENT copy_process() blindly does
> > > > >
> > > > > p->exit_signal = args->exit_signal;
> > > > >
> > > > > the valid_signal(sig) check in do_notify_parent() mostly saves us, but we
> > > > > must not allow child->exit_signal < 0, if nothing else this breaks
> > > > > thread_group_leader().
> > > > >
> > > > > And afaics this patch doesn't fix this? I think we need the valid_signal()
> > > > > check...
> > > >
> > > > Thanks for sending this patch so quickly after our conversation
> > > > yesterday, Eugene!
> > > > We definitely want valid_signal() to verify the signal is ok.
> >
> > So we could do your check in copy_clone_args_from_user(), and then we do
> > another valid_signal() check in clone3_args_valid()? We could do the
> > latter in copy_clone_args_from_user() too but it's nicer to do it along
> > the other checks in clone3_args_valid().
>
> I am fine either way. Sure, we can add valid_signal() into clone3_args_valid(),
> but then I'd ask to simplify the "overflow" check above. Something like
>
> if (args.exit_signal > UINT_MAX)
> return -EINVAL;
>
> looks much more readable to me.
>
>
> Or we can simply do
>
> if (args.exit_signal & ~((u64)CSIGNAL))
> return -EINVAL;
>
> in copy_clone_args_from_user() and forget about all problems.
Both are fine with me. The latter might have the advantage that we catch
both legacy clone and clone3. I think Eugene prefers this as well.
Christian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal
2019-09-10 14:46 ` Christian Brauner
@ 2019-09-10 15:18 ` Eugene Syromiatnikov
0 siblings, 0 replies; 10+ messages in thread
From: Eugene Syromiatnikov @ 2019-09-10 15:18 UTC (permalink / raw)
To: Christian Brauner
Cc: Oleg Nesterov, linux-kernel, Christian Brauner, Andrew Morton,
Peter Zijlstra (Intel),
Ingo Molnar, Dmitry V. Levin, Eric Biederman
On Tue, Sep 10, 2019 at 04:46:15PM +0200, Christian Brauner wrote:
> On Tue, Sep 10, 2019 at 04:39:44PM +0200, Oleg Nesterov wrote:
> > On 09/10, Christian Brauner wrote:
> > > On Tue, Sep 10, 2019 at 03:10:48PM +0200, Christian Brauner wrote:
> > > > On Tue, Sep 10, 2019 at 03:09:35PM +0200, Christian Brauner wrote:
> > > > > On Tue, Sep 10, 2019 at 02:44:41PM +0200, Oleg Nesterov wrote:
> > > > > > On 09/10, Eugene Syromiatnikov wrote:
> > > > > > >
> > > > > > > --- a/kernel/fork.c
> > > > > > > +++ b/kernel/fork.c
> > > > > > > @@ -2562,6 +2562,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> > > > > > > if (copy_from_user(&args, uargs, size))
> > > > > > > return -EFAULT;
> > > > > > >
> > > > > > > + if (unlikely(((unsigned int)args.exit_signal) != args.exit_signal))
> > > > > > > + return -EINVAL;
> > > > > >
> > > > > > Hmm. Unless I am totally confused you found a serious bug...
> > > > > >
> > > > > > Without CLONE_THREAD/CLONE_PARENT copy_process() blindly does
> > > > > >
> > > > > > p->exit_signal = args->exit_signal;
> > > > > >
> > > > > > the valid_signal(sig) check in do_notify_parent() mostly saves us, but we
> > > > > > must not allow child->exit_signal < 0, if nothing else this breaks
> > > > > > thread_group_leader().
> > > > > >
> > > > > > And afaics this patch doesn't fix this? I think we need the valid_signal()
> > > > > > check...
> > > > >
> > > > > Thanks for sending this patch so quickly after our conversation
> > > > > yesterday, Eugene!
> > > > > We definitely want valid_signal() to verify the signal is ok.
> > >
> > > So we could do your check in copy_clone_args_from_user(), and then we do
> > > another valid_signal() check in clone3_args_valid()? We could do the
> > > latter in copy_clone_args_from_user() too but it's nicer to do it along
> > > the other checks in clone3_args_valid().
> >
> > I am fine either way. Sure, we can add valid_signal() into clone3_args_valid(),
> > but then I'd ask to simplify the "overflow" check above. Something like
> >
> > if (args.exit_signal > UINT_MAX)
> > return -EINVAL;
> >
> > looks much more readable to me.
> >
> >
> > Or we can simply do
> >
> > if (args.exit_signal & ~((u64)CSIGNAL))
> > return -EINVAL;
> >
> > in copy_clone_args_from_user() and forget about all problems.
>
> Both are fine with me. The latter might have the advantage that we catch
> both legacy clone and clone3. I think Eugene prefers this as well.
Unfortunately, it doesn't. I think, the best place for the check is
either in _do_fork or copy_process itself; however, it's quite messy as
that way it's detached from the other checks, but, at the same time,
there are a lot of code paths (like the one in arch/x86/ia32/sys_ia32.c),
and it's kinda obscure that the caller of _do_fork has to check that
exit_syscall is positive itself.
> Christian
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-09-10 15:18 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-10 11:57 [PATCH] fork: fail on non-zero higher 32 bits of args.exit_signal Eugene Syromiatnikov
2019-09-10 12:20 ` Dmitry V. Levin
2019-09-10 12:44 ` Oleg Nesterov
2019-09-10 13:09 ` Christian Brauner
2019-09-10 13:10 ` Christian Brauner
2019-09-10 13:27 ` Christian Brauner
2019-09-10 14:27 ` Eugene Syromiatnikov
2019-09-10 14:39 ` Oleg Nesterov
2019-09-10 14:46 ` Christian Brauner
2019-09-10 15:18 ` Eugene Syromiatnikov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).