From patchwork Thu Jun 4 23:17:56 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josh Stone X-Patchwork-Id: 6550521 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 A5A4D9F1C1 for ; Thu, 4 Jun 2015 23:21:06 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9E6C9206BA for ; Thu, 4 Jun 2015 23:21:05 +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 3DAB52068F for ; Thu, 4 Jun 2015 23:21:04 +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 1Z0eP0-0004hq-AY; Thu, 04 Jun 2015 23:18:22 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z0eOw-0004fF-MF for linux-arm-kernel@lists.infradead.org; Thu, 04 Jun 2015 23:18:19 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 7F0962E6DA0; Thu, 4 Jun 2015 23:17:57 +0000 (UTC) Received: from [10.3.113.136] (ovpn-113-136.phx2.redhat.com [10.3.113.136]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t54NHuxY006576; Thu, 4 Jun 2015 19:17:56 -0400 Message-ID: <5570DCA4.3050600@redhat.com> Date: Thu, 04 Jun 2015 16:17:56 -0700 From: Josh Stone User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Russell King - ARM Linux Subject: Re: [PATCH] arm64: fix missing syscall trace exit References: <20150601102448.GG1641@arm.com> <1433293304-26539-1-git-send-email-jistone@redhat.com> <556E5454.9080400@redhat.com> <20150604100625.GI7557@n2100.arm.linux.org.uk> <55708783.2090909@redhat.com> In-Reply-To: <55708783.2090909@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150604_161818_787167_243D0642 X-CRM114-Status: GOOD ( 19.86 ) X-Spam-Score: -5.0 (-----) Cc: Catalin Marinas , Will Deacon , 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.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable 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 06/04/2015 10:14 AM, Josh Stone wrote: > Whether that exact path is reached -- I think so. I ran my test on a > distro kernel to see the failure, then applied only this fix and ran > again, could no longer see failure. > > I can try a systemtap or ftrace kprobe on ret_fast_syscall to be sure > that path is reached. I haven't gotten an ARM system yet. ARM64 doesn't have kprobes, so I can't directly probe ret_fast_syscall, but I did use the sched_switch tracepoint to confirm that the thread_info flags didn't contain any tracing flags until the moment I set PTRACE_SYSCALL, so it ought to be on that fast path. Plus I confirmed again that without those two lines in ret_fast_syscall it still fails my test, and succeeds with them, so I can't see how it could be anything but this path. > Because I was working from a distro kernel, it didn't have debugging > options, no. I'll go run that now, including both arm and arm64 if I > can find available systems... Now I booted an arm64 machine into kernel v4.1-rc6-52-gff25ea8 plus my __sys_trace_return patch, and I enabled debug options. I get a lot of might_sleep errors from xgbe_tx_timer (below), but this happens even without my patch. I get no kernel debug errors or warnings from my test, except that it records the SIGSEGV termination (which is by design). I even threw a loop inside the test to hammer it more -- all clean. Still, I don't think it's right to trace with interrupts disabled, so here's a version which enables them again first. How does this look? === Off topic, here's the xgbe_tx_timer BUG. As I mentioned, this happens even on a vanilla kernel, before I've run any of my tests. I think this is a legitimate bug to call disable_irq() from a softirq timer. disable_irq -> synchronize_irq -> wait_event -> might_sleep [ 19.841911] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110 [ 19.850081] in_atomic(): 1, irqs_disabled(): 0, pid: 1133, name: sed [ 19.856434] INFO: lockdep is turned off. [ 19.860349] CPU: 3 PID: 1133 Comm: sed Tainted: G W 4.1.0-rc6-orig+ #5 [ 19.867999] Hardware name: Default string Default string/Default string, BIOS ROD0080B 03/18/2015 [ 19.876865] Call trace: [ 19.879306] [] dump_backtrace+0x0/0x16c [ 19.884702] [] show_stack+0x10/0x1c [ 19.889746] [] dump_stack+0x84/0xbc [ 19.894796] [] ___might_sleep+0x15c/0x248 [ 19.900360] [] __might_sleep+0x54/0x94 [ 19.905685] [] synchronize_irq+0x2c/0x88 [ 19.911167] [] disable_irq+0x1c/0x2c [ 19.916304] [] xgbe_tx_timer+0x64/0x90 [ 19.921606] [] call_timer_fn+0xd4/0x48c [ 19.927002] [] run_timer_softirq+0x240/0x440 [ 19.932833] [] __do_softirq+0x118/0x608 [ 19.938221] [] irq_exit+0x9c/0xdc [ 19.943094] [] __handle_domain_irq+0x68/0xb4 [ 19.948916] [] gic_handle_irq+0x30/0x7c [ 19.954310] Exception stack(0xfffffe001ef4bb20 to 0xfffffe001ef4bc40) [ 19.960742] bb20: d6b401c0 fffffe03 01ea7600 fffffe00 1ef4bc60 fffffe00 00117a80 fffffe00 [ 19.968913] bb40: d6b401f0 fffffe03 0095f450 fffffe00 01ea7610 fffffe00 00000000 00000000 [ 19.977088] bb60: 1ef4bc10 fffffe00 1ef4bbe0 fffffe00 0109d468 fffffe00 00000000 00000000 [ 19.985262] bb80: d4a96880 fffffe03 00000000 00000000 1ef4bc80 fffffe00 00000000 756e694c [ 19.993436] bba0: 00000006 00000004 00010000 00000000 98343c1c 000003ff 98343b44 000003ff [ 20.001603] bbc0: 00226d00 fffffe00 983440dc 000003ff 00000000 00000000 d6b401c0 fffffe03 [ 20.009776] bbe0: 01ea7600 fffffe00 00fc0000 fffffe00 00fc2000 fffffe00 00fff3a0 fffffe00 [ 20.017950] bc00: 00000015 00000000 0000011a 00000000 00000038 00000000 00742000 fffffe00 [ 20.026125] bc20: 1ef48000 fffffe00 1ef4bc60 fffffe00 00228dd4 fffffe00 1ef4bc60 fffffe00 [ 20.034299] [] el1_irq+0x68/0x100 [ 20.039173] [] get_empty_filp+0xf8/0x1ec [ 20.044658] [] path_openat+0x34/0x644 [ 20.049874] [] do_filp_open+0x2c/0x88 [ 20.055095] [] do_sys_open+0x13c/0x21c [ 20.060397] [] SyS_openat+0xc/0x18 diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 959fe87..988bea4 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -608,11 +608,16 @@ ENDPROC(cpu_switch_to) */ ret_fast_syscall: disable_irq // disable interrupts - ldr x1, [tsk, #TI_FLAGS] + ldr x1, [tsk, #TI_FLAGS] // re-check for syscall tracing + and x2, x1, #_TIF_SYSCALL_WORK + cbnz x2, ret_fast_syscall_trace and x2, x1, #_TIF_WORK_MASK cbnz x2, fast_work_pending enable_step_tsk x1, x2 kernel_exit 0, ret = 1 +ret_fast_syscall_trace: + enable_irq // enable interrupts + b __sys_trace_return /* * Ok, we need to do extra processing, enter the slow path.