[PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Dave Martin]

This patch refactors the UAPI header definitions for the Arm SVE
extension to avoid multiple-definition problems when userspace mixes its
own sigcontext.h definitions with the kernel's ptrace.h (which is
apparently routine).

A common backend header is created to hold common definitions, suitably
namespaced, and with an appropriate header guard.

See the commit message in patch 3 for further explanation of why this
is needed.

Because of the non-trivial header guard in the new sve_context.h, patch
1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
a similar way to the current handling of #ifndef _UAPI_FOO.

Dave Martin (3):
  kbuild: install_headers.sh: Strip _UAPI from #if-defined() guards
  arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET definition
  arm64/sve: Disentangle <uapi/asm/ptrace.h> from
    <uapi/asm/sigcontext.h>

 arch/arm64/include/uapi/asm/ptrace.h      | 39 ++++++++++-----------
 arch/arm64/include/uapi/asm/sigcontext.h  | 56 +++++++++++++++----------------
 arch/arm64/include/uapi/asm/sve_context.h | 50 +++++++++++++++++++++++++++
 scripts/headers_install.sh                |  1 +
 4 files changed, 97 insertions(+), 49 deletions(-)
 create mode 100644 arch/arm64/include/uapi/asm/sve_context.h

-- 
2.1.4

[PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Dave Martin]

This patch refactors the UAPI header definitions for the Arm SVE
extension to avoid multiple-definition problems when userspace mixes its
own sigcontext.h definitions with the kernel's ptrace.h (which is
apparently routine).

A common backend header is created to hold common definitions, suitably
namespaced, and with an appropriate header guard.

See the commit message in patch 3 for further explanation of why this
is needed.

Because of the non-trivial header guard in the new sve_context.h, patch
1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
a similar way to the current handling of #ifndef _UAPI_FOO.

Dave Martin (3):
  kbuild: install_headers.sh: Strip _UAPI from #if-defined() guards
  arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET definition
  arm64/sve: Disentangle <uapi/asm/ptrace.h> from
    <uapi/asm/sigcontext.h>

 arch/arm64/include/uapi/asm/ptrace.h      | 39 ++++++++++-----------
 arch/arm64/include/uapi/asm/sigcontext.h  | 56 +++++++++++++++----------------
 arch/arm64/include/uapi/asm/sve_context.h | 50 +++++++++++++++++++++++++++
 scripts/headers_install.sh                |  1 +
 4 files changed, 97 insertions(+), 49 deletions(-)
 create mode 100644 arch/arm64/include/uapi/asm/sve_context.h

-- 
2.1.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/3] kbuild: install_headers.sh: Strip _UAPI from #if-defined() guards

[Dave Martin]

install_headers.sh knows how to strip the _UAPI prefix from #ifdef/
ifndef and #define directives used to guard headers against multiple
or inappropriate inclusion.  Currently this does not work for guards
in the "#if defined()" style, which may be needed for non-trivial
cases.

This patch adds similar logic so that the _UAPI prefix is also
stripped from guard directives written using "#if defined()" etc.

This is not completely foolproof, but will work for simple cases of
using #if defined() to guard against inappropriate header inclusion.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 scripts/headers_install.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
index 593f8879..fe1d3fc 100755
--- a/scripts/headers_install.sh
+++ b/scripts/headers_install.sh
@@ -38,6 +38,7 @@ do
 		-e 's/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g' \
 		-e 's/(^|[[:space:](])(inline|asm|volatile)([[:space:](]|$)/\1__\2__\3/g' \
 		-e 's@#(ifndef|define|endif[[:space:]]*/[*])[[:space:]]*_UAPI@#\1 @' \
+		-e ':1;s/(#(if|elif)(.*[^A-Za-z0-9_])defined\([[:space:]]*)_UAPI/\1/;t1' \
 		"$SRCDIR/$i" > "$OUTDIR/$FILE.sed" || exit 1
 	scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ "$OUTDIR/$FILE.sed" \
 		> "$OUTDIR/$FILE"
-- 
2.1.4

[PATCH 1/3] kbuild: install_headers.sh: Strip _UAPI from #if-defined() guards

[Dave Martin]

install_headers.sh knows how to strip the _UAPI prefix from #ifdef/
ifndef and #define directives used to guard headers against multiple
or inappropriate inclusion.  Currently this does not work for guards
in the "#if defined()" style, which may be needed for non-trivial
cases.

This patch adds similar logic so that the _UAPI prefix is also
stripped from guard directives written using "#if defined()" etc.

This is not completely foolproof, but will work for simple cases of
using #if defined() to guard against inappropriate header inclusion.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 scripts/headers_install.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
index 593f8879..fe1d3fc 100755
--- a/scripts/headers_install.sh
+++ b/scripts/headers_install.sh
@@ -38,6 +38,7 @@ do
 		-e 's/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g' \
 		-e 's/(^|[[:space:](])(inline|asm|volatile)([[:space:](]|$)/\1__\2__\3/g' \
 		-e 's@#(ifndef|define|endif[[:space:]]*/[*])[[:space:]]*_UAPI@#\1 @' \
+		-e ':1;s/(#(if|elif)(.*[^A-Za-z0-9_])defined\([[:space:]]*)_UAPI/\1/;t1' \
 		"$SRCDIR/$i" > "$OUTDIR/$FILE.sed" || exit 1
 	scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ "$OUTDIR/$FILE.sed" \
 		> "$OUTDIR/$FILE"
-- 
2.1.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/3] arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET definition

[Dave Martin]

SVE_PT_REGS_OFFSET is supposed to indicate the offset for skipping
over the ptrace NT_ARM_SVE header (struct user_sve_header) to the
start of the SVE register data proper.

However, currently SVE_PT_REGS_OFFSET is defined in terms of struct
sve_context, which is wrong: that structure describes the SVE
header in the signal frame, not in the ptrace regset.

This patch fixes the definition to use the ptrace header structure
struct user_sve_header instead.

By good fortune, the to structures are the same size anyway, so
there is no functional or ABI change.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 arch/arm64/include/uapi/asm/ptrace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index a36227f..65ef8b0 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -131,7 +131,7 @@ struct user_sve_header {
 
 /* Offset from the start of struct user_sve_header to the register data */
 #define SVE_PT_REGS_OFFSET					\
-	((sizeof(struct sve_context) + (SVE_VQ_BYTES - 1))	\
+	((sizeof(struct user_sve_header) + (SVE_VQ_BYTES - 1))	\
 		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
 
 /*
-- 
2.1.4

[PATCH 2/3] arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET definition

[Dave Martin]

SVE_PT_REGS_OFFSET is supposed to indicate the offset for skipping
over the ptrace NT_ARM_SVE header (struct user_sve_header) to the
start of the SVE register data proper.

However, currently SVE_PT_REGS_OFFSET is defined in terms of struct
sve_context, which is wrong: that structure describes the SVE
header in the signal frame, not in the ptrace regset.

This patch fixes the definition to use the ptrace header structure
struct user_sve_header instead.

By good fortune, the to structures are the same size anyway, so
there is no functional or ABI change.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 arch/arm64/include/uapi/asm/ptrace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index a36227f..65ef8b0 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -131,7 +131,7 @@ struct user_sve_header {
 
 /* Offset from the start of struct user_sve_header to the register data */
 #define SVE_PT_REGS_OFFSET					\
-	((sizeof(struct sve_context) + (SVE_VQ_BYTES - 1))	\
+	((sizeof(struct user_sve_header) + (SVE_VQ_BYTES - 1))	\
 		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
 
 /*
-- 
2.1.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Dave Martin]

Currently, <uapi/asm/sigcontext.h> provides common definitions for
describing SVE context structures that are also used by the ptrace
definitions in <uapi/asm/ptrace.h>.

For this reason, a #include of <asm/sigcontext.h> was added in
ptrace.h, but it this turns out that this can interact badly with
userspace code that tries to include ptrace.h on top of the libc
headers (which may provide their own shadow definitions for
sigcontext.h).

To make the headers easier for userspace to consume, this patch
bounces the common definitions into an __SVE_* namespace and moves
them to a backend header <uapi/asm/sve_context.h> that can be
included by the other headers as appropriate.  This should allow
ptrace.h to be used alongside libc's sigcontext.h (if any) without
ill effects.

This should make the situation unambiguous: <asm/sigcontext.h> is
the header to include for the sigframe-specific definitions, while
<asm/ptrace.h> is the header to include for ptrace-specific
definitions.

To avoid conflicting with existing usage, <asm/sigcontext.h>
remains the canonical way to get the common definitions for
SVE_VQ_MIN, sve_vq_from_vl() etc., both in userspace and in the
kernel: relying on these being defined as a side effect of
including just <asm/ptrace.h> was never intended to be safe.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 arch/arm64/include/uapi/asm/ptrace.h      | 39 ++++++++++-----------
 arch/arm64/include/uapi/asm/sigcontext.h  | 56 +++++++++++++++----------------
 arch/arm64/include/uapi/asm/sve_context.h | 50 +++++++++++++++++++++++++++
 3 files changed, 96 insertions(+), 49 deletions(-)
 create mode 100644 arch/arm64/include/uapi/asm/sve_context.h

diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index 65ef8b0..cff79c5 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -23,7 +23,7 @@
 #include <linux/types.h>
 
 #include <asm/hwcap.h>
-#include <asm/sigcontext.h>
+#include <asm/sve_context.h>
 
 
 /*
@@ -130,9 +130,9 @@ struct user_sve_header {
  */
 
 /* Offset from the start of struct user_sve_header to the register data */
-#define SVE_PT_REGS_OFFSET					\
-	((sizeof(struct user_sve_header) + (SVE_VQ_BYTES - 1))	\
-		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
+#define SVE_PT_REGS_OFFSET						\
+	((sizeof(struct user_sve_header) + (__SVE_VQ_BYTES - 1))	\
+		/ __SVE_VQ_BYTES * __SVE_VQ_BYTES)
 
 /*
  * The register data content and layout depends on the value of the
@@ -178,39 +178,36 @@ struct user_sve_header {
  * Additional data might be appended in the future.
  */
 
-#define SVE_PT_SVE_ZREG_SIZE(vq)	SVE_SIG_ZREG_SIZE(vq)
-#define SVE_PT_SVE_PREG_SIZE(vq)	SVE_SIG_PREG_SIZE(vq)
-#define SVE_PT_SVE_FFR_SIZE(vq)		SVE_SIG_FFR_SIZE(vq)
+#define SVE_PT_SVE_ZREG_SIZE(vq)	__SVE_ZREG_SIZE(vq)
+#define SVE_PT_SVE_PREG_SIZE(vq)	__SVE_PREG_SIZE(vq)
+#define SVE_PT_SVE_FFR_SIZE(vq)		__SVE_FFR_SIZE(vq)
 #define SVE_PT_SVE_FPSR_SIZE		sizeof(__u32)
 #define SVE_PT_SVE_FPCR_SIZE		sizeof(__u32)
 
-#define __SVE_SIG_TO_PT(offset) \
-	((offset) - SVE_SIG_REGS_OFFSET + SVE_PT_REGS_OFFSET)
-
 #define SVE_PT_SVE_OFFSET		SVE_PT_REGS_OFFSET
 
 #define SVE_PT_SVE_ZREGS_OFFSET \
-	__SVE_SIG_TO_PT(SVE_SIG_ZREGS_OFFSET)
+	(SVE_PT_REGS_OFFSET + __SVE_ZREGS_OFFSET)
 #define SVE_PT_SVE_ZREG_OFFSET(vq, n) \
-	__SVE_SIG_TO_PT(SVE_SIG_ZREG_OFFSET(vq, n))
+	(SVE_PT_REGS_OFFSET + __SVE_ZREG_OFFSET(vq, n))
 #define SVE_PT_SVE_ZREGS_SIZE(vq) \
-	(SVE_PT_SVE_ZREG_OFFSET(vq, SVE_NUM_ZREGS) - SVE_PT_SVE_ZREGS_OFFSET)
+	(SVE_PT_SVE_ZREG_OFFSET(vq, __SVE_NUM_ZREGS) - SVE_PT_SVE_ZREGS_OFFSET)
 
 #define SVE_PT_SVE_PREGS_OFFSET(vq) \
-	__SVE_SIG_TO_PT(SVE_SIG_PREGS_OFFSET(vq))
+	(SVE_PT_REGS_OFFSET + __SVE_PREGS_OFFSET(vq))
 #define SVE_PT_SVE_PREG_OFFSET(vq, n) \
-	__SVE_SIG_TO_PT(SVE_SIG_PREG_OFFSET(vq, n))
+	(SVE_PT_REGS_OFFSET + __SVE_PREG_OFFSET(vq, n))
 #define SVE_PT_SVE_PREGS_SIZE(vq) \
-	(SVE_PT_SVE_PREG_OFFSET(vq, SVE_NUM_PREGS) - \
+	(SVE_PT_SVE_PREG_OFFSET(vq, __SVE_NUM_PREGS) - \
 		SVE_PT_SVE_PREGS_OFFSET(vq))
 
 #define SVE_PT_SVE_FFR_OFFSET(vq) \
-	__SVE_SIG_TO_PT(SVE_SIG_FFR_OFFSET(vq))
+	(SVE_PT_REGS_OFFSET + __SVE_FFR_OFFSET(vq))
 
 #define SVE_PT_SVE_FPSR_OFFSET(vq)				\
 	((SVE_PT_SVE_FFR_OFFSET(vq) + SVE_PT_SVE_FFR_SIZE(vq) +	\
-			(SVE_VQ_BYTES - 1))			\
-		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
+			(__SVE_VQ_BYTES - 1))			\
+		/ __SVE_VQ_BYTES * __SVE_VQ_BYTES)
 #define SVE_PT_SVE_FPCR_OFFSET(vq) \
 	(SVE_PT_SVE_FPSR_OFFSET(vq) + SVE_PT_SVE_FPSR_SIZE)
 
@@ -221,8 +218,8 @@ struct user_sve_header {
 
 #define SVE_PT_SVE_SIZE(vq, flags)					\
 	((SVE_PT_SVE_FPCR_OFFSET(vq) + SVE_PT_SVE_FPCR_SIZE		\
-			- SVE_PT_SVE_OFFSET + (SVE_VQ_BYTES - 1))	\
-		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
+			- SVE_PT_SVE_OFFSET + (__SVE_VQ_BYTES - 1))	\
+		/ __SVE_VQ_BYTES * __SVE_VQ_BYTES)
 
 #define SVE_PT_SIZE(vq, flags)						\
 	 (((flags) & SVE_PT_REGS_MASK) == SVE_PT_REGS_SVE ?		\
diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
index dca8f8b..5f3c0ce 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -130,6 +130,8 @@ struct sve_context {
 
 #endif /* !__ASSEMBLY__ */
 
+#include <asm/sve_context.h>
+
 /*
  * The SVE architecture leaves space for future expansion of the
  * vector length beyond its initial architectural limit of 2048 bits
@@ -138,21 +140,20 @@ struct sve_context {
  * See linux/Documentation/arm64/sve.txt for a description of the VL/VQ
  * terminology.
  */
-#define SVE_VQ_BYTES		16	/* number of bytes per quadword */
+#define SVE_VQ_BYTES		__SVE_VQ_BYTES	/* bytes per quadword */
 
-#define SVE_VQ_MIN		1
-#define SVE_VQ_MAX		512
+#define SVE_VQ_MIN		__SVE_VQ_MIN
+#define SVE_VQ_MAX		__SVE_VQ_MAX
 
-#define SVE_VL_MIN		(SVE_VQ_MIN * SVE_VQ_BYTES)
-#define SVE_VL_MAX		(SVE_VQ_MAX * SVE_VQ_BYTES)
+#define SVE_VL_MIN		__SVE_VL_MIN
+#define SVE_VL_MAX		__SVE_VL_MAX
 
-#define SVE_NUM_ZREGS		32
-#define SVE_NUM_PREGS		16
+#define SVE_NUM_ZREGS		__SVE_NUM_ZREGS
+#define SVE_NUM_PREGS		__SVE_NUM_PREGS
 
-#define sve_vl_valid(vl) \
-	((vl) % SVE_VQ_BYTES == 0 && (vl) >= SVE_VL_MIN && (vl) <= SVE_VL_MAX)
-#define sve_vq_from_vl(vl)	((vl) / SVE_VQ_BYTES)
-#define sve_vl_from_vq(vq)	((vq) * SVE_VQ_BYTES)
+#define sve_vl_valid(vl)	__sve_vl_valid(vl)
+#define sve_vq_from_vl(vl)	__sve_vq_from_vl(vl)
+#define sve_vl_from_vq(vq)	__sve_vl_from_vq(vq)
 
 /*
  * If the SVE registers are currently live for the thread at signal delivery,
@@ -205,34 +206,33 @@ struct sve_context {
  * Additional data might be appended in the future.
  */
 
-#define SVE_SIG_ZREG_SIZE(vq)	((__u32)(vq) * SVE_VQ_BYTES)
-#define SVE_SIG_PREG_SIZE(vq)	((__u32)(vq) * (SVE_VQ_BYTES / 8))
-#define SVE_SIG_FFR_SIZE(vq)	SVE_SIG_PREG_SIZE(vq)
+#define SVE_SIG_ZREG_SIZE(vq)	__SVE_ZREG_SIZE(vq)
+#define SVE_SIG_PREG_SIZE(vq)	__SVE_PREG_SIZE(vq)
+#define SVE_SIG_FFR_SIZE(vq)	__SVE_FFR_SIZE(vq)
 
 #define SVE_SIG_REGS_OFFSET					\
-	((sizeof(struct sve_context) + (SVE_VQ_BYTES - 1))	\
-		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
+	((sizeof(struct sve_context) + (__SVE_VQ_BYTES - 1))	\
+		/ __SVE_VQ_BYTES * __SVE_VQ_BYTES)
 
-#define SVE_SIG_ZREGS_OFFSET	SVE_SIG_REGS_OFFSET
+#define SVE_SIG_ZREGS_OFFSET \
+		(SVE_SIG_REGS_OFFSET + __SVE_ZREGS_OFFSET)
 #define SVE_SIG_ZREG_OFFSET(vq, n) \
-	(SVE_SIG_ZREGS_OFFSET + SVE_SIG_ZREG_SIZE(vq) * (n))
-#define SVE_SIG_ZREGS_SIZE(vq) \
-	(SVE_SIG_ZREG_OFFSET(vq, SVE_NUM_ZREGS) - SVE_SIG_ZREGS_OFFSET)
+		(SVE_SIG_REGS_OFFSET + __SVE_ZREG_OFFSET(vq, n))
+#define SVE_SIG_ZREGS_SIZE(vq) __SVE_ZREGS_SIZE(vq)
 
 #define SVE_SIG_PREGS_OFFSET(vq) \
-	(SVE_SIG_ZREGS_OFFSET + SVE_SIG_ZREGS_SIZE(vq))
+		(SVE_SIG_REGS_OFFSET + __SVE_PREGS_OFFSET(vq))
 #define SVE_SIG_PREG_OFFSET(vq, n) \
-	(SVE_SIG_PREGS_OFFSET(vq) + SVE_SIG_PREG_SIZE(vq) * (n))
-#define SVE_SIG_PREGS_SIZE(vq) \
-	(SVE_SIG_PREG_OFFSET(vq, SVE_NUM_PREGS) - SVE_SIG_PREGS_OFFSET(vq))
+		(SVE_SIG_REGS_OFFSET + __SVE_PREG_OFFSET(vq, n))
+#define SVE_SIG_PREGS_SIZE(vq) __SVE_PREGS_SIZE(vq)
 
 #define SVE_SIG_FFR_OFFSET(vq) \
-	(SVE_SIG_PREGS_OFFSET(vq) + SVE_SIG_PREGS_SIZE(vq))
+		(SVE_SIG_REGS_OFFSET + __SVE_FFR_OFFSET(vq))
 
 #define SVE_SIG_REGS_SIZE(vq) \
-	(SVE_SIG_FFR_OFFSET(vq) + SVE_SIG_FFR_SIZE(vq) - SVE_SIG_REGS_OFFSET)
-
-#define SVE_SIG_CONTEXT_SIZE(vq) (SVE_SIG_REGS_OFFSET + SVE_SIG_REGS_SIZE(vq))
+		(__SVE_FFR_OFFSET(vq) + __SVE_FFR_SIZE(vq))
 
+#define SVE_SIG_CONTEXT_SIZE(vq) \
+		(SVE_SIG_REGS_OFFSET + SVE_SIG_REGS_SIZE(vq))
 
 #endif /* _UAPI__ASM_SIGCONTEXT_H */
diff --git a/arch/arm64/include/uapi/asm/sve_context.h b/arch/arm64/include/uapi/asm/sve_context.h
new file mode 100644
index 0000000..140f14c
--- /dev/null
+++ b/arch/arm64/include/uapi/asm/sve_context.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* Copyright (C) 2017-2018 ARM Limited */
+
+#if !defined(_UAPI__ASM_PTRACE_H) && !defined(_UAPI__ASM_SIGCONTEXT_H)
+#error "Do not include this header or use its definitions directly."
+#endif
+
+#ifndef _UAPI__ASM_SVE_CONTEXT_H
+#define _UAPI__ASM_SVE_CONTEXT_H
+
+#define __SVE_VQ_BYTES		16	/* number of bytes per quadword */
+
+#define __SVE_VQ_MIN		1
+#define __SVE_VQ_MAX		512
+
+#define __SVE_VL_MIN		(__SVE_VQ_MIN * __SVE_VQ_BYTES)
+#define __SVE_VL_MAX		(__SVE_VQ_MAX * __SVE_VQ_BYTES)
+
+#define __SVE_NUM_ZREGS		32
+#define __SVE_NUM_PREGS		16
+
+#define __sve_vl_valid(vl)			\
+	((vl) % __SVE_VQ_BYTES == 0 &&		\
+	 (vl) >= __SVE_VL_MIN &&		\
+	 (vl) <= __SVE_VL_MAX)
+
+#define __sve_vq_from_vl(vl)	((vl) / __SVE_VQ_BYTES)
+#define __sve_vl_from_vq(vq)	((vq) * __SVE_VQ_BYTES)
+
+#define __SVE_ZREG_SIZE(vq)	((__u32)(vq) * __SVE_VQ_BYTES)
+#define __SVE_PREG_SIZE(vq)	((__u32)(vq) * (__SVE_VQ_BYTES / 8))
+#define __SVE_FFR_SIZE(vq)	__SVE_PREG_SIZE(vq)
+
+#define __SVE_ZREGS_OFFSET	0
+#define __SVE_ZREG_OFFSET(vq, n) \
+	(__SVE_ZREGS_OFFSET + __SVE_ZREG_SIZE(vq) * (n))
+#define __SVE_ZREGS_SIZE(vq) \
+	(__SVE_ZREG_OFFSET(vq, __SVE_NUM_ZREGS) - __SVE_ZREGS_OFFSET)
+
+#define __SVE_PREGS_OFFSET(vq) \
+	(__SVE_ZREGS_OFFSET + __SVE_ZREGS_SIZE(vq))
+#define __SVE_PREG_OFFSET(vq, n) \
+	(__SVE_PREGS_OFFSET(vq) + __SVE_PREG_SIZE(vq) * (n))
+#define __SVE_PREGS_SIZE(vq) \
+	(__SVE_PREG_OFFSET(vq, __SVE_NUM_PREGS) - __SVE_PREGS_OFFSET(vq))
+
+#define __SVE_FFR_OFFSET(vq) \
+	(__SVE_PREGS_OFFSET(vq) + __SVE_PREGS_SIZE(vq))
+
+#endif /* ! _UAPI__ASM_SVE_CONTEXT_H */
-- 
2.1.4

[PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Dave Martin]

Currently, <uapi/asm/sigcontext.h> provides common definitions for
describing SVE context structures that are also used by the ptrace
definitions in <uapi/asm/ptrace.h>.

For this reason, a #include of <asm/sigcontext.h> was added in
ptrace.h, but it this turns out that this can interact badly with
userspace code that tries to include ptrace.h on top of the libc
headers (which may provide their own shadow definitions for
sigcontext.h).

To make the headers easier for userspace to consume, this patch
bounces the common definitions into an __SVE_* namespace and moves
them to a backend header <uapi/asm/sve_context.h> that can be
included by the other headers as appropriate.  This should allow
ptrace.h to be used alongside libc's sigcontext.h (if any) without
ill effects.

This should make the situation unambiguous: <asm/sigcontext.h> is
the header to include for the sigframe-specific definitions, while
<asm/ptrace.h> is the header to include for ptrace-specific
definitions.

To avoid conflicting with existing usage, <asm/sigcontext.h>
remains the canonical way to get the common definitions for
SVE_VQ_MIN, sve_vq_from_vl() etc., both in userspace and in the
kernel: relying on these being defined as a side effect of
including just <asm/ptrace.h> was never intended to be safe.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 arch/arm64/include/uapi/asm/ptrace.h      | 39 ++++++++++-----------
 arch/arm64/include/uapi/asm/sigcontext.h  | 56 +++++++++++++++----------------
 arch/arm64/include/uapi/asm/sve_context.h | 50 +++++++++++++++++++++++++++
 3 files changed, 96 insertions(+), 49 deletions(-)
 create mode 100644 arch/arm64/include/uapi/asm/sve_context.h

diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index 65ef8b0..cff79c5 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -23,7 +23,7 @@
 #include <linux/types.h>
 
 #include <asm/hwcap.h>
-#include <asm/sigcontext.h>
+#include <asm/sve_context.h>
 
 
 /*
@@ -130,9 +130,9 @@ struct user_sve_header {
  */
 
 /* Offset from the start of struct user_sve_header to the register data */
-#define SVE_PT_REGS_OFFSET					\
-	((sizeof(struct user_sve_header) + (SVE_VQ_BYTES - 1))	\
-		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
+#define SVE_PT_REGS_OFFSET						\
+	((sizeof(struct user_sve_header) + (__SVE_VQ_BYTES - 1))	\
+		/ __SVE_VQ_BYTES * __SVE_VQ_BYTES)
 
 /*
  * The register data content and layout depends on the value of the
@@ -178,39 +178,36 @@ struct user_sve_header {
  * Additional data might be appended in the future.
  */
 
-#define SVE_PT_SVE_ZREG_SIZE(vq)	SVE_SIG_ZREG_SIZE(vq)
-#define SVE_PT_SVE_PREG_SIZE(vq)	SVE_SIG_PREG_SIZE(vq)
-#define SVE_PT_SVE_FFR_SIZE(vq)		SVE_SIG_FFR_SIZE(vq)
+#define SVE_PT_SVE_ZREG_SIZE(vq)	__SVE_ZREG_SIZE(vq)
+#define SVE_PT_SVE_PREG_SIZE(vq)	__SVE_PREG_SIZE(vq)
+#define SVE_PT_SVE_FFR_SIZE(vq)		__SVE_FFR_SIZE(vq)
 #define SVE_PT_SVE_FPSR_SIZE		sizeof(__u32)
 #define SVE_PT_SVE_FPCR_SIZE		sizeof(__u32)
 
-#define __SVE_SIG_TO_PT(offset) \
-	((offset) - SVE_SIG_REGS_OFFSET + SVE_PT_REGS_OFFSET)
-
 #define SVE_PT_SVE_OFFSET		SVE_PT_REGS_OFFSET
 
 #define SVE_PT_SVE_ZREGS_OFFSET \
-	__SVE_SIG_TO_PT(SVE_SIG_ZREGS_OFFSET)
+	(SVE_PT_REGS_OFFSET + __SVE_ZREGS_OFFSET)
 #define SVE_PT_SVE_ZREG_OFFSET(vq, n) \
-	__SVE_SIG_TO_PT(SVE_SIG_ZREG_OFFSET(vq, n))
+	(SVE_PT_REGS_OFFSET + __SVE_ZREG_OFFSET(vq, n))
 #define SVE_PT_SVE_ZREGS_SIZE(vq) \
-	(SVE_PT_SVE_ZREG_OFFSET(vq, SVE_NUM_ZREGS) - SVE_PT_SVE_ZREGS_OFFSET)
+	(SVE_PT_SVE_ZREG_OFFSET(vq, __SVE_NUM_ZREGS) - SVE_PT_SVE_ZREGS_OFFSET)
 
 #define SVE_PT_SVE_PREGS_OFFSET(vq) \
-	__SVE_SIG_TO_PT(SVE_SIG_PREGS_OFFSET(vq))
+	(SVE_PT_REGS_OFFSET + __SVE_PREGS_OFFSET(vq))
 #define SVE_PT_SVE_PREG_OFFSET(vq, n) \
-	__SVE_SIG_TO_PT(SVE_SIG_PREG_OFFSET(vq, n))
+	(SVE_PT_REGS_OFFSET + __SVE_PREG_OFFSET(vq, n))
 #define SVE_PT_SVE_PREGS_SIZE(vq) \
-	(SVE_PT_SVE_PREG_OFFSET(vq, SVE_NUM_PREGS) - \
+	(SVE_PT_SVE_PREG_OFFSET(vq, __SVE_NUM_PREGS) - \
 		SVE_PT_SVE_PREGS_OFFSET(vq))
 
 #define SVE_PT_SVE_FFR_OFFSET(vq) \
-	__SVE_SIG_TO_PT(SVE_SIG_FFR_OFFSET(vq))
+	(SVE_PT_REGS_OFFSET + __SVE_FFR_OFFSET(vq))
 
 #define SVE_PT_SVE_FPSR_OFFSET(vq)				\
 	((SVE_PT_SVE_FFR_OFFSET(vq) + SVE_PT_SVE_FFR_SIZE(vq) +	\
-			(SVE_VQ_BYTES - 1))			\
-		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
+			(__SVE_VQ_BYTES - 1))			\
+		/ __SVE_VQ_BYTES * __SVE_VQ_BYTES)
 #define SVE_PT_SVE_FPCR_OFFSET(vq) \
 	(SVE_PT_SVE_FPSR_OFFSET(vq) + SVE_PT_SVE_FPSR_SIZE)
 
@@ -221,8 +218,8 @@ struct user_sve_header {
 
 #define SVE_PT_SVE_SIZE(vq, flags)					\
 	((SVE_PT_SVE_FPCR_OFFSET(vq) + SVE_PT_SVE_FPCR_SIZE		\
-			- SVE_PT_SVE_OFFSET + (SVE_VQ_BYTES - 1))	\
-		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
+			- SVE_PT_SVE_OFFSET + (__SVE_VQ_BYTES - 1))	\
+		/ __SVE_VQ_BYTES * __SVE_VQ_BYTES)
 
 #define SVE_PT_SIZE(vq, flags)						\
 	 (((flags) & SVE_PT_REGS_MASK) == SVE_PT_REGS_SVE ?		\
diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
index dca8f8b..5f3c0ce 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -130,6 +130,8 @@ struct sve_context {
 
 #endif /* !__ASSEMBLY__ */
 
+#include <asm/sve_context.h>
+
 /*
  * The SVE architecture leaves space for future expansion of the
  * vector length beyond its initial architectural limit of 2048 bits
@@ -138,21 +140,20 @@ struct sve_context {
  * See linux/Documentation/arm64/sve.txt for a description of the VL/VQ
  * terminology.
  */
-#define SVE_VQ_BYTES		16	/* number of bytes per quadword */
+#define SVE_VQ_BYTES		__SVE_VQ_BYTES	/* bytes per quadword */
 
-#define SVE_VQ_MIN		1
-#define SVE_VQ_MAX		512
+#define SVE_VQ_MIN		__SVE_VQ_MIN
+#define SVE_VQ_MAX		__SVE_VQ_MAX
 
-#define SVE_VL_MIN		(SVE_VQ_MIN * SVE_VQ_BYTES)
-#define SVE_VL_MAX		(SVE_VQ_MAX * SVE_VQ_BYTES)
+#define SVE_VL_MIN		__SVE_VL_MIN
+#define SVE_VL_MAX		__SVE_VL_MAX
 
-#define SVE_NUM_ZREGS		32
-#define SVE_NUM_PREGS		16
+#define SVE_NUM_ZREGS		__SVE_NUM_ZREGS
+#define SVE_NUM_PREGS		__SVE_NUM_PREGS
 
-#define sve_vl_valid(vl) \
-	((vl) % SVE_VQ_BYTES == 0 && (vl) >= SVE_VL_MIN && (vl) <= SVE_VL_MAX)
-#define sve_vq_from_vl(vl)	((vl) / SVE_VQ_BYTES)
-#define sve_vl_from_vq(vq)	((vq) * SVE_VQ_BYTES)
+#define sve_vl_valid(vl)	__sve_vl_valid(vl)
+#define sve_vq_from_vl(vl)	__sve_vq_from_vl(vl)
+#define sve_vl_from_vq(vq)	__sve_vl_from_vq(vq)
 
 /*
  * If the SVE registers are currently live for the thread at signal delivery,
@@ -205,34 +206,33 @@ struct sve_context {
  * Additional data might be appended in the future.
  */
 
-#define SVE_SIG_ZREG_SIZE(vq)	((__u32)(vq) * SVE_VQ_BYTES)
-#define SVE_SIG_PREG_SIZE(vq)	((__u32)(vq) * (SVE_VQ_BYTES / 8))
-#define SVE_SIG_FFR_SIZE(vq)	SVE_SIG_PREG_SIZE(vq)
+#define SVE_SIG_ZREG_SIZE(vq)	__SVE_ZREG_SIZE(vq)
+#define SVE_SIG_PREG_SIZE(vq)	__SVE_PREG_SIZE(vq)
+#define SVE_SIG_FFR_SIZE(vq)	__SVE_FFR_SIZE(vq)
 
 #define SVE_SIG_REGS_OFFSET					\
-	((sizeof(struct sve_context) + (SVE_VQ_BYTES - 1))	\
-		/ SVE_VQ_BYTES * SVE_VQ_BYTES)
+	((sizeof(struct sve_context) + (__SVE_VQ_BYTES - 1))	\
+		/ __SVE_VQ_BYTES * __SVE_VQ_BYTES)
 
-#define SVE_SIG_ZREGS_OFFSET	SVE_SIG_REGS_OFFSET
+#define SVE_SIG_ZREGS_OFFSET \
+		(SVE_SIG_REGS_OFFSET + __SVE_ZREGS_OFFSET)
 #define SVE_SIG_ZREG_OFFSET(vq, n) \
-	(SVE_SIG_ZREGS_OFFSET + SVE_SIG_ZREG_SIZE(vq) * (n))
-#define SVE_SIG_ZREGS_SIZE(vq) \
-	(SVE_SIG_ZREG_OFFSET(vq, SVE_NUM_ZREGS) - SVE_SIG_ZREGS_OFFSET)
+		(SVE_SIG_REGS_OFFSET + __SVE_ZREG_OFFSET(vq, n))
+#define SVE_SIG_ZREGS_SIZE(vq) __SVE_ZREGS_SIZE(vq)
 
 #define SVE_SIG_PREGS_OFFSET(vq) \
-	(SVE_SIG_ZREGS_OFFSET + SVE_SIG_ZREGS_SIZE(vq))
+		(SVE_SIG_REGS_OFFSET + __SVE_PREGS_OFFSET(vq))
 #define SVE_SIG_PREG_OFFSET(vq, n) \
-	(SVE_SIG_PREGS_OFFSET(vq) + SVE_SIG_PREG_SIZE(vq) * (n))
-#define SVE_SIG_PREGS_SIZE(vq) \
-	(SVE_SIG_PREG_OFFSET(vq, SVE_NUM_PREGS) - SVE_SIG_PREGS_OFFSET(vq))
+		(SVE_SIG_REGS_OFFSET + __SVE_PREG_OFFSET(vq, n))
+#define SVE_SIG_PREGS_SIZE(vq) __SVE_PREGS_SIZE(vq)
 
 #define SVE_SIG_FFR_OFFSET(vq) \
-	(SVE_SIG_PREGS_OFFSET(vq) + SVE_SIG_PREGS_SIZE(vq))
+		(SVE_SIG_REGS_OFFSET + __SVE_FFR_OFFSET(vq))
 
 #define SVE_SIG_REGS_SIZE(vq) \
-	(SVE_SIG_FFR_OFFSET(vq) + SVE_SIG_FFR_SIZE(vq) - SVE_SIG_REGS_OFFSET)
-
-#define SVE_SIG_CONTEXT_SIZE(vq) (SVE_SIG_REGS_OFFSET + SVE_SIG_REGS_SIZE(vq))
+		(__SVE_FFR_OFFSET(vq) + __SVE_FFR_SIZE(vq))
 
+#define SVE_SIG_CONTEXT_SIZE(vq) \
+		(SVE_SIG_REGS_OFFSET + SVE_SIG_REGS_SIZE(vq))
 
 #endif /* _UAPI__ASM_SIGCONTEXT_H */
diff --git a/arch/arm64/include/uapi/asm/sve_context.h b/arch/arm64/include/uapi/asm/sve_context.h
new file mode 100644
index 0000000..140f14c
--- /dev/null
+++ b/arch/arm64/include/uapi/asm/sve_context.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* Copyright (C) 2017-2018 ARM Limited */
+
+#if !defined(_UAPI__ASM_PTRACE_H) && !defined(_UAPI__ASM_SIGCONTEXT_H)
+#error "Do not include this header or use its definitions directly."
+#endif
+
+#ifndef _UAPI__ASM_SVE_CONTEXT_H
+#define _UAPI__ASM_SVE_CONTEXT_H
+
+#define __SVE_VQ_BYTES		16	/* number of bytes per quadword */
+
+#define __SVE_VQ_MIN		1
+#define __SVE_VQ_MAX		512
+
+#define __SVE_VL_MIN		(__SVE_VQ_MIN * __SVE_VQ_BYTES)
+#define __SVE_VL_MAX		(__SVE_VQ_MAX * __SVE_VQ_BYTES)
+
+#define __SVE_NUM_ZREGS		32
+#define __SVE_NUM_PREGS		16
+
+#define __sve_vl_valid(vl)			\
+	((vl) % __SVE_VQ_BYTES == 0 &&		\
+	 (vl) >= __SVE_VL_MIN &&		\
+	 (vl) <= __SVE_VL_MAX)
+
+#define __sve_vq_from_vl(vl)	((vl) / __SVE_VQ_BYTES)
+#define __sve_vl_from_vq(vq)	((vq) * __SVE_VQ_BYTES)
+
+#define __SVE_ZREG_SIZE(vq)	((__u32)(vq) * __SVE_VQ_BYTES)
+#define __SVE_PREG_SIZE(vq)	((__u32)(vq) * (__SVE_VQ_BYTES / 8))
+#define __SVE_FFR_SIZE(vq)	__SVE_PREG_SIZE(vq)
+
+#define __SVE_ZREGS_OFFSET	0
+#define __SVE_ZREG_OFFSET(vq, n) \
+	(__SVE_ZREGS_OFFSET + __SVE_ZREG_SIZE(vq) * (n))
+#define __SVE_ZREGS_SIZE(vq) \
+	(__SVE_ZREG_OFFSET(vq, __SVE_NUM_ZREGS) - __SVE_ZREGS_OFFSET)
+
+#define __SVE_PREGS_OFFSET(vq) \
+	(__SVE_ZREGS_OFFSET + __SVE_ZREGS_SIZE(vq))
+#define __SVE_PREG_OFFSET(vq, n) \
+	(__SVE_PREGS_OFFSET(vq) + __SVE_PREG_SIZE(vq) * (n))
+#define __SVE_PREGS_SIZE(vq) \
+	(__SVE_PREG_OFFSET(vq, __SVE_NUM_PREGS) - __SVE_PREGS_OFFSET(vq))
+
+#define __SVE_FFR_OFFSET(vq) \
+	(__SVE_PREGS_OFFSET(vq) + __SVE_PREGS_SIZE(vq))
+
+#endif /* ! _UAPI__ASM_SVE_CONTEXT_H */
-- 
2.1.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

Hi Dave,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Dave-Martin/arm64-sve-UAPI-Disentangle-ptrace-h-from-sigcontext-h/20181214-225154
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.2.0 make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61900 bytes --]

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

Hi Dave,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Dave-Martin/arm64-sve-UAPI-Disentangle-ptrace-h-from-sigcontext-h/20181214-225154
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.2.0 make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61900 bytes --]

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Dave Martin]

On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:
> Hi Dave,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on arm64/for-next/core]
> [also build test WARNING on v4.20-rc6 next-20181214]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Dave-Martin/arm64-sve-UAPI-Disentangle-ptrace-h-from-sigcontext-h/20181214-225154
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
> config: arm64-allmodconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.2.0 make.cross ARCH=arm64 
> 
> All warnings (new ones prefixed by >>):
> 
> >> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>

Since the new header is not meant to be included directly (and has a
guard to that effect), we don't strictly need to do anything here.

The way to include <asm/sve_context.h> in userspace is via
<asm/sigcontext.h> or <asm/ptrace.h>, both of which include
<linux/types.h> first.


Ironically, the type casts in sve_context.h that necessitate this
#include are probably not needed either.  I misunderstood the C
standard as indicating that if vq is a 16-bit type (which is the case
in some places) then the result of multiplying it by something may be
truncated to 16 bits.  This is not the case: the operands of * are
promoted at least to int first, and int is large enough to hold the
result of these multiplication for all valid vq values.

Removing the cast causes some otherwise __u32 expressions to become
ints (albeit with the same numeric value).

This affects semantics and code generation, so it's probably safest
not to touch these casts now given that they have already been exposed
as UAPI.

We should probably add the #include for cleanliness, but nothing should
break if we don't.

Cheers
---Dave

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Dave Martin]

On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:
> Hi Dave,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on arm64/for-next/core]
> [also build test WARNING on v4.20-rc6 next-20181214]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Dave-Martin/arm64-sve-UAPI-Disentangle-ptrace-h-from-sigcontext-h/20181214-225154
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
> config: arm64-allmodconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.2.0 make.cross ARCH=arm64 
> 
> All warnings (new ones prefixed by >>):
> 
> >> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>

Since the new header is not meant to be included directly (and has a
guard to that effect), we don't strictly need to do anything here.

The way to include <asm/sve_context.h> in userspace is via
<asm/sigcontext.h> or <asm/ptrace.h>, both of which include
<linux/types.h> first.


Ironically, the type casts in sve_context.h that necessitate this
#include are probably not needed either.  I misunderstood the C
standard as indicating that if vq is a 16-bit type (which is the case
in some places) then the result of multiplying it by something may be
truncated to 16 bits.  This is not the case: the operands of * are
promoted at least to int first, and int is large enough to hold the
result of these multiplication for all valid vq values.

Removing the cast causes some otherwise __u32 expressions to become
ints (albeit with the same numeric value).

This affects semantics and code generation, so it's probably safest
not to touch these casts now given that they have already been exposed
as UAPI.

We should probably add the #include for cleanliness, but nothing should
break if we don't.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Szabolcs Nagy]

On 18/12/2018 12:14, Dave Martin wrote:
> On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:
>> Hi Dave,
>>
>> Thank you for the patch! Perhaps something to improve:
>>
>> [auto build test WARNING on arm64/for-next/core]
>> [also build test WARNING on v4.20-rc6 next-20181214]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>
>> url:    https://github.com/0day-ci/linux/commits/Dave-Martin/arm64-sve-UAPI-Disentangle-ptrace-h-from-sigcontext-h/20181214-225154
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
>> config: arm64-allmodconfig (attached as .config)
>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> reproduce:
>>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>         chmod +x ~/bin/make.cross
>>         # save the attached .config to linux build tree
>>         GCC_VERSION=7.2.0 make.cross ARCH=arm64 
>>
>> All warnings (new ones prefixed by >>):
>>
>>>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>
> 
> Since the new header is not meant to be included directly (and has a
> guard to that effect), we don't strictly need to do anything here.
> 
> The way to include <asm/sve_context.h> in userspace is via
> <asm/sigcontext.h> or <asm/ptrace.h>, both of which include
> <linux/types.h> first.
> 

i think there is no need to explicitly prevent the inclusion of
the header.

it is enough to have a comment that it's not supposed to be
included by user code (so the header can be later refactored).

and then such automated header checks (or whatever other hacks
ppl do temporarily) can continue to work.

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Szabolcs Nagy]

On 18/12/2018 12:14, Dave Martin wrote:
> On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:
>> Hi Dave,
>>
>> Thank you for the patch! Perhaps something to improve:
>>
>> [auto build test WARNING on arm64/for-next/core]
>> [also build test WARNING on v4.20-rc6 next-20181214]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>
>> url:    https://github.com/0day-ci/linux/commits/Dave-Martin/arm64-sve-UAPI-Disentangle-ptrace-h-from-sigcontext-h/20181214-225154
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
>> config: arm64-allmodconfig (attached as .config)
>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> reproduce:
>>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>         chmod +x ~/bin/make.cross
>>         # save the attached .config to linux build tree
>>         GCC_VERSION=7.2.0 make.cross ARCH=arm64 
>>
>> All warnings (new ones prefixed by >>):
>>
>>>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>
> 
> Since the new header is not meant to be included directly (and has a
> guard to that effect), we don't strictly need to do anything here.
> 
> The way to include <asm/sve_context.h> in userspace is via
> <asm/sigcontext.h> or <asm/ptrace.h>, both of which include
> <linux/types.h> first.
> 

i think there is no need to explicitly prevent the inclusion of
the header.

it is enough to have a comment that it's not supposed to be
included by user code (so the header can be later refactored).

and then such automated header checks (or whatever other hacks
ppl do temporarily) can continue to work.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Dave Martin]

On Wed, Dec 19, 2018 at 03:11:52PM +0000, Szabolcs Nagy wrote:
> On 18/12/2018 12:14, Dave Martin wrote:
> > On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:

[...]

> >>>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>
> > 
> > Since the new header is not meant to be included directly (and has a
> > guard to that effect), we don't strictly need to do anything here.
> > 
> > The way to include <asm/sve_context.h> in userspace is via
> > <asm/sigcontext.h> or <asm/ptrace.h>, both of which include
> > <linux/types.h> first.
> > 
> 
> i think there is no need to explicitly prevent the inclusion of
> the header.
> 
> it is enough to have a comment that it's not supposed to be
> included by user code (so the header can be later refactored).
> 
> and then such automated header checks (or whatever other hacks
> ppl do temporarily) can continue to work.

The guard is in linux-next now AFAIK.

Are you saying that it's likely to break something and needs to be
removed, or it is unnecessary but harmless?

Cheers
---Dave

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Dave Martin]

On Wed, Dec 19, 2018 at 03:11:52PM +0000, Szabolcs Nagy wrote:
> On 18/12/2018 12:14, Dave Martin wrote:
> > On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:

[...]

> >>>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>
> > 
> > Since the new header is not meant to be included directly (and has a
> > guard to that effect), we don't strictly need to do anything here.
> > 
> > The way to include <asm/sve_context.h> in userspace is via
> > <asm/sigcontext.h> or <asm/ptrace.h>, both of which include
> > <linux/types.h> first.
> > 
> 
> i think there is no need to explicitly prevent the inclusion of
> the header.
> 
> it is enough to have a comment that it's not supposed to be
> included by user code (so the header can be later refactored).
> 
> and then such automated header checks (or whatever other hacks
> ppl do temporarily) can continue to work.

The guard is in linux-next now AFAIK.

Are you saying that it's likely to break something and needs to be
removed, or it is unnecessary but harmless?

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Szabolcs Nagy]

On 19/12/2018 15:23, Dave Martin wrote:
> On Wed, Dec 19, 2018 at 03:11:52PM +0000, Szabolcs Nagy wrote:
>> On 18/12/2018 12:14, Dave Martin wrote:
>>> On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:
> 
> [...]
> 
>>>>>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>
>>>
>>> Since the new header is not meant to be included directly (and has a
>>> guard to that effect), we don't strictly need to do anything here.
>>>
>>> The way to include <asm/sve_context.h> in userspace is via
>>> <asm/sigcontext.h> or <asm/ptrace.h>, both of which include
>>> <linux/types.h> first.
>>>
>>
>> i think there is no need to explicitly prevent the inclusion of
>> the header.
>>
>> it is enough to have a comment that it's not supposed to be
>> included by user code (so the header can be later refactored).
>>
>> and then such automated header checks (or whatever other hacks
>> ppl do temporarily) can continue to work.
> 
> The guard is in linux-next now AFAIK.
> 
> Are you saying that it's likely to break something and needs to be
> removed, or it is unnecessary but harmless?

unnecessary but harmless.

(i assumed the header check bot would want to include every
header on its own and see if there are undefined symbols, but
if it works with the guard then fine)

Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Szabolcs Nagy]

On 19/12/2018 15:23, Dave Martin wrote:
> On Wed, Dec 19, 2018 at 03:11:52PM +0000, Szabolcs Nagy wrote:
>> On 18/12/2018 12:14, Dave Martin wrote:
>>> On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:
> 
> [...]
> 
>>>>>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>
>>>
>>> Since the new header is not meant to be included directly (and has a
>>> guard to that effect), we don't strictly need to do anything here.
>>>
>>> The way to include <asm/sve_context.h> in userspace is via
>>> <asm/sigcontext.h> or <asm/ptrace.h>, both of which include
>>> <linux/types.h> first.
>>>
>>
>> i think there is no need to explicitly prevent the inclusion of
>> the header.
>>
>> it is enough to have a comment that it's not supposed to be
>> included by user code (so the header can be later refactored).
>>
>> and then such automated header checks (or whatever other hacks
>> ppl do temporarily) can continue to work.
> 
> The guard is in linux-next now AFAIK.
> 
> Are you saying that it's likely to break something and needs to be
> removed, or it is unnecessary but harmless?

unnecessary but harmless.

(i assumed the header check bot would want to include every
header on its own and see if there are undefined symbols, but
if it works with the guard then fine)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Szabolcs Nagy]

On 11/12/2018 19:26, Dave Martin wrote:
> This patch refactors the UAPI header definitions for the Arm SVE
> extension to avoid multiple-definition problems when userspace mixes its
> own sigcontext.h definitions with the kernel's ptrace.h (which is
> apparently routine).
> 
> A common backend header is created to hold common definitions, suitably
> namespaced, and with an appropriate header guard.
> 
> See the commit message in patch 3 for further explanation of why this
> is needed.
> 
> Because of the non-trivial header guard in the new sve_context.h, patch
> 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
> a similar way to the current handling of #ifndef _UAPI_FOO.
> 

thanks for doing this.

the patches fix the gdb build issue on musl libc with an
additional gdb patch:
https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html
(in userspace i'd expect users relying on signal.h providing
whatever is in asm/sigcontext.h.)

i think sve_context.h could be made to work with direct include,
even if that's not useful because there is no public api there.
(and then you dont need the first patch)

> Dave Martin (3):
>   kbuild: install_headers.sh: Strip _UAPI from #if-defined() guards
>   arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET definition
>   arm64/sve: Disentangle <uapi/asm/ptrace.h> from
>     <uapi/asm/sigcontext.h>
> 
>  arch/arm64/include/uapi/asm/ptrace.h      | 39 ++++++++++-----------
>  arch/arm64/include/uapi/asm/sigcontext.h  | 56 +++++++++++++++----------------
>  arch/arm64/include/uapi/asm/sve_context.h | 50 +++++++++++++++++++++++++++
>  scripts/headers_install.sh                |  1 +
>  4 files changed, 97 insertions(+), 49 deletions(-)
>  create mode 100644 arch/arm64/include/uapi/asm/sve_context.h
> 

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Szabolcs Nagy]

On 11/12/2018 19:26, Dave Martin wrote:
> This patch refactors the UAPI header definitions for the Arm SVE
> extension to avoid multiple-definition problems when userspace mixes its
> own sigcontext.h definitions with the kernel's ptrace.h (which is
> apparently routine).
> 
> A common backend header is created to hold common definitions, suitably
> namespaced, and with an appropriate header guard.
> 
> See the commit message in patch 3 for further explanation of why this
> is needed.
> 
> Because of the non-trivial header guard in the new sve_context.h, patch
> 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
> a similar way to the current handling of #ifndef _UAPI_FOO.
> 

thanks for doing this.

the patches fix the gdb build issue on musl libc with an
additional gdb patch:
https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html
(in userspace i'd expect users relying on signal.h providing
whatever is in asm/sigcontext.h.)

i think sve_context.h could be made to work with direct include,
even if that's not useful because there is no public api there.
(and then you dont need the first patch)

> Dave Martin (3):
>   kbuild: install_headers.sh: Strip _UAPI from #if-defined() guards
>   arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET definition
>   arm64/sve: Disentangle <uapi/asm/ptrace.h> from
>     <uapi/asm/sigcontext.h>
> 
>  arch/arm64/include/uapi/asm/ptrace.h      | 39 ++++++++++-----------
>  arch/arm64/include/uapi/asm/sigcontext.h  | 56 +++++++++++++++----------------
>  arch/arm64/include/uapi/asm/sve_context.h | 50 +++++++++++++++++++++++++++
>  scripts/headers_install.sh                |  1 +
>  4 files changed, 97 insertions(+), 49 deletions(-)
>  create mode 100644 arch/arm64/include/uapi/asm/sve_context.h
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Dave Martin]

On Fri, Dec 14, 2018 at 06:13:33PM +0000, Szabolcs Nagy wrote:
> On 11/12/2018 19:26, Dave Martin wrote:
> > This patch refactors the UAPI header definitions for the Arm SVE
> > extension to avoid multiple-definition problems when userspace mixes its
> > own sigcontext.h definitions with the kernel's ptrace.h (which is
> > apparently routine).
> > 
> > A common backend header is created to hold common definitions, suitably
> > namespaced, and with an appropriate header guard.
> > 
> > See the commit message in patch 3 for further explanation of why this
> > is needed.
> > 
> > Because of the non-trivial header guard in the new sve_context.h, patch
> > 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
> > a similar way to the current handling of #ifndef _UAPI_FOO.
> > 
> 
> thanks for doing this.
> 
> the patches fix the gdb build issue on musl libc with an
> additional gdb patch:
> https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html
> (in userspace i'd expect users relying on signal.h providing
> whatever is in asm/sigcontext.h.)
> 
> i think sve_context.h could be made to work with direct include,
> even if that's not useful because there is no public api there.
> (and then you dont need the first patch)

My general view is that if you want the sigframe types userspace should
usually include <ucontext.h> and refer to mcontext_t.

Because the prototype for sa_sigaction() specifies a void * for the
ucontext argument, I've generally assumed that <signal.h> is not
sufficient to get ucontext_t (or mcontext_t) (but maybe I'm too paranoid
there).

Non-POSIX-flavoured software might include <asm/sigcontext.h> directly.
In glibc/musl libc will that conflict with <signal.h>, or can the two
coexist?

Cheers
---Dave

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Dave Martin]

On Fri, Dec 14, 2018 at 06:13:33PM +0000, Szabolcs Nagy wrote:
> On 11/12/2018 19:26, Dave Martin wrote:
> > This patch refactors the UAPI header definitions for the Arm SVE
> > extension to avoid multiple-definition problems when userspace mixes its
> > own sigcontext.h definitions with the kernel's ptrace.h (which is
> > apparently routine).
> > 
> > A common backend header is created to hold common definitions, suitably
> > namespaced, and with an appropriate header guard.
> > 
> > See the commit message in patch 3 for further explanation of why this
> > is needed.
> > 
> > Because of the non-trivial header guard in the new sve_context.h, patch
> > 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
> > a similar way to the current handling of #ifndef _UAPI_FOO.
> > 
> 
> thanks for doing this.
> 
> the patches fix the gdb build issue on musl libc with an
> additional gdb patch:
> https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html
> (in userspace i'd expect users relying on signal.h providing
> whatever is in asm/sigcontext.h.)
> 
> i think sve_context.h could be made to work with direct include,
> even if that's not useful because there is no public api there.
> (and then you dont need the first patch)

My general view is that if you want the sigframe types userspace should
usually include <ucontext.h> and refer to mcontext_t.

Because the prototype for sa_sigaction() specifies a void * for the
ucontext argument, I've generally assumed that <signal.h> is not
sufficient to get ucontext_t (or mcontext_t) (but maybe I'm too paranoid
there).

Non-POSIX-flavoured software might include <asm/sigcontext.h> directly.
In glibc/musl libc will that conflict with <signal.h>, or can the two
coexist?

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Szabolcs Nagy]

On 14/12/2018 18:25, Dave Martin wrote:
> On Fri, Dec 14, 2018 at 06:13:33PM +0000, Szabolcs Nagy wrote:
>> On 11/12/2018 19:26, Dave Martin wrote:
>>> This patch refactors the UAPI header definitions for the Arm SVE
>>> extension to avoid multiple-definition problems when userspace mixes its
>>> own sigcontext.h definitions with the kernel's ptrace.h (which is
>>> apparently routine).
>>>
>>> A common backend header is created to hold common definitions, suitably
>>> namespaced, and with an appropriate header guard.
>>>
>>> See the commit message in patch 3 for further explanation of why this
>>> is needed.
>>>
>>> Because of the non-trivial header guard in the new sve_context.h, patch
>>> 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
>>> a similar way to the current handling of #ifndef _UAPI_FOO.
>>>
>>
>> thanks for doing this.
>>
>> the patches fix the gdb build issue on musl libc with an
>> additional gdb patch:
>> https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html
>> (in userspace i'd expect users relying on signal.h providing
>> whatever is in asm/sigcontext.h.)
>>
>> i think sve_context.h could be made to work with direct include,
>> even if that's not useful because there is no public api there.
>> (and then you dont need the first patch)
> 
> My general view is that if you want the sigframe types userspace should
> usually include <ucontext.h> and refer to mcontext_t.
> 

ucontext.h does not expose the asm/sigcontext.h types in glibc,
but it is compatible with the inclusion of asm/sigcontext.h
(or signal.h).

in musl ucontext.h includes signal.h and signal.h provides
the asm/sigcontext.h api with abi compatible definitions.

> Because the prototype for sa_sigaction() specifies a void * for the
> ucontext argument, I've generally assumed that <signal.h> is not
> sufficient to get ucontext_t (or mcontext_t) (but maybe I'm too paranoid
> there).

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

"The <signal.h> header shall define the ucontext_t type as a structure
 that shall include at least the following members:
...
 mcontext_t  uc_mcontext A machine-specific representation of the saved
             context."

so signal.h must define ucontext_t but mcontext_t can be opaque.
(it is opaque with posix conform feature tests to avoid
namespace pollution, but with _GNU_SOURCE defined all
asm/sigcontext.h apis are there and mcontext_t matches
struct sigcontext)

> 
> Non-POSIX-flavoured software might include <asm/sigcontext.h> directly.
> In glibc/musl libc will that conflict with <signal.h>, or can the two
> coexist?

if you compile e.g in standard conform mode then
i think signal.h and asm/sigcontext.h are compatible.

> 
> Cheers
> ---Dave
> 

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Szabolcs Nagy]

On 14/12/2018 18:25, Dave Martin wrote:
> On Fri, Dec 14, 2018 at 06:13:33PM +0000, Szabolcs Nagy wrote:
>> On 11/12/2018 19:26, Dave Martin wrote:
>>> This patch refactors the UAPI header definitions for the Arm SVE
>>> extension to avoid multiple-definition problems when userspace mixes its
>>> own sigcontext.h definitions with the kernel's ptrace.h (which is
>>> apparently routine).
>>>
>>> A common backend header is created to hold common definitions, suitably
>>> namespaced, and with an appropriate header guard.
>>>
>>> See the commit message in patch 3 for further explanation of why this
>>> is needed.
>>>
>>> Because of the non-trivial header guard in the new sve_context.h, patch
>>> 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
>>> a similar way to the current handling of #ifndef _UAPI_FOO.
>>>
>>
>> thanks for doing this.
>>
>> the patches fix the gdb build issue on musl libc with an
>> additional gdb patch:
>> https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html
>> (in userspace i'd expect users relying on signal.h providing
>> whatever is in asm/sigcontext.h.)
>>
>> i think sve_context.h could be made to work with direct include,
>> even if that's not useful because there is no public api there.
>> (and then you dont need the first patch)
> 
> My general view is that if you want the sigframe types userspace should
> usually include <ucontext.h> and refer to mcontext_t.
> 

ucontext.h does not expose the asm/sigcontext.h types in glibc,
but it is compatible with the inclusion of asm/sigcontext.h
(or signal.h).

in musl ucontext.h includes signal.h and signal.h provides
the asm/sigcontext.h api with abi compatible definitions.

> Because the prototype for sa_sigaction() specifies a void * for the
> ucontext argument, I've generally assumed that <signal.h> is not
> sufficient to get ucontext_t (or mcontext_t) (but maybe I'm too paranoid
> there).

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

"The <signal.h> header shall define the ucontext_t type as a structure
 that shall include at least the following members:
...
 mcontext_t  uc_mcontext A machine-specific representation of the saved
             context."

so signal.h must define ucontext_t but mcontext_t can be opaque.
(it is opaque with posix conform feature tests to avoid
namespace pollution, but with _GNU_SOURCE defined all
asm/sigcontext.h apis are there and mcontext_t matches
struct sigcontext)

> 
> Non-POSIX-flavoured software might include <asm/sigcontext.h> directly.
> In glibc/musl libc will that conflict with <signal.h>, or can the two
> coexist?

if you compile e.g in standard conform mode then
i think signal.h and asm/sigcontext.h are compatible.

> 
> Cheers
> ---Dave
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Dave P Martin]

On Fri, Dec 14, 2018 at 07:00:07PM +0000, Szabolcs Nagy wrote:
> On 14/12/2018 18:25, Dave Martin wrote:
> > On Fri, Dec 14, 2018 at 06:13:33PM +0000, Szabolcs Nagy wrote:
> >> On 11/12/2018 19:26, Dave Martin wrote:
> >>> This patch refactors the UAPI header definitions for the Arm SVE
> >>> extension to avoid multiple-definition problems when userspace mixes its
> >>> own sigcontext.h definitions with the kernel's ptrace.h (which is
> >>> apparently routine).
> >>>
> >>> A common backend header is created to hold common definitions, suitably
> >>> namespaced, and with an appropriate header guard.
> >>>
> >>> See the commit message in patch 3 for further explanation of why this
> >>> is needed.
> >>>
> >>> Because of the non-trivial header guard in the new sve_context.h, patch
> >>> 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
> >>> a similar way to the current handling of #ifndef _UAPI_FOO.
> >>>
> >>
> >> thanks for doing this.
> >>
> >> the patches fix the gdb build issue on musl libc with an
> >> additional gdb patch:
> >> https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html
> >> (in userspace i'd expect users relying on signal.h providing
> >> whatever is in asm/sigcontext.h.)
> >>
> >> i think sve_context.h could be made to work with direct include,
> >> even if that's not useful because there is no public api there.
> >> (and then you dont need the first patch)
> > 
> > My general view is that if you want the sigframe types userspace should
> > usually include <ucontext.h> and refer to mcontext_t.
> > 
> 
> ucontext.h does not expose the asm/sigcontext.h types in glibc,
> but it is compatible with the inclusion of asm/sigcontext.h
> (or signal.h).
> 
> in musl ucontext.h includes signal.h and signal.h provides
> the asm/sigcontext.h api with abi compatible definitions.
> 
> > Because the prototype for sa_sigaction() specifies a void * for the
> > ucontext argument, I've generally assumed that <signal.h> is not
> > sufficient to get ucontext_t (or mcontext_t) (but maybe I'm too paranoid
> > there).
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html
> 
> "The <signal.h> header shall define the ucontext_t type as a structure
>  that shall include at least the following members:
> ...
>  mcontext_t  uc_mcontext A machine-specific representation of the saved
>              context."
> 
> so signal.h must define ucontext_t but mcontext_t can be opaque.
> (it is opaque with posix conform feature tests to avoid
> namespace pollution, but with _GNU_SOURCE defined all
> asm/sigcontext.h apis are there and mcontext_t matches
> struct sigcontext)

I see.  Sounds reasonable.

> > 
> > Non-POSIX-flavoured software might include <asm/sigcontext.h> directly.
> > In glibc/musl libc will that conflict with <signal.h>, or can the two
> > coexist?
> 
> if you compile e.g in standard conform mode then
> i think signal.h and asm/sigcontext.h are compatible.

So long as we don't break any existing usage (?) I guess this is fine.

Cheers
---Dave

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

[Dave P Martin]

On Fri, Dec 14, 2018 at 07:00:07PM +0000, Szabolcs Nagy wrote:
> On 14/12/2018 18:25, Dave Martin wrote:
> > On Fri, Dec 14, 2018 at 06:13:33PM +0000, Szabolcs Nagy wrote:
> >> On 11/12/2018 19:26, Dave Martin wrote:
> >>> This patch refactors the UAPI header definitions for the Arm SVE
> >>> extension to avoid multiple-definition problems when userspace mixes its
> >>> own sigcontext.h definitions with the kernel's ptrace.h (which is
> >>> apparently routine).
> >>>
> >>> A common backend header is created to hold common definitions, suitably
> >>> namespaced, and with an appropriate header guard.
> >>>
> >>> See the commit message in patch 3 for further explanation of why this
> >>> is needed.
> >>>
> >>> Because of the non-trivial header guard in the new sve_context.h, patch
> >>> 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in
> >>> a similar way to the current handling of #ifndef _UAPI_FOO.
> >>>
> >>
> >> thanks for doing this.
> >>
> >> the patches fix the gdb build issue on musl libc with an
> >> additional gdb patch:
> >> https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html
> >> (in userspace i'd expect users relying on signal.h providing
> >> whatever is in asm/sigcontext.h.)
> >>
> >> i think sve_context.h could be made to work with direct include,
> >> even if that's not useful because there is no public api there.
> >> (and then you dont need the first patch)
> > 
> > My general view is that if you want the sigframe types userspace should
> > usually include <ucontext.h> and refer to mcontext_t.
> > 
> 
> ucontext.h does not expose the asm/sigcontext.h types in glibc,
> but it is compatible with the inclusion of asm/sigcontext.h
> (or signal.h).
> 
> in musl ucontext.h includes signal.h and signal.h provides
> the asm/sigcontext.h api with abi compatible definitions.
> 
> > Because the prototype for sa_sigaction() specifies a void * for the
> > ucontext argument, I've generally assumed that <signal.h> is not
> > sufficient to get ucontext_t (or mcontext_t) (but maybe I'm too paranoid
> > there).
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html
> 
> "The <signal.h> header shall define the ucontext_t type as a structure
>  that shall include at least the following members:
> ...
>  mcontext_t  uc_mcontext A machine-specific representation of the saved
>              context."
> 
> so signal.h must define ucontext_t but mcontext_t can be opaque.
> (it is opaque with posix conform feature tests to avoid
> namespace pollution, but with _GNU_SOURCE defined all
> asm/sigcontext.h apis are there and mcontext_t matches
> struct sigcontext)

I see.  Sounds reasonable.

> > 
> > Non-POSIX-flavoured software might include <asm/sigcontext.h> directly.
> > In glibc/musl libc will that conflict with <signal.h>, or can the two
> > coexist?
> 
> if you compile e.g in standard conform mode then
> i think signal.h and asm/sigcontext.h are compatible.

So long as we don't break any existing usage (?) I guess this is fine.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel