From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Trap WFI executed in userspace
Date: Wed, 8 Aug 2018 13:34:09 +0100 [thread overview]
Message-ID: <20180808123408.GC24736@iMac.local> (raw)
In-Reply-To: <9af8bb9a-7c6c-2560-5965-118dfadf8141@arm.com>
On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> On 07/08/18 11:05, Dave Martin wrote:
> > On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote:
> >> It recently came to light that userspace can execute WFI, and that
> >> the arm64 kernel doesn trap this event. This sounds rather benign,
Nitpick: "doesn't".
> >> but the kernel should decide when it wants to wait for an interrupt,
> >> and not userspace.
> >>
> >> Let's trap WFI and treat it as a way to yield the CPU to another
> >> process.
[...]
> > I can't think of a legitimate reason for userspace to execute WFI
> > however. Userspace doesn't have interrupts under Linux, so it makes
> > no sense to wait for one.
> >
> > Have we seen anybody using WFI in userspace? It may be cleaner to
> > map this to SIGILL rather than be permissive and regret it later.
>
> I couldn't find any user, and I'm happy to just send userspace to hell
> in that case. But it could also been said that since it was never
> prevented, it is a de-facto ABI.
I wouldn't really go as far as SIGILL on WFI. I think the patch is fine
as it is. In case Will plans to merge it:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Dave Martin <Dave.Martin@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: Trap WFI executed in userspace
Date: Wed, 8 Aug 2018 13:34:09 +0100 [thread overview]
Message-ID: <20180808123408.GC24736@iMac.local> (raw)
In-Reply-To: <9af8bb9a-7c6c-2560-5965-118dfadf8141@arm.com>
On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> On 07/08/18 11:05, Dave Martin wrote:
> > On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote:
> >> It recently came to light that userspace can execute WFI, and that
> >> the arm64 kernel doesn trap this event. This sounds rather benign,
Nitpick: "doesn't".
> >> but the kernel should decide when it wants to wait for an interrupt,
> >> and not userspace.
> >>
> >> Let's trap WFI and treat it as a way to yield the CPU to another
> >> process.
[...]
> > I can't think of a legitimate reason for userspace to execute WFI
> > however. Userspace doesn't have interrupts under Linux, so it makes
> > no sense to wait for one.
> >
> > Have we seen anybody using WFI in userspace? It may be cleaner to
> > map this to SIGILL rather than be permissive and regret it later.
>
> I couldn't find any user, and I'm happy to just send userspace to hell
> in that case. But it could also been said that since it was never
> prevented, it is a de-facto ABI.
I wouldn't really go as far as SIGILL on WFI. I think the patch is fine
as it is. In case Will plans to merge it:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
next prev parent reply other threads:[~2018-08-08 12:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 9:33 [PATCH] arm64: Trap WFI executed in userspace Marc Zyngier
2018-08-07 9:33 ` Marc Zyngier
2018-08-07 10:05 ` Dave Martin
2018-08-07 10:05 ` Dave Martin
2018-08-07 10:24 ` Marc Zyngier
2018-08-07 10:24 ` Marc Zyngier
2018-08-07 10:30 ` Dave Martin
2018-08-07 10:30 ` Dave Martin
2018-08-07 12:12 ` Robin Murphy
2018-08-07 12:12 ` Robin Murphy
2018-08-07 13:02 ` Dave Martin
2018-08-07 13:02 ` Dave Martin
2018-08-08 12:34 ` Catalin Marinas [this message]
2018-08-08 12:34 ` Catalin Marinas
2018-08-09 12:34 ` Dave Martin
2018-08-09 12:34 ` Dave Martin
2018-08-09 12:38 ` Will Deacon
2018-08-09 12:38 ` Will Deacon
2018-08-09 12:47 ` Dave Martin
2018-08-09 12:47 ` Dave Martin
2018-08-09 13:25 ` Marc Zyngier
2018-08-09 13:25 ` Marc Zyngier
2018-09-20 22:04 ` Pavel Machek
2018-09-20 22:04 ` Pavel Machek
2018-09-20 22:33 ` Marc Zyngier
2018-09-20 22:33 ` Marc Zyngier
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=20180808123408.GC24736@iMac.local \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.