[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190206031029.GB9368@visor>
Date: Tue, 5 Feb 2019 19:10:29 -0800
From: Ivan Delalande <colona@...sta.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Dmitry Safonov <0x7f454c46@...il.com>,
Oleg Nesterov <oleg@...hat.com>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v2] exec: don't force_sigsegv processes with a pending
fatal signal
On Tue, Feb 05, 2019 at 01:11:19PM -0800, Andrew Morton wrote:
> On Mon, 4 Feb 2019 18:53:08 -0800 Ivan Delalande <colona@...sta.com> wrote:
> > --- a/fs/exec.c
> > +++ b/fs/exec.c
> > @@ -1660,7 +1660,12 @@ int search_binary_handler(struct linux_binprm *bprm)
> > if (retval < 0 && !bprm->mm) {
> > /* we got to flush_old_exec() and failed after it */
> > read_unlock(&binfmt_lock);
> > - force_sigsegv(SIGSEGV, current);
> > + if (!fatal_signal_pending(current)) {
> > + if (print_fatal_signals)
> > + pr_info("load_binary() failed: %d\n",
> > + retval);
>
> Should we be using print_fatal_signal() here?
I don't think so, the force_sigsegv() already ensures it will be called
from get_signal() when the signal is handled, and so the process
information will be printed then.
> > + force_sigsegv(SIGSEGV, current);
> > + }
> > return retval;
> > }
> > if (retval != -ENOEXEC || !bprm->file) {
Thanks,
--
Ivan Delalande
Arista Networks
Powered by blists - more mailing lists