public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Cc: David Daney <ddaney@caviumnetworks.com>,
	Jesper Nilsson <jesper@jni.nu>,
	linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: MIPS: return after handling coprocessor 2 exception
Date: Fri, 18 Jun 2010 11:00:53 +0100	[thread overview]
Message-ID: <20100618100053.GA4466@linux-mips.org> (raw)
In-Reply-To: <4C1B263E.7070906@niisi.msk.ru>

On Fri, Jun 18, 2010 at 11:54:38AM +0400, Gleb O. Raiko wrote:

> >What happens when the call chain is empty, and the proper action *is*
> >SIGILL?
> 
> It's never empty, in fact. The default notifier declared at top of
> traps.c sends SIGILL. The problem that current code is sending
> SIGILL in all cases.

That's not really a problem.  The design idea is that a the default
notifier has the lowest priority, that is any user notifier installed
should have higher priority resulting in it getting run first.  To avoid
the default notifier from getting executed such an extra notifier should
set NOTIFY_STOP_MASK in its return like:

static int default_cu2_call(struct notifier_block *nfb, unsigned long action,
        void *data)
{
	...

	return NOTIFY_OK | NOTIFY_STOP;
}

The notifier list could also be used for example by perf but there it
we'd want the notifier function not to return NOTIFY_STOP as the result;

Arguably sending the signal for CU2 instructions has been delegated to the
hook so the I agree that the break stateement should be replaced with a
return and will apply the patch.

  Ralf

  reply	other threads:[~2010-06-18 10:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-17 13:25 MIPS: return after handling coprocessor 2 exception Jesper Nilsson
2010-06-17 17:13 ` David Daney
2010-06-17 19:04   ` Jesper Nilsson
2010-06-18  7:54   ` Gleb O. Raiko
2010-06-18 10:00     ` Ralf Baechle [this message]
2010-06-18 10:35       ` Gleb O. Raiko
2010-06-18 12:14         ` Ralf Baechle

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=20100618100053.GA4466@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=ddaney@caviumnetworks.com \
    --cc=jesper@jni.nu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=raiko@niisi.msk.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox