From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yury Norov Subject: Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Date: Thu, 12 May 2016 15:59:09 +0300 Message-ID: <20160512125909.GA29077@yury-N73SV> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <573305A8.50406@huawei.com> <5733149C.4030903@huawei.com> <5250356.myv9GIZ34h@wuerfel> <5733FC71.8070101@huawei.com> <20160512082427.GA1587@yury-N73SV> <57347C9E.7010708@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <57347C9E.7010708@huawei.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: "Zhangjian (Bamvor)" Cc: linux-doc@vger.kernel.org, Andrew Pinski , catalin.marinas@arm.com, heiko.carstens@de.ibm.com, Hanjun Guo , joseph@codesourcery.com, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, "jijun (D)" , Prasun.Kapoor@caviumnetworks.com, schwab@suse.de, agraf@suse.de, Arnd Bergmann , pinskia@gmail.com, klimov.linux@gmail.com, broonie@kernel.org, linux-arm-kernel@lists.infradead.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, Andrew Pinski , schwidefsky@de.ibm.com, christoph.muellner@theobroma-systems.com List-Id: linux-arch.vger.kernel.org On Thu, May 12, 2016 at 08:52:46PM +0800, Zhangjian (Bamvor) wrote: > Hi, > > On 2016/5/12 16:24, Yury Norov wrote: > >On Thu, May 12, 2016 at 11:45:53AM +0800, Zhangjian (Bamvor) wrote: > > > >[...] > > > >>>Hmm, that is indeed tricky. I think COMPAT_SYSCALL_WRAP4 rightfully > >>>refuses the loff_t argument here, as the common case is that this is > >>>not possible. > >>It works if I apply the following patch, I defined the wrong `__TYPE_IS_xxx` > >>yesterday. Should we merge this into ILP32 series or send the compat.h > >>and syscalls.h individually? The current series of ILP32 is a little bit > >>long and hard to review. > >>diff --git a/include/linux/compat.h b/include/linux/compat.h > >>index ba6ebe0..22a9565 100644 > >>--- a/include/linux/compat.h > >>+++ b/include/linux/compat.h > >>@@ -747,7 +747,8 @@ asmlinkage long compat_sys_fanotify_mark(int, unsigned int, __u32, __u32, > >> #ifndef __SC_COMPAT_CAST > >> #define __SC_COMPAT_CAST(t, a) ({ \ > >> BUILD_BUG_ON((sizeof(t) > 4) && !__TYPE_IS_L(t) && \ > >>- !__TYPE_IS_UL(t) && !__TYPE_IS_PTR(t)); \ > >>+ !__TYPE_IS_UL(t) && !__TYPE_IS_PTR(t) && \ > >>+ !__TYPE_IS_LOFFT(t)); \ > > > >I think it's wrong, as loff_t is 64-bit in 32-bit userspace, and this > >will clear meaningful data in top halve. > Yes. It is my fault. The original thoughts is clear the up 32bit for size_t. > How should we skip the loff_t? > > Regards > > Bamvor I already suggested: For cases like this I think we should write wrappers by hands. In unistd.h we can use __SC_WRAP, so they will work like wrappers generated by COMPAT_SYSCALL_WRAPx() Do you see any downsides? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bn1bon0086.outbound.protection.outlook.com ([157.56.111.86]:51328 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751395AbcELNT1 (ORCPT ); Thu, 12 May 2016 09:19:27 -0400 Date: Thu, 12 May 2016 15:59:09 +0300 From: Yury Norov Subject: Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Message-ID: <20160512125909.GA29077@yury-N73SV> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <573305A8.50406@huawei.com> <5733149C.4030903@huawei.com> <5250356.myv9GIZ34h@wuerfel> <5733FC71.8070101@huawei.com> <20160512082427.GA1587@yury-N73SV> <57347C9E.7010708@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <57347C9E.7010708@huawei.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: "Zhangjian (Bamvor)" Cc: Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, Andrew Pinski , catalin.marinas@arm.com, heiko.carstens@de.ibm.com, Hanjun Guo , joseph@codesourcery.com, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, "jijun (D)" , Prasun.Kapoor@caviumnetworks.com, schwab@suse.de, agraf@suse.de, pinskia@gmail.com, klimov.linux@gmail.com, broonie@kernel.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, Andrew Pinski , schwidefsky@de.ibm.com, christoph.muellner@theobroma-systems.com Message-ID: <20160512125909.kDctwUvzJn9rsiZXYL-CfrsH3FJBOoCvMAgBRTbHN-o@z> On Thu, May 12, 2016 at 08:52:46PM +0800, Zhangjian (Bamvor) wrote: > Hi, > > On 2016/5/12 16:24, Yury Norov wrote: > >On Thu, May 12, 2016 at 11:45:53AM +0800, Zhangjian (Bamvor) wrote: > > > >[...] > > > >>>Hmm, that is indeed tricky. I think COMPAT_SYSCALL_WRAP4 rightfully > >>>refuses the loff_t argument here, as the common case is that this is > >>>not possible. > >>It works if I apply the following patch, I defined the wrong `__TYPE_IS_xxx` > >>yesterday. Should we merge this into ILP32 series or send the compat.h > >>and syscalls.h individually? The current series of ILP32 is a little bit > >>long and hard to review. > >>diff --git a/include/linux/compat.h b/include/linux/compat.h > >>index ba6ebe0..22a9565 100644 > >>--- a/include/linux/compat.h > >>+++ b/include/linux/compat.h > >>@@ -747,7 +747,8 @@ asmlinkage long compat_sys_fanotify_mark(int, unsigned int, __u32, __u32, > >> #ifndef __SC_COMPAT_CAST > >> #define __SC_COMPAT_CAST(t, a) ({ \ > >> BUILD_BUG_ON((sizeof(t) > 4) && !__TYPE_IS_L(t) && \ > >>- !__TYPE_IS_UL(t) && !__TYPE_IS_PTR(t)); \ > >>+ !__TYPE_IS_UL(t) && !__TYPE_IS_PTR(t) && \ > >>+ !__TYPE_IS_LOFFT(t)); \ > > > >I think it's wrong, as loff_t is 64-bit in 32-bit userspace, and this > >will clear meaningful data in top halve. > Yes. It is my fault. The original thoughts is clear the up 32bit for size_t. > How should we skip the loff_t? > > Regards > > Bamvor I already suggested: For cases like this I think we should write wrappers by hands. In unistd.h we can use __SC_WRAP, so they will work like wrappers generated by COMPAT_SYSCALL_WRAPx() Do you see any downsides?