Skip to contentSkip to conversation

arm64: uapi: expose our struct ucontext to the uapi headers

PATCH New Will Deacon 3 participants 6 messages Jan 16, 2015 arm64

lore
Share & tools
lore

Will Deacon

author
#0 lore raw

PATCH 1/1 arm64: uapi: expose our struct ucontext to the uapi headers

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 <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Marcus Shawcroft <[email protected]>
Signed-off-by Will Deacon <[email protected]>

---

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%)
arch/arm64/include/uapi/asm/Kbuild +1 -0
index 942376d37d22..825b0fe51c2b 100644
@@ -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
arch/arm64/include/uapi/asm/ucontext.h renamed from arch/arm64/include/asm/ucontext.h +5 -3
similarity index 88%
rename from arch/arm64/include/asm/ucontext.h
rename to arch/arm64/include/uapi/asm/ucontext.h
index 42e04c877428..791de8e89e35 100644
@@ -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 */
Signature · 1 line
2.1.4
maintainer
#1 lore raw

PATCH 1/1 arm64: uapi: expose our struct ucontext to the uapi headers

Quoted 11 lines · 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.

Quoted 8 lines
Cc Arnd Bergmann <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Marcus Shawcroft <[email protected]>
Signed-off-by Will Deacon <[email protected]>

---

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).

Quoted 4 lines
 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 <[email protected]>

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

Catalin

#2 lore raw

PATCH 1/1 arm64: uapi: expose our struct ucontext to the uapi headers

Quoted 6 lines · 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

maintainer
#3 lore raw

PATCH 1/1 arm64: uapi: expose our struct ucontext to the uapi headers

Quoted 11 lines · Arnd Bergmann
Quoted 6 lines · 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

Quoted 8 lines

#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.

Signature · 1 line
Catalin
author
#4 lore raw

PATCH 1/1 arm64: uapi: expose our struct ucontext to the uapi headers

Quoted 16 lines · Catalin Marinas
Quoted 15 lines · Arnd Bergmann
Quoted 6 lines · 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

Quoted 8 lines
Quoted 4 lines

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

maintainer
#5 lore raw

PATCH 1/1 arm64: uapi: expose our struct ucontext to the uapi headers

Quoted 22 lines · Will Deacon
Quoted 21 lines · Catalin Marinas
Quoted 19 lines · Arnd Bergmann
Quoted 6 lines · 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.

Quoted 7 lines
Quoted 3 lines

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).

Signature · 1 line
Catalin