linux-kernel - Re: NMI for ARC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrV1ZacNJy0TvPzV2Qucgt3oVp6Z+z_CJ9vjhOhMFQCP+Q@mail.gmail.com>
Date:   Wed, 28 Sep 2016 15:47:55 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
        arcml <linux-snps-arc@...ts.infradead.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: NMI for ARC

On Wed, Sep 28, 2016 at 3:44 PM, Vineet Gupta
<Vineet.Gupta1@...opsys.com> wrote:
> On 09/28/2016 03:26 PM, Andy Lutomirski wrote:
>>>>>> 2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
>>>>>> > > >> require interrupt safety, does that need to be NMI safe as well. We ofcourse want
>>>>>> > > >> the very late register restore parts to be non-interruptible, but is this required
>>>>>> > > >> before we call prrempt_schedule_irq() off of asm code.
>>>>> > > >
>>>>> > > > Urgh, I'm never quite sure on the details here, I've Cc'ed Andy who
>>>>> > > > might actually know this off the top of his head. I'll try and dig
>>>>> > > > through x86 to see what it does.
>>>> > >
>>>> > > On x86, it's quite simple.  IRQs are *always* off during the final
>>>> > > register restore, and we don't re-check for preemption there.  x86
>>>> > > handles preemption after turning off IRQs, and IRQs are guaranteed to
>>>> > > stay off until we actually return to userspace.
>>>> > >
>>>> > > The code is almost entirely in C in arch/x86/entry/common.c.  There
>>>> > > isn't anything particularly x86-speficic in there.
>>> >
>>> > Right, so what I think Vineet is asking is if we need to disable NMIs as
>>> > well, we cannot on x86 disable NMIs so no.
>>> >
>> The same argument works here, too: an NMI won't set TIF_NEED_RESCHED
>> without sending an IPI, so we can't miss a wakeup.
>
> The case I saw was different: timer intr (normal prio) comes in - scheduler_tick()
> sets TIF_NEED_RESCHED and before this intr return, it gets interrupted by perf
> intr (higher prio) and we decide not to follow through on preemption because a
> nested intr can't return to userspace anyways.
>
>

This shouldn't cause a problem.  When the timer interrupt returns, it
should be able to handle preemption.