From patchwork Wed Jan 11 15:33:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Martin X-Patchwork-Id: 9510453 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 966176075C for ; Wed, 11 Jan 2017 15:34:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 73EA2284D9 for ; Wed, 11 Jan 2017 15:34:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 65D492856C; Wed, 11 Jan 2017 15:34:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 5B838284D9 for ; Wed, 11 Jan 2017 15:34:20 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1cRKup-0006mw-K4; Wed, 11 Jan 2017 15:34:19 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1cRKum-0006Yx-5a for linux-arm-kernel@lists.infradead.org; Wed, 11 Jan 2017 15:34:17 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CE00FC14; Wed, 11 Jan 2017 07:33:55 -0800 (PST) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 18F083F242; Wed, 11 Jan 2017 07:33:54 -0800 (PST) Date: Wed, 11 Jan 2017 15:33:52 +0000 From: Dave Martin To: Catalin Marinas Subject: Re: Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64) Message-ID: <20170111153349.GK3699@e103592.cambridge.arm.com> References: <20161230151323.583b7ac5@xhacker> <20170109151354.GC7593@e104818-lin.cambridge.arm.com> <20170110121423.GF19960@e104818-lin.cambridge.arm.com> <20170111144902.GA20288@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170111144902.GA20288@e104818-lin.cambridge.arm.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-20170111_073416_225107_0D64EFD8 X-CRM114-Status: GOOD ( 24.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jisheng Zhang , linux-arm-kernel@lists.infradead.org, Bas van Tiel Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Jan 11, 2017 at 02:49:03PM +0000, Catalin Marinas wrote: > On Tue, Jan 10, 2017 at 12:14:23PM +0000, Catalin Marinas wrote: > > On Mon, Jan 09, 2017 at 07:06:19PM +0100, Bas van Tiel wrote: > > > > I defined STACKSIZE to the kernel's SIGSTKSZ (16384) and it seems to run > > > > fine, though I'll leave it longer/overnight (on a Juno board). With the > > > > 4K signal stack it was crashing shortly after start. > > > > > > I tried the STACKSIZE of 16384 for both the RPI3 and the PINEA64 board > > > and still see the same behaviour of crashing. Sometimes the process > > > is also blocked for a long time before it crashes. > > > > > > Setting the interval to 200 usec [5 Khz] will help to crash it faster. > > > > > > To further isolate the issue I will create a kernel module (based on a > > > hrtimer) that will sent a periodic signal to the registered process > > > and execute the same sighandler logic to check if the problem is still > > > there. > > > > I lowered the interval to 100us (it was 100ms in the original file) and > > I can indeed trigger segfault easily on Juno. But it doesn't fail in the > > same way every time, I sometimes get permission fault, other times bad > > frame. > > With 100us interval, it segfaults on x86 fairly quickly as well, so I > don't think it's a kernel issue. To be able to take a signal at all, stacks need to be at least SIGSTKSZ bytes in practice: The other issue looks a bit subtler, to do with signal masking. SIGALRM will be masked on entry to timer_interrupt() and restored on return, due to and absence of SA_NODEFER from sa_flags when calling sigaction. (Setting SIGALRM in sa_mask also has this effect, but this is redundant without SA_NODEFER.) However, by explicitly clearing this signal from signal_context.uc_sigmask, we'll enter scheduler() with SIGALRM unmasked. If a new SIGALRM is taken before scheduler() has called setcontext(), we'll pile up another signal on signal_stack and call schedule() again, still on signal_stack ... and this can repeat indefinitely. There's no need to clear SIGALRM from the signal mask: it will be cleared when timer_interrupt() returns after resuming an interrupted task (as part of the signal frame restore work done by rt_sigreturn). So: @@ -61,7 +61,6 @@ timer_interrupt(int j, siginfo_t *si, void *old_context) signal_context.uc_stack.ss_sp = signal_stack; signal_context.uc_stack.ss_size = STACKSIZE; signal_context.uc_stack.ss_flags = 0; - sigemptyset(&signal_context.uc_sigmask); makecontext(&signal_context, scheduler, 1); /* save running thread, jump to scheduler */ For me, this seems to fix the problem. It also makes sense of what we've seen: we need either short timer intervals, slow machines, or high system load (or some combination) in order to take enough extra signals in scheduler() to cause a stack overflow. I can't see the purpose of running scheduler() in its own context here, except so that it doesn't contribute stack overhead to the thread stacks (which hardly seems worthwhile, since its overhead is probably a lot smaller than the signal overhead anyway -- maybe I'm missing something). makeconext() and swapcontext() are obsoleted by POSIX.1-2008 and considered non-portable (see makecontext(3), swapcontext(3)). Really, the ucontext API should not be used for anything except cooperative switching now (certainly this covered the vast majority or real-world usage the last time I looked into it). For anything else, pthreads almost certainly do it better. Cheers ---Dave diff --git a/context_demo.c b/context_demo.c index 2cc63f7..b1f3bbc 100644 --- a/context_demo.c +++ b/context_demo.c @@ -22,7 +22,7 @@ #define NUMCONTEXTS 10 /* how many contexts to make */ -#define STACKSIZE 4096 /* stack size */ +#define STACKSIZE SIGSTKSZ /* stack size */ #define INTERVAL 100 /* timer interval in nanoseconds */ sigset_t set; /* process wide signal mask */