From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756103AbbLHEg4 (ORCPT ); Mon, 7 Dec 2015 23:36:56 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38486 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753438AbbLHEgx (ORCPT ); Mon, 7 Dec 2015 23:36:53 -0500 Date: Tue, 8 Dec 2015 05:36:49 +0100 From: Ingo Molnar To: Arnd Bergmann Cc: Andy Lutomirski , Linus Torvalds , X86 ML , "linux-kernel@vger.kernel.org" , linux-arch Subject: Re: [PSEUDOPATCH] rename is_compat_task Message-ID: <20151208043648.GA2182@gmail.com> References: <11525805.FykVOSlruZ@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11525805.FykVOSlruZ@wuerfel> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Arnd Bergmann wrote: > On Monday 07 December 2015 15:12:59 Andy Lutomirski wrote: > > Hi all- > > > > Every time I look at is_compat_task, I cringe. That function > > determines whether we're in a compat syscall, not whether we're in a > > compat task. There are probably architectures (arm64?) under which > > these are the same conditions, but they are definitely *not* the same > > thing on x86. > > > > Can we just fix it? I propose the following patch: > > > > $ find -type f |xargs sed -i -e 's/is_compat_task/in_compat_syscall/g' > > > > If there's general agreement, can we do that at the end of the next > > merge window? > > > > I could also send a patch series to add in_compat_syscall, change all > > the users, then delete the old stuff, but that seems overcomplicated > > for something that's literally just renaming a token. > > As far as I know, x86 is the special case here, on all other architectures, this > actually checks the task, and it's impossible to call a system call of the other > kind. Well, even on architectures that don't allow mixed mode system calls for the same task the name 'in_compat_syscall()' is still correct: it just happens to also be a permanent condition for the life time of a task. On architectures that allow mixed mode syscalls the assumption and confusion carried by the 'is_compat_task()' misnomer has resulted in real security bugs, hence Andy's suggestion for a rename. So without my x86 hat on I'd still argue that 'is_compat_syscall()' is the more expressive (and hence more robust, safer) name. On architectures that don't care the change carries zero costs. So are there any deep objections to doing this rename in a single, quick, pain-minimized fashion right at the end of the next merge window, when the amount of pending patches in various maintainer trees is at a cyclical minimum? We can also keep an is_compat_task() migratory define for one more cycle just in case. Thanks, Ingo