Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1273984 > unrolled thread

[PATCH] ARM64: fix building without CONFIG_UID16

Started byArnd Bergmann <arnd@arndb.de>
First post2015-11-20 12:20 +0100
Last post2015-11-30 09:40 +0100
Articles 4 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] ARM64: fix building without CONFIG_UID16 Arnd Bergmann <arnd@arndb.de> - 2015-11-20 12:20 +0100
    Re: [PATCH] ARM64: fix building without CONFIG_UID16 Will Deacon <will.deacon@arm.com> - 2015-11-23 16:30 +0100
    Re: [PATCH] ARM64: fix building without CONFIG_UID16 Catalin Marinas <catalin.marinas@arm.com> - 2015-11-25 13:20 +0100
    Re: [PATCH] ARM64: fix building without CONFIG_UID16 Heiko Carstens <heiko.carstens@de.ibm.com> - 2015-11-30 09:40 +0100

#1273984 — [PATCH] ARM64: fix building without CONFIG_UID16

FromArnd Bergmann <arnd@arndb.de>
Date2015-11-20 12:20 +0100
Subject[PATCH] ARM64: fix building without CONFIG_UID16
Message-ID<qwRTr-6uh-5@gated-at.bofh.it>
As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16
disabled currently fails because the system call table still needs to
reference the individual function entry points that are provided by
kernel/sys_ni.c in this case, and the declarations are hidden inside
of #ifdef CONFIG_UID16:

arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function)
 __SYSCALL(__NR_lchown, sys_lchown16)

I believe this problem only exists on ARM64, because older architectures
tend to not need declarations when their system call table is built
in assembly code, while newer architectures tend to not need UID16
support. ARM64 only uses these system calls for compatibility with
32-bit ARM binaries.

This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is
set unconditionally on ARM64 with CONFIG_COMPAT, so we see the
declarations whenever we need them, but otherwise the behavior is
unchanged.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: stable@vger.kernel.org
Fixes: af1839eb4bd4 ("Kconfig: clean up the long arch list for the UID16 config option")
---
I would suggest merging this through the arm64 tree, as this is
likely the only architecture that cares about it, and there is little
risk of clashes with other patches in the global headers.

The bug goes back to when arch/arm64 was introduced as far as I can
tell, but I'm not sure if we care about stable backports or not.
I've put stable on Cc anyway, let me know if anyone thinks we should not.

diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index a156b82dd14c..c2b66a277e98 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -524,7 +524,7 @@ asmlinkage long sys_chown(const char __user *filename,
 asmlinkage long sys_lchown(const char __user *filename,
 				uid_t user, gid_t group);
 asmlinkage long sys_fchown(unsigned int fd, uid_t user, gid_t group);
-#ifdef CONFIG_UID16
+#ifdef CONFIG_HAVE_UID16
 asmlinkage long sys_chown16(const char __user *filename,
 				old_uid_t user, old_gid_t group);
 asmlinkage long sys_lchown16(const char __user *filename,
diff --git a/include/linux/types.h b/include/linux/types.h
index 70d8500bddf1..70dd3dfde631 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -35,7 +35,7 @@ typedef __kernel_gid16_t        gid16_t;
 
 typedef unsigned long		uintptr_t;
 
-#ifdef CONFIG_UID16
+#ifdef CONFIG_HAVE_UID16
 /* This is defined by include/asm-{arch}/posix_types.h */
 typedef __kernel_old_uid_t	old_uid_t;
 typedef __kernel_old_gid_t	old_gid_t;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1275489

FromWill Deacon <will.deacon@arm.com>
Date2015-11-23 16:30 +0100
Message-ID<qy1e3-3DU-39@gated-at.bofh.it>
In reply to#1273984
On Fri, Nov 20, 2015 at 12:12:21PM +0100, Arnd Bergmann wrote:
> As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16
> disabled currently fails because the system call table still needs to
> reference the individual function entry points that are provided by
> kernel/sys_ni.c in this case, and the declarations are hidden inside
> of #ifdef CONFIG_UID16:
> 
> arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function)
>  __SYSCALL(__NR_lchown, sys_lchown16)
> 
> I believe this problem only exists on ARM64, because older architectures
> tend to not need declarations when their system call table is built
> in assembly code, while newer architectures tend to not need UID16
> support. ARM64 only uses these system calls for compatibility with
> 32-bit ARM binaries.
> 
> This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is
> set unconditionally on ARM64 with CONFIG_COMPAT, so we see the
> declarations whenever we need them, but otherwise the behavior is
> unchanged.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: stable@vger.kernel.org
> Fixes: af1839eb4bd4 ("Kconfig: clean up the long arch list for the UID16 config option")
> ---
> I would suggest merging this through the arm64 tree, as this is
> likely the only architecture that cares about it, and there is little
> risk of clashes with other patches in the global headers.
> 
> The bug goes back to when arch/arm64 was introduced as far as I can
> tell, but I'm not sure if we care about stable backports or not.
> I've put stable on Cc anyway, let me know if anyone thinks we should not.

Acked-by: Will Deacon <will.deacon@arm.com>

Catalin, can you pick this one up, please?

Will

> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index a156b82dd14c..c2b66a277e98 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -524,7 +524,7 @@ asmlinkage long sys_chown(const char __user *filename,
>  asmlinkage long sys_lchown(const char __user *filename,
>  				uid_t user, gid_t group);
>  asmlinkage long sys_fchown(unsigned int fd, uid_t user, gid_t group);
> -#ifdef CONFIG_UID16
> +#ifdef CONFIG_HAVE_UID16
>  asmlinkage long sys_chown16(const char __user *filename,
>  				old_uid_t user, old_gid_t group);
>  asmlinkage long sys_lchown16(const char __user *filename,
> diff --git a/include/linux/types.h b/include/linux/types.h
> index 70d8500bddf1..70dd3dfde631 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -35,7 +35,7 @@ typedef __kernel_gid16_t        gid16_t;
>  
>  typedef unsigned long		uintptr_t;
>  
> -#ifdef CONFIG_UID16
> +#ifdef CONFIG_HAVE_UID16
>  /* This is defined by include/asm-{arch}/posix_types.h */
>  typedef __kernel_old_uid_t	old_uid_t;
>  typedef __kernel_old_gid_t	old_gid_t;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1277316

FromCatalin Marinas <catalin.marinas@arm.com>
Date2015-11-25 13:20 +0100
Message-ID<qyHdg-6aD-27@gated-at.bofh.it>
In reply to#1273984
On Fri, Nov 20, 2015 at 12:12:21PM +0100, Arnd Bergmann wrote:
> As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16
> disabled currently fails because the system call table still needs to
> reference the individual function entry points that are provided by
> kernel/sys_ni.c in this case, and the declarations are hidden inside
> of #ifdef CONFIG_UID16:
> 
> arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function)
>  __SYSCALL(__NR_lchown, sys_lchown16)
> 
> I believe this problem only exists on ARM64, because older architectures
> tend to not need declarations when their system call table is built
> in assembly code, while newer architectures tend to not need UID16
> support. ARM64 only uses these system calls for compatibility with
> 32-bit ARM binaries.
> 
> This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is
> set unconditionally on ARM64 with CONFIG_COMPAT, so we see the
> declarations whenever we need them, but otherwise the behavior is
> unchanged.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: stable@vger.kernel.org
> Fixes: af1839eb4bd4 ("Kconfig: clean up the long arch list for the UID16 config option")

Applied. Thank.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1279672

FromHeiko Carstens <heiko.carstens@de.ibm.com>
Date2015-11-30 09:40 +0100
Message-ID<qAsa5-1cU-5@gated-at.bofh.it>
In reply to#1273984
On Fri, Nov 20, 2015 at 12:12:21PM +0100, Arnd Bergmann wrote:
> As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16
> disabled currently fails because the system call table still needs to
> reference the individual function entry points that are provided by
> kernel/sys_ni.c in this case, and the declarations are hidden inside
> of #ifdef CONFIG_UID16:

Will we ever get rid of UID16? kernel/uid.c contains this nice comment:

/*
 *	Wrapper functions for 16bit uid back compatibility. All nicely tied
 *	together in the faint hope we can take the out in five years time.
 */

Which seems to exist since at least February 2000. ;)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web