From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752654AbcELJUg (ORCPT ); Thu, 12 May 2016 05:20:36 -0400 Received: from mout.kundenserver.de ([217.72.192.74]:50376 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751497AbcELJUd (ORCPT ); Thu, 12 May 2016 05:20:33 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Yury Norov , catalin.marinas@arm.com, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, heiko.carstens@de.ibm.com, linux-doc@vger.kernel.org, Nathan_Lynch@mentor.com, agraf@suse.de, klimov.linux@gmail.com, broonie@kernel.org, bamvor.zhangjian@huawei.com, schwab@suse.de, schwidefsky@de.ibm.com, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com Subject: Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Date: Thu, 12 May 2016 11:19:21 +0200 Message-ID: <4326765.8HKKkI07Zs@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160512002000.GA30997@yury-N73SV> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <20160512002000.GA30997@yury-N73SV> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:mNUSD5mjPBvi7L7mr+VM9/vNasniTAAszdbyNALNE4vE8dJrMoM goIWPhiLX37uYoKWU5m8pG7PwpMLAIurvCcZIDQIikYYu3rq7q3Lw7nR2PlxE80igkNeHdT cMm6MqtbcyxuS5uFY8L/w9Nk0Pif0QiMUs9M9a0/S5dqwGKc9ZSHYxOnXGq2vrotBjU3qeM lUPK1HlLfKqejISwAbjdA== X-UI-Out-Filterresults: notjunk:1;V01:K0:2/DCAHZMIxg=:Z9XKzJH4Md1KWnW5j7t0Kr BiA4nCKn5J2OabvDSlSOwBXcMvx50LrQi2svKknxCA6ygkWeE2R62KN1cr9ILWKSwhaRn4gfb X7i3wT61/uj1SHWee8WdbQml4jL8/Xzuzl+NG/4ZOSa7G2LbVhxLlIlxR5mJRHmY3ISP5Ir1g I8aQgY2hJd58CWEEI+dilmQsUAquvQzTvEZ6lLMECgcIWmToNrrP7XUoMpVU9hzJhwCqFJklY fP68DxY4oIBXBjqG6f7NqqemLmoMmBvhpfvco82r8F7q85WGd0L7fHpFaSmx3OPAj2tdT3rml P9UXBVD7jTbF4pkTx3wzyJRntvlOK533dduGi9r0htdjvYA+vbT029pgSAvS3ET6782nmXi8G mPqZXk+pOT3PAZlslz+SuSyqJZd1cC4ylGoue+BJW47U+537KYv5s33C9bfZFCahKku3uMyaK Is0TT+HqpVFBWWRtlM3IGXX09RfB9xFX4spGwQ23p07voCVT9KII9Z5UjYxgongUhUKBo1NTZ uMsjILl/Tof4lxeO2RlQSOEXyJo+rXcw9pcYRyCDSzWGUIk69PciP/KNZGsRz/Mx2hsHdRegn z2mwwvm3PGZd9SYH3bK7FtmPjfjIPt75Qp8yaWBsVEIK2xVcz9HIb3+Wzu8qXA4vH10vull51 /STpWpnZnxOTSw7TzSu/CM7YkBTIBgkkjLAg8tDdNaGcMg4RU6f2EAxA1sqFZn4FVd5QVXSpR mCmew7UC6boLIAwz Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 12 May 2016 03:20:00 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. > > This patch fixes it. It also fixes USER_DS macro to return different > values depending on compat. > > This patch is enough to handle preadv02 and pwritev02, but problem #2 > is still there. > > Signed-off-by: Yury Norov > Good catch! Can you do a version of this patch that works on the current mainline kernel and can be backported to fix aarch32 emulation? For ilp32 mode, I think we can better fix arch/arm64/kernel/binfmt_ilp32.c as it is introduced. Arnd