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 S1752777AbbC2UwN (ORCPT <rfc822;w@1wt.eu>);
	Sun, 29 Mar 2015 16:52:13 -0400
Received: from mail-qg0-f41.google.com ([209.85.192.41]:33390 "EHLO
	mail-qg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752455AbbC2UwL (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 29 Mar 2015 16:52:11 -0400
MIME-Version: 1.0
In-Reply-To: <20150329070816.GD18007@gmail.com>
References: <202c56ca63823c338af8e2e54948dbe222da6343.1426728647.git.luto@kernel.org>
 <tip-a67e7277d01ccfd39b0db5a198c2643cc19dd79c@git.kernel.org>
 <CALCETrWZfcRhHogkTC--9aRGOuXuOYuvNdQfrCj0cK3+eNW4jA@mail.gmail.com>
 <20150324194402.GA27598@gmail.com> <CALCETrU4r1F99BzTS68MeYN0p6v+qem5_LnC+2H4GVztrSu+Zg@mail.gmail.com>
 <55155F9E.3030605@redhat.com> <20150329070816.GD18007@gmail.com>
From: Denys Vlasenko <vda.linux@googlemail.com>
Date: Sun, 29 Mar 2015 22:51:50 +0200
Message-ID: <CAK1hOcNf67EN76y0ydu=GgiacPhNz_rDWHUXzeV9W1WWaotUYg@mail.gmail.com>
Subject: Re: [tip:x86/asm] x86/asm/entry: Add user_mode_ignore_vm86()
To: Ingo Molnar <mingo@kernel.org>
Cc: Denys Vlasenko <dvlasenk@redhat.com>,
        Andy Lutomirski <luto@amacapital.net>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Brad Spengler <spender@grsecurity.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Borislav Petkov <bp@alien8.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andrew Lutomirski <luto@kernel.org>,
        "linux-tip-commits@vger.kernel.org" 
	<linux-tip-commits@vger.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 Sun, Mar 29, 2015 at 9:08 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> >> Would be still nice to have it as an add on patch, if you agree with
>> >> my arguments.
>> >
>> > Given that there are only a very small number of callers left and
>> > they're all Obviously Correct (tm), I'm not too worried about it.
>> > Maybe if we kill off __copy_to_user, I'll be inspired to kill off
>> > user_mode_ignore_vm86 as well :)
>>
>>
>> I was looking at the code involving this function and it looks
>> like a much better name for user_mode_ignore_vm86() would be
>> user_mode_cs().
>>
>> Every time we use it, we check vm8086 mode just before it:
>>
>> perf_event.c
>>
>>         if (regs->flags & X86_VM_MASK)
>>                 return 0x10 * regs->cs;
>>
>>         if (user_mode_ignore_vm86(regs) && regs->cs != __USER_CS)
>>                 return get_segment_base(regs->cs);
>>
>>
>> traps.c (three similar instances):
>>
>>         if (v8086_mode(regs)) {
>> ...
>>                 goto exit;
>>         }
>>         if (user_mode_ignore_vm86(regs))...
>>
>>
>> "_ignore_vm86" part doesn't quite work as an explanation.
>> user_mode_cs() would immediately tell me "do we have a user's cs?"
>
> So what the function name wanted to express is something like this:
>
>         if (user_mode_vm86_mode_already_checked_so_this_is_marginally_faster_but_dont_use_it_otherwise_because_that_would_be_a_roothole())
>         {
>                 ...
>         }
>
> but that name was considered somewhat long.

LOL :D

Seriously, though. I do think that  user_mode_cs(regs)  is a good name.
It's short.
It describes what it in fact checks.
"(is it) user mode cs" reads as a valid English phrase, whereas
"(is it) user mode ignore vm86" does not.