From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752808AbcELSEM (ORCPT ); Thu, 12 May 2016 14:04:12 -0400 Received: from mail-bn1bon0062.outbound.protection.outlook.com ([157.56.111.62]:48311 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752693AbcELSEI (ORCPT ); Thu, 12 May 2016 14:04:08 -0400 Authentication-Results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=caviumnetworks.com; Date: Thu, 12 May 2016 21:03:42 +0300 From: Yury Norov To: Catalin Marinas CC: , , , Subject: Re: [PATCH v2] arm64: fix current_thread_info()->addr_limit setup Message-ID: <20160512175154.GA13383@yury-N73SV> References: <1463069163-374-1-git-send-email-ynorov@caviumnetworks.com> <20160512172203.GL11226@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160512172203.GL11226@e104818-lin.cambridge.arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: VI1PR02CA0013.eurprd02.prod.outlook.com (10.162.7.151) To SN1PR07MB2239.namprd07.prod.outlook.com (10.164.47.145) X-MS-Office365-Filtering-Correlation-Id: 16159cc4-e462-4fea-9584-08d37a8fceec X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2239;2:JTMvlHgJG+V5HorUWYXw+J88aOkJx1hOQocq+6YhTB7IQfyxs/rFBjyNVXqebmkzbkuF+22YaVrAFkpv7WwZ7dUKlWZxUpfjCZBhQpJe7T1kdCWE8vIMABKQdq0nwFP9t/gpmyTa6ClH4atrUD7Jj24jrBPyrapuZmoO+6LDGJPVIpIJaCr6p6E5AbEpUDaA;3:WG3ZqgVdA6JDg5BiYEYMZ4QAx2kfM8kYXXHpVHfQlqhfW8pnlYNrS2P9WmOfF0qX2n/znJf7/uTFfxGBc1hWj+zPN1pDov4aQnGGoqmTJnHYOsQ0yxXaxeWyUej+APOx;25:s96ad4PsSkE1NzSzCHX0P+jX8AK34Ma2Slfv1fKeCQNZPdChV66FDaxJDzQio1AgHdhlpwNoA2FqzoJ150lrcBm63FBhKaHwW/5P3uStSGBXOSr2H7PVzwvv0TfLcupQ5osPpbeYjVDEnUzOblCwcjjAiTzAk1H3prlu9kNojx+Tjth5taAxiz3wZo8yeEipPk0op/2P310RXyEmyywTqksWOe3V/DG7fUISW9IOlE7T1N81xOmPaxDGHpQ9Bqdd4Yas/wSLKnAxQElvvRhRQ5SOxVTBpniEfX6U8dFZI9dBSjXUqVE5Wi3W+jr/xqt5TFzev6DKjFC16G6dYYVfVdWJjYZzt8/QdAmPcZf0KcvkFVVLajlhKV9k81dcC9rVO/rYPeRJ1wrB4asclfSp6yzJxRcTVTuShqMZjfhhPXg= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2239; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2239;20:xvRSFKIbv+IaP1TskJZNBpkoD28MRLemyxGwR+vVzfbn/hL4rerndPEHrAhIuKWpgxJAvo+mIOLoy4DGJGvJmR5v1WXJ5MwAlqENDEAjypfbPPSV1q7Pf40dIyeU/pynzOmvD4rjSjNWTlqVXjn5cTNtpAruas3AAlYy0RFfWia5kYVhVEiEvjh5wS6tkF6APOSLbOgA0ZtBf/tKVnqsmBQkuoTH6VDg3JlwhMmXNukh5MKBD93R325ZQdjVHnYwCFVjc9e+nSnWe9ZUBf8LWIvF7eRzLf6a2YDgsXiN79bn4gbPivD6WQxFCw+tgSNxJ1GnmDR0+xuVH6It0AEJsqVGIJVBfHe+M99t+T+kAlRO4CnofgAk1JY8lK9B4b8L3m6Yuydmix5kFctFDGCY++TDQT5I7IQiyPsmLE1uksRhj1whafmu3MQi391a93bcRZ5rmzZtwBYJd65/kx84zmWotDaBnlnCPyGNWO+Jzj7Ih9DaUJGIXB6wuOwZgzmprexC/63AglN73SrFDH2ortu4vf/Qmq9y/fk7/bRPoVe6LGS+yBRAJ7NZqOAiMHCIXIWsmKYG3WcWzT0nZVRToey4nQ6Uh5OFuBGPffXEVC8= 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:SN1PR07MB2239;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2239; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2239;4:4n4paVScS92oL4PMNv4qg0AuHH3DnARygSygGm/vRYoZbeZFi1+IM/zOx3cg+DSgWTCJnWnAYTkfgLG6XbJ7PFpDyzrjdU9s1hKz0N/dLMbogqs+nnKC/tkrlQrGfPCkvZ8SMmMo7115hQsU5KFPy2UbgzxRtURWdwvHVoZh8+opD47wjnCQWyEcPnTtt3bE+HR08DjvwPyCJP9RjiuzPCMqNTRwEDtFqK++hl/2LxgV5tOXWxkvO8N8CAMJ0qF9Ve4XAfwLB43Le2vMAFtkjr/W9zdje2po4TRnfnhCXLsaag1vgPjml7lQPZszXW89qwCVl0JS6d8PZoqzuBGzmLG7SjNLjzTcQtZQGIuQtgELyQqdZPtX3TegNnbKX5YE X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6069001)(24454002)(586003)(46406003)(110136002)(33656002)(189998001)(15975445007)(83506001)(54356999)(76176999)(50466002)(2950100001)(50986999)(92566002)(1076002)(6116002)(5008740100001)(97756001)(4001350100001)(42186005)(76506005)(3846002)(19580395003)(23726003)(19580405001)(2906002)(33716001)(5004730100002)(66066001)(1720100001)(77096005)(81166006)(4326007)(47776003)(9686002);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR07MB2239;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;SN1PR07MB2239;23:uNnIuU/DuoqqUxrn4V4ofcFdm3qf4pxBs8nu6Lx2t?= =?us-ascii?Q?GP7rSa5t2MILLl+voSeFsueAp4bZXt/0YO0yidi++E72XoiU8YklHdjDyHRo?= =?us-ascii?Q?E6NsPWOCfLIhSKTtKBCCoU/BFC1gufFoDutcXp/n9V0Mce9AoZxlYV5BcYuE?= =?us-ascii?Q?4Uk98V6xngIsdMdbjRW3w/4sh6SBdD5koQMc3NLyBZuu3D+UfOTkSZ7QkSx0?= =?us-ascii?Q?vlQuJTFLpu/d+es0RZ291mpTXhfbKoK13uv5UlAm1bhezIMu+0Hgf1GMTZJ4?= =?us-ascii?Q?XdF1sq7Ng1JtjQrjFRrtaKLVavMnGCPjhF8hUAjqwhaKunTRTxf1Rj7X83gP?= =?us-ascii?Q?AyKV+A3GYU6IGeKIz/9U7EUpx3XuE5chxTCPZQOMr3ZeK2iZ08I5yQ7dGsIo?= =?us-ascii?Q?d0R0J3dQg/nsFVmB3iMcRoYQdAk+DqxxG3eGDnjqvRPINEOV0oRmuOtZkbjQ?= =?us-ascii?Q?K0K/LpaKwJ6TvM/N0vAZD+N0YnawcwTtbdoHGRNcuZn5RHsTUJuuQgLo+qcH?= =?us-ascii?Q?JAvKTdnEy2pMAjt7R5rQM2R25VtY6EQNflm5by4CvOxEBsU5cI+uIL/yVGrp?= =?us-ascii?Q?oPfRlcWZvHTxSE2q4/KGAklrTpnuIbir1X6FeLR/gnHTDnJg61p0wCb/pzR5?= =?us-ascii?Q?jmPZdTitku+5qw6d8WSsDWQTbrFWisV0+lHKH2+ckIlM6ZNeL+wEHcweuu+d?= =?us-ascii?Q?3M2W5fRS9nYFOC40b9i+PphBTMTehjEdPiJN4xdNI0IX3fK9YWzddOgbuT2C?= =?us-ascii?Q?pStJNm+F9q+GGIc0ZrTExEoTQcjFHbbkcC1cbnybyxZRYNyhm75yc3lIB0cJ?= =?us-ascii?Q?AQRa1tR+jJKYtsG8o/ke69NnIsRpEp9nRNec0qIbFWmz1SeGmOFznEhFSnw4?= =?us-ascii?Q?SiIr9dRORIHPxXh3HKSXe0k7hiSucvAJuZAaK8ASW23LEq1rnZ+9vHhSM/+O?= =?us-ascii?Q?tXyrESQPpSJiFiuFeSaCYMm4sXq8iS4fBRH8hxk789vFbuPCQ0PcV3xlhI6s?= =?us-ascii?Q?/nSZsfCd+WDZSbWyIlyHTVvCSQn8O4jtUVdIfU3u8ASOw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2239;5:gXLMb6IlUad3x7u+1htk2i2hdN9Yoi8I6d0xJ3aQ5IIKJibpQ82M4ZJBbjOVTVFwg5JUPX+LMkuACuEFlH7Vf6siVfeFwnrti6lPQ5kRabxOfQOCq8LMnHKrEqH/Vh6Yn4iwHjfayNIhv9ypskSJ1g==;24:UNunDo6BY2m3DPp6HavTJ6oSDvOx6Rde1uo95XxOuqGeF3HjLc5F9fXJLwhOvHHHvh8OyVANuNnLlk0iYGWiU9NRF/O5fkBClkxLVMa3oy4=;7:JBl8rYyozPvbhErlTyKjyXjpMNVmDWn9FHoQYiF4NN8JFxtO886VYIcwXQ3DnfLMJt4O+U1jYaKfnwQj3/R4+z6UfoZqc6K+4GuGPlsZqntTJ88UZVBKQVWhujbHQ2idJcNHyyJAKWi0ITbkEZ/wa+WnHRoBO0AhHbjw4HIxysY+JDAmlDmVNW3OCKp8PtAF SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 18:04:05.5520 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR07MB2239 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 12, 2016 at 06:22:03PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 07:06:03PM +0300, Yury Norov wrote: > > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h > > index 24ed037..fda75ce 100644 > > --- a/arch/arm64/include/asm/elf.h > > +++ b/arch/arm64/include/asm/elf.h > > @@ -138,7 +138,10 @@ typedef struct user_fpsimd_state elf_fpregset_t; > > */ > > #define ELF_PLAT_INIT(_r, load_addr) (_r)->regs[0] = 0 > > > > -#define SET_PERSONALITY(ex) clear_thread_flag(TIF_32BIT); > > +#define SET_PERSONALITY(ex) do { \ > > + clear_thread_flag(TIF_32BIT); \ > > + set_fs(TASK_SIZE_64); \ > > +} while (0) > > > > #define ARCH_DLINFO \ > > do { \ > > @@ -181,7 +184,11 @@ typedef compat_elf_greg_t compat_elf_gregset_t[COMPAT_ELF_NGREG]; > > ((x)->e_flags & EF_ARM_EABI_MASK)) > > > > #define compat_start_thread compat_start_thread > > -#define COMPAT_SET_PERSONALITY(ex) set_thread_flag(TIF_32BIT); > > +#define COMPAT_SET_PERSONALITY(ex) do { \ > > + set_thread_flag(TIF_32BIT); \ > > + set_fs(TASK_SIZE_32); \ > > +} while (0) > > + > > #define COMPAT_ARCH_DLINFO > > extern int aarch32_setup_vectors_page(struct linux_binprm *bprm, > > int uses_interp); > > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h > > index 0685d74..5b269e6 100644 > > --- a/arch/arm64/include/asm/uaccess.h > > +++ b/arch/arm64/include/asm/uaccess.h > > @@ -60,7 +60,7 @@ extern int fixup_exception(struct pt_regs *regs); > > #define KERNEL_DS (-1UL) > > #define get_ds() (KERNEL_DS) > > > > -#define USER_DS TASK_SIZE_64 > > +#define USER_DS TASK_SIZE > > We can avoid the USER_DS change as long as SET_PERSONALITY updates the > thread's addr_limit. There are very few explicit set_fs(USER_DS) calls > and they are on the thread exit path (or exec). > > That's unless we try to make a generic set_fs(USER_DS) addition to > something like setup_new_exec() and we wouldn't need the SET_PERSONALITY > changes: > I think we'd better leave it fixed. Just because it's correct. Now it looks like we have fixed early usages (before SET_PERSONALITY()) of set_fs() explicitly, and normal usages (and possible in future) by fixing USER_DS. > diff --git a/fs/exec.c b/fs/exec.c > index c4010b8207a1..54cc537f5986 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1226,6 +1226,9 @@ EXPORT_SYMBOL(would_dump); > > void setup_new_exec(struct linux_binprm * bprm) > { > + /* set the address limit for the new executable */ > + set_fs(USER_DS); > + > arch_pick_mmap_layout(current->mm); > > /* This is the point of no return */ > > > #define get_fs() (current_thread_info()->addr_limit) > > > > static inline void set_fs(mm_segment_t fs) > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > > index 8062482..2b25930 100644 > > --- a/arch/arm64/kernel/process.c > > +++ b/arch/arm64/kernel/process.c > > @@ -211,17 +211,13 @@ static void tls_thread_flush(void) > > { > > asm ("msr tpidr_el0, xzr"); > > > > - if (is_compat_task()) { > > - current->thread.tp_value = 0; > > - > > - /* > > - * We need to ensure ordering between the shadow state and the > > - * hardware state, so that we don't corrupt the hardware state > > - * with a stale shadow state during context switch. > > - */ > > - barrier(); > > - asm ("msr tpidrro_el0, xzr"); > > - } > > + /* > > + * We need to ensure ordering between the shadow state and the > > + * hardware state, so that we don't corrupt the hardware state > > + * with a stale shadow state during context switch. > > + */ > > + barrier(); > > + asm ("msr tpidrro_el0, xzr"); > > } > > Why did you dropped tp_value initialisation? Context switching on native > 64-bit tasks rely on copying the tpidr_el0 in and out of tp_value. > However, compat tasks use the read-only tpidrro_el0 register set > explicitly via a system call. Until this call happens, the TLS register > would contain some garbage after the thread has been switched back in. > OOPS, my fault. I just missed a line. Should I send v3, or you or Arnd can apply it and fix in your branch? > -- > Catalin > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel