From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755258AbbL3R3X (ORCPT ); Wed, 30 Dec 2015 12:29:23 -0500 Received: from mail-bn1bon0079.outbound.protection.outlook.com ([157.56.111.79]:52125 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753659AbbL3R3T (ORCPT ); Wed, 30 Dec 2015 12:29:19 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; Date: Wed, 30 Dec 2015 20:29:05 +0300 From: Yury Norov To: Arnd Bergmann CC: Catalin Marinas , , , , , , , , , , , , , , , Subject: Re: [PATCH v6 13/20] arm64: ilp32: share aarch32 syscall wrappers to ilp32 Message-ID: <20151230172905.GA8296@yury-N73SV> References: <1450215766-14765-1-git-send-email-ynorov@caviumnetworks.com> <201512222244.15155.arnd@arndb.de> <20151223133736.GB28445@e104818-lin.cambridge.arm.com> <201512232141.54384.arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <201512232141.54384.arnd@arndb.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: AM2PR02CA0031.eurprd02.prod.outlook.com (25.160.28.169) To BLUPR07MB611.namprd07.prod.outlook.com (10.141.207.16) X-Microsoft-Exchange-Diagnostics: 1;BLUPR07MB611;2:f5ug+agDJ/HShSwQXOc5duu+pIGqeCQCpz8xvjwZGtS+lNnzpjzAKxhtP/U5qnzO/wVXpPMpEZGZGFIr9/noMml9l5lveUHE5nDRwqZhrtEVFoKW7Tbok3xZq9WQDhm3GOPLmZJXO/QLBhbyXBO5dw==;3:QOnA0zCm2czxEG+q2SZyH/vVRnpeqFgx/eA2Yj88uMe87hbjOa4Q9aflD1LEvWYT96oogWG++uX7pqLadra3nKetNAV312j60zvNI5BNd6/jbzuuXpoMyU/FW4zDXXLn;25:Bh4l2Kxb+E7fen6fLwJjwVY8McC8jdXj9eewtrnGAwvsoKMhH6flR7OfHIp4MNYUYfrS7EgLZSgrpYhAysns8KhXlSTDnIXJcKm5X3JfRjg/3dR//uIgXFCJzbx3rG/d6IB8FcezbiSh1TKdHEGyHEYdf0tIPMi/uoI1O8QI00+2xS/n0vYYsVwZA9C/axAyhrRDCKskcCsrOBGJJxJ+6u2xr9Ce6m2Ww/a8Gf/aJdg7IpwVYS62I/9c/YnveI8SFl6OmBPHR20/lYduJQK6nQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR07MB611; X-Microsoft-Exchange-Diagnostics: 1;BLUPR07MB611;20:P7/sUeY2DFwIL7NLJfODgs0BOEeaLm0z7rp9sHtPfq6edRzEkQWVzLm2SC5FplNL3y8OP41SyvqIXpl9qP4nwh6CXHskhlxQ06m6OPotpNA5xRmGz4S/iDYX1drh9h7HtuevIYRXM/Nf1nkL+nguG9RaLeJHr/LQyENRu3WLy8s1KadJfkLAdSOB0MXf9MQAM0bYUv5SEw8jdvPTu7EdHtrpNQBAYoBASDbCwLWIizCSLXaTUakIhKn4gRavRYFqxrtL12oXeCZpaS0gdHNd1D1LmScv1PakyZfkr975N7LZ+iORYaxwLuwh2vaB79qneIvPHL5trusEsY/U0vzzqSHwywbt8Fr1Yqo+IZP5wkeJ1nqJdUU7r9LWY4qHGnOlYEnlVf5cwcjHk5OSYZNyFB9VVn5K+otZYy7VH7qLkomsDZOeW2K0LmXK93+dS6XJPahbsXrVi08WyqnCrn58sv0mi1ysmP4D6Cp8JbTK5lb0bg+7EEYRbBAPUoR96v5vUxq+Ni0dRu2gtP49yBicJuuZzV0lWlcRoQdecqZk3Khd0kyfDJAmZwv6MjQwXf+DEj4AQPL58dVgA4u4IgJW4hkNNDrJsb2ENKJd7dgl9OI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046);SRVR:BLUPR07MB611;BCL:0;PCL:0;RULEID:;SRVR:BLUPR07MB611; X-Microsoft-Exchange-Diagnostics: 1;BLUPR07MB611;4:kIj7q7FQneJk2Zp/pZPYQAHMzwYJppRCQnmAL9Gd754J8pvDINwDb8aykGqFtT5iOUTZA6e1+WYVpiIw9d/tTN41MpaK6+y5pHHgBGLHqu7chiOAzwAqrnfKoqaMSw+8y0Gsx/h75dcnvm7tqntD2Nq4gs/zhrk5F6ryzGbIkZUpbfyZZ285zwOWeeFPtdkcHhOSq4W7OBr/WkBawQi7ljnFLSUok4TbCei0gWbfR/VazGqQmZFnfn0rsaJ8g0xKgQPRYxk4GzkEaY2R6BmdVrzNgbxLMQBnM6GVXQfjbtHkj7vmehh2BiBmAtehQOWF3Vfx2BPUCLH4gNHPc0TAnS1WvYR+tY/jUvRG4OOxsCPWgPu/PdU/3JC9iwxxW1rN X-Forefront-PRVS: 08062C429B X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6069001)(6009001)(189002)(199003)(24454002)(5008740100001)(50466002)(23726003)(101416001)(189998001)(4001350100001)(92566002)(5001960100002)(4326007)(42186005)(5004730100002)(3846002)(46406003)(6116002)(97736004)(586003)(1076002)(81156007)(77096005)(83506001)(122386002)(110136002)(54356999)(1096002)(97756001)(2950100001)(50986999)(87976001)(106356001)(93886004)(66066001)(76506005)(33656002)(47776003)(33716001)(76176999)(105586002)(40100003);DIR:OUT;SFP:1101;SCL:1;SRVR:BLUPR07MB611;H:localhost;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BLUPR07MB611;23:O+yG0BSUHWNhvkaIVYIJa2E+Zk7sXxWPSS4c/IaZ0Y?= =?us-ascii?Q?shCU/U61Jl+6lZyV04Mah9a3NQhlhApbtTxwK7Z0Z8fVxGZ8X/vtkxBffeOm?= =?us-ascii?Q?dV060/vLgFhwmpX+AapaL5bDuUdDpTe2KHQSC2VKtDGXgFkWAsbrEps+spkx?= =?us-ascii?Q?hWEl5Z9Ri4ccvJ8n4BUVkJfgyWzLRxPa/N5AnsDzlmNj2rER++khJ/Yrpgpi?= =?us-ascii?Q?7d8sev9KLPLRhWo1yEcCh5visnohR1NUdSqF1bdRA8BaxeL4cLtVU3DF0gFX?= =?us-ascii?Q?INEXCe51hZeVLnG89aOPNGlDZuLPA4tRBlUQG0w5i6EbHrd8UXLzx3/oZia2?= =?us-ascii?Q?q3Gl7UgEqPh9nfnjexJqBl/axQcrXKYUADi9sUxZlO7L5YCVGHopqkhmq8jU?= =?us-ascii?Q?tXyKE3y6BrfM2cMXmx6VaMfiQ1IL4q97/4tkQSlwXPl2OOskqMMVDis7zpww?= =?us-ascii?Q?zA77ns8iJQQFkBTMT8Mg6Xim5JYYtbdP93puC4KWiBa0fWAlNt3oehXFL3le?= =?us-ascii?Q?WesvhdhaS8nnAjaIgFzVCA4muL0ekCqwuZ6QTo4KsPlvYZhL+5avLVm3VP7o?= =?us-ascii?Q?7PHEkXHDiZ84ApDBYNYgHNHVqTo9yjKYGhnB+AYKdu2TClnZvmwEtbergb2L?= =?us-ascii?Q?vP6OYFLZVI8NXmelzbSZOtWp98DX+nVXwGgaC4tr5HUH/6PfoyozG1FU0o/C?= =?us-ascii?Q?KUIDxv9sYMlwZbpvHxlxxn9cLoCK/M8lYVBN7a9mGpMUt+vpVQ19wwlRnG4e?= =?us-ascii?Q?1M/iCWxB0iSF8TfqyvI5N1D/McnZU3cQiR5uAhuPDsjStotl5RZz+NCVJdIO?= =?us-ascii?Q?okdfINID/k2nIorhiqQKehiZuSJT+c/DgFIr3KEkHKL/2pA5y5+Zj/uah0Ba?= =?us-ascii?Q?kko0UWNlho6X9wrh6mZeni/4inmWDZ8g5oNNMja3oqWQZDXuY6EJrcaQUrMf?= =?us-ascii?Q?GTsSpqIXtZo5jF4p5CAuj90QCAPZHdD+oP7QDKk3plzR38CxmRimQB9dlNlK?= =?us-ascii?Q?qAJ58yeU61lmRdiC9B80nWxuUMOkn/IV1DGPALED7rrdytTIOPljgkKAGA36?= =?us-ascii?Q?BHlxpYDnnTEl32iZm8JiKB224zdgYZwwDzpuyzYzePwhP9LittERS/GNBhv/?= =?us-ascii?Q?RhKmqJDfE=3D?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR07MB611;5:BuKr2x+eK3x3R0gYG+bp5FlpM2/l6NkbqF4U1k9u61QxHUN0hc2d5VW3MPRd6lYDdUuyXGANPq+ibmcizLyixdww1mt2iNdwlf7XpP7+gq6C0zERruNXtbYg1QZJ/1ne6LAiCcPgSsNEB5xYlzCUrg==;24:8gtrE04zMith14SsVDEJCh3XGhgrUxdBlLokYrR6D7tChFjuGcWRqEPDMgmkT9bS30cu7hMaskpDGict+3GWKNUeS6Rkiij58iGqnOQ6ERU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Dec 2015 17:29:17.1833 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR07MB611 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 23, 2015 at 09:41:54PM +0100, Arnd Bergmann wrote: > On Wednesday 23 December 2015, Catalin Marinas wrote: > > > That means we have to set ARCH_PACK_STATFS64 in the arm64 header files > > > though, and propagate the OABI alignment to arm64/ilp32 as well, rather > > > than using the 88-byte version that every other 32-bit architecture > > > except for x86-32 and arm32 has. > > > > Yuri replied that for EABI glibc, sizeof(struct statfs64) is already 88. > > If that's correct and the packing attribute is ignored by glibc, we > > could drop ARCH_PACK_COMPAT_STATFS64 as well (OABI not supported by > > arm64). But I would be slightly worried since glibc is not the only user > > of the kernel ABI. > > It looks like glibc has its own definition of 'struct statfs64', which > is incompatible with the one in the kernel headers for ARM EABI. > > However, there are other libc implementations besides glibc, and we > can't assume that they all do it the same way, so we clearly have to > keep using the wrapper for ARM EABI. For ARM64/ILP32, we are probably > better off defining it the same way in kernel and libc without that > wrapper. > > > For ILP32, I think we can skip defining ARCH_PACK_STATFS64 (of course, > > only if __ILP32__) and state that sizeof(struct statfs64) is 88 > > (unpacked). In which case we need the wrappers above to be able to reuse > > the compat_sys_statfs64 code. > > > > > Another option would be to set "#define __statfs_word __u64" and use > > > the 64-bit statfs call, instead of compat_sys_statfs64, but that in turn > > > requires special-casing statfs in libc. > > > > I wouldn't go this route as we kind of agreed that ILP32 should look > > like any other 32-bit ABI. > > It's really tricky then: in order to support EABI binaries from a libc > that uses the kernel headers with the OABI compatible definition, we > must not copy the 88 byte structure to user space, because that would > overwrite user space stack data, and that in turn means we have to set > ARCH_PACK_COMPAT_STATFS64, but that in turn prevents us from using the > generic 32-bit syscall ABI for the arm64/ilp32 fstatfs64 call. > > It seems that today, put_compat_statfs64() doesn't actually use > the size argument, and it just copies the individual fields, which > is fine either way. This means we could turn around the logic > in the arm32 wrapper, remove ARCH_PACK_COMPAT_STATFS64, and make > the ilp32 code call directly into compat_sys_fstatfs64(), but it > would be a bit fragile, as we rely on put_compat_statfs64() not > actually writing the padding fields that the native do_statfs64() > writes. If someone changed them to both use copy_to_user, we'd > silently introduce data corruption on rarely used libc implementations. > > Arnd So. For ilp32, the only wrapper left here, is compat_sys_mmap2_wrapper. But this is workaroud, as comment tells: Note: off_4k (w5) is always in units of 4K. If we can't do the requested offset because it is not page-aligned, we return -EINVAL. Not sure we should pull it to ILP32. If so, we can call sys_mmap_pgoff() directly. And we don't need this patch at all therefore. Any throughts? Yury.