From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758141AbcCVBuX (ORCPT ); Mon, 21 Mar 2016 21:50:23 -0400 Received: from mail-bn1on0063.outbound.protection.outlook.com ([157.56.110.63]:51155 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751929AbcCVBuV (ORCPT ); Mon, 21 Mar 2016 21:50:21 -0400 Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=caviumnetworks.com; Date: Tue, 22 Mar 2016 04:49:48 +0300 From: Yury Norov To: "Zhangjian (Bamvor)" CC: , , , Andreas Schwab , "dingtianhong@huawei.com" , , , Alexander Graf , , , , , , , , Bamvor Zhang Jian , , Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Message-ID: <20160322014948.GA9275@yury-N73SV> References: <20160218223506.GA7816@yury-N73SV> <20160225202855.GD16123@yury-N73SV> <56EBD84D.2060009@huawei.com> <20160318154918.GA1595@yury-N73SV> <56EC24EE.6020803@suse.de> <20160318164627.GA3201@yury-N73SV> <56EE5B6E.6030305@huawei.com> <56EFD9B0.6080004@huawei.com> <20160321184312.GB26563@yury-N73SV> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160321184312.GB26563@yury-N73SV> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: HE1PR02CA0084.eurprd02.prod.outlook.com (25.163.170.52) To BY2PR07MB613.namprd07.prod.outlook.com (10.141.222.144) X-MS-Office365-Filtering-Correlation-Id: b1549926-bad8-47b8-cf9a-08d351f4518f X-Microsoft-Exchange-Diagnostics: 1;BY2PR07MB613;2:e2O9DGNndphXgddGwjhc9PmzAYMkhoZRk3Ll0yW9JTankDq85bqrLBnX/ujzvIk8AvW3CNbfOdleup/e6UnTSG/LU/i2uSocsIWxKvqYb9D1FshIpFqURZDGqJW+MRUHb92GAP7XOk4uS33zkhrHHZWbCVhYf0lOSSANjW6utUi5fDCv12LIFp+I81D5bIUh;3:Db5fVEP4kxbMMONSmjUQE+YgPPogJ5NiT11O8RAE0jLyt4XYGhjOa5nPBKL19rxHG7JAdD+IoIzE74mIftTWZ3DFdhYYBc1dfkb+92M4i79Jnieif66Xit+A9BV+UlwI;25:q3TCSIV28/UyyJLL3LPx1PBrm4jwhZ0U/CIJbrnswXtmB4Gf29yWyt7xzYLyJNTidpm+M5DS9OgOYogQDZ7ImhIYuw05S18a6ECvGyO39eCwcKjAfj3TvicSZpVcqEZrYXirVzeXQl5mr1/iaoM+I4TJK+fx0uT9LxqOWoelaYYPC8DXMjDzGxKDHipBe7SLQ5en6N3cYJxWLTYcpnl9GL32PFhHaxWp6jwJB7EfWApTk5HCKUSG0t0VvLO9BPyUYSXgQ/LF16liYkzpU+pOO82MeEegjSK3HYwC1VvJFNwiddLyGL7FKep9sykkqJSps3u0xiDdO4BCJhTuOMvMktnrkcn8/Xx+736lMQuhZGSgU+NTz0Aye2ZpAO95dDp8G784mlcVaKTwU+0oxjt18PqOEeSSE3+BRq/LGKJvdz0Cr6XNZVTZjXNc2uGifuIE/cdyZ+fm3Bo4x1B5zg9LQ8Akq5yGQZx7nZAM2HQ25Rp1PVTQtSzysBZIULWzHmVTemqSdUvY4erYA3NsrmTiCQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR07MB613; X-Microsoft-Exchange-Diagnostics: 1;BY2PR07MB613;20:M7nMkkJJ87fz5jRCCdxJNElZcic8d02fFCcORWOb+L8LB4Xr3kIrNQsjxE0QzbGekSfQOIpW/pc4y2I5Lc3fvn93uqmN5/dUzYjy3DJwLekhmQgS/tQxaiBNLPSZLq0Rgdq1F6i/6LesqtjoxuODkdku6gey0AtnBo2L9b6IuLEZI5cVOYljIduvxM3l0sZQ9NiIhoR+u3n0eBrJiDiLuLkDO9sxwZhZQsouj0GJvBoABf6tRgDITbpGLPn0FZGOMu6jlT3UMEjPzkCD2oTs6/NV4r6RCMmP6YLeu9eEbx76arb/LzZGttc2pJpF1iq0fgIx2QMGYBj3cJYgNc3cg9IN09dh2hr3HUGXun9mvhdM3syxU0Ou3lOGoiMxsIH1yMZM3eiFHyZZtblxmt25h3Oy4a/wrv7nOtwJUWXGAhrLX9ln5YZQxdATZeRtTvAYoS1RLo1b1CIFXnujTeamPn3A6a+Zpd2aFa6uJZ/yYtLb/+pdG4YW8cCmBgqdc4QPcMggdM511C0Xl6ErowOVf4HM20LKDuGwrF4lxQyo7BXP3jCqW/GR7989cEj5rI8P9M8R2B+gVL2HYTlRtgutGYuruAnE8XklF/qqQWdNSN0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);SRVR:BY2PR07MB613;BCL:0;PCL:0;RULEID:;SRVR:BY2PR07MB613; X-Microsoft-Exchange-Diagnostics: 1;BY2PR07MB613;4:geiecV1MOSCYcSQikBymffuGOZ8AaCxiUSUikEk06yH//h9RZmZKDnZkfOTg6zDDe3yRivLBBXVy1OciY4G5SlB1pYNASaL0TkSnZNnCta4TtzEZuALr2McUAiw93gz2Rrnc3F0MyQC07a/sPYju3nSMAuQhjgIfIhpYvs+EpBP0AZe9xtL+cIhMq+AK4zLwHZMfyF9pWeDeyJbk6EAU+MUBAqvXgUmvb0ZK1WgHw1aeNkgRfVtOdVgnTgkusEEZ9j+4HZCi4+IAykd6LvLkXdcg/SOAhqtGLpk4keO42sjccFqsJF8IVcGnLCBxLXq1NEbrrpgCpXqRbCy//CRVmCzqUr7VwUyrh8OFLhKAGZx8u6yiyTAlyfjGhaXcqdqD X-Forefront-PRVS: 08897B549D X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6069001)(24454002)(76176999)(189998001)(3846002)(6116002)(586003)(33656002)(54356999)(23726003)(77096005)(92566002)(5004730100002)(19580405001)(19580395003)(97756001)(2950100001)(93886004)(83506001)(110136002)(4001350100001)(42186005)(46406003)(2906002)(47776003)(66066001)(1076002)(50986999)(575784001)(81166005)(4326007)(1096002)(33716001)(5008740100001)(76506005);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR07MB613;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY2PR07MB613;23:OLfKpi8lxj26DsUFJBgt34/jHdSoYhbW/P3aQtPUw0?= =?us-ascii?Q?17Jw6Olh7FMLe/ZVOGm0Ozr/Wwu+8R8BNZYTGB/a4AKWQrcJK9zUcu/2UqSe?= =?us-ascii?Q?CIp/hZm8kGC4HhxSM8/WUtfGrsE6dZOwWRS4wV7BASK5Jgm1fAAKocGrG3M9?= =?us-ascii?Q?XfAnHT8X/CnRZiF3byOlCQts/zgk2E3PLk0cxG73K1OaGz8jkTQiErnyJdDz?= =?us-ascii?Q?RU2USjLGgQ4tgRiQbTdwdtvnCzsORa6CgLWprUVY6/Y7edZSHoaVmIJwHoD1?= =?us-ascii?Q?ic/HG/alHInZ4aMmQQy9KeSjSCGuF95VaSOqw7/RpPB/3if0ab3jcaopE/g1?= =?us-ascii?Q?ejA2NTAkQ+zy5y5K04398EFp0tei5shYl7C6qEyi0GCxlZaA2VXAwTGD083A?= =?us-ascii?Q?b/3+D1FGXqRS8o7nUOK3BslYPdeZK2PiKUO7tZAJSBG1ZVfjlL6JU+4owt/F?= =?us-ascii?Q?pOAvnMTiPvjweU2irV9MFva+a5YMwvQabBxzcPHK1O3dQK0MobtL8DmGvnHr?= =?us-ascii?Q?2pfjNn5ILgRjpd7YKl2L5oo+z7m0RN4F7B1yoG7K2GYZAngExrxyrZ8HPMGl?= =?us-ascii?Q?nWYsLvzjKgWZaVkBuTnw/7VSTy5pKe+Logo/fCH9CxsgaFQEiPfmtHcVb+1S?= =?us-ascii?Q?P6ZqVjSwJCcdtZEGEmCEwFvto6/ukGYNdO1ZRRxc+OipfN0WeZ5jotOrc+dd?= =?us-ascii?Q?7xm6mqpLqWSzFZhTPgyRkUGnA6H46BSlI+ZVYY0I1oTUCfIIFevRRQViuOUD?= =?us-ascii?Q?lSwM+wtd+DleodI+flrPpcLyVCF8MbM0cTpH/LzjBwYkiAvdpil8bEk/5Inf?= =?us-ascii?Q?B/7STziqxb88iDq3MzCwNtE+sWAKC6wRfelT8E+HOFzdBy1mGZnmqYOf5vH4?= =?us-ascii?Q?n7PtfyRrcpuAxsTJZAVaSJI97rQHTFavAALO8WU0sONDk1xKHWKEOkNraT76?= =?us-ascii?Q?RRW92ilFMRemBHz7aUlfFoh3E1MjWfV3TsFi74xpNzOncwYCu0PR8WB5Db5w?= =?us-ascii?Q?o=3D?= X-Microsoft-Exchange-Diagnostics: 1;BY2PR07MB613;5:IfWOymKR3ex259/gNaNV4NaiebWwMtLaQ43D3/HqzjrpTplyYDLyKD92PkgPcsbNUaGUChGqB+QKDmMl7mZu75EKTKMndK908aBTO+z8hDYd55Q3020EDfxqEM2XkMCCH0jB9C288VNhqpZzZxq4yg==;24:yBkl8joTzU1u7RGlVrAfkb1I3LW2Ordgcnbs7Bo8p66BSyYICgENI2OwQbaKLlQcTQ4h2/IZZPcAtb8t+Kh892YJn9hwLPXPqejajQylai4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2016 01:50:16.5996 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR07MB613 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 21, 2016 at 09:43:12PM +0300, Yury Norov wrote: > On Mon, Mar 21, 2016 at 07:23:28PM +0800, Zhangjian (Bamvor) wrote: > > >>So this most probably means that ilp32 code doesn't handle one of cloned > > >>item properly. I have already discovered a bug where child processes > > >>used parent TLS, > > >It is a kernel bug or glibc bug? Could you please explain it or show the patch? > > >The current ILP32 patches looks good to me. Recently, I backport these patches > > >to our 4.1 kernel. And I saw crash frequently even if I only do a single print > > >or infinite loop. There is some small changes about tls register after 4.1. I > > >am not sure if it is a similar issue. It is great if you have some suggestions/ > > >ideas. > > My issue is because I forget to change is_compat_task to > > is_a32_compat_task in arch/arm64/kernel/process.c such piece of code > > is delete after commit d00a3810c162 ("arm64: context-switch user tls > > register tpidr_el0 for compat tasks). It is not exist in upstream > > kernel, never mind. > > > > Meanwhile, I found that it seem that there is another is_compat_task > > in tls_thread_flush. Is it relative the issue you mentioned? > > > > ``` > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > > index 432b094..9ab968c 100644 > > --- a/arch/arm64/kernel/process.c > > +++ b/arch/arm64/kernel/process.c > > @@ -209,7 +209,7 @@ static void tls_thread_flush(void) > > { > > asm ("msr tpidr_el0, xzr"); > > > > - if (is_compat_task()) { > > + if (is_a32_compat_task()) { > > current->thread.tp_value = 0; > > > > /* > > ``` > > > > Regards > > > > Bamvor > > Hi, > > This fix looks correct, though doesn't fix issue. > Thank you. > > Yury. Hi again. Next fix helps with SIGSEGV crash of trigo test. But now it hangs on futex, so work is not finished yet. Nevertheless, you can apply it and do your tests. Signed-off-by: Yury Norov --- arch/arm64/kernel/signal_ilp32.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/arm64/kernel/signal_ilp32.c b/arch/arm64/kernel/signal_ilp32.c index 455b0fb..1bb0ea8 100644 --- a/arch/arm64/kernel/signal_ilp32.c +++ b/arch/arm64/kernel/signal_ilp32.c @@ -107,6 +107,7 @@ int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, if (!frame) return 1; + err |= copy_siginfo_to_user32(&frame->info, &ksig->info); __put_user_error(0, &frame->sig.uc.uc_flags, err); __put_user_error(NULL, &frame->sig.uc.uc_link, err); @@ -115,12 +116,9 @@ int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, err |= setup_sigframe(&frame->sig, regs, set); if (err == 0) { setup_return(regs, &ksig->ka, frame, - offsetof(struct ilp32_rt_sigframe, sig), usig); - if (ksig->ka.sa.sa_flags & SA_SIGINFO) { - err |= copy_siginfo_to_user32(&frame->info, &ksig->info); - regs->regs[1] = (unsigned long)&frame->info; - regs->regs[2] = (unsigned long)&frame->sig.uc; - } + offsetof(struct ilp32_rt_sigframe, sig), usig); + regs->regs[1] = (unsigned long)&frame->info; + regs->regs[2] = (unsigned long)&frame->sig.uc; } return err; -- 2.5.0 From mboxrd@z Thu Jan 1 00:00:00 1970 From: ynorov@caviumnetworks.com (Yury Norov) Date: Tue, 22 Mar 2016 04:49:48 +0300 Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64 In-Reply-To: <20160321184312.GB26563@yury-N73SV> References: <20160218223506.GA7816@yury-N73SV> <20160225202855.GD16123@yury-N73SV> <56EBD84D.2060009@huawei.com> <20160318154918.GA1595@yury-N73SV> <56EC24EE.6020803@suse.de> <20160318164627.GA3201@yury-N73SV> <56EE5B6E.6030305@huawei.com> <56EFD9B0.6080004@huawei.com> <20160321184312.GB26563@yury-N73SV> Message-ID: <20160322014948.GA9275@yury-N73SV> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Mar 21, 2016 at 09:43:12PM +0300, Yury Norov wrote: > On Mon, Mar 21, 2016 at 07:23:28PM +0800, Zhangjian (Bamvor) wrote: > > >>So this most probably means that ilp32 code doesn't handle one of cloned > > >>item properly. I have already discovered a bug where child processes > > >>used parent TLS, > > >It is a kernel bug or glibc bug? Could you please explain it or show the patch? > > >The current ILP32 patches looks good to me. Recently, I backport these patches > > >to our 4.1 kernel. And I saw crash frequently even if I only do a single print > > >or infinite loop. There is some small changes about tls register after 4.1. I > > >am not sure if it is a similar issue. It is great if you have some suggestions/ > > >ideas. > > My issue is because I forget to change is_compat_task to > > is_a32_compat_task in arch/arm64/kernel/process.c such piece of code > > is delete after commit d00a3810c162 ("arm64: context-switch user tls > > register tpidr_el0 for compat tasks). It is not exist in upstream > > kernel, never mind. > > > > Meanwhile, I found that it seem that there is another is_compat_task > > in tls_thread_flush. Is it relative the issue you mentioned? > > > > ``` > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > > index 432b094..9ab968c 100644 > > --- a/arch/arm64/kernel/process.c > > +++ b/arch/arm64/kernel/process.c > > @@ -209,7 +209,7 @@ static void tls_thread_flush(void) > > { > > asm ("msr tpidr_el0, xzr"); > > > > - if (is_compat_task()) { > > + if (is_a32_compat_task()) { > > current->thread.tp_value = 0; > > > > /* > > ``` > > > > Regards > > > > Bamvor > > Hi, > > This fix looks correct, though doesn't fix issue. > Thank you. > > Yury. Hi again. Next fix helps with SIGSEGV crash of trigo test. But now it hangs on futex, so work is not finished yet. Nevertheless, you can apply it and do your tests. Signed-off-by: Yury Norov --- arch/arm64/kernel/signal_ilp32.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/arm64/kernel/signal_ilp32.c b/arch/arm64/kernel/signal_ilp32.c index 455b0fb..1bb0ea8 100644 --- a/arch/arm64/kernel/signal_ilp32.c +++ b/arch/arm64/kernel/signal_ilp32.c @@ -107,6 +107,7 @@ int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, if (!frame) return 1; + err |= copy_siginfo_to_user32(&frame->info, &ksig->info); __put_user_error(0, &frame->sig.uc.uc_flags, err); __put_user_error(NULL, &frame->sig.uc.uc_link, err); @@ -115,12 +116,9 @@ int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, err |= setup_sigframe(&frame->sig, regs, set); if (err == 0) { setup_return(regs, &ksig->ka, frame, - offsetof(struct ilp32_rt_sigframe, sig), usig); - if (ksig->ka.sa.sa_flags & SA_SIGINFO) { - err |= copy_siginfo_to_user32(&frame->info, &ksig->info); - regs->regs[1] = (unsigned long)&frame->info; - regs->regs[2] = (unsigned long)&frame->sig.uc; - } + offsetof(struct ilp32_rt_sigframe, sig), usig); + regs->regs[1] = (unsigned long)&frame->info; + regs->regs[2] = (unsigned long)&frame->sig.uc; } return err; -- 2.5.0