From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932075AbcB2QbM (ORCPT ); Mon, 29 Feb 2016 11:31:12 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:49821 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751058AbcB2QbJ (ORCPT ); Mon, 29 Feb 2016 11:31:09 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Andreas Schwab , pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, catalin.marinas@arm.com, broonie@kernel.org, heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, agraf@suse.de, Nathan_Lynch@mentor.com, klimov.linux@gmail.com, Yury Norov , "Zhangjian (Bamvor)" , joseph@codesourcery.com, schwidefsky@de.ibm.com, jan.dakinevich@gmail.com, christoph.muellner@theobroma-systems.com Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Date: Mon, 29 Feb 2016 17:30:06 +0100 Message-ID: <2753057.uyT99zxyCM@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <208897488.c0hkBy2G1S@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:2AR+OGvirZU4S9sHW9lNbq75nQ5tTign2wqIOTrnaUlI1kAf1jS JganNgezUJ4G06y/CDk1zinlVwal7+fxPkUNPlJ/IbYcbpeCSzRocZqwcEoLMkWn2Gkz7WW kJXLfpgeHUbMIKqdr5QJHLBZi+xca8rq3798sPyz2RU9RBrF7aQNTm2KELyUIEC8XIm7SnM tSHxTXNIlW5R4CpYTi2JQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:+xBUkL2Rp40=:iR92ymgI79HQVzoKUIgxyB DDfHeeZsfAeH5wdXt7OOq3B09fE2h9xv+D6yXNHyhUBOQmDz9jL56Cwci4otk+vqs9fA+6Iqp OW3LgAAIxueX1AorH1LStfW7cy6Arp87sN26nda62yruelp81oCPUFWBT/4UpY+JYCvL1foXw gIiakNPkdLhqrbtSKzcUD54Namn3NdMZjpVKWF4s4E1pv+FUWZmdiPfMHxlsM2FUbp0+i/guK xGXN/fmXwLz+0b/jZc4mqknRxnfVOdi5gn0xvw1UWUQ5ZFn0+nZ3uvcPWZh+pDIZkZa9AopXB 8Ygj1S5pCxPFtyg6c0zx8CEUKUtrVlYHuvT+3dC8/+qZerUetHukqSf9qGGAJ5EuuouhRCFAK EAM2VowIpC+pSsRJrnW3vavn0kEnQ76qGDWcnm1Kv8lsEXM+BLGq3yJqb0zfhUKwjgSCwO8Ot ecjvI/gUBFaOK6wTiAJfQ+hr5QEFY/0H03neguyzTxdmQm0ZoFZULMu6x26zIvo7DT7LO82sR mKaVbN9ZIJzQtd5rzdonGZDguWv//UbLDQPtPjUjLRNfxX5ScCt4eKE6Koy5x4HPAVbbRgb/m o7BmImPG8PbD8vHIy/JrpxiFtb1HJtqjsSOLt6xXD+ZsiAIY3YL5tLkDW2VlokCmIul998YNe 8u8XgV3D7VDkzG206MHHJ0iDtWLpjub2BMhPPkWsQnBfrsblWt+HNuewi1zCToIsAu8HsoK1B l+p76iL8kmsKKpW7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 29 February 2016 17:00:29 Andreas Schwab wrote: > Arnd Bergmann writes: > > > In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11 > > you are defining a struct __kernel_stat64 in the glibc. Is this the expected > > way to do it? I would have thought you'd get the definition from the kernel > > headers. > > The problem really is that struct stat64 does not match the kernel > struct stat64. The latter uses the broken st_ino, where the 64-bit > inode is actually stored at the end of the structure, and there is > padding *before* the 32-bit inode, not after (so you cannot overlay a > 64-bit inode field in little endian mode). You need to add the attached > file as sysdeps/unix/sysv/linux/aarch64/bits/stat.h, then you can use > the user-space struct stat64 to communicate with the *stat64 syscalls, > and __kernel_stat64 is not needed any more. > Ok, got it. So this is an unfortunate side-effect of using the same 'stat64' as arm32 does. If it's really that broken, should we change the kernel (once more) to use the layout of arm64 instead? That has the 64-bit time fields though, so it might require similar hacks, unless we first merge support for 64-bit time_t based syscalls (which seems unlikely at this point, sorry for the delay on my end). Is there possibly a way to reference the implementation that we have for stat64 on arm32 rather than duplicating it? Arnd