From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755542AbcA1Qbm (ORCPT ); Thu, 28 Jan 2016 11:31:42 -0500 Received: from mail-bn1bon0076.outbound.protection.outlook.com ([157.56.111.76]:59472 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752787AbcA1Qbj (ORCPT ); Thu, 28 Jan 2016 11:31:39 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; Date: Thu, 28 Jan 2016 19:31:09 +0300 From: Yury Norov To: Heiko Carstens CC: , , , , , , , , , , , , , , Subject: Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic headers Message-ID: <20160128163109.GA8529@yury-N73SV> References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com> <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com> <20160128121618.GB5418@osiris> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160128121618.GB5418@osiris> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: VI1PR07CA0056.eurprd07.prod.outlook.com (25.164.94.152) To CO2PR07MB618.namprd07.prod.outlook.com (10.141.228.149) X-Microsoft-Exchange-Diagnostics: 1;CO2PR07MB618;2:HDIvykNm4SRdrBJO23rlRvgMYydlViNfFhuH0+ugz8lMAvE5blyBwgu7hjmp9zO2zSbhd2Di0fKMGdlg7f+ssdt5mpCS/oTc/EgcIHFfwqjvHh+7Ewk0CGltAnV2CTCUym6hqDy1a3GOBn56pBWRxg==;3:njsIga7c95cmY3i4uH6jmJhUELPJ0kdfpPYgvzYQHd/rUUpsmlEzBu6aJXK0HjA/dPY//gqMDMZYvarEEh4PVBdff3VXlq5myw5+XSE2nhlR3Lwr3mZ2vaJsgsKjmEeH;25:4vE+1j6FOPitQLLUeYNxK/lq5GFWrb3MTe2u0SB7TC/W230Hn6z67QunMWwJwKIJtd2+Xs9SHN3xvK2ZiOiu6S+zOZeyFH6mSqHU1QhRm7c1a1YYj45vp9ayzRtDTClpbgx0Bdo2jzW3g06CZN7A0H0+BEkSwCFP9DQ4K8b7pyNeW4eNwXmChsmh8o1HALx5mgi7VjWWbs4RIuuAbNHX4vExtLbHVPotqlRDl0S4zvmrq6O4M48lfd2qCsxvnIO2 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR07MB618; X-MS-Office365-Filtering-Correlation-Id: 3476b386-c440-4810-5110-08d328007ddd X-Microsoft-Exchange-Diagnostics: 1;CO2PR07MB618;20:Uantdl3HpsiFrwm9q+wznwi0zzBva1DnLBoXf4BFQ4lr08JwghF7WMgrb8oYQPCvjsgoRiYvDJMCz1Wjz4yPlsaVSb0ea+3V+YbnuB/xzNE7pV8rQVR51hCbj5mJJ8u4GICEWXjL8OtnEdwgFWjQx8f7rAOirNt+x8bRLgNt3cTO9w+1OfnUaFu0XjiBcXUxbNtTZlbAPa+1NlWTeoR8iAyeKKzG/DW6DEikm0l0m8FmKiNCpjST2gJERn6fjqS5edFPSAJSp7tOiuUwC/AeFfqJP3o0Q+ISgUM6a3ydHehRdNo3B+xaCHtq82u1UUtLe6Sf9/ONX8U8hgVul5FRjXaq6JJWl3LBPJLB759oC5IO4K5QPYqgHai7c9xOXT3b+uPczfRVr4XjM5tefFsxhUVTV49eu06eYSxMl20vCsaBGdcpghz2iuY1Zz9PwZO00XcYA0lrD048+I9dpyN26nKOILQ/P5IC9TTcyfBXTQViJnQ3aeKIkuj0kraT28g/CYsbVyF+jywi3li7pa4QFjN8aLh8EcBgSL4LqknjPq7Fxdb7fXiKUCkwKlIOgyRaVQ/NpXUF2wnks8Hc8IDpbj/N6USZLP/BNDQlXglnzFg= 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:CO2PR07MB618;BCL:0;PCL:0;RULEID:;SRVR:CO2PR07MB618; X-Microsoft-Exchange-Diagnostics: 1;CO2PR07MB618;4:hpC01MGa3PXa3Uk+HCvRZMEHMkyJbRhm+3b0AjeKcpkeWHh9lUfxX9K6dPy5MnCZQXy1NmtqTj9he7KwUY3Uo9X5ei0UzJr+YtMeYgsksKENDIMjuWzZk+upVRVrKUsORsdyjpq02qHqQuf/rb0GL2FNktIADfCLVvzRu3fG7mU300Oc+3nQ184Yw2Ohr01Cm4KUx3YmwCvwcj/jiU7SXUOJgCbDPt/AuUMlxlZmL2qAcIFJr/LSC7yz4D1euzCupkIA8vkLHuod6w3HZbmuaML16r7Ia6KdoLP4dVaFJ5vXSbHanc8PoTRU3KLA/h1vK0Abn/JnYOQEctumhXlFB/k+Qe9JC++U/auOR/4HdheiKJQ/9pNagQI1XX8WSQr9 X-Forefront-PRVS: 083526BF8A X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6069001)(6009001)(24454002)(199003)(189002)(19580405001)(47776003)(19580395003)(122386002)(40100003)(92566002)(97756001)(42186005)(50466002)(76506005)(83506001)(5008740100001)(23726003)(1096002)(6116002)(1076002)(3846002)(586003)(2906002)(33716001)(46406003)(4326007)(3470700001)(87976001)(66066001)(101416001)(2950100001)(54356999)(50986999)(105586002)(106356001)(5004730100002)(97736004)(5001960100002)(189998001)(110136002)(76176999)(33656002)(77096005)(81156007)(4001350100001)(41533002);DIR:OUT;SFP:1101;SCL:1;SRVR:CO2PR07MB618;H:localhost;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CO2PR07MB618;23:Uqi5gkWsJVS4UsjLKaifTuniEKpvPuXYFcHYy6oTgL?= =?us-ascii?Q?1ePDNzg8lpS0Z2Sfq6Ji7HQ9dy4L2e3GrTef6O0fu9RsOHmGeGN4MOjG0O3D?= =?us-ascii?Q?XwVr13W/yLJ5s0Bhdv1dt55AJQcJWgmQJNiWswvw1kJWDPUo3GbH3o7bYv0D?= =?us-ascii?Q?87zZHyaM4nvYd3UT0OY16gyX6H0zjSeUFZMIecIcaKMpGLkoMjOfDfFWJanJ?= =?us-ascii?Q?qDHW/Q5E/R0FSf+paCOiqRwPfmP14JO8z7WrsEerk6TzjZVeuPXV3srm73zD?= =?us-ascii?Q?NssjLuUHdOFRiYzrEC72gUWIjMFTDz0Qcv94UxCRidPOEvJgOK0NxGKBEqB+?= =?us-ascii?Q?1n+V1UL0JLpNnpkb5wku+Adg3WO2tGLVcr0p5zopVvoVzzPYJM8vW+mO6mx/?= =?us-ascii?Q?fzjZyPRHO5A994q8SWonQaebvIw99z/i4KTRjWS6OzAOAV8O+/GR1I3If9wh?= =?us-ascii?Q?UIQh0WiQ83Iggv1C9NsI3XgcmtGgJ+dAZ8w1JWDkv6HM3Aa/5I7xQC3ZvIdi?= =?us-ascii?Q?cTfZt/NL2BefoEhVriy5uvidIgI/f5WMUL5hb9pYM82PiTt0ULPanmaG4RCu?= =?us-ascii?Q?ZHDoLUzpMrfx594r81/2iR8QBK5VTS8IAETIZZgDTc+ik4GHBh777O2Bsq/b?= =?us-ascii?Q?J6roQk8s5GSXHHB9IbO0au0JRagtTVvobhXI7GR4egj55I38zTmZ175f+YJG?= =?us-ascii?Q?P/XkA0VO8pBcZsXUQVpFTHH1Rk19XvLLQiiyZ6aoNyFB7hdv7K53WJ7ddaKx?= =?us-ascii?Q?Ecrr412ld4vV/i4LIRP3vCK4xf0XAnLCa95srGEHTlT8QBo7jjDDlRaBxWCw?= =?us-ascii?Q?1L7tQ3XofphNcjqaRMg4ex0rsvFtefmO7hg5ijdd4MuPUuYCzPOOwzCcupEw?= =?us-ascii?Q?q4ySkF3x4jCrsUKVGvEN/HqQbEfuhSaDEmlGGne5OaCwbCJ6uBBtf1mkLGy0?= =?us-ascii?Q?T+VRAK0IQYa7c+KjgDbxQcT0Y41Q5qgsD88YTm+4BY8nPT1SMOxMJ8ImU9Fp?= =?us-ascii?Q?Yib/roUCkbr/8AAqOxUJ3ZwtNhR3ztU5Ie/qlH65cTkokY4ouY2V+0qWhWgd?= =?us-ascii?Q?hXLsmzRULTSMKY4f6d7+DiL4l/oTUS90IRGakNpVNBpSofj/906DVnbyikPE?= =?us-ascii?Q?95x/o8qPkIA+49m8dzxwInKPkdxLzrnAnt9bODctBxnK50a/uKM60gIg1k/m?= =?us-ascii?Q?7So3QSig7v3PBhRuwcoGrh+I4Sq0F7Ca95?= X-Microsoft-Exchange-Diagnostics: 1;CO2PR07MB618;5:3SCVeIDPGv/Rw6QCJD2gaV2WC3tFv5XteAr7Hr+SKgQ3PZKmN4/MlHq/bReK0vPyfxrHueN10GA31PU54ordidQUPYKW9teNSafD3GAVBa82x3QfPP+wQ5QM7O9dJjOSU+2zM/Sywo5Am/B7abh71g==;24:UvR9K9Nx1e7pv0i5mcFsdUTutcHirLtSpZxoiVDkmlFiWvqHkZ0pfa1fZK+R9RtvF7eVZ6OrdEG4bTi13pvJD6eyeiQjA9LXEHBiz6ddpfo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2016 16:31:36.0670 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR07MB618 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote: > Hello Yury, > > On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote: > > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's > > moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long, > > unsigned long and pointer types are all 32-bit length. > > > > linux/syscalls_structs.h header is introduced, because from now (see next patch) > > structure types listed there are needed for both normal and compat mode. > > > > cond_syscall_wrapped now defined two symbols: sys_foo() and compat_sys_foo(), if > > compat wrappers are enabled. > > > > Here __SC_WRAP() macro is introduced as well. s390 doesn't need it as it uses > > asm-generated syscall table. But architectures that generate that tables with > > C code (ARM64/ILP32) should redefine it as '#define __SC_WRAP(name) compat_##name'. > > > > Signed-off-by: Yury Norov > > ... > Hi Heiko, > How about if you rename SYSCALL_DEFINE_WRAP to SYSCALL_COMPAT_DEFINE which > has the semantics that no dedicated compat system call exists (aka system > call is compat safe). > > Then convert all existing SYSCALL_DEFINE'd system calls for which no compat > variant exists to SYSCALL_COMPAT_DEFINE. > > This would allow to specify "compat_sys_" in the compat system > call table for _all_ system calls. > We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_" symbol for each syscall. So if strong compat symbol will be declared somwere else, it will owerride the weak one. Being under COMPAT_WRAPPER config, it will not affect someone else except s390 and aarch64/ilp32. The downside of this approach is that we'll have to move wrapper machinery to 'include/linux/syscalls.h', thought under wrapper config. > No need to look up if a compat variant (or wrapper) exists or > sys_ should be used instead. Also no possibility for security > bugs that could creep in because SYSCALL_DEFINE has been used instead of > SYSCALL_DEFINE_WRAP. If we'll choose to stay with current approach, we'll definitely need to update documentation. > > Ideally the implementation would only generate an alias if no sign/zero > extension is necessary. > > Trivially this would be true for system calls without arguments like e.g. > sys_fork() which would get a compat_sys_fork alias without any further > code. > > I'm not sure how difficult it is to implement the same logic for system > calls that have parameters. That is: either generate a > compat_sys_ wrapper function, or if the SYSCALL_COMPAT_DEFINE > macro figures out that no zero sign extension is required, only an alias > without any additional code. > > I think in the long term something like this is much easier to maintain. > > Does that make sense? For me, the most important adwantage of this approach is that we don't need the list of 'magic' system calls anymore. It's even more important if we'll face a requirement to support ABI that differs from both natural and ilp32 ABIs. New __SC_COMPAT_CAST will do all the job for us. The downsides are that we'll have unneeded wrappers for some syscalls, if linker will not clear them, and wasting of space if we'll find no way how to explain compiler to generate simple alias when it's enough... I'll play with it and write you what I'll come to. Yury. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yury Norov Subject: Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic headers Date: Thu, 28 Jan 2016 19:31:09 +0300 Message-ID: <20160128163109.GA8529@yury-N73SV> References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com> <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com> <20160128121618.GB5418@osiris> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Content-Disposition: inline In-Reply-To: <20160128121618.GB5418@osiris> Sender: linux-arch-owner@vger.kernel.org List-Archive: List-Post: To: Heiko Carstens Cc: arnd@arndb.de, catalin.marinas@arm.com, schwidefsky@de.ibm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-arch@vger.kernel.org, Prasun.Kapoor@caviumnetworks.com, pinskia@gmail.com, agraf@suse.de, broonie@kernel.org, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com, Nathan_Lynch@mentor.com, klimov.linux@gmail.com List-ID: On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote: > Hello Yury, > > On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote: > > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's > > moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long, > > unsigned long and pointer types are all 32-bit length. > > > > linux/syscalls_structs.h header is introduced, because from now (see next patch) > > structure types listed there are needed for both normal and compat mode. > > > > cond_syscall_wrapped now defined two symbols: sys_foo() and compat_sys_foo(), if > > compat wrappers are enabled. > > > > Here __SC_WRAP() macro is introduced as well. s390 doesn't need it as it uses > > asm-generated syscall table. But architectures that generate that tables with > > C code (ARM64/ILP32) should redefine it as '#define __SC_WRAP(name) compat_##name'. > > > > Signed-off-by: Yury Norov > > ... > Hi Heiko, > How about if you rename SYSCALL_DEFINE_WRAP to SYSCALL_COMPAT_DEFINE which > has the semantics that no dedicated compat system call exists (aka system > call is compat safe). > > Then convert all existing SYSCALL_DEFINE'd system calls for which no compat > variant exists to SYSCALL_COMPAT_DEFINE. > > This would allow to specify "compat_sys_" in the compat system > call table for _all_ system calls. > We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_" symbol for each syscall. So if strong compat symbol will be declared somwere else, it will owerride the weak one. Being under COMPAT_WRAPPER config, it will not affect someone else except s390 and aarch64/ilp32. The downside of this approach is that we'll have to move wrapper machinery to 'include/linux/syscalls.h', thought under wrapper config. > No need to look up if a compat variant (or wrapper) exists or > sys_ should be used instead. Also no possibility for security > bugs that could creep in because SYSCALL_DEFINE has been used instead of > SYSCALL_DEFINE_WRAP. If we'll choose to stay with current approach, we'll definitely need to update documentation. > > Ideally the implementation would only generate an alias if no sign/zero > extension is necessary. > > Trivially this would be true for system calls without arguments like e.g. > sys_fork() which would get a compat_sys_fork alias without any further > code. > > I'm not sure how difficult it is to implement the same logic for system > calls that have parameters. That is: either generate a > compat_sys_ wrapper function, or if the SYSCALL_COMPAT_DEFINE > macro figures out that no zero sign extension is required, only an alias > without any additional code. > > I think in the long term something like this is much easier to maintain. > > Does that make sense? For me, the most important adwantage of this approach is that we don't need the list of 'magic' system calls anymore. It's even more important if we'll face a requirement to support ABI that differs from both natural and ilp32 ABIs. New __SC_COMPAT_CAST will do all the job for us. The downsides are that we'll have unneeded wrappers for some syscalls, if linker will not clear them, and wasting of space if we'll find no way how to explain compiler to generate simple alias when it's enough... I'll play with it and write you what I'll come to. Yury. From mboxrd@z Thu Jan 1 00:00:00 1970 From: ynorov@caviumnetworks.com (Yury Norov) Date: Thu, 28 Jan 2016 19:31:09 +0300 Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic headers In-Reply-To: <20160128121618.GB5418@osiris> References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com> <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com> <20160128121618.GB5418@osiris> Message-ID: <20160128163109.GA8529@yury-N73SV> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote: > Hello Yury, > > On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote: > > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's > > moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long, > > unsigned long and pointer types are all 32-bit length. > > > > linux/syscalls_structs.h header is introduced, because from now (see next patch) > > structure types listed there are needed for both normal and compat mode. > > > > cond_syscall_wrapped now defined two symbols: sys_foo() and compat_sys_foo(), if > > compat wrappers are enabled. > > > > Here __SC_WRAP() macro is introduced as well. s390 doesn't need it as it uses > > asm-generated syscall table. But architectures that generate that tables with > > C code (ARM64/ILP32) should redefine it as '#define __SC_WRAP(name) compat_##name'. > > > > Signed-off-by: Yury Norov > > ... > Hi Heiko, > How about if you rename SYSCALL_DEFINE_WRAP to SYSCALL_COMPAT_DEFINE which > has the semantics that no dedicated compat system call exists (aka system > call is compat safe). > > Then convert all existing SYSCALL_DEFINE'd system calls for which no compat > variant exists to SYSCALL_COMPAT_DEFINE. > > This would allow to specify "compat_sys_" in the compat system > call table for _all_ system calls. > We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_" symbol for each syscall. So if strong compat symbol will be declared somwere else, it will owerride the weak one. Being under COMPAT_WRAPPER config, it will not affect someone else except s390 and aarch64/ilp32. The downside of this approach is that we'll have to move wrapper machinery to 'include/linux/syscalls.h', thought under wrapper config. > No need to look up if a compat variant (or wrapper) exists or > sys_ should be used instead. Also no possibility for security > bugs that could creep in because SYSCALL_DEFINE has been used instead of > SYSCALL_DEFINE_WRAP. If we'll choose to stay with current approach, we'll definitely need to update documentation. > > Ideally the implementation would only generate an alias if no sign/zero > extension is necessary. > > Trivially this would be true for system calls without arguments like e.g. > sys_fork() which would get a compat_sys_fork alias without any further > code. > > I'm not sure how difficult it is to implement the same logic for system > calls that have parameters. That is: either generate a > compat_sys_ wrapper function, or if the SYSCALL_COMPAT_DEFINE > macro figures out that no zero sign extension is required, only an alias > without any additional code. > > I think in the long term something like this is much easier to maintain. > > Does that make sense? For me, the most important adwantage of this approach is that we don't need the list of 'magic' system calls anymore. It's even more important if we'll face a requirement to support ABI that differs from both natural and ilp32 ABIs. New __SC_COMPAT_CAST will do all the job for us. The downsides are that we'll have unneeded wrappers for some syscalls, if linker will not clear them, and wasting of space if we'll find no way how to explain compiler to generate simple alias when it's enough... I'll play with it and write you what I'll come to. Yury.