From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755799AbcECJGW (ORCPT ); Tue, 3 May 2016 05:06:22 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:55675 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755713AbcECJGS (ORCPT ); Tue, 3 May 2016 05:06:18 -0400 From: Arnd Bergmann To: Catalin Marinas Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, schwab@suse.de, broonie@kernel.org, linux-doc@vger.kernel.org, heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, Yury Norov , bamvor.zhangjian@huawei.com, joseph@codesourcery.com, schwidefsky@de.ibm.com, Nathan_Lynch@mentor.com, Philipp Tomsich , linux-arm-kernel@lists.infradead.org, christoph.muellner@theobroma-systems.com Subject: Re: [PATCH 24/25] arm64:ilp32: add vdso-ilp32 and use for signal return Date: Tue, 03 May 2016 11:05:02 +0200 Message-ID: <3846428.6xx69KGEja@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160503090045.GB10733@e104818-lin.cambridge.arm.com> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <1554541.oDP7Ro5zB2@wuerfel> <20160503090045.GB10733@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:WIRhrcZ6aoxEulKn02XPfCRyRTsoV+S3c9TIyd1w9iH+spGsuv1 6ZxDVa2QC9G5c5a7TqxxPwK+xpEyVT4BZSGmFty390ct0nX8r8lNDlnvnlN4i67m4FOh6UF Uyx4o6KLm/bKhfhn4i8UTS7JVZALnlf/KNf1Uh8AkXuv8jzYVK6RaTMmjJDEX3+++/JdXS0 wrRuxGGYwuC25Km3AqXyQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:wAmO4z/d3Zk=:JesllSCY65PWYo4PJbjHu9 MsbLVnBAuxM309MuopVWRRxRF43eoAAXludfY/rowJErKrljwHh4beW2JUvMj31iM0kJ9Ww/N hFHJ9+BAtIZl8veoa5Pt0O3eamG+VOalJkdXRR7Ixtr+ejswhXi3QXsvjDiarS8C0T5gslWQl R+3ItOHlGjdWZLplyuDy5YwIg5ZQs9NGfpR8Z9O0siuhlqEmqJc0wxg0diUkwF9daehVFCuVb 9htqXq0tiDXn1RkyiVyIcl8G5xnFD9Y4P1G0DCpfSuiCIYHTMGNKXhQZa68D4pkt3bQlc+Q86 VldV+yW8x1+T0SZqHr+6rPX4bku025ugmEvQrR9uJN2HKGWn6uIPPdC/ITXFMIZOlxDdLm++Q 1RbCX+bFLv1asldciZLtKDcVHo9PhFUuBQtGTfo3Ls4jMchYOyFCCFwH/T2C3EKXkionhIro0 2Zh7YOeeKw5uDu6hfymzZbZ9XuaTQ7L0wIvIElyb11lA1+wyo9K/F7DmfSVeYGqlXFYQqPppd 10Y9mUuLWvpLVqqWqt2Aw1lNaznE6AbcYr/PBdo7TTDUA241407Wx5LA1iYCECWkSavf3J0KS lrd2nQwRaM7nYSJFB41EYGTK1lzeiSy9pLLUzWoMM4BPPfBfMmhEdzkmYyxT1NI9scFx5I4Rz zjzTX9wXQshJSbihYoa0NH5D3HupYK+4hS7M6FL6i5g3eBwfJv9OR8O1XZKngcIb0TkEzA2gv f3UeUmMFxRBHsJYq Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 03 May 2016 10:00:45 Catalin Marinas wrote: > On Fri, Apr 29, 2016 at 07:30:19PM +0200, Arnd Bergmann wrote: > > On Friday 29 April 2016 17:01:55 Catalin Marinas wrote: > > > On Wed, Apr 06, 2016 at 01:08:46AM +0300, Yury Norov wrote: > > > > ILP32 VDSO exports next symbols: > > > > __kernel_rt_sigreturn; > > > > __kernel_gettimeofday; > > > > __kernel_clock_gettime; > > > > __kernel_clock_getres; > > > > > > [...] > > > > > > > +$(obj)/gettimeofday-ilp32.o: $(src)/../vdso/gettimeofday.S > > > > + $(call if_changed_dep,vdso-ilp32as) > > > > > > Are struct timeval and timespec the same between ILP32 and LP64? For > > > example, __kernel_gettimeofday() assumes TVAL_TV_SEC offset defined in > > > asm-offsets.c based on the LP64 timeval. > > > > No, ilp32 uses the generic 32-bit data structures, which have a 32-bit > > time_t. I guess that means it can work for little-endian but not > > big-endian, right? > > I don't think it works for little-endian either. The LP64 struct timeval > is 16 bytes while the ILP32 one is 8 bytes. The VDSO gettimeofday is > storing 16 bytes (stp x10, x11, [x0, #TVAL_TV_SEC]) You are right. Yury asked pointed out the same thing on IRC as well. Using the 64-bit gettimeofday() will put the right number in the .tv_sec member on little-endian, but will write zeroes to tv_nsec and corrupt the memory following it. Yury also tried it out and noticed that for a (so far) unknown reason, the vdso gets never used by his glibc build, so it has not triggered any test case failures. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 03 May 2016 11:05:02 +0200 Subject: [PATCH 24/25] arm64:ilp32: add vdso-ilp32 and use for signal return In-Reply-To: <20160503090045.GB10733@e104818-lin.cambridge.arm.com> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <1554541.oDP7Ro5zB2@wuerfel> <20160503090045.GB10733@e104818-lin.cambridge.arm.com> Message-ID: <3846428.6xx69KGEja@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 03 May 2016 10:00:45 Catalin Marinas wrote: > On Fri, Apr 29, 2016 at 07:30:19PM +0200, Arnd Bergmann wrote: > > On Friday 29 April 2016 17:01:55 Catalin Marinas wrote: > > > On Wed, Apr 06, 2016 at 01:08:46AM +0300, Yury Norov wrote: > > > > ILP32 VDSO exports next symbols: > > > > __kernel_rt_sigreturn; > > > > __kernel_gettimeofday; > > > > __kernel_clock_gettime; > > > > __kernel_clock_getres; > > > > > > [...] > > > > > > > +$(obj)/gettimeofday-ilp32.o: $(src)/../vdso/gettimeofday.S > > > > + $(call if_changed_dep,vdso-ilp32as) > > > > > > Are struct timeval and timespec the same between ILP32 and LP64? For > > > example, __kernel_gettimeofday() assumes TVAL_TV_SEC offset defined in > > > asm-offsets.c based on the LP64 timeval. > > > > No, ilp32 uses the generic 32-bit data structures, which have a 32-bit > > time_t. I guess that means it can work for little-endian but not > > big-endian, right? > > I don't think it works for little-endian either. The LP64 struct timeval > is 16 bytes while the ILP32 one is 8 bytes. The VDSO gettimeofday is > storing 16 bytes (stp x10, x11, [x0, #TVAL_TV_SEC]) You are right. Yury asked pointed out the same thing on IRC as well. Using the 64-bit gettimeofday() will put the right number in the .tv_sec member on little-endian, but will write zeroes to tv_nsec and corrupt the memory following it. Yury also tried it out and noticed that for a (so far) unknown reason, the vdso gets never used by his glibc build, so it has not triggered any test case failures. Arnd