From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932296AbcELNo7 (ORCPT ); Thu, 12 May 2016 09:44:59 -0400 Received: from mail-bn1on0056.outbound.protection.outlook.com ([157.56.110.56]:46496 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932109AbcELNo4 (ORCPT ); Thu, 12 May 2016 09:44:56 -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 16:44:31 +0300 From: Yury Norov To: Catalin Marinas CC: , , , , , , , , , , , , , , , , , Subject: Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Message-ID: <20160512134431.GB30205@yury-N73SV> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <20160512002000.GA30997@yury-N73SV> <20160512133533.GF11226@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160512133533.GF11226@e104818-lin.cambridge.arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: AM3PR03CA016.eurprd03.prod.outlook.com (10.141.191.144) To BN4PR07MB2226.namprd07.prod.outlook.com (10.164.63.144) X-MS-Office365-Filtering-Correlation-Id: fba800f6-183b-4c6d-7c9d-08d37a6b982a X-Microsoft-Exchange-Diagnostics: 1;BN4PR07MB2226;2:ig/ymL5IR2+incN0N/J/IfhkedtYkTHpaqxSr2yhsfmY9bhHpfxdh68J27OVaWW2E/pjxTSbyOMxnZC8j2Y4d/bRpbMazUwz2sggqcfj57I7o3MeMfoSpWjaeyl3UtKEHq7VJbSc481Vhm5QN1n3TpbNbntjRCCiGeC+TqZ8E4WezQ2FARlgje/nPlXkoq9l;3:6elLdd6Nb8P4SQm/ZRa3Tsm2URDU2XqCNXFijEszFMhxHHm0BQUIgFTshr5LPYXR4zBFcm0C/oJ5/YolVFHXKD7+T+rz4uJZnlzGvhFp1rwLRjwPXRMfvQWMfg9G1Aoy X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN4PR07MB2226; X-Microsoft-Exchange-Diagnostics: 1;BN4PR07MB2226;25:RABJzlCCL8YMxHAZBE5dSTEJO8wIDxA8YI2r7Dn0EnIgC/51id0aZE6w9KQFa4JcVF93XSmGKn5CmRV7F5v2Nsfe+NSQt2cfdCT+o8aO7kGoOBK3xqu5ZC3oiAR5iYdEO+MRmtuo/Oeb7HMf+ISXKkpLvB213JyHHvIPRn2enqtC55QGDHPpPLEwjK/YUA0CQf+NL7kRyEFRBAv11roc2A7RCFzmzQwtfc2bsGjp2JVCaf8UzQ+nQbFsv8ZSG2nVHEOogvpHlOgropDsoxXgTeKm3PpcSIZ9X/Aarr8fEe6fMVoqabgwmb0aMaELyKedXPHGUNWtYu2mant1NRRVNOgIl3TQ3NLUwUKrqtEWVwP6Bv4sSPZSwtfWKagKAOrRlJVeSl+XYa+nlDDVRTI7BRpWDK3huyXJccuzjV4V7cOXfuX6oZ1FpQOLbCpjR+yHRvsOi5RofeLtWA5h8lk2QOGZJL7H9SPy3zT/vzvN2eODR1Yuyz6RSwJzpjmycGVh5AFQJ6z9kn5zrPyocZbVMcgq67+uLYMQreZzfVVinyx+piQKIKRaAyLoYMNGXhwRXKLMtv3rdkLNiEVwIyCN1C7nB6KRul27uJNm0uXhbSOQkdUkJYhQbYNhyQegGQv8L2bgoavYPrwnxA4sjL7nI5TqASUe//4lvRtY7isWGLH/urK6DgVq1jqENTHYF0HWi+T2AuBt302saS7Nf7vX0jls/tUMSHpf5hqIm1xhmjocfspARiqPPL8Et8g1uyzb X-Microsoft-Exchange-Diagnostics: 1;BN4PR07MB2226;20:UUB5SPqGAewkST09jl6jnAePNGwGIqSxqka/v/mmbndqaQANsijcmqbG6f2gKdae25tPo/nrUlp89AaZ2/Zl5eC/mVuTomGH1phkhLwpYH6eUMld5SuV5fiCFX5nws60bBQoTscny/9xihD43mVLjcsLXL/hpZ8T2JNKXUT0M5xRE8/MyhIA8is7pwygoHPPYx/ojxw/1SUwg4E48Gvqj9be5egiF4j0+7RqTbLyhgFy/pfLiRHb/xpdO59nD2PLygVSz4A4tzUHgJ/TkPApJyC+a7ejjlLSOYhZACTzV/tUMz/3ZltUD/AO2pK+ozk/p5lHCycZpGAgnlvxRG9tRrcQXdJjxEu0UZG85G2IMNiMvtUogpui0NedVm5nFiZMRjKZuQg0NW8PECYL0ldGPnMLlj/Y35pU7H9qFZFuvB3zQODh6MexsG5XMNlUJpZLA4fUnGb/ZVWBLCcYdG1ixfCDmTCk6LUmrY8kgfI+TUkAAsB22c9LPgG1CZJsxIdHuVwmNWS03wclp7lgUalMwJZx0o+VNobu0LNzomCeTBkub58nYoNpyulls10G98dJg4ZYWF9ISKT9itIIeYk31jbgWnuuwu4WXEosV+2t3i4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001);SRVR:BN4PR07MB2226;BCL:0;PCL:0;RULEID:;SRVR:BN4PR07MB2226; X-Microsoft-Exchange-Diagnostics: 1;BN4PR07MB2226;4:SN6VM7eALK8KHLX7G4dAAuawanL4FEEXLKWsY1h7qXtds3qPZN6Q7jjAaaQ+gRR6G1EvmikdrOntdAc51BvzjeT6PaKjqzhm/4B9C1NkHfG0qFeH8M19SRJhRXA+iUACQUEo3G1YLe6jrHO+UHbM0MWvWC3sL58ocA22wZTGXUT5gtbkhIVSkWbfYbx4wKeBWVSeLo9wxNULVEXIQ6kAxmVbDLrKLNpmZid84opJqFviwhuTTFAesHD3CIXu1jw87JnaIHR+H8Nlm0qjfCk+4aEBrvvXTMtlQNB5c5tea1qdUy+X/WhDKU3eISHT9f05+yVACRbzbjlWBMV01XbIJ1kugFdaav6P0QXhilfDjLTU5T+rNMh3xtgTWdXMN/4j X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(979002)(6069001)(6009001)(24454002)(4001350100001)(92566002)(586003)(66066001)(2950100001)(9686002)(5008740100001)(54356999)(76176999)(46406003)(2906002)(189998001)(4326007)(81166006)(5004730100002)(77096005)(50986999)(33716001)(110136002)(83506001)(23726003)(76506005)(33656002)(47776003)(42186005)(1076002)(50466002)(6116002)(3846002)(575784001)(97756001)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1101;SCL:1;SRVR:BN4PR07MB2226;H:localhost;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN4PR07MB2226;23:Nx6ylrJ0pkswNTfESKPpFfVjPnPg+HDabnAKz18ds?= =?us-ascii?Q?ZWmgb49vU/CO8uPziXbVcn3XfbW9KOuvjM6hQazg6RLntUTkd7uoDz/mbkCP?= =?us-ascii?Q?D9rrFIAPJksvoxTAmDt6DuRxEWSs8/QW42SfTwjYOAicgnq7SXm7zkBgw/ep?= =?us-ascii?Q?rnptdLLHWY/Dx4WTB14dyGgZab69+BL55mN1iWCqhMhEBKVpQEb5JOTurv0M?= =?us-ascii?Q?ZMlhVJYlzMtM+oZXtMtxxLel0gOxOCUI6FQnJAZDZA9gopxBAkJKfAfYILgi?= =?us-ascii?Q?7l6raWimxVO0XDUfn+98tqyz08YYhaP+kGOPtl2AYC3bxRqg/9J0+9gxJA5+?= =?us-ascii?Q?3Dea/saAEE658pqXCqPiRingJYJJEBVRqjRMsfuOMaEQ4Ot5bq1WUbW0ZBDB?= =?us-ascii?Q?BmUJsBK8UWPL0Yv2/OT5DveftrShoQhUuWxKdGFxvtBDaEd75yIf+o5JDotG?= =?us-ascii?Q?plqKThtA2AhFmsyzpWb9K5cPr0GYRTzksZPe1ZInEIiQdMSRk/dp/iL79m++?= =?us-ascii?Q?2RyVVdO7Gt5gKtvalnd4enR9FetaMA/DHFEqMC06DXb3zweObd5vHeSDnL+X?= =?us-ascii?Q?/TnkIWX10QbUzWy/GC9mrt3/Aqt1tcRHugbHtYTGkEh2oTlGrMIMLSbh1xyt?= =?us-ascii?Q?9wjSzK4CYbxXpSM/4sK5QQE5VExVMSJeFtNrFElSiw+XZMd/Ub1uXmA5SZOk?= =?us-ascii?Q?uV/lxTeSMh8h+SGcadKHOn4f04KUPD2I1eChoa52zQevdLWPb0bgmX9vGuJZ?= =?us-ascii?Q?tXn5lVzx5qBMpM7AovumVMVNnTSGnSua89JsFGH8tHYHXck2qIszGfX1kmuh?= =?us-ascii?Q?MqrPK2q7QxMPQlmgCm1oTwDix6G0eEt5QHfr9vyN8Ce469JBI93GclsV+JgD?= =?us-ascii?Q?/uYN2FfPyC60B9PJ4UY8fN3vKx7pX4UIAfrw9J4L9Mw1E4R2tTuXP0qdv2+S?= =?us-ascii?Q?edKsmGEaLkKMsdvIj8AOZe0k1fwgOw9KolSVIm+aDmxntBeNu4JhII8pPFwb?= =?us-ascii?Q?QUh0Ah9ZxFYgCTJEUnW4xysGYny4Qg05+nwquuVb31rFQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN4PR07MB2226;5:aaIzFfpfH3PqmtsPpBPwdiL5aWP9pYy63yVOb6BbzbcHcPL/bHjDD5Brlk7ZM9SFRrmkaOreXjzEHLeItGOkG9VE026ptTYuMwkYCU0PKth/rbs4ggf3pJio/qxIL38IWHB5QuBHKxQNGV399jrR5Q==;24:V8y0ANxT+ch4kyVs81h++GQLy3VNkEMP9xb5HoO2Hl3FGkdXaIliA+ABkx/MBAbeuBmAJx/xBQ6xOqiWGoSASzy4VFfiOmb6+J33590DMFc=;7:0L7ivxNLGUvHTeIOAb24CoR+REgyvGuuGuRKnlq3slXPCrtitz0qBqYEzTNudL74vcWhUGJ65vhC3f6xbROEbPyZB6hLAYgK7/kfHDOuavIpcK5yMyVR+62Qg4yrQXNoomup+0lJbWp0DK2GnTvBVU97FAwzf+nkUhQfg3dQFTNVAmyOkciHnaVWjZFMhSpi SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 13:44:51.9101 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN4PR07MB2226 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > I assume accesses beyond this address would fault anyway but I haven't > checked the code paths. > > > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h > > index 7a39683..6ba4952 100644 > > --- a/arch/arm64/include/asm/elf.h > > +++ b/arch/arm64/include/asm/elf.h > > @@ -146,6 +146,7 @@ typedef struct user_fpsimd_state elf_fpregset_t; > > do { \ > > clear_thread_flag(TIF_32BIT_AARCH64); \ > > clear_thread_flag(TIF_32BIT); \ > > + set_fs(TASK_SIZE_64); \ > > } while (0) > > See below. > > > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h > > index 19cfdc5..3b0dd8d 100644 > > --- a/arch/arm64/include/asm/uaccess.h > > +++ b/arch/arm64/include/asm/uaccess.h > > @@ -51,7 +51,7 @@ > > #define KERNEL_DS (-1UL) > > #define get_ds() (KERNEL_DS) > > > > -#define USER_DS TASK_SIZE_64 > > +#define USER_DS TASK_SIZE > > I agree with this. > > > #define get_fs() (current_thread_info()->addr_limit) > > > > static inline void set_fs(mm_segment_t fs) > > diff --git a/arch/arm64/kernel/binfmt_elf32.c b/arch/arm64/kernel/binfmt_elf32.c > > index 5487872..2e8d9f3 100644 > > --- 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 > > -- > Catalin