Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp14088873ybl; Mon, 30 Dec 2019 03:56:40 -0800 (PST) X-Google-Smtp-Source: APXvYqxa6VZyHCQvWA5uGWzACCtcQTwpYhyy1lCvT+os951f7MOXoHbz/2MmVWG6gO0ZtPJd8hEi X-Received: by 2002:a05:6830:1e2d:: with SMTP id t13mr76265432otr.128.1577707000860; Mon, 30 Dec 2019 03:56:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577707000; cv=none; d=google.com; s=arc-20160816; b=xtiWcMcwwVs0/eRN6sNcRLP0h9DcR3bQslxKruMpbtUCUZSGr/3fAYN4I2/KtDgOxg TkFIoeH8TnZWvuQ3HZPzO08JVDl8I8SyjsTE/wlTj6MsrAJIjL2u8NTmktpOybFO6tjo ByJ3DUaV1ackB6JKGazoIHOCA9oYim3q4dB1RaoQDA8j0KjjfJSpSbahvvBcxjxiX+nX IjncNGUDra/vK6sarW/zpjgK3NxkewwSQsJd5RYVqigH8V6hImzBuJdBu13gLQ+T+M+Q fWdUqsNKLSscLTOuE62xkZ10PlWGyZyIOW1Xi1GrC6910w6DXOB6RsDP+YeL3+fBWpjh fZrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=QmvUyOThLKgIMmAYLq0yhUeeOF7gjd7fkLseJ1QqBz0=; b=LAGPj2ZycfzWwnv/5VAHBU9coY/ma3N2CxXybbMgF0J7HxVi0wLCKjQP6Uwn1gXxkB hI7ei5EC4kxuHM+7UPvUno8j4wwdqyWtska57EJIVYL0EY+qaeUsFAL1b1Bp8vzZq+NI W736o5Fddc8bh/+H1Q8Bl+2/ZNDr2SJcyeeUcyC9PyyzL1E2eliKuF/09nA/K+yS9K/i HA/HZMvLjG14MdW0g6sbXV6NooUCnfYsklPua+gjDft5lXFsGP5KgFi/J9WXIdNTBUIs g7K3qOEdOLlwzjiJA2nrgKj5Spik84nz2QFdxCMQ3xzfUCMLWOyGm3JfgvJwhRFEQfpt U+6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cnPlqgi+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h64si14711453oif.215.2019.12.30.03.56.28; Mon, 30 Dec 2019 03:56:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cnPlqgi+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727407AbfL3Lzb (ORCPT + 99 others); Mon, 30 Dec 2019 06:55:31 -0500 Received: from mail-pj1-f67.google.com ([209.85.216.67]:36611 "EHLO mail-pj1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726196AbfL3Lzb (ORCPT ); Mon, 30 Dec 2019 06:55:31 -0500 Received: by mail-pj1-f67.google.com with SMTP id n59so8025929pjb.1 for ; Mon, 30 Dec 2019 03:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=QmvUyOThLKgIMmAYLq0yhUeeOF7gjd7fkLseJ1QqBz0=; b=cnPlqgi+FQx6/QEMcrf8L3berGqTWJqZpi1LDYXdPHSFSKbij9MzBTZqYdNLXJeNeA EEHPXp3J1dIz6iVi0+vzngX0t4bl144PzH3rElS1AOp9Tn81oLdwPeu+hUm0CKehq+0Q mS5jKidKmcVa+UAWJpuZ4uKyeE+D0atLbPHaxdeoX6NvNRYfO6lf5btSY3GHeNWmSpjx 6D7CqXeaGTk3wzPbKkIP+A32DnRNRXjSqDEkkawAQMBURMnE2ANwDQzFlvdw3UY2Nk7q UhsyGd9KMgttFpivz3Ic+CRnHNWicbfkuidoWK9B16W5Y0wqlPPBGDU/CRmpj4rCQuve 7UcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=QmvUyOThLKgIMmAYLq0yhUeeOF7gjd7fkLseJ1QqBz0=; b=KwmR3f52YXuM8dSwaATzpEYw5uC056wW/YdpkMoxziZd40ONL1CYQLhLnq80DSvNiU S16vqFUXqR4A3NmaqWdB8nUDtqzmt60WBi8K0FM1AKLWz3mrm9td/dZTlA3lM3CvC74f reqACdtHl5Hi/R8APTFG6YtCHXIoQjKlrrgKes+Y8WpKF9uU2tqinZ21PfvTq4NBY3rv kX3oTgmUFCsUva8hHu4e0xXmzkoezjw5XxpEj7ei9YGrIuT9JCJhiEhu9uUR3zytSAER Dv4bKw+EcUfxI9bgFmgR+Ne5gHWGWKVreXxxvRt1yOo+mUE5xfsbePW1XHG0azjBdakn OkHg== X-Gm-Message-State: APjAAAUGOLRQQtfYFVcEhRaYfY7MdDIraBkR9KwEU7lBj7+WJSGBiVy4 4dFSbqLeug1y0dEEOhcpfho= X-Received: by 2002:a17:902:8207:: with SMTP id x7mr42684646pln.286.1577706930056; Mon, 30 Dec 2019 03:55:30 -0800 (PST) Received: from localhost ([49.207.54.121]) by smtp.gmail.com with ESMTPSA id c19sm53990746pfc.144.2019.12.30.03.55.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 30 Dec 2019 03:55:29 -0800 (PST) Date: Mon, 30 Dec 2019 17:25:27 +0530 From: afzal mohammed To: Russell King Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Catalin Marinas , Greg Ungerer , Vladimir Murzin Subject: [RFC PATCH 2/2] ARM: !MMU: v7-M: preemption support Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ICSR RETTOBASE bit indicates whether there is any active exception other than the exception indicated by current value of IPSR. Existing code already makes use of it to find whether interrupt occurred during user(thread) mode. Add preemption support in the code path that executes upon finding an active exception other than the current interrupt. Having an active exception during interrupt exception indicates that the interrupt occurred during SVC or PendSV with current Linux exception setup. On PendSV, interrupts are disabled at exception entry (applicable to all) & enabled back just before returning from exception. Hence it has been assumed that active exception during interrupt is indicating SVC interruption. This would have to be revisited. With this change, there is some effect, but not enough to make it usable, this is being debugged. A simple character driver that does infinite while loop during read was used to test it as follows (/dev/mymisc corresponds to the node for the character driver), A. Before this change, A.1 ~ # cat /dev/mymisc [ 28.099225] mymisc_open [ 28.101625] mymisc_read: enter command prompt is not usable (expected), interrupts do happen during this time. A.2 ~ # cat /dev/mymisc & [1] 39 cat /dev/mymisc ~ # [ 11.699880] mymisc_open [ 11.702274] mymisc_read: enter command prompt is not usable (expected as preemption not supported). B. After this change, B.1 ~ # cat /dev/mymisc [ 27.374821] mymisc_open [ 27.377349] mymisc_read: enter though user will not get control back (as expected as it is fg process), entering on prompt causes new line, doesn't know what to make out of this behaviour, this doesn't happen in the A.1 case. Interrupts happen here as well. B.2 ~ # cat /dev/mymisc & [1] 41 cat /dev/mymisc ~ # [ 44.836417] mymisc_open [ 44.838814] mymisc_read: enter though prompt is available under the control of user, upon typing anything on the prompt (typed character doesn't get echoed), it crashes as follows, [ 44.838814] mymisc_read: enter [ 51.710314] [ 51.710314] Unhandled exception: IPSR = 00000006 LR = fffffffd [ 51.717576] CPU: 0 PID: 37 Comm: sh Not tainted 5.5.0-rc4-00004-g2328d01dbd85 #105 [ 51.725078] Hardware name: STM32 (Device Tree Support) [ 51.730206] PC is at 0x90195958 [ 51.733329] LR is at 0x901c4df3 [ 51.736471] pc : [<90195958>] lr : [<901c4df3>] psr: 21000000 [ 51.742713] sp : 901e5a58 ip : 00000000 fp : 901d89fc [ 51.747911] r10: 00000000 r9 : 00000000 r8 : 00000001 [ 51.753143] r7 : 000000a8 r6 : 901e5a58 r5 : 901e5b08 r4 : ffffffff [ 51.759643] r3 : 000000a8 r2 : ffffffff r1 : 00000001 r0 : 00000001 [ 51.766122] xPSR: 21000000 [ 51.768866] CPU: 0 PID: 37 Comm: sh Not tainted 5.5.0-rc4-00004-g2328d01dbd85 #105 [ 51.776369] Hardware name: STM32 (Device Tree Support) [ 51.781594] [<0800c0c9>] (unwind_backtrace) from [<0800b25b>] (show_stack+0xb/0xc) [ 51.789166] [<0800b25b>] (show_stack) from [<0800b9eb>] (__invalid_entry+0x4b/0x4c) It is a Usage Fault happening while in thread(user) mode. PC & LR in the dump is strange in the sense that they do not point to text section. The change here has been made based on how Cortex-A handles preemption. Since PAN is not applicable and since it seemed that saving & restoring thread_info::addr_limit does not make difference on the !MMU Cortex-M due to single address space being used, there was no additional save & restore of 'dacr' & 'addr_limit' as done in the case of interrupt during system call on Cortex-A. Also as DUT was UP Cortex-M4, it seemed that cache related would not affect in anyway w.r.t preemption, as currently cache is not enabled for M4 in Linux. As mentioned above, it was assumed that active exception during interrupt meant SVC was interrupted, though it could have been PendSV as well. To ensure that issue is not due to interrupt during PendSV, the PendSV handling of pending work was lifted & sticked onto __irq_entry and setting PendSV removed as well. Still the behaviour is same. Signed-off-by: afzal mohammed --- arch/arm/kernel/entry-v7m.S | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S index 581562dbecf3..e671115767d2 100644 --- a/arch/arm/kernel/entry-v7m.S +++ b/arch/arm/kernel/entry-v7m.S @@ -55,14 +55,29 @@ strerr: .asciz "\nUnhandled exception: IPSR = %08lx LR = %08lx\n" ldr r1, =BASEADDR_V7M_SCB ldr r0, [r1, V7M_SCB_ICSR] tst r0, V7M_SCB_ICSR_RETTOBASE - beq 2f + beq 101f ldr r2, [tsk, #TI_FLAGS] tst r2, #_TIF_WORK_MASK beq 2f @ no work pending mov r0, #V7M_SCB_ICSR_PENDSVSET str r0, [r1, V7M_SCB_ICSR] @ raise PendSV + b 2f + +101: +#ifdef CONFIG_PREEMPT + ldr r2, [tsk, #TI_PREEMPT] + teq r2, #0 @ preempt count != 0 ? + bne 2f + ldr r0, [tsk, #TI_FLAGS] + tst r0, #_TIF_NEED_RESCHED @ __TIF_NEED_RESCHED set ? + beq 2f +102: bl preempt_schedule_irq + ldr r0, [tsk, #TI_FLAGS] + tst r0, #_TIF_NEED_RESCHED @ __TIF_NEED_RESCHED set ? + bne 102b +#endif 2: pop {lr} -- 2.24.1