From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754182Ab2EFSqq (ORCPT ); Sun, 6 May 2012 14:46:46 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:35645 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754079Ab2EFSqp (ORCPT ); Sun, 6 May 2012 14:46:45 -0400 Date: Sun, 6 May 2012 19:46:42 +0100 From: Al Viro To: "H. Peter Anvin" Cc: Linus Torvalds , linux-kernel@vger.kernel.org, Ralf Baechle Subject: Re: [PATCH] broken TASK_SIZE for ia32_aout Message-ID: <20120506184641.GW6871@ZenIV.linux.org.uk> References: <20120506162000.GT6871@ZenIV.linux.org.uk> <20120506175451.GU6871@ZenIV.linux.org.uk> <4FA6BBD9.3040308@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA6BBD9.3040308@zytor.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 06, 2012 at 10:58:49AM -0700, H. Peter Anvin wrote: > > What kind of semantics do we want? "Thread property" one, set when we > > set personality on execve(), or "syscall property", like e.g. x86 TIF_IRET > > and TS_COMPAT? > > It depends on the ABI properties of the platform. The x86 compat ABI is > that any task can issue a compat ABI request and get a compat ABI > response (a 64-bit task can call int $0x80 for an ia32 syscall > invocation, or use syscall with either an x86-64 or and x32 system call > number.) So is_compat_task() returns the current system call mode of > the task, because that is what downstream users need. One of the > biggest users is the input subsystem, which earns the black mark for > worst possible ABI design, and that definitely depends on the system > call type being invoked. Umm... Let me restate that question: is there ever a case when it would _not_ be a syscall property? I.e. when both 64bit and 32bit syscalls are possible for a given process *and* callers of is_compat_task() care about the kind of process and not the kind of syscall? Is e.g. sparc behaviour ("what kind of process it is, regardless of whether we are issuing a 32bit or a 64bit syscall") correct? Sure, on a platform where the possible kind of syscall is a function of process' personality, a thread property can be a used to tell which kind of syscall we are in.