From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932122AbbLAWkg (ORCPT ); Tue, 1 Dec 2015 17:40:36 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:54429 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756417AbbLAWkf (ORCPT ); Tue, 1 Dec 2015 17:40:35 -0500 From: Arnd Bergmann To: Yury Norov Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, pinskia@gmail.com, ddaney.cavm@gmail.com, jan.dakinevich@gmail.com, Prasun.Kapoor@caviumnetworks.com, christoph.muellner@theobroma-systems.com, philipp.tomsich@theobroma-systems.com, broonie@kernel.org, andrey.konovalov@linaro.org, Nathan_Lynch@mentor.com, agraf@suse.de, bamvor.zhangjian@huawei.com, klimov.linux@gmail.com, joseph@codesourcery.com, schwab@suse.de 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 23:39:42 +0100 Message-ID: <12844690.Yr8y3jA010@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151201212904.GA14442@yury-N73SV> References: <1447795019-30176-1-git-send-email-ynorov@caviumnetworks.com> <3754277.KmO9Nk3XLD@wuerfel> <20151201212904.GA14442@yury-N73SV> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:IFm4tYy/UIRuDKeVnJzV6SNHv7vOL5DnLrJQjKpJlofVG3iIOpk y6TnhV3EJGNQqQu2KLSajVG/V74u+nGER7AFaIu0nLKpjMx6qWezscXUr3YXcvKlwVKs8Tl 0rYbsRBmqWnWWOXXtq/Vb3RSLFFQsiQHyGXon+8t2bB38p+NsRaOxX41zEc6NUbJbP/Kk6h dxxjAZhTQpl7bo1ixb6gg== X-UI-Out-Filterresults: notjunk:1;V01:K0:UAwM17vzhl4=:fm+DVtdNxlgjB9JnQuVVPW MZVLKQ3FSQkbmUP2yq7utFDZn4LZcW+UDpKtoXiEhHu8Yx1/3syM6h/41RtG02SymOK1SzUOy M7hAyTjwCHhxB3cdcM750brnXdREc1gm+RyYRy40PLiFN3JuJaYFWQ5zj1/lor8ZrsDC+csBQ CXyUP40DSW0tlcXlBHxzVe1oBKrqENQm1/YkPoTbEzshrMCVkrGsQ02gZ3JuwxSBYWLYhB770 +t+PzW07MDMRFtpBUt5SY63VUTQuRqeOLDBkx8BreXO87w7BPjdptdy1dZVZb4Eu+UkQP7zgS 14STpGRXl32Z6nY6B/6DhpyOYKbQMPScJo6IHtJSu82OOzYAmX/MjOg0ZEPWClexNwJuxf/hX 0cuOYq0NVdvb4bEQQaFpM+IIkB5uMTvhBzg/Sp1Z3/UrYo4WjOlxBjhoTbYois7xkGOvLbyfw uz5v3jTtqh2L2kq2YWYOFzXLfB1+dv/Wxcvq6VvUmOP5MY8AWN94mkzM8xmLkVlxdwWUPv9DP lI6dnTBNzncsVN+px3ja6bQ9x7V/2tDJaD21txMRnVcHSUYqfYzU5GC3g4vbU/k27p25sMJz3 VZVzLoQzCovejODxV3hLd1VVmK89D9A/IDz0T/pVh0FU2k2pjP9kFaktkT3jGwD+z5kAzusbB H7AlcRNjNunxdOt8ZgymlFutwEjyI0IAsO1Fkk9/14jWC1XBD8qStBK5fQqhvxrqP8anD0LxK 3Qkuu5nGLbmH6bkX Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 02 December 2015 00:29:04 Yury Norov wrote: > > > +#define compat_sys_shmat sys_shmat > > > > What's special about compat_sys_shmat? > > > > It's about definition. > For aarch32 glibc defines it as (__getpagesize () << 2). > For ILP32 there's no definition, and so generic one is used: (__getpagesize ()). Ok, got it. > In kernel, for ARM64, COMPAT_SHMLBA defined just as 0x4000. Both > compat and non-compat shmat syscalls pass identical arguments to > do_shmat, except shmlba. Effectively, library expects shmlba to > be 0x1000, as sys_shmat does. And compat_sys_shmat expects 0x4000. > > I think, both kernel and library parts are to be fixed. In library > we'd use definition identical to ARM. For kernel we'd use compat > syscall. I'm not sure I understand this part. What changes specifically do we need? It sounds like shmat is one of the cases we an override makes sense and we should use sys_shmat with PAGE_SIZE for aarch64 ilp32 mode. > My question. Why aarch64 defines COMPAT_SHMLBA as 0x4000? If there's > no specific reason for it, it looks like a bug, and we should > define it like in arch/arm: > #define SHMLBA (4 * PAGE_SIZE) /* attach addr a multiple of this */ > > Maybe that's why AARCH32 is limited to 4K pages in config. The reason why AARCH32 is limited to 4K pages is the alignment of ELF sections, and with newer binutils versions, that is no longer a problem, other than the bug you just found. We normally assume that the page size on ARM is fixed to 4K, so there might be user space that just hardcodes 16K SHMLBA rather than using the glibc (__getpagesize () << 2) definition. Changing the kernel would break those programs, but you can also argue that they are already broken today. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 01 Dec 2015 23:39:42 +0100 Subject: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it In-Reply-To: <20151201212904.GA14442@yury-N73SV> References: <1447795019-30176-1-git-send-email-ynorov@caviumnetworks.com> <3754277.KmO9Nk3XLD@wuerfel> <20151201212904.GA14442@yury-N73SV> Message-ID: <12844690.Yr8y3jA010@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday 02 December 2015 00:29:04 Yury Norov wrote: > > > +#define compat_sys_shmat sys_shmat > > > > What's special about compat_sys_shmat? > > > > It's about definition. > For aarch32 glibc defines it as (__getpagesize () << 2). > For ILP32 there's no definition, and so generic one is used: (__getpagesize ()). Ok, got it. > In kernel, for ARM64, COMPAT_SHMLBA defined just as 0x4000. Both > compat and non-compat shmat syscalls pass identical arguments to > do_shmat, except shmlba. Effectively, library expects shmlba to > be 0x1000, as sys_shmat does. And compat_sys_shmat expects 0x4000. > > I think, both kernel and library parts are to be fixed. In library > we'd use definition identical to ARM. For kernel we'd use compat > syscall. I'm not sure I understand this part. What changes specifically do we need? It sounds like shmat is one of the cases we an override makes sense and we should use sys_shmat with PAGE_SIZE for aarch64 ilp32 mode. > My question. Why aarch64 defines COMPAT_SHMLBA as 0x4000? If there's > no specific reason for it, it looks like a bug, and we should > define it like in arch/arm: > #define SHMLBA (4 * PAGE_SIZE) /* attach addr a multiple of this */ > > Maybe that's why AARCH32 is limited to 4K pages in config. The reason why AARCH32 is limited to 4K pages is the alignment of ELF sections, and with newer binutils versions, that is no longer a problem, other than the bug you just found. We normally assume that the page size on ARM is fixed to 4K, so there might be user space that just hardcodes 16K SHMLBA rather than using the glibc (__getpagesize () << 2) definition. Changing the kernel would break those programs, but you can also argue that they are already broken today. Arnd