From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753117AbcELOem (ORCPT ); Thu, 12 May 2016 10:34:42 -0400 Received: from mail-bn1bon0054.outbound.protection.outlook.com ([157.56.111.54]:33920 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751923AbcELOek (ORCPT ); Thu, 12 May 2016 10:34:40 -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 17:34:15 +0300 From: Yury Norov To: Catalin Marinas CC: , , , , , , , , , , , , , , , , , Subject: Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Message-ID: <20160512143415.GD30205@yury-N73SV> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <20160512002000.GA30997@yury-N73SV> <20160512133533.GF11226@e104818-lin.cambridge.arm.com> <20160512134431.GB30205@yury-N73SV> <20160512140734.GG11226@e104818-lin.cambridge.arm.com> <20160512142016.GH11226@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160512142016.GH11226@e104818-lin.cambridge.arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: DB5PR06CA0016.eurprd06.prod.outlook.com (10.162.165.26) To CY1PR07MB2230.namprd07.prod.outlook.com (10.164.112.144) X-MS-Office365-Filtering-Correlation-Id: b662057c-2f96-4fd1-10d7-08d37a728a69 X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;2:gix7+rElmNGcL9VgHtjaOj9btpQhLjVDgzBGH9kmvWgOJ2hMcgj6xxDNDizl999eVNVEtOt8oPOHAV1HGn4zFlQSwQOn/d/Bt8B2VXJ/hWX/N4laeBXY3TAFebQ/l3nbZdEb3s2UqdOyEC6KItGQyqAWkGz4djZ+l55iYbzEAg6lXZcLO9U0O/fUVxGyyMiA;3:cPtqhRM/oi684D8hUgIhN4jPRdn/QzTNzOxWiCJdREjs6lc4nZ8eeMonaE8gTF6ux70zivF3Lrcd5/+RhbazTiU5nkIJ1uyywFi54D+ZVcarUHzBu4JXu1E9Cp96BxkL X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2230; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;25:y92zSYgxPEQw6UqvSgzf9ad83UeGGZVE26wTy6lBImEbhJQTFpRcLuGn18W/dg6jkM9ggUvhfscSKQxUjaAas0I6nVL/mYzjGqwlslSYTQbnVI3dxUqNMEK9LI0I3Nmt7mCn0Z/wGKhDx0e7xBsBBhPllCHWdjp2sKelHyJVJbtBN8bdqpoRvXEGR1oWu9n8eDewtDHcyUVfB74YJXSlddDUeGsHfaScockSgEaAUZhtRQ3tHBW/FjraBtp6WpfNKFLuEPBWDtX5VvtXQdxoBDP0z4ZWtBbI/HRS92G9jywQKJGqqgIKK0hvCJV2Alp9hF34PpTMpFsxqdocn2NmeuANXcUWVPx/TcgwhcHe0aQyqBteEuo4dYBdpQlYLD/HepeW1wuCRKybhp6dbwv60Ba0R/WNitDeZfLWR2+ApLs311zaunou4l1RNDr9ytrdmvBYLJ3tZsJvXkBxJojmcJ6MVIGuspnYyUTr3crXf6p8pTftEXJK2vPP0pnuANQYA+9R5M0diMxBWLREu2oDMwwrsry+nKtPeNZmzl3vvg3GWs8tDAJ62iVpQGOHPjdJTnC04tESuA9dnfT6wegNwPVT4fFQdYycAtoIrirB7+6QafNgwvC32DkY5J99DsybTnvA+0lB8Leb3qso5PBoJBnz9drigiPkCCFPZmAzz4sreQI8LcwvzKr76Rn5uswRWdtNdPgqsV4cSwVC5AopbUG+0YoU3boXFaU1lU1cZtSofihQXAXwlFks4RSrDj06 X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;20:xhwnVVX5cOeVHRLeVqOadx8KTX34lY8p0xeiWyaoqUaVpojgm+exYJnp8LWsPCLYKtr1PWRRExt51EfU5y34DdDl+4mtSZnTXq+mi5sH4asI0ZlclTGCXVma84d9mNItel5W8J7lYGAJvhUd84vtkeSg8x0bACqsLJixOuC5oFDjIYcoKTiF7wqgdNeBRwRAIX0ekSSg1VrHENXtWNCVI37+flgYogy9W5q+2o/yDiQ+qMzvl4SN66fNHDFLZKkNizVzmeNgc++H2COnUQycYLjFD5ADh8lHYWsz4U+eCtRauF5yjLGoC4zQZoP6URbWDYsck6YQ9QFQ/UCl7r1POBgY9prltr2CH0IMu6BJgXhK1/VdPVCuV6uGs8GzViI2BaDEavjzJk8A00Js3AXRu0cjrEgM5Bkag9BJR+MsG4RLPRZlAvHgVV3FXqWaegxrQomDfuij26PBhwpkzV2IkOq5NFyTkDyynb8ISIx7t+sB/uJkQGPHxOuwjy5+jM3VlBX51tLj8Y6VKMKl4OQ5ODcxu+7iuXnkQbDzd25tsToRc3h2OQQrgtfw3zpOsMzXfVCkg1zN5dxMZnarDQTl3ySN9uI1FmIYQSPr3satNFc= 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)(3002001)(10201501046);SRVR:CY1PR07MB2230;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2230; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;4:aKsr0TIekHRSqa/bdztGSoxS4F1NCweGPBgTX+I+WYCRRmGFV2L8La4PRXqqQPSZ9YqfM2YtkTXISJ/GnGtjUlJOAEpuhGFRpU42WaOItE1LtoL9DsazAZ8K08hBCCfk/XF1GgcFCpA/a3Lbc4tVdP6uRO5u0tnFQk8Q/JNZBU3d3l+ii4IAVrgH1g+TyiivtRGAiI5w6Bg8T8ylDMxgTviLzS8U7EMz3AzoCWcQoklUEyxS3nenSa0ePBBuzoqeNxBnyyR3DG34Z4lI5bcfvKqTdhprDp6zDVOWz6zdN9eK8eREngiz3Oplvx+0rr9xF5Z0YG0Sz8nN3leuOlBusU9pUAp+uGdHpfL1GMF/+r/tbk6JFtZQmrNrTcA2pTiV X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6069001)(24454002)(66066001)(189998001)(110136002)(83506001)(81166006)(6116002)(42186005)(23726003)(586003)(76506005)(3846002)(4001350100001)(5008740100001)(1076002)(46406003)(76176999)(54356999)(50986999)(9686002)(47776003)(2950100001)(33716001)(93886004)(5004730100002)(97756001)(2906002)(50466002)(92566002)(33656002)(77096005);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR07MB2230;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;23:pgiaEXlfBieYn52yGhhhQvN8fBn2rnSJ5QxhbXCim1+WwfkJhV0HnAmVGrRJ7rZxZ2c4qCCN2gqDrJXVOnsuRil5fResRqy9IG+FOPFE2HZaBBSS1kZnk1wfVjYmtgSwUaxuvu8CPSbebWqW5LQnH3L44siRSpd9RnGtT8hEE3WH4UBdGO9p7DRfcq/T6QMy/Ry5J/bVe7CdW2/YWAgtD+t2kOjhYWuSrC0woJMA6aFLRpmxjgai8NafPkaOIPdImnuiTij475NUyvvmPCzKJebsgqLAswGEQWsyDMbrYVv3Wr4TidGNaH6FxXqNfDkJvx/4IGS8alu/rnr/0GKSvvzUEIoMwkHxZwP02LQVWhE94bK6B8j0jqtsHwRIJWA6ekpwRGL8mh+0mWual/zPfY/m+lvwHxy4kliyGy5XU40BElfWfglHfqHkfcHCI3zVAgZ2BBKsDMKZj7+vg1u7Sx4eZbxw3RPWq8FDZfEJrURjgrwdYIO2s8p356rlu57j9O0EaawmYRHUq8yzbfsldyClKZTMA3Cx+OUoY/uI4c4q3c7I8saiIQGchdcZEXhNhorJjVRoJjsEtqg88+yYKX2AiusnngegB3vZ/UZE3ouSh1eq/Jijs7ldNjUWSkcfUBn06J4pLc4PE6zsg4Yy7GdwpTqw0Y6EOLla3YJoY04/e8Lz1BJ3AUavQc67FfG/86eDapr2sbgDuivjFk3xnsnn2Ffnbp1IzPxF5MCfaK/jVfM4XGJadrPlbHMZ9E1SqcDfe2HhAQeCGJfVqxHDdMQbUrEGyca9/YMCqUJZnI5/3zMkdNA27RynyJ7H+JuhS3PRvigRoRx7j8VztMf6yrwvGKff6un70n7gIZLkulrD/WEJMfz7MpYvuIj9u4OunB/+hhT2Xcrtu1yQ+mYFz83Y7DkWDo/i8ne85cw0vkE= X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;5:jvEN0XbQzxXmdS3qogw3xYg6AjrB7B5F8N7fhGFy4Go0qPGQnjeCsbX5YwEBnn+6ejgCLmPYx2/8i7x3Tzh4DJk3Qtyom+CulsH7znCqIFldy+vk3SEHt0390P3L6h/d8Hb8M0vAdds/FIYRDtcqOw==;24:dFbXdLCotvRlO9KbQxeTMvreVoBfnCMI016qwY0SHrk8OTM3iUeM/ni/+QfyTS88XShnOD0didtdYaHcSvf+cl9TYzeKHdqffaAs9Iuh/r8=;7:qvm7ZbAT8M4cnZuR2JFpfR9UQ7kl7vg1ytlcUlWX+wfxxiU5b0UtSjWO/2+RbYe0kZdTXcw9LDXJ7cWS0D8B71aHFqYc5sVDP0YAQYzbKQFFxluKsJiXRSRjeK+2GJJ6ZyPfxb6wSvdXCn/Q2QgxilwF2Y1cinUUCzYoAS/LzoPsDFyYWcWeXvSLh+d/QXfj SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 14:34:35.2154 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2230 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote: > > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote: > > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote: > > > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote: > > > > > I debugged preadv02 and pwritev02 failures and found very weird bug. > > > > > Test passes {iovec_base = 0xffffffff, iovec_len = 64} as one element > > > > > of vector, and kernel reports successful read/write. > > > > > > > > > > There are 2 problems: > > > > > 1. How kernel allows such address to be passed to fs subsystem; > > > > > 2. How fs successes to read/write at non-mapped, and in fact non-user > > > > > address. > > > > > > > > > > I don't know the answer on 2'nd question, and it might be something > > > > > generic. But I investigated first problem. > > > > > > > > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to > > > > > validate user address, and on arm64 it ends up with checking buffer > > > > > end against current_thread_info()->addr_limit. > > > > > > > > > > current_thread_info()->addr_limit for ilp32, and most probably for > > > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail. > > > > > It happens because on thread creation we call flush_old_exec() to set > > > > > addr_limit, and completely ignore compat mode there. > > > > [...] > > > > > > > --- a/arch/arm64/kernel/binfmt_elf32.c > > > > > +++ b/arch/arm64/kernel/binfmt_elf32.c > > > > > @@ -12,6 +12,7 @@ > > > > > do { \ > > > > > clear_thread_flag(TIF_32BIT_AARCH64); \ > > > > > set_thread_flag(TIF_32BIT); \ > > > > > + set_fs(TASK_SIZE_32); \ > > > > > } while (0) > > > > > > > > > > #define COMPAT_ARCH_DLINFO > > > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c b/arch/arm64/kernel/binfmt_ilp32.c > > > > > index a934fd4..a8599c6 100644 > > > > > --- a/arch/arm64/kernel/binfmt_ilp32.c > > > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c > > > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t cputime, > > > > > do { \ > > > > > set_thread_flag(TIF_32BIT_AARCH64); \ > > > > > clear_thread_flag(TIF_32BIT); \ > > > > > + set_fs(TASK_SIZE_32); \ > > > > > } while (0) > > > > > > > > I don't think we need these two. AFAICT, flush_old_exec() takes care of > > > > setting the USER_DS for the new thread. > > > > > > That's true, but USER_DS depends on personality which is not set yet > > > for new thread, as I wrote above. In fact, I tried correct USER_DS > > > only, and it doesn't work > > > > Ah, it looks like load_elf_binary() sets the personality after > > flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the > > maximum 64-bit task value, so they should have a similar issue with > > native 32-bit vs compat behaviour. > > I think we have another problem. flush_old_exec() calls the arm64 > flush_thread() where tls_thread_flush() checks for is_compat_task(). So > starting a 32-bit application from a 64-bit one not go on the correct > path. As per now, all native, aarch32 and ilp32 tasks can exec() any binaries they need. Are you think it's wrong? If so, how we coild run first compat application (maybe shell), it there are only lp64 tasks on the system? > > -- > Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yury Norov Subject: Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Date: Thu, 12 May 2016 17:34:15 +0300 Message-ID: <20160512143415.GD30205@yury-N73SV> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <20160512002000.GA30997@yury-N73SV> <20160512133533.GF11226@e104818-lin.cambridge.arm.com> <20160512134431.GB30205@yury-N73SV> <20160512140734.GG11226@e104818-lin.cambridge.arm.com> <20160512142016.GH11226@e104818-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Content-Disposition: inline In-Reply-To: <20160512142016.GH11226@e104818-lin.cambridge.arm.com> Sender: linux-doc-owner@vger.kernel.org List-Archive: List-Post: To: Catalin Marinas Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, arnd@arndb.de, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, heiko.carstens@de.ibm.com, linux-doc@vger.kernel.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, broonie@kernel.org, bamvor.zhangjian@huawei.com, linux-arm-kernel@lists.infradead.org, schwab@suse.de, schwidefsky@de.ibm.com, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com List-ID: On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote: > > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote: > > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote: > > > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote: > > > > > I debugged preadv02 and pwritev02 failures and found very weird bug. > > > > > Test passes {iovec_base = 0xffffffff, iovec_len = 64} as one element > > > > > of vector, and kernel reports successful read/write. > > > > > > > > > > There are 2 problems: > > > > > 1. How kernel allows such address to be passed to fs subsystem; > > > > > 2. How fs successes to read/write at non-mapped, and in fact non-user > > > > > address. > > > > > > > > > > I don't know the answer on 2'nd question, and it might be something > > > > > generic. But I investigated first problem. > > > > > > > > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to > > > > > validate user address, and on arm64 it ends up with checking buffer > > > > > end against current_thread_info()->addr_limit. > > > > > > > > > > current_thread_info()->addr_limit for ilp32, and most probably for > > > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail. > > > > > It happens because on thread creation we call flush_old_exec() to set > > > > > addr_limit, and completely ignore compat mode there. > > > > [...] > > > > > > > --- a/arch/arm64/kernel/binfmt_elf32.c > > > > > +++ b/arch/arm64/kernel/binfmt_elf32.c > > > > > @@ -12,6 +12,7 @@ > > > > > do { \ > > > > > clear_thread_flag(TIF_32BIT_AARCH64); \ > > > > > set_thread_flag(TIF_32BIT); \ > > > > > + set_fs(TASK_SIZE_32); \ > > > > > } while (0) > > > > > > > > > > #define COMPAT_ARCH_DLINFO > > > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c b/arch/arm64/kernel/binfmt_ilp32.c > > > > > index a934fd4..a8599c6 100644 > > > > > --- a/arch/arm64/kernel/binfmt_ilp32.c > > > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c > > > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t cputime, > > > > > do { \ > > > > > set_thread_flag(TIF_32BIT_AARCH64); \ > > > > > clear_thread_flag(TIF_32BIT); \ > > > > > + set_fs(TASK_SIZE_32); \ > > > > > } while (0) > > > > > > > > I don't think we need these two. AFAICT, flush_old_exec() takes care of > > > > setting the USER_DS for the new thread. > > > > > > That's true, but USER_DS depends on personality which is not set yet > > > for new thread, as I wrote above. In fact, I tried correct USER_DS > > > only, and it doesn't work > > > > Ah, it looks like load_elf_binary() sets the personality after > > flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the > > maximum 64-bit task value, so they should have a similar issue with > > native 32-bit vs compat behaviour. > > I think we have another problem. flush_old_exec() calls the arm64 > flush_thread() where tls_thread_flush() checks for is_compat_task(). So > starting a 32-bit application from a 64-bit one not go on the correct > path. As per now, all native, aarch32 and ilp32 tasks can exec() any binaries they need. Are you think it's wrong? If so, how we coild run first compat application (maybe shell), it there are only lp64 tasks on the system? > > -- > Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: ynorov@caviumnetworks.com (Yury Norov) Date: Thu, 12 May 2016 17:34:15 +0300 Subject: [RFC6 PATCH v6 00/21] ILP32 for ARM64 In-Reply-To: <20160512142016.GH11226@e104818-lin.cambridge.arm.com> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <20160512002000.GA30997@yury-N73SV> <20160512133533.GF11226@e104818-lin.cambridge.arm.com> <20160512134431.GB30205@yury-N73SV> <20160512140734.GG11226@e104818-lin.cambridge.arm.com> <20160512142016.GH11226@e104818-lin.cambridge.arm.com> Message-ID: <20160512143415.GD30205@yury-N73SV> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote: > > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote: > > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote: > > > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote: > > > > > I debugged preadv02 and pwritev02 failures and found very weird bug. > > > > > Test passes {iovec_base = 0xffffffff, iovec_len = 64} as one element > > > > > of vector, and kernel reports successful read/write. > > > > > > > > > > There are 2 problems: > > > > > 1. How kernel allows such address to be passed to fs subsystem; > > > > > 2. How fs successes to read/write at non-mapped, and in fact non-user > > > > > address. > > > > > > > > > > I don't know the answer on 2'nd question, and it might be something > > > > > generic. But I investigated first problem. > > > > > > > > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to > > > > > validate user address, and on arm64 it ends up with checking buffer > > > > > end against current_thread_info()->addr_limit. > > > > > > > > > > current_thread_info()->addr_limit for ilp32, and most probably for > > > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail. > > > > > It happens because on thread creation we call flush_old_exec() to set > > > > > addr_limit, and completely ignore compat mode there. > > > > [...] > > > > > > > --- a/arch/arm64/kernel/binfmt_elf32.c > > > > > +++ b/arch/arm64/kernel/binfmt_elf32.c > > > > > @@ -12,6 +12,7 @@ > > > > > do { \ > > > > > clear_thread_flag(TIF_32BIT_AARCH64); \ > > > > > set_thread_flag(TIF_32BIT); \ > > > > > + set_fs(TASK_SIZE_32); \ > > > > > } while (0) > > > > > > > > > > #define COMPAT_ARCH_DLINFO > > > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c b/arch/arm64/kernel/binfmt_ilp32.c > > > > > index a934fd4..a8599c6 100644 > > > > > --- a/arch/arm64/kernel/binfmt_ilp32.c > > > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c > > > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t cputime, > > > > > do { \ > > > > > set_thread_flag(TIF_32BIT_AARCH64); \ > > > > > clear_thread_flag(TIF_32BIT); \ > > > > > + set_fs(TASK_SIZE_32); \ > > > > > } while (0) > > > > > > > > I don't think we need these two. AFAICT, flush_old_exec() takes care of > > > > setting the USER_DS for the new thread. > > > > > > That's true, but USER_DS depends on personality which is not set yet > > > for new thread, as I wrote above. In fact, I tried correct USER_DS > > > only, and it doesn't work > > > > Ah, it looks like load_elf_binary() sets the personality after > > flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the > > maximum 64-bit task value, so they should have a similar issue with > > native 32-bit vs compat behaviour. > > I think we have another problem. flush_old_exec() calls the arm64 > flush_thread() where tls_thread_flush() checks for is_compat_task(). So > starting a 32-bit application from a 64-bit one not go on the correct > path. As per now, all native, aarch32 and ilp32 tasks can exec() any binaries they need. Are you think it's wrong? If so, how we coild run first compat application (maybe shell), it there are only lp64 tasks on the system? > > -- > Catalin