[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181128220545.fplqmbkfhxowx3lf@brauner.io>
Date: Wed, 28 Nov 2018 23:05:49 +0100
From: Christian Brauner <christian@...uner.io>
To: Joey Pabalinas <joeypabalinas@...il.com>
Cc: ebiederm@...ssion.com, linux-kernel@...r.kernel.org,
serge@...lyn.com, jannh@...gle.com, luto@...nel.org,
akpm@...ux-foundation.org, oleg@...hat.com, cyphar@...har.com,
viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
linux-api@...r.kernel.org, dancol@...gle.com, timmurray@...gle.com,
linux-man@...r.kernel.org, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Wed, Nov 28, 2018 at 11:45:34AM -1000, Joey Pabalinas wrote:
> On Mon, Nov 19, 2018 at 11:32:39AM +0100, Christian Brauner wrote:
> > + if (info) {
> > + ret = __copy_siginfo_from_user(sig, &kinfo, info);
> > + if (unlikely(ret))
> > + goto err;
>
I think you're misreading here. It jumps to:
err:
fdput(f);
return ret;
and does propagate the error. This is also an old iteration of the patch.
Christian
> What's the reason you don't propagate up the errors from __copy_siginfo_from_user()?
> Granted, I admit that -E2BIG is kind of weird to return, but -EFAULT seems like a
> fairly sane error.
>
> Or is there some reason it's more useful to just return -EINVAL for all of the
> failure cases here?
>
> --
> Cheers,
> Joey Pabalinas
Powered by blists - more mailing lists