[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5432C9F2.2030503@zytor.com>
Date: Mon, 06 Oct 2014 09:57:22 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andy Lutomirski <luto@...capital.net>
CC: Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Sebastian Lackner <sebastian@...-team.de>,
Anish Bhatt <anish@...lsio.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Chuck Ebbert <cebbert.lkml@...il.com>
Subject: Re: [PATCH v4 0/2] x86_64,entry: Clear NT on entry and speed up switch_to
On 10/06/2014 09:45 AM, Andy Lutomirski wrote:
> On Mon, Oct 6, 2014 at 9:41 AM, H. Peter Anvin <hpa@...or.com> wrote:
>> On 10/06/2014 09:39 AM, Andy Lutomirski wrote:
>>> On Wed, Oct 1, 2014 at 11:49 AM, Andy Lutomirski <luto@...capital.net> wrote:
>>>> Anish Bhatt noticed that user programs can set RFLAGS.NT before
>>>> syscall or sysenter, and the kernel entry code doesn't filter out
>>>> NT. This causes kernel C code and, depending on thread flags, the
>>>> exit slow path to run with NT set.
>>>>
>>>
>>> Quick ping: now that the merge window is (sort of) open, what's
>>> happening with these patches?
>>>
>>> Thanks,
>>> Andy
>>>
>>
>> My preference would be to queue them up for 3.19 since they arrived late
>> in the 3.18 cycle.
>
> I see nothing wrong with deferring patch 2 for 3.19, but deferring
> patch 1, which is tagged for stable, for an entire release seems a bit
> silly to me.
>
Yes, that is probably going to get pushed later in this merge window;
that is usually how we deal with that sort of thing.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists