From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751495AbbBLFYn (ORCPT ); Thu, 12 Feb 2015 00:24:43 -0500 Received: from ozlabs.org ([103.22.144.67]:60042 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750942AbbBLFYl (ORCPT ); Thu, 12 Feb 2015 00:24:41 -0500 Message-ID: <1423718679.24302.3.camel@ellerman.id.au> Subject: Re: [PATCH v2 1/3] powerpc: Don't force ENOSYS as error on syscall fail From: Michael Ellerman To: Bogdan Purcareata Cc: benh@kernel.crashing.org, paulus@samba.org, linuxppc-dev@lists.ozlabs.org, pmoore@redhat.com, linux-kernel@vger.kernel.org, strosake@linux.vnet.ibm.com Date: Thu, 12 Feb 2015 16:24:39 +1100 In-Reply-To: <1423643778-32525-2-git-send-email-bogdan.purcareata@freescale.com> References: <1423643778-32525-1-git-send-email-bogdan.purcareata@freescale.com> <1423643778-32525-2-git-send-email-bogdan.purcareata@freescale.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2015-02-11 at 08:36 +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. Don't always set ENOSYS on > do_syscall_trace_enter failure. > > v2: > - move setting ENOSYS as errno from the syscall entry assembly to > do_syscall_trace_enter, only in the specific case > diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S > index 194e46d..0111e04 100644 > --- a/arch/powerpc/kernel/entry_64.S > +++ b/arch/powerpc/kernel/entry_64.S > @@ -269,7 +269,6 @@ syscall_dotrace: > b .Lsyscall_dotrace_cont > > syscall_enosys: > - li r3,-ENOSYS > b syscall_exit This still looks wrong to me. On 64 bit we do: CURRENT_THREAD_INFO(r11, r1) ld r10,TI_FLAGS(r11) andi. r11,r10,_TIF_SYSCALL_DOTRACE bne syscall_dotrace .Lsyscall_dotrace_cont: cmpldi 0,r0,NR_syscalls bge- syscall_enosys ... syscall_enosys: li r3,-ENOSYS b .Lsyscall_exit Your patch removes the load of ENOSYS. Which means if we're not doing syscall tracing, and we get an out-of-bounds syscall number, we'll return with something random on r3. Won't we? The 32-bit code looks more or less similar, although the label has a different name. cheers