[PATCH] arm64: uapi: expose our struct ucontext to the uapi headers

[PATCH] arm64: uapi: expose our struct ucontext to the uapi headers

[Will Deacon]

arm64 defines its own ucontext structure which is incompatible with the
struct defined (and exposed to userspace by) the asm-generic headers.

glibc carries its own struct definition that is compatible with the
arm64 definition, but we should expose our format in the uapi headers in
case other libraries want to make use of the ucontext pushed as part of
an arm64 sigframe.

This patch moves the arm64 asm/ucontext.h to the uapi headers, along
with the necessary #include of linux/types.h.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marcus Shawcroft <marcus.shawcroft@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---

I think we also need something similar for arch/arm/ unless we decide
that exposing the incorrect asm-generic header is harmless.

 arch/arm64/include/uapi/asm/Kbuild           | 1 +
 arch/arm64/include/{ => uapi}/asm/ucontext.h | 8 +++++---
 2 files changed, 6 insertions(+), 3 deletions(-)
 rename arch/arm64/include/{ => uapi}/asm/ucontext.h (88%)

diff --git a/arch/arm64/include/uapi/asm/Kbuild b/arch/arm64/include/uapi/asm/Kbuild
index 942376d37d22..825b0fe51c2b 100644
--- a/arch/arm64/include/uapi/asm/Kbuild
+++ b/arch/arm64/include/uapi/asm/Kbuild
@@ -18,4 +18,5 @@ header-y += siginfo.h
 header-y += signal.h
 header-y += stat.h
 header-y += statfs.h
+header-y += ucontext.h
 header-y += unistd.h
diff --git a/arch/arm64/include/asm/ucontext.h b/arch/arm64/include/uapi/asm/ucontext.h
similarity index 88%
rename from arch/arm64/include/asm/ucontext.h
rename to arch/arm64/include/uapi/asm/ucontext.h
index 42e04c877428..791de8e89e35 100644
--- a/arch/arm64/include/asm/ucontext.h
+++ b/arch/arm64/include/uapi/asm/ucontext.h
@@ -13,8 +13,10 @@
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
-#ifndef __ASM_UCONTEXT_H
-#define __ASM_UCONTEXT_H
+#ifndef _UAPI__ASM_UCONTEXT_H
+#define _UAPI__ASM_UCONTEXT_H
+
+#include <linux/types.h>
 
 struct ucontext {
 	unsigned long	  uc_flags;
@@ -27,4 +29,4 @@ struct ucontext {
 	struct sigcontext uc_mcontext;
 };
 
-#endif /* __ASM_UCONTEXT_H */
+#endif /* _UAPI__ASM_UCONTEXT_H */
-- 
2.1.4

[PATCH] arm64: uapi: expose our struct ucontext to the uapi headers

[Catalin Marinas]

On Fri, Jan 16, 2015 at 01:52:14PM +0000, Will Deacon wrote:
> arm64 defines its own ucontext structure which is incompatible with the
> struct defined (and exposed to userspace by) the asm-generic headers.
> 
> glibc carries its own struct definition that is compatible with the
> arm64 definition, but we should expose our format in the uapi headers in
> case other libraries want to make use of the ucontext pushed as part of
> an arm64 sigframe.
> 
> This patch moves the arm64 asm/ucontext.h to the uapi headers, along
> with the necessary #include of linux/types.h.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marcus Shawcroft <marcus.shawcroft@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> 
> I think we also need something similar for arch/arm/ unless we decide
> that exposing the incorrect asm-generic header is harmless.

I'm trying to understand how we got here on arm32 (arm64 pretty much
inherited the behaviour). Before the uapi headers split, we had
arch/arm/include/asm/ucontext.h which has an #ifdef __KERNEL__ and
struct ucontext defined outside this block but we don't seem to have
ever exported this header to user. Luckily, glibc uses its own
definition which matches the kernel one.

At some point the asm-generic gained a ucontext.h which is fine but it
was not ending up in user space as we had an arch ucontext.h. However,
with the uapi headers change and maybe some additional commits, we end
up copying the uapi/asm-generic/ucontext.h to usr/include/asm/ in the
exported headers which differs from the arch ucontext.h as the latter
was never split in uapi/non-uapi parts (it wasn't in the
arch/arm/include/Kbuild).

>  arch/arm64/include/uapi/asm/Kbuild           | 1 +
>  arch/arm64/include/{ => uapi}/asm/ucontext.h | 8 +++++---
>  2 files changed, 6 insertions(+), 3 deletions(-)
>  rename arch/arm64/include/{ => uapi}/asm/ucontext.h (88%)

For this patch:

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

For arm32 I think we need to split ucontext.h into uapi and non-uapi
part according to the #ifdef __KERNEL__.

Catalin

[PATCH] arm64: uapi: expose our struct ucontext to the uapi headers

[Arnd Bergmann]

On Friday 16 January 2015 14:47:38 Catalin Marinas wrote:
> However,
> with the uapi headers change and maybe some additional commits, we end
> up copying the uapi/asm-generic/ucontext.h to usr/include/asm/ in the
> exported headers which differs from the arch ucontext.h as the latter
> was never split in uapi/non-uapi parts (it wasn't in the
> arch/arm/include/Kbuild).

Are you sure? When I look at the build/usr/include/asm directory, I
only see wrappers like this one

#include <asm-generic/auxvec.h>  // inside usr/include/asm/auxvec.h

and the include/uapi/asm-generic/auxvec.h gets copied to usr/asm-generic/auxvec.h

However, I don't see this wrapper done for the arm or arm64 version
of ucontext.h: we get a copy of the generic file in usr/include/asm/ucontext.h
but no wrapper for it because arch/arm*/include/uapi/asm/Kbuild does not
list ucontext.h.

	Arnd

[PATCH] arm64: uapi: expose our struct ucontext to the uapi headers

[Catalin Marinas]

On Fri, Jan 16, 2015 at 03:26:15PM +0000, Arnd Bergmann wrote:
> On Friday 16 January 2015 14:47:38 Catalin Marinas wrote:
> > However,
> > with the uapi headers change and maybe some additional commits, we end
> > up copying the uapi/asm-generic/ucontext.h to usr/include/asm/ in the
> > exported headers which differs from the arch ucontext.h as the latter
> > was never split in uapi/non-uapi parts (it wasn't in the
> > arch/arm/include/Kbuild).
> 
> Are you sure? When I look at the build/usr/include/asm directory, I
> only see wrappers like this one
> 
> #include <asm-generic/auxvec.h>  // inside usr/include/asm/auxvec.h
> 
> and the include/uapi/asm-generic/auxvec.h gets copied to usr/asm-generic/auxvec.h
> 
> However, I don't see this wrapper done for the arm or arm64 version
> of ucontext.h: we get a copy of the generic file in usr/include/asm/ucontext.h
> but no wrapper for it because arch/arm*/include/uapi/asm/Kbuild does not
> list ucontext.h.

I think you are right, maybe I just got confused with
usr/include/asm-generic/ucontext.h which doesn't matter as user space
should not include it.

-- 
Catalin

[PATCH] arm64: uapi: expose our struct ucontext to the uapi headers

[Will Deacon]

On Fri, Jan 16, 2015 at 03:35:06PM +0000, Catalin Marinas wrote:
> On Fri, Jan 16, 2015 at 03:26:15PM +0000, Arnd Bergmann wrote:
> > On Friday 16 January 2015 14:47:38 Catalin Marinas wrote:
> > > However,
> > > with the uapi headers change and maybe some additional commits, we end
> > > up copying the uapi/asm-generic/ucontext.h to usr/include/asm/ in the
> > > exported headers which differs from the arch ucontext.h as the latter
> > > was never split in uapi/non-uapi parts (it wasn't in the
> > > arch/arm/include/Kbuild).
> > 
> > Are you sure? When I look at the build/usr/include/asm directory, I
> > only see wrappers like this one
> > 
> > #include <asm-generic/auxvec.h>  // inside usr/include/asm/auxvec.h
> > 
> > and the include/uapi/asm-generic/auxvec.h gets copied to usr/asm-generic/auxvec.h
> > 
> > However, I don't see this wrapper done for the arm or arm64 version
> > of ucontext.h: we get a copy of the generic file in usr/include/asm/ucontext.h
> > but no wrapper for it because arch/arm*/include/uapi/asm/Kbuild does not
> > list ucontext.h.
> 
> I think you are right, maybe I just got confused with
> usr/include/asm-generic/ucontext.h which doesn't matter as user space
> should not include it.

Right; but exporting our own structure is still useful from a userspace
perspective, otherwise they have to follow glibc's lead and define their
own compatible layout.

Will

[PATCH] arm64: uapi: expose our struct ucontext to the uapi headers

[Catalin Marinas]

On Fri, Jan 16, 2015 at 03:37:15PM +0000, Will Deacon wrote:
> On Fri, Jan 16, 2015 at 03:35:06PM +0000, Catalin Marinas wrote:
> > On Fri, Jan 16, 2015 at 03:26:15PM +0000, Arnd Bergmann wrote:
> > > On Friday 16 January 2015 14:47:38 Catalin Marinas wrote:
> > > > However,
> > > > with the uapi headers change and maybe some additional commits, we end
> > > > up copying the uapi/asm-generic/ucontext.h to usr/include/asm/ in the
> > > > exported headers which differs from the arch ucontext.h as the latter
> > > > was never split in uapi/non-uapi parts (it wasn't in the
> > > > arch/arm/include/Kbuild).
> > > 
> > > Are you sure? When I look at the build/usr/include/asm directory, I
> > > only see wrappers like this one
> > > 
> > > #include <asm-generic/auxvec.h>  // inside usr/include/asm/auxvec.h
> > > 
> > > and the include/uapi/asm-generic/auxvec.h gets copied to usr/asm-generic/auxvec.h
> > > 
> > > However, I don't see this wrapper done for the arm or arm64 version
> > > of ucontext.h: we get a copy of the generic file in usr/include/asm/ucontext.h
> > > but no wrapper for it because arch/arm*/include/uapi/asm/Kbuild does not
> > > list ucontext.h.
> > 
> > I think you are right, maybe I just got confused with
> > usr/include/asm-generic/ucontext.h which doesn't matter as user space
> > should not include it.
> 
> Right; but exporting our own structure is still useful from a userspace
> perspective, otherwise they have to follow glibc's lead and define their
> own compatible layout.

That's fine, I think the patch still make sense (but not as urgent as we
haven't broken anything).

-- 
Catalin