From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752737AbdLLSgt (ORCPT <rfc822;w@1wt.eu>);
        Tue, 12 Dec 2017 13:36:49 -0500
Received: from mail-it0-f48.google.com ([209.85.214.48]:37516 "EHLO
        mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752512AbdLLSgo (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 12 Dec 2017 13:36:44 -0500
X-Google-Smtp-Source: ACJfBos/434Yu04K/e8QilSvGUSGFONsXj8Ihw2Pwry9BM441XzyUkziHjx6r68s+XigMZXy+kVdHwFnFC+N7kiaabI=
MIME-Version: 1.0
In-Reply-To: <CALCETrVBZrL-SBpSw5zzTZb36Dr72AjxfO7Dq5Onz7K8GZt4AA@mail.gmail.com>
References: <2809506.pL8kVbvXcY@aspire.rjw.lan> <1578405.51lzoSX1jh@aspire.rjw.lan>
 <20171209103325.GA13867@amd> <CA+55aFw8tuoJ2gcXx3K2sKFf2Y9hXX4naMVQNqGOUivnjwhjkg@mail.gmail.com>
 <20171209220110.GA11496@amd> <CA+55aFySAdiBZhZ0PSDjH5PuvPPcMsBRXbxCkObfm1eY7gHDbQ@mail.gmail.com>
 <20171210162305.GA10159@amd> <CA+55aFxc9e=CuwrAzhX7BgV4Or+unTQDXW1Xk-gXOZPiAtN3Bw@mail.gmail.com>
 <20171210185638.GA10363@amd> <CA+55aFy2-vNAXSnSBoiSfvhijKXzYVmpYr1VCOb87+tgrw0B1Q@mail.gmail.com>
 <20171210204350.GA25013@amd> <CA+55aFwK96Eryb2PMoeaLxPSu4srGQakh=jO646Wqv9advLp0A@mail.gmail.com>
 <CA+55aFwMCHd7ppU2aWafXoHdTme=g=HJ1UMmNp5WuQ9pQ7i7Cg@mail.gmail.com> <CALCETrVBZrL-SBpSw5zzTZb36Dr72AjxfO7Dq5Onz7K8GZt4AA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 12 Dec 2017 10:36:43 -0800
X-Google-Sender-Auth: 5fIOTXrpB1IiwHkuMZxW73wC7EY
Message-ID: <CA+55aFxSZX0FWKzxbcAsTz5huk9ftHkHmfnuhckjuVs4byETgQ@mail.gmail.com>
Subject: Re: Linux 4.15-rc2: Regression in resume from ACPI S3
To: Andy Lutomirski <luto@kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>, Zhang Rui <rui.zhang@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Jarkko Nikula <jarkko.nikula@linux.intel.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Dec 12, 2017 at 10:05 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>
>> - do NOT use "load_gs_index()", which does that swapgs dance (twice!)
>> and plays with interrupt state. Just load the segment register, and
>> then do the wrmsrl() of the {FS,GS,KERNEL_GS}_BASE values. There is no
>> need for the swapgs dance.
>
> Using what helper?  On x86_64, it can fault, and IIRC we explicitly
> don't allow loadsegment(gs, ...).

Just do the loadsegment() thing. The fact that we don't have a gs
version of it is legacy - to catch bad users. It shouldn't stop us
from having good users.

That said - can it really fault? Because if it can, then why can't %fs
fault? And on x86-64, we just do

        asm volatile ("movw %0, %%fs" :: "r" (ctxt->fs));

and don't actually use 'loadsegment()' for _any_ of the segments.  We
only do the fault protection on 32-bit.

In fact, we really should try to avoid taking faults here anyway,
shouldn't we? We haven't loaded enough of the context yet.

Hmm.

Maybe we should load only the fixed kernel segments at this point, and
then do all the loadsegment() of gs/fs in the later phase when we're
all set up.

THERE we can do the swapgs dance with interrupt tracing etc, because
*there* we actually are fully set up. I guess that means reloading the
FS/GS base MSR's,

              Linus