All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthieu CASTET <matthieu.castet@parrot.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] binfmt_elf: fix return value in case of interpreter load failure
Date: Tue, 16 Apr 2013 16:25:56 +0200	[thread overview]
Message-ID: <20130416142556.GA11333@redhat.com> (raw)
In-Reply-To: <20130415145324.d63be917d438b3f4ec37f845@linux-foundation.org>

On 04/15, Andrew Morton wrote:
>
> On Fri, 12 Apr 2013 16:49:50 +0200 Matthieu CASTET <matthieu.castet@parrot.com> wrote:
>
> > The only valid remaining part of my patch is to return SIGKILL when
> > load_elf_interp fail (IS_ERR((void *)elf_entry) is true) (for example load
> > address of linker is bad) instead of SIGSEGV. This will follow what is done when
> > loading binary.
> >
> > But is it even worth doing?
>
> SIGSEGV can be caught

Actually it can't be, flush_signal_handlers() was already called.
SIGSEGV can be blocked/ignored after that, but please note that
force_sig_info(SIGSEGV) will unblock and set SIG_DFL if necessary.

In short, force_sig() will actuallu kill the task in any case.

But: afaics send_sig(SIGSEGV) above load_elf_interp() is wrong,
we should either use SIGKILL (which can't be ignored/blocked) or
force_sig.

> that would be a user-visible change.

Yes. waitpid(&status) can notice the difference.

> I just
> don't know what the implications of such a change would be :(

Mee too... Looks harmless but still.

OTOH, I do not know why/when we should use SIGKILL or SIGSEGV in
this code.

Oleg.


      reply	other threads:[~2013-04-16 14:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-11 13:53 [PATCH] binfmt_elf: fix return value in case of interpreter load failure Matthieu CASTET
2013-04-11 22:04 ` Andrew Morton
2013-04-12 14:49   ` Matthieu CASTET
2013-04-15 21:53     ` Andrew Morton
2013-04-16 14:25       ` Oleg Nesterov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130416142556.GA11333@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthieu.castet@parrot.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.