Received: by 10.223.176.5 with SMTP id f5csp311594wra; Mon, 5 Feb 2018 22:41:09 -0800 (PST) X-Google-Smtp-Source: AH8x225VFZ9i0edtwWu8EvJcCEiD/ZZRyx1NfS04vTm+F6F1uX4qdT2thCbOyGUfpd/QnBDBOc4W X-Received: by 10.101.90.78 with SMTP id z14mr1152093pgs.215.1517899269466; Mon, 05 Feb 2018 22:41:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517899269; cv=none; d=google.com; s=arc-20160816; b=DcD3kxEjdG4ojgCL5Z57SW8N9E6yuEMl6MWebATfXx/7J8FkzuIrLER7+89K1/vueX 8CX5u7tBXkVk+eScl01l7HmaP//50rYSGzU7TO1A6rqKa+9gLXZK37NRvSm5jHpXrWJL 548dvY5vTOfkLgVgUTIIAfVf/4TMSehqBaUAs0/nbtobl57qPyOdhrf82z0nw89To1c+ eX2GAmduZdDvJUhC73ypE1IsErVm6JbwzD/L720fXEI8aXZrZaTmIlEJE7J5ENlRSCBx JDRoEUC1uthhlXmFCzzVEbuMHLnuV69yzCDcMfrf42hRbu23vBgFzEcW7cGvNqr15DdC TmMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=s1fC83Llk79JI4hIwXw7om4h9eyT5Pt45OV0JtDusaU=; b=p3e08xwyGbDJ/48f8+oXyRNkINV+JCKq46xocYONB1XLyIwIaJYzH6Sip1ytOH9wBq 4BUYicU7V43z+67oIdlLVTd8Wg5QuhTNRFZ2wY0cp2sBWH2bJY9Fn1Yh8W9HMxgWovTk fvSVUR4ybBjoI5U+gCEkMeyQUy625qrck/rAvEEN0PxrB1TEBPUZhJGCf+liCDlkRax3 4zOLbsK3Ur8qJ2mwcsyhDjQVT8oFU0AB8SSR9EyBHxMnpbnHyGfn5Le6euqQ2YpmYioT Ew8A1vr0DGKcWBKknrlXIKKUkRke243bztl0IDo9qYqIrYHOxW/aoJpb5UnLEYmVik19 dvjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uneBW0N/; 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=NONE 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 p5-v6si1124321plr.282.2018.02.05.22.40.43; Mon, 05 Feb 2018 22:41:09 -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=uneBW0N/; 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=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752242AbeBFGjq (ORCPT + 99 others); Tue, 6 Feb 2018 01:39:46 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:37718 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751872AbeBFGjk (ORCPT ); Tue, 6 Feb 2018 01:39:40 -0500 Received: by mail-it0-f65.google.com with SMTP id h129so1177783ita.2; Mon, 05 Feb 2018 22:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s1fC83Llk79JI4hIwXw7om4h9eyT5Pt45OV0JtDusaU=; b=uneBW0N/NmEIBqtfIflDVn8/8W6kMIX51IDkgNGgSr4OeAdhJQMKxEYmW4RhlKhOh1 WcSdCelWonRWkClk5ml7Gmim9IwU38lwSMvqB9WGdXifrDc2PaH3SoUHv3F1VYHoY16t j/kuhBDd/snmO17GF/Q2FUT1l0e80gTSIonSHRYbXBkz43dlDbTyDAJsHe0D8LauqdfW 9UnYSzG5FPblFgYOPAGOtHt3AmmgFW3GFodVfIZp6WgPPMssCqc3MWyM1BeNnxrIYpAk rL2GbboLWjgabr+7FfXe7hqL/cacdfo3IKIDZQ5fmNywDcHfDFdaOc1BJ39zAHtjtiwZ FcTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s1fC83Llk79JI4hIwXw7om4h9eyT5Pt45OV0JtDusaU=; b=Kqk63i8DlpoDMe+tu3XIbCdekfuP7pZsPOfDlqAtYntvgV+4GjJnmd3gyFrfiFoJhg lDx0TOEBzIqIEZPebe2lbsajQyQpyR3AOJZSQZCacZNGLRSG7bf0XK12YkkreQhlj8uT lXhzqruvhGu4GOOB7PL+Z/KQC9IxgRo5msWkaIBxslEv6/J5vhWD3WVHdIC0FfoqaYFA xLyYfG9kDmHd6/QlA1OBCE/0A0ZQglYFfNBxhT78fMlF0nNPzEYf5jLdh33hVRkNZ2/V Bp8zz2fJ8le2gQrzIyAgQBy2diYduP9Dl5jva7GeD4ySMIeQniKVFtm/Z953pkSxuCIS COwQ== X-Gm-Message-State: APf1xPATJRzGSxQyztNJfxve/itvuQMbPkCaxlMRwpXSVleNwxO0+gGO 4wNk6reQ87lyCLEP0AFUGqEerPo9gIrPLu/gJvQ= X-Received: by 10.36.111.14 with SMTP id x14mr1651202itb.77.1517899179345; Mon, 05 Feb 2018 22:39:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.175.34 with HTTP; Mon, 5 Feb 2018 22:39:38 -0800 (PST) In-Reply-To: References: From: Vincent Chen Date: Tue, 6 Feb 2018 14:39:38 +0800 Message-ID: Subject: Re: [PATCH v6 20/36] nds32: Signal handling support To: Arnd Bergmann Cc: Greentime Hu , Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren , Randy Dunlap , David Miller , Jonas Bonn , Stefan Kristiansson , Stafford Horne , Vincent Chen Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks, I got it. After referring to arm64 and risc-v, we try to refine our code, such as removing unneeded checking and refining syscall restart flow. We hope these modifications can enhance the reliability and readability. However, the following 2 files which you had acked are included in this modification. 1. arch/nds32/include/asm/nds32.h (patch: Assembly macros and definitions) The definition of macro tbl and why are removed. - Now, we use pt_reg->syscallno instead of 'why' to determine whether entering kernel is via syscall or not. Therefore, macro 'why' is unneeded. --- a/arch/nds32/include/asm/nds32.h +++ b/arch/nds32/include/asm/nds32.h @@ -66,10 +66,6 @@ static inline unsigned long CACHE_LINE_SIZE #endif /* __ASSEMBLY__ */ -/* tbl and why is used in ex-scall.S and ex-exit.S */ -#define tbl $r8 -#define why $r8 - #define IVB_BASE PHYS_OFFSET 2. arch/nds32/kernel/ex-scall.S (patch: System calls handling) a. Define macro tbl - The marco tbl is used only in this file. So, I move its definition from arch/nds32/include/asm/nds32.h to here. b. Remove 'set why = 0' when issuing syscall number is invalid c. Adjust input arguments of syscall_trace_enter --- a/arch/nds32/kernel/ex-scall.S +++ b/arch/nds32/kernel/ex-scall.S ... +#define tbl $r8 /* * $r7 will be writen as syscall nr - * by retrieving from $ITYPE 'SWID' bitfiled */ .macro get_scno lwi $r7, [$sp + R15_OFFSET] @@ -54,7 +49,6 @@ ENTRY(eh_syscall) get_scno gie_enable -ENTRY(eh_syscall_phase_2) lwi $p0, [tsk+#TSK_TI_FLAGS] andi $p1, $p0, #_TIF_WORK_SYSCALL_ENTRY @@ -71,7 +65,6 @@ jmp_systbl: jr $p1 ! no return _SCNO_EXCEED: - movi why, 0 ori $r0, $r7, #0 ori $r1, $sp, #0 b bad_syscall @@ -81,8 +74,7 @@ _SCNO_EXCEED: * context switches, and waiting for our parent to respond. */ __sys_trace: - move $r1, $sp - move $r0, $r7 ! trace entry [IP = 0] + move $r0, $sp bal syscall_trace_enter move $r7, $r0 la $lp, __sys_trace_return ! return address If you think these modifications in acked files are not permitted, we will recover it. We verify all modifications by LTP 2017 related cases and glibc 2.26 testsuite. We plan to add it in the next version patch and hope you can give us some comments as before. Thanks Vincent 2018-01-24 19:13 GMT+08:00 Arnd Bergmann : > On Wed, Jan 24, 2018 at 1:56 AM, Vincent Chen wrote: >> 2018-01-18 18:30 GMT+08:00 Arnd Bergmann : >>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu wrote: >>>> From: Greentime Hu >>>> >>>> This patch adds support for signal handling. >>>> >>>> Signed-off-by: Vincent Chen >>>> Signed-off-by: Greentime Hu >>> >>> I never feel qualified enough to properly review signal handling code, so >>> no Ack from me for this code even though I don't see anything wrong with it. >>> Hopefully someone else can give an Ack after looking more closely. >>> >> >> Dear Arnd: >> >> We'd be glad to improve signal handling code to meet your requirement. >> Could you >> tell us which part we need to refine or which implementation is good >> for us to refer? > > No, as I said, the problem is on my side, I just don't understand enough of it. > I would assume that the arm64 and risc-v implementations are the most > thoroughly reviewed, but haven't looked at those in enough detail either. > If your code does something that risc-v doesn't do, try to understand whether > there should be a difference or not. > > Arnd