From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932310AbcELPcB (ORCPT ); Thu, 12 May 2016 11:32:01 -0400 Received: from mail-bn1bon0096.outbound.protection.outlook.com ([157.56.111.96]:2513 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752177AbcELPb6 (ORCPT ); Thu, 12 May 2016 11:31:58 -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 18:27:21 +0300 From: Yury Norov To: Catalin Marinas CC: , , , , , , , , , , , , , , , , , Subject: Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Message-ID: <20160512152721.GA31729@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> <20160512143415.GD30205@yury-N73SV> <20160512145402.GI11226@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160512145402.GI11226@e104818-lin.cambridge.arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: AM2PR09CA0074.eurprd09.prod.outlook.com (10.160.228.170) To SN1PR07MB2240.namprd07.prod.outlook.com (10.164.47.146) X-MS-Office365-Filtering-Correlation-Id: 2857ade3-25a6-4cbd-43ab-08d37a7a8c4d X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2240;2:Fccy20kHI9WHHqF4/5ZanvOj07bDGFN6cDSFasQ2dc6D4j6mJct2yeo8/mLFgz+w7ktFOF4Isa32z0eSL2oNqGPRIkD/6I+0WzR/4o/VqHb8m0jVrE3MKJ2TI394NpICKNdYDlYEIpaaZO2ZiHPcUqmmx+JEUHtBgT47pUcKtRVvMVb2lO2+ziRGuVzpT96e;3:TY/fHkoEoZHRw+qLPvq8ohtMXhVEalgA2sYeCSltah3MeoKprWa6vksp5T4r1leqyd974G17y2fm3rCwLBXoYEvG4SO394nyxmOHtUpjRNNEkk+3q7f/R/QRKxpUZyAF;25:BXEOiGcz9uIp98F04SZtuRnRbY0NDNVplGqapUu/oAJbHia5Av+mVtCvVzIxbk3P+CJOj5uJZZo4i5il0i8u4IDPdDjyt1RwcKbc7CmRaK/k2JehC3zq3vBrDxfmLrcO+zNtIh9gU/W4UsWIggsQ5ZmeqJYGWAeylGpSgXdI/5/YVrdaVrtwQ8eJgXPgflNYHpaz6OSO0hIZY3+7RLs+ggOnKsOfzGxhZlRo3Ay9jYX3zuvZRTxEAAjTdq0d9MbNcaGEwJkrGyvq0y0jQBjjKq5ZA6oAqh9J7oKS/NFKVEdKeFzLHyLYWkedVpBYGiS3Te+B6P8B+H5fluXNwbgWWdiDZzk/ZpOzizz58wjMF4mNvc1UJQ4esXby4bVGDnG0Kzi0a47V2CdWm6KQYnAu5m/S68Fhs680ohYP69H2Bms= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2240; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2240;20:GKaoGkZvK7YZY3XW4dK/QIP1LTSMa29UbNMjH2SgPx4EpAhHqOOd6Ka8ZBvEGE4hXgJSFaj6ReawoCXYIAqajnKGJVqb/mt4+BxqNbzx25rnYhCeQnAiFeQ1hm/9kF6nGKTyDcOa/TqZp3RYVXot6gHoIdyh+F5btsLtYrbBERkQ7EKb5F+gVJxDHzRASW0QdVsRBfi4gxGaE7RjVr6WOF7wswfwaFAp0qK0Tv3M1rCO6C5bPy+1ZdbpqqMrm+GNI8B7mVH789885cAAlccYGHkyTprRqbuMz/W3PqLlITIwgtE7UwdGMjyeN9Wu8wUj5CVoY78AK8A8iL9BmU41Jc1aX8rVwuyJgTWduTPiBe8r1wFR4OBJ1dzDtxnRKnRhzCKaBlRwqFfAABoovJtlB82eWXtQAYi1lopJNDSUJ+RXK/p7SoKa4Fviji4Eawf+Vhyhn27GELWdLcw2aonYy0mrFQKhBIv1gu4X9hfjPUTHatOB9cOTxQuN14caG04Z64DWNkVSiUQRFmPrN9QZVEgso3OlSTVCKIA7pq8s/ZA2aMNFAhqQSPlFjLL/dXNcVqBUEpoBzAjqlOi+EwixCiSkNXmTJG6d23adw6lsmPg= 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:SN1PR07MB2240;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2240; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2240;4:i6BT6WcsvcyLVonQSr3jf2/PLc6yJpVK7choShYnudUi0PKJ16fGFkN1/9P6NNyvpsWJphEPQ5NiCDz4s0STcKoIVf3+zbQLUewuTa14fkATRUFDCusox8Wo7fKhrfvV6KwjSV2HVXmgwmrEM24VyI0qn+YSVKK5+UnqWpL/Z/oN+r19VVbHylMjJJBjFmcKNSCWkW6fxvXL3MgFNRZWA91f7wrW7rSAHmZzxnFLbMyQahAuglcipdR6pw9dJT2k+kE+1zq+HleI4kMMqrIQQ3fRw+F6nbt4Toxr/qzLpk5v6QSwDNm2lxxaiEkonHOarZ7OA53ezOddzpnL9ypADzL0ncbKd+MBN54hBLVO11uW/3UVC0iB6ilnO1uhqkaH X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6069001)(6009001)(24454002)(66066001)(4001350100001)(47776003)(33716001)(93886004)(5008740100001)(83506001)(1076002)(50986999)(54356999)(5004730100002)(42186005)(76506005)(97756001)(46406003)(76176999)(33656002)(110136002)(2950100001)(23726003)(586003)(77096005)(50466002)(189998001)(81166006)(9686002)(4326007)(92566002)(2906002)(3846002)(6116002);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR07MB2240;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2240;23:hdrAA+GZi4wfejppNTatDMjyOBYzadomSeuA4VwgcFcOVlLprhjKwJ2oxjjWHU12Sjglidp4l79CBnLNHINFTlNvPr1nSo1s3Dbg67jcUSeA2teTrXSH5ITWBiYrj4nRZM2385dZMNpBxa4JquTOgHca4dKIp8OxcR2z0L4PqwCannGfafeeog0BzrzIPOSseUFreFhjD1bEqXOf1Xs6+ohPbL59mz4aR26xYAlf0o4iEBMJnhO4elu5Bg8bJoqT1dhJHLfVSYnkj+20n+RerB0wZQB1ScG5dxwded0NmO3Su+rUEKD9HFV91ZMmuRWM0LZ4D3BkDFugFc1lPITVxt+7ARovs8o6fysWTpot1IXz13gTdhEJmIzE5fLFR727J3CqL3b58ExTnxgpTjbLFipb7LnOFN83WjCG/I01DiTDzSCaLsIu83G9FpnwfTk2XCYwgrqnUx9NuJL9dABAlZCWTrfJHaaHH+MSHiUaCHyYPnKp8uYmTDiEjlLWHqpk0XOCaggDJbXi2+L7gNQsAGLJ2WdQN4WCTWZ3UfIRJjWYtYobTgTtTTegAephOjgeOWkHsSUEs6mvZ/1rwDp1doienpNK2jDjjcjrchtY8Lg6Xezlf8IOETiyRiEvxnhcVfTMipvHFyj/8J7nbjZF5JJZiup+/eZHAjl//SecXsoy3cq4VQyI9O+YWhPUvDCSNqohfCBO0wqd8idF8TS/7K/szhXXPIDp8UlJoFbpnWDRLgCkcev5pbm2thSAjhTn9Z0SDseD+lA4jTgoQmk9buMiP/dCXpam6fIBPUTWqQKOL6wkan3kTjJhxe2U17ISrxXOLwKhViSAHQ3X+FULSkXI6UQYOjBIv7cC5zPd5vLGaQmkevqhZhDfwvoRidSwWJ07UStCBqgqUz6tqlDW41iAh8XXHPaJtxfs5AK4w6K4ZSub5k9t4F/4oNX+H864 X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2240;5:/LB9KGQRAyAA1zH9KtvVUi6qOTWO4VAi4xNyyLNwaw/OGGbhulzof/ExB7EaftLdyqH862G11IHUQ0NTKd/S0aK4RMcRr7AgW3LD78QLd9+APDHuWyDit2NZGNdLh6B3UONpT+wPCXVR/EKAImHi6A==;24:oU59jcyrDgAsv9ssihDARBGmUMBN+usEQTaR0Q2HLOq8fYfJBSXtJOym/n97v4htF4T+nIhW1GGhsza8W3nXDL8x8UOI26RtFLUo8yCQZMw=;7:1bEb/086+y1XDCJmXAQ7y9C9Y325u6NZoMU4EXPw0w+bSdH3jl6Een6wpQM5HW1wFi4x1CVQ1Mv+1uafEyjHcwxCHtNtbx2/Qu7B6VUtxCN+yt3hFW8Pk+dEsPNsamCDEvyaKJmG5sZuhFzj8DGGb95McGI9xPjUXxJa3J2B96cGpq65XbC7O+vSFQdYWbQ2 SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 15:31:54.4094 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR07MB2240 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 12, 2016 at 03:54:03PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 05:34:15PM +0300, Yury Norov wrote: > > 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. > > And that's correct. > > > 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? > > What I meant is that we rely on flush_old_exec() to initialise the TLS > register for the compat task but it currently depends on what the parent > is. I think tls_thread_flush() should actually drop the is_compat_task() > thread and always initialise all the TLS registers. > OK. I'll do it in v2. > -- > Catalin