Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756099AbbLALb7 (ORCPT ); Tue, 1 Dec 2015 06:31:59 -0500 Received: from mout.kundenserver.de ([217.72.192.74]:62585 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754206AbbLALb6 (ORCPT ); Tue, 1 Dec 2015 06:31:58 -0500 From: Arnd Bergmann To: Andreas Schwab Cc: Yury Norov , linux-arm-kernel@lists.infradead.org, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, catalin.marinas@arm.com, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, broonie@kernel.org, jan.dakinevich@gmail.com, joseph@codesourcery.com, ddaney.cavm@gmail.com, bamvor.zhangjian@huawei.com, philipp.tomsich@theobroma-systems.com, andrey.konovalov@linaro.org, christoph.muellner@theobroma-systems.com Subject: Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Date: Tue, 01 Dec 2015 12:30:56 +0100 Message-ID: <1608639.5Yic1PH469@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <87zixue8lj.fsf@igel.home> References: <1447795019-30176-1-git-send-email-ynorov@caviumnetworks.com> <2776283.xtmDQm6BqS@wuerfel> <87zixue8lj.fsf@igel.home> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:o0WPAAq4aoTY7EUfgoKUE/2olLxldCrrZulBsBLI6Zj44XRhIVS TMd5t4I3LeNKjlu7IRtf04CKtZ1W6PI5wIUIlQuuvQH0IdvFkX/8CjLPSGIbZixxb+Np0fZ ZeTPdPnT2M6vHDz6DClcNBIKT+EsVBm0cDB7HIMLl0bitLzNLBSVOIS5qgSxy/5mwhpWgfJ c94GYDty/NdNIpRPw76KA== X-UI-Out-Filterresults: notjunk:1;V01:K0:4W7Nqge1QQ4=:r8vkVPR9J/oJxLLqnjjlhz 5zm6tLyLspJAu2fb8NfVLAHRuJJNXgpN0C1kjhE5YCfXvJ0jtag+usO+FmVTQeZUjw+Wmg36E xd/r5x7a0x6W1T2BQAxPzc7ZVHHTxz8vzLAbeaL0ahbS5iklOlfKxqLoM6Ic7puEExY26Rqe1 TfgQhqhJ/6RTJF8Z7XzTmfz3mlWiF6fLFwl4+t1cyKawJiJAFcqhRrSZjDA0kam903F0JHFN8 4mxMuqm9IQJMMZOezqvMiIq9WbsX75odpMSj9ySHoQUEhl5E40Ovk+aPx6krib3AcDeeiWh9E u6hg0waRH6J/N+uFm23acc1ZSA22qjs6fsVCF1Ehefcaj+YMdKlIYxf0af6K6hXMFXm/h9jUm zek8CNt9KxMyz/O/p5h7Uw+PHXclbFXaSPZDxaWV6XFzBfD9H4OmA/WWGAY0VCgFKJWbC9BTa 5+ILGNM0Cz5IjhcAUPw3MQZKmdkCm4p5NoPVmrwNJq5fG3gkN8UYCl2sDqAs93N1nQadeKwO3 oJGkMnXnjn6R5PZ5S5oWFgq4aTR81f+wZylS+2X0JthxkjTmBgyb1V1yVRy7h7JmafWxe46jQ P2nYIhjdwEgVF6++Iyt1D0Xm1csGXw7rKeFBXd4iKqEri56ETBJQMeHYCeTuk04rLNluqpn8f 4/H6y8/xsvCclxJgkfeH2aQLHKUjE7LhklBD0Gn88bjoAr7wKm76RDNb/famaEUZE7mt3NzGh qetIvyZxgvDA6Hhv Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1269 Lines: 29 On Tuesday 01 December 2015 12:01:12 Andreas Schwab wrote: > Arnd Bergmann writes: > > > On Tuesday 01 December 2015 10:20:59 Andreas Schwab wrote: > >> Yury Norov writes: > >> > >> > There's a tricky bug with signal stack, that Andreas also discovered. > >> > >> That was only a confusion about the compat state of sys_rt_sigaction. > >> It just requires making sure glibc uses the correct (64bit layout) > >> struct kernel_sigaction. > > > > I don't think we need to use the 64-bit version of sigaction, both > > kernel and libc are simpler if we use the normal 32-bit version. > > Since glibc has to do the conversion anyway (due to sigset_t), using the > 64bit layout avoids a second conversion in the kernel. I don't get the part about sigset_t. Why would glibc want to use the 64-bit layout? This one looks like one of the cases where we absolutely want to use the 32-bit layout or otherwise get into big trouble if we ever want to support native ILP32 kernels. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/