[PATCH resend] uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name
From: Randy Dunlap rdunlap@infradead.org
Since this header is in "include/uapi/linux/", apparently people want to use it in userspace programs -- even in C++ ones. However, the header uses a C++ reserved keyword ("private"), so change that to "dh_private" instead to allow the header file to be used in C++ userspace.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=191051 Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command")
Signed-off-by: Randy Dunlap rdunlap@infradead.org Cc: David Howells dhowells@redhat.com Cc: James Morris jmorris@namei.org Cc: "Serge E. Hallyn" serge@hallyn.com Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: Mat Martineau mathew.j.martineau@linux.intel.com Cc: stable@vger.kernel.org --- include/uapi/linux/keyctl.h | 2 +- security/keys/dh.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
--- lnx-416.orig/include/uapi/linux/keyctl.h +++ lnx-416/include/uapi/linux/keyctl.h @@ -65,7 +65,7 @@
/* keyctl structures */ struct keyctl_dh_params { - __s32 private; + __s32 dh_private; __s32 prime; __s32 base; }; --- lnx-416.orig/security/keys/dh.c +++ lnx-416/security/keys/dh.c @@ -307,7 +307,7 @@ long __keyctl_dh_compute(struct keyctl_d } dh_inputs.g_size = dlen;
- dlen = dh_data_from_key(pcopy.private, &dh_inputs.key); + dlen = dh_data_from_key(pcopy.dh_private, &dh_inputs.key); if (dlen < 0) { ret = dlen; goto out2;
On Tue, Aug 28, 2018 at 04:34:04PM -0700, Randy Dunlap wrote:
From: Randy Dunlap rdunlap@infradead.org
Since this header is in "include/uapi/linux/", apparently people want to use it in userspace programs -- even in C++ ones. However, the header uses a C++ reserved keyword ("private"), so change that to "dh_private" instead to allow the header file to be used in C++ userspace.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=191051 Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command")
Signed-off-by: Randy Dunlap rdunlap@infradead.org Cc: David Howells dhowells@redhat.com Cc: James Morris jmorris@namei.org Cc: "Serge E. Hallyn" serge@hallyn.com Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: Mat Martineau mathew.j.martineau@linux.intel.com Cc: stable@vger.kernel.org
include/uapi/linux/keyctl.h | 2 +- security/keys/dh.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
--- lnx-416.orig/include/uapi/linux/keyctl.h +++ lnx-416/include/uapi/linux/keyctl.h @@ -65,7 +65,7 @@ /* keyctl structures */ struct keyctl_dh_params {
- __s32 private;
- __s32 dh_private;
Ick ick ick, why not just put the C "namespace" on all uapi files if you are including them from c++ code? I'm sure this isn't the only problem that has this problem, right?
This is valid C, no need to start worrying about C++ reserved names.
thanks,
greg "'struct class' is your friend" k-h
On Tue, 28 Aug 2018 19:42:24 -0700 Greg KH gregkh@linuxfoundation.org wrote:
--- lnx-416.orig/include/uapi/linux/keyctl.h +++ lnx-416/include/uapi/linux/keyctl.h @@ -65,7 +65,7 @@ /* keyctl structures */ struct keyctl_dh_params {
- __s32 private;
- __s32 dh_private;
Ick ick ick, why not just put the C "namespace" on all uapi files if you are including them from c++ code? I'm sure this isn't the only problem that has this problem, right?
This is valid C, no need to start worrying about C++ reserved names.
We've done this before and it's a simple enough change in order to be friendly toward others.
That being said, it's been like this for two years so presumably anyone who is using this header from C++ is already `extern "C" { ...}' around their #include.
I'm OK with the patch as-is, but if we run into this issue more often, we might want to look at doing something kernel-wide.
I'm not sure what though. Adding
#ifdef __cplusplus extern "C" { #endif
...
#ifdef __cplusplus } #endif
into every uapi file might work. Unpleasing.
On Tue, Aug 28, 2018 at 04:34:04PM -0700, Randy Dunlap wrote:
From: Randy Dunlap rdunlap@infradead.org
Since this header is in "include/uapi/linux/", apparently people want to use it in userspace programs -- even in C++ ones. However, the header uses a C++ reserved keyword ("private"), so change that to "dh_private" instead to allow the header file to be used in C++ userspace.
This change breaks all existing C programs that rely on <linux/keyctl.h> uapi header in order to get struct keyctl_dh_params definition, however.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=191051 Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command")
Signed-off-by: Randy Dunlap rdunlap@infradead.org Cc: David Howells dhowells@redhat.com Cc: James Morris jmorris@namei.org Cc: "Serge E. Hallyn" serge@hallyn.com Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: Mat Martineau mathew.j.martineau@linux.intel.com Cc: stable@vger.kernel.org
include/uapi/linux/keyctl.h | 2 +- security/keys/dh.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
--- lnx-416.orig/include/uapi/linux/keyctl.h +++ lnx-416/include/uapi/linux/keyctl.h @@ -65,7 +65,7 @@ /* keyctl structures */ struct keyctl_dh_params {
- __s32 private;
- __s32 dh_private;
__s32 prime; __s32 base; }; --- lnx-416.orig/security/keys/dh.c +++ lnx-416/security/keys/dh.c @@ -307,7 +307,7 @@ long __keyctl_dh_compute(struct keyctl_d } dh_inputs.g_size = dlen;
- dlen = dh_data_from_key(pcopy.private, &dh_inputs.key);
- dlen = dh_data_from_key(pcopy.dh_private, &dh_inputs.key); if (dlen < 0) { ret = dlen; goto out2;
On Mon, 10 Sep 2018 00:00:18 +0200 Eugene Syromiatnikov esyr@redhat.com wrote:
On Tue, Aug 28, 2018 at 04:34:04PM -0700, Randy Dunlap wrote:
From: Randy Dunlap rdunlap@infradead.org
Since this header is in "include/uapi/linux/", apparently people want to use it in userspace programs -- even in C++ ones. However, the header uses a C++ reserved keyword ("private"), so change that to "dh_private" instead to allow the header file to be used in C++ userspace.
This change breaks all existing C programs that rely on <linux/keyctl.h> uapi header in order to get struct keyctl_dh_params definition, however.
Are there such programs? Do they reference the `private' field?
Andrew Morton akpm@linux-foundation.org wrote:
Are there such programs? Do they reference the `private' field?
They would use the keyutils.h header from keyutils package probably. There the field was named "priv" not "private". The kernel's UAPI header should be amended again to match that.
David
linux-stable-mirror@lists.linaro.org
-
Andrew Morton -
David Howells -
Eugene Syromiatnikov -
Greg KH -
Randy Dunlap