Re: [PSEUDOPATCH] rename is_compat_task

[Ingo Molnar <mingo@kernel.org>]

* Arnd Bergmann <arnd@arndb.de> 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