linux-kernel - Re: [patch V6 10/37] x86/entry: Switch XEN/PV hypercall entry to IDTENTRY

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 21 May 2020 12:45:14 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Frederic Weisbecker <frederic@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        Brian Gerst <brgerst@...il.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Will Deacon <will@...nel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Wei Liu <wei.liu@...nel.org>,
        Michael Kelley <mikelley@...rosoft.com>,
        Jason Chen CJ <jason.cj.chen@...el.com>,
        Zhao Yakui <yakui.zhao@...el.com>,
        "Peter Zijlstra \(Intel\)" <peterz@...radead.org>
Subject: Re: [patch V6 10/37] x86/entry: Switch XEN/PV hypercall entry to IDTENTRY

Andy Lutomirski <luto@...nel.org> writes:
> On Wed, May 20, 2020 at 12:17 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> Andy Lutomirski <luto@...nel.org> writes:
>> > Andrew Cooper pointed out that there is too much magic in Xen for this
>> > to work.  So never mind.
>>
>> :)
>>
>> But you made me stare more at that stuff and I came up with a way
>> simpler solution. See below.
>
> I like it, but I bet it can be even simpler if you do the
> tickle_whatever_paulmck_call_it() change:
>
>> +__visible noinstr void xen_pv_evtchn_do_upcall(struct pt_regs *regs)
>> +{
>> +       struct pt_regs *old_regs;
>> +       bool inhcall;
>> +
>> +       idtentry_enter(regs);
>> +       old_regs = set_irq_regs(regs);
>> +
>> +       run_on_irqstack(__xen_pv_evtchn_do_upcall, NULL, regs);
>> +
>> +       set_irq_regs(old_regs);
>> +
>> +       inhcall = get_and_clear_inhcall();
>> +       __idtentry_exit(regs, inhcall);
>> +       restore_inhcall(inhcall);
>
> How about:
>
>        inhcall = get_and_clear_inhcall();
>        if (inhcall) {
>         if (!WARN_ON_ONCE((regs->flags & X86_EFLAGS_IF) || preempt_count()) {
>           local_irq_enable();
>           cond_resched();
>           local_irq_disable();

This really want's to use preempt_schedule_irq() as the above is racy
vs. need_resched().

>         }
>      }
>      restore_inhcall(inhcall);
>      idtentry_exit(regs);
>
> This could probably be tidied up by having a xen_maybe_preempt() that
> does the inhcall and resched mess.
>
> The point is that, with the tickle_nohz_ stuff, there is nothing
> actually preventing IRQ handlers from sleeping as long as they aren't
> on the IRQ stack and as long as the interrupted context was safe to
> sleep in.

You still lose the debug checks. I'm working on it ...

Thanks,

        tglx