From patchwork Thu May 28 21:42:56 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Russell King - ARM Linux X-Patchwork-Id: 6502271 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id C13B09F1CC for ; Thu, 28 May 2015 21:45:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CBC0F20569 for ; Thu, 28 May 2015 21:45:42 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C9A1A20456 for ; Thu, 28 May 2015 21:45:41 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Yy5aN-00071p-L9; Thu, 28 May 2015 21:43:31 +0000 Received: from pandora.arm.linux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Yy5aI-0006sz-NI for linux-arm-kernel@lists.infradead.org; Thu, 28 May 2015 21:43:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arm.linux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=FtTZsMWooJ7NrVKQZtek87uv6JxxzGRxV94qmzElAeE=; b=LGfkiR+jbEwqiK+QhdVEsgxhSgLEwDlyKOuOY+TYBZLDSmb5KgAvAjYQqCn5kI2WYi1mUnHIGL4hsk8a/tbjgllW/x7qBGp8XS781q/4ss1nvdIlR5EsaNpA4QgKwcZTeVNfkQQKffX+BMtmfhR1ccflsFD/XOu30nlcWLSRhro=; Received: from n2100.arm.linux.org.uk ([fd8f:7570:feb6:1:214:fdff:fe10:4f86]:52640) by pandora.arm.linux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yy5Zr-0005fU-KY; Thu, 28 May 2015 22:42:59 +0100 Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76) (envelope-from ) id 1Yy5Zo-0008N5-QI; Thu, 28 May 2015 22:42:56 +0100 Date: Thu, 28 May 2015 22:42:56 +0100 From: Russell King - ARM Linux To: William Cohen Subject: Re: Kernel oops on 32-bit arm with syscall with invalid sysno Message-ID: <20150528214256.GF2067@n2100.arm.linux.org.uk> References: <55677D6A.1060008@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <55677D6A.1060008@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150528_144327_086391_1311CB6E X-CRM114-Status: GOOD ( 12.59 ) X-Spam-Score: -0.1 (/) Cc: "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, May 28, 2015 at 04:41:14PM -0400, William Cohen wrote: > When reviewing testsuite failures for systemtap I found that the > 32-bit arm kernels (both 4.1.0-rc5 and 3.19.8) were not handling the > libc syscall with invalid sysno in the manner described by > http://www.gnu.org/software/libc/manual/html_node/System-Calls.html. > Rather than returning -1 and setting errno to ENOSYS the invalid > syscall gives segfault and a kernel oops. Looking at this, it seems that we're triggering this: BUG_ON(context->in_syscall || context->name_count); which seems to imply that we've called audit_syscall_entry() twice without a call to audit_syscall_exit(). That is something we can fix - and something which only happens with the syscall of "-1" (which is our "syscall was cancelled" value.) If I have diagnosed this correctly, the following patch should fix it. However, as you're asking for the "cancelled" syscall value, what you'll get returned from the syscall is the r0 value preserved as the result of the syscall. In other words, you won't get -1 and errno set to ENOSYS. Not much can be done about that without breaking syscall cancelling, so expect your test case to continue failing. diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S index f8ccc21fa032..2c40c1214a72 100644 --- a/arch/arm/kernel/entry-common.S +++ b/arch/arm/kernel/entry-common.S @@ -241,11 +241,11 @@ __sys_trace: cmp scno, #-1 @ skip the syscall? bne 2b add sp, sp, #S_OFF @ restore stack - b ret_slow_syscall + b 3f __sys_trace_return: str r0, [sp, #S_R0 + S_OFF]! @ save returned r0 - mov r0, sp +3: mov r0, sp bl syscall_trace_exit b ret_slow_syscall