From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751853AbbBKH7o (ORCPT ); Wed, 11 Feb 2015 02:59:44 -0500 Received: from mail-bl2on0107.outbound.protection.outlook.com ([65.55.169.107]:39776 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750984AbbBKH7n (ORCPT ); Wed, 11 Feb 2015 02:59:43 -0500 Message-ID: <54DB0BDD.2010807@freescale.com> Date: Wed, 11 Feb 2015 09:59:25 +0200 From: Purcareata Bogdan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Michael Ellerman , Bogdan Purcareata CC: , , , , , Subject: Re: [RFC][PATCH 1/3] powerpc: Don't force ENOSYS as error on syscall fail References: <1423468516-8688-1-git-send-email-bogdan.purcareata@freescale.com> <1423468516-8688-2-git-send-email-bogdan.purcareata@freescale.com> <1423623845.12568.1.camel@ellerman.id.au> In-Reply-To: <1423623845.12568.1.camel@ellerman.id.au> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.88.166.1] X-ClientProxiedBy: DB4PR05CA0031.eurprd05.prod.outlook.com (25.160.40.41) To BN1PR03MB187.namprd03.prod.outlook.com (10.255.200.149) Authentication-Results: linux.vnet.ibm.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB187; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004);SRVR:BN1PR03MB187; X-Forefront-PRVS: 0484063412 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(6049001)(51704005)(24454002)(164054003)(377424004)(46102003)(80316001)(19580405001)(19580395003)(59896002)(2950100001)(83506001)(23676002)(33656002)(36756003)(65806001)(65956001)(50466002)(122386002)(87976001)(77096005)(47776003)(66066001)(86362001)(92566002)(54356999)(65816999)(42186005)(50986999)(87266999)(76176999)(77156002)(62966003)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR03MB187;H:[10.171.74.27];FPR:;SPF:None;MLV:sfv;LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB187; X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2015 07:59:39.4260 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB187 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11.02.2015 05:04, Michael Ellerman wrote: > On Mon, 2015-02-09 at 07:55 +0000, Bogdan Purcareata wrote: >> In certain scenarios - e.g. seccomp filtering with ERRNO as default action - >> the system call fails for other reasons than the syscall not being available. >> The seccomp filter can be configured to store a user-defined error code on >> return from a blacklisted syscall. >> >> The RFC is this: are there currently any user-space scenarios where it is >> required that the system call return ENOSYS as error code on failure, no matter >> the circumstances? I don't want to break userspace requirements. I have not >> added code to force this error code in situations different than >> secure_computing failure, in order to keep overhead at a minimum. >> >> Signed-off-by: Bogdan Purcareata >> --- >> arch/powerpc/kernel/entry_32.S | 3 ++- >> arch/powerpc/kernel/entry_64.S | 2 +- >> 2 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S >> index 59848e5..52e48dd 100644 >> --- a/arch/powerpc/kernel/entry_32.S >> +++ b/arch/powerpc/kernel/entry_32.S >> @@ -425,7 +425,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) >> b 1b >> #endif /* CONFIG_44x */ >> >> -66: li r3,-ENOSYS >> +66: >> +# li r3,-ENOSYS >> b ret_from_syscall >> >> .globl ret_from_fork >> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S >> index e6bfe8e..80db02e 100644 >> --- a/arch/powerpc/kernel/entry_64.S >> +++ b/arch/powerpc/kernel/entry_64.S >> @@ -269,7 +269,7 @@ syscall_dotrace: >> b .Lsyscall_dotrace_cont >> >> syscall_enosys: >> - li r3,-ENOSYS >> +# li r3,-ENOSYS >> b syscall_exit > > So what happens if you call this with a syscall number that's out of bounds? As far as my current understanding goes, the call will return with -1 with a errno that's undefined (or I've not seen it be defined anywhere). I've thought more about this, and I guess the best option would be to move setting -ENOSYS as errno from the syscall entry assembly to do_syscall_trace_enter (as opposed to eliminating it at all). I was a little reluctant to do this at first in order to keep overhead to a minimum, but it's certainly not an option to change behavior if the syscall number is out of bounds. v2 to come shortly. Thanks, Bogdan P.