Re: PER_LINUX32, Was: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Thu, 23 Aug 2012, Arnd Bergmann wrote:
> > > > +asmlinkage int compat_sys_personality(compat_ulong_t personality)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + if (personality(current->personality) == PER_LINUX32 &&
> > > > + personality == PER_LINUX)
> > > > + personality = PER_LINUX32;
> > > > + ret = sys_personality(personality);
> > > > + if (ret == PER_LINUX32)
> > > > + ret = PER_LINUX;
> > > > + return ret;
> > > > +}
> > >
> > > Where did you get this from?
> > >
> > > You should not need compat_sys_personality, just call the native function.
> >
> > Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
> > syscall will start seeing the wrong uname.
>
> Coming back at this topic, I noticed another issue. Jiri Kosina
> has recently posted patches to fix this function in the other architectures
Yeah, there were quite a few broken ones, some of them since the beginning
of time.
> in order to mask out the other personality bits, which is a correct fix,
> but the above function is odd for other reasons.
>
> * On MIPS, it is used only for compat tasks, like you have it above.
> * On PA-RISC, it is used for native 32 bit tasks and for compat 32 bit tasks,
> but not for native 64 bit ones.
> * On IA64, it was used for compat tasks (support for which has since
> been removed from the kernel), plus all 32 bit tasks would start with
> PER_LINUX32.
> * On PowerPC, Sparc and s390, it is used for native 64 bit tasks and for
> compat 32 bit tasks, but not for native 32 bit ones.
> * On Tile, it was never used.
> * On x86_64, it used to be defined (copied from ia64) but not used
> throughout the git history.
>
> The semantics of the function are also interesting: The intention seems
> to be that to a compat task, PER_LINUX32 would appear as PER_LINUX.
> The effect is that any process can set PER_LINUX32 but it can never
> be unset except by a 64 bit MIPS or PA-RISC task.
>
> Since x86_64 does not implement this behavior at all, I suspect that
> there are now lots of things depending on not having it, while all
> the other architectures might also have some (even predating the
> x86_64 port) use cases that depend on depend on not being able to
> observe PER_LINUX32 in 32 bit compat tasks.
>
> I think we should try to agree on how this is all supposed to work
> and use common code, either put the ppc/sparc/s390 version into
> sys_personality, or remove all of them and just do what x86 and tile
> do, using the regular sys_personality for all tasks.
How about rather introducing common compat_sys_personality() and switching
the archs that are using it to it? Unifying the behavior (PER_LINUX /
PER_LINUX32 masquerading) should be painless.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PER_LINUX32, Was: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Thu, 23 Aug 2012, Arnd Bergmann wrote:
+asmlinkage int compat_sys_personality(compat_ulong_t personality)
+{
+ int ret;
+
+ if (personality(current-personality) == PER_LINUX32
+ personality == PER_LINUX)
+ personality = PER_LINUX32;
+ ret = sys_personality(personality);
+ if (ret == PER_LINUX32)
+ ret = PER_LINUX;
+ return ret;
+}
Where did you get this from?
You should not need compat_sys_personality, just call the native function.
Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
syscall will start seeing the wrong uname.
Coming back at this topic, I noticed another issue. Jiri Kosina
has recently posted patches to fix this function in the other architectures
Yeah, there were quite a few broken ones, some of them since the beginning
of time.
in order to mask out the other personality bits, which is a correct fix,
but the above function is odd for other reasons.
* On MIPS, it is used only for compat tasks, like you have it above.
* On PA-RISC, it is used for native 32 bit tasks and for compat 32 bit tasks,
but not for native 64 bit ones.
* On IA64, it was used for compat tasks (support for which has since
been removed from the kernel), plus all 32 bit tasks would start with
PER_LINUX32.
* On PowerPC, Sparc and s390, it is used for native 64 bit tasks and for
compat 32 bit tasks, but not for native 32 bit ones.
* On Tile, it was never used.
* On x86_64, it used to be defined (copied from ia64) but not used
throughout the git history.
The semantics of the function are also interesting: The intention seems
to be that to a compat task, PER_LINUX32 would appear as PER_LINUX.
The effect is that any process can set PER_LINUX32 but it can never
be unset except by a 64 bit MIPS or PA-RISC task.
Since x86_64 does not implement this behavior at all, I suspect that
there are now lots of things depending on not having it, while all
the other architectures might also have some (even predating the
x86_64 port) use cases that depend on depend on not being able to
observe PER_LINUX32 in 32 bit compat tasks.
I think we should try to agree on how this is all supposed to work
and use common code, either put the ppc/sparc/s390 version into
sys_personality, or remove all of them and just do what x86 and tile
do, using the regular sys_personality for all tasks.
How about rather introducing common compat_sys_personality() and switching
the archs that are using it to it? Unifying the behavior (PER_LINUX /
PER_LINUX32 masquerading) should be painless.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Friday 24 August 2012, Catalin Marinas wrote: > > What good is the run-time BUG() here? Nothing should be calling these > > when CONFIG_COMPAT is disabled, so I think you should just remove > > the #ifdef around the declarations, and the entire #else case. > > They are called from handle_signal(), so that's to avoid #ifdef inside > functions. I can drop the BUG() (but keep the empty function) and > change the checks to is_compat_task() so that the compiler optimises the > condition out when !COMPAT. > Sounds good. Note that you can turn a lot of #ifdef into if(IS_ENABLED(CONFIG_FOO)) as well, even if there is no other runtime check for them. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Friday 24 August 2012, Catalin Marinas wrote: What good is the run-time BUG() here? Nothing should be calling these when CONFIG_COMPAT is disabled, so I think you should just remove the #ifdef around the declarations, and the entire #else case. They are called from handle_signal(), so that's to avoid #ifdef inside functions. I can drop the BUG() (but keep the empty function) and change the checks to is_compat_task() so that the compiler optimises the condition out when !COMPAT. Sounds good. Note that you can turn a lot of #ifdef into if(IS_ENABLED(CONFIG_FOO)) as well, even if there is no other runtime check for them. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
> On Tuesday 14 August 2012, Catalin Marinas wrote:
>
> > +#ifdef CONFIG_AARCH32_EMULATION
> > +#include
> > +
> > +#define AARCH32_KERN_SIGRET_CODE_OFFSET0x500
> > +
> > +extern const compat_ulong_t aarch32_sigret_code[6];
> > +
> > +int compat_setup_frame(int usig, struct k_sigaction *ka, sigset_t *set,
> > + struct pt_regs *regs);
> > +int compat_setup_rt_frame(int usig, struct k_sigaction *ka, siginfo_t
> > *info,
> > + sigset_t *set, struct pt_regs *regs);
> > +
> > +void compat_setup_restart_syscall(struct pt_regs *regs);
> > +#else
> > +
> > +static inline int compat_setup_frame(int usid, struct k_sigaction *ka,
> > +sigset_t *set, struct pt_regs *regs)
> > +{
> > + BUG();
> > +}
>
> What good is the run-time BUG() here? Nothing should be calling these
> when CONFIG_COMPAT is disabled, so I think you should just remove
> the #ifdef around the declarations, and the entire #else case.
They are called from handle_signal(), so that's to avoid #ifdef inside
functions. I can drop the BUG() (but keep the empty function) and
change the checks to is_compat_task() so that the compiler optimises the
condition out when !COMPAT.
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
On Tuesday 14 August 2012, Catalin Marinas wrote:
+#ifdef CONFIG_AARCH32_EMULATION
+#include linux/compat.h
+
+#define AARCH32_KERN_SIGRET_CODE_OFFSET0x500
+
+extern const compat_ulong_t aarch32_sigret_code[6];
+
+int compat_setup_frame(int usig, struct k_sigaction *ka, sigset_t *set,
+ struct pt_regs *regs);
+int compat_setup_rt_frame(int usig, struct k_sigaction *ka, siginfo_t
*info,
+ sigset_t *set, struct pt_regs *regs);
+
+void compat_setup_restart_syscall(struct pt_regs *regs);
+#else
+
+static inline int compat_setup_frame(int usid, struct k_sigaction *ka,
+sigset_t *set, struct pt_regs *regs)
+{
+ BUG();
+}
What good is the run-time BUG() here? Nothing should be calling these
when CONFIG_COMPAT is disabled, so I think you should just remove
the #ifdef around the declarations, and the entire #else case.
They are called from handle_signal(), so that's to avoid #ifdef inside
functions. I can drop the BUG() (but keep the empty function) and
change the checks to is_compat_task() so that the compiler optimises the
condition out when !COMPAT.
--
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PER_LINUX32, Was: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Thu, Aug 23, 2012 at 07:46:30AM +0100, Arnd Bergmann wrote:
> On Thursday 16 August 2012, Will Deacon wrote:
> > On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 14 August 2012, Catalin Marinas wrote:
> > > > +asmlinkage int compat_sys_personality(compat_ulong_t personality)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + if (personality(current->personality) == PER_LINUX32 &&
> > > > + personality == PER_LINUX)
> > > > + personality = PER_LINUX32;
> > > > + ret = sys_personality(personality);
> > > > + if (ret == PER_LINUX32)
> > > > + ret = PER_LINUX;
> > > > + return ret;
> > > > +}
> > >
> > > Where did you get this from?
> > >
> > > You should not need compat_sys_personality, just call the native function.
> >
> > Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
> > syscall will start seeing the wrong uname.
>
> Coming back at this topic, I noticed another issue. Jiri Kosina
> has recently posted patches to fix this function in the other architectures
> in order to mask out the other personality bits, which is a correct fix,
> but the above function is odd for other reasons.
>
> * On MIPS, it is used only for compat tasks, like you have it above.
> * On PA-RISC, it is used for native 32 bit tasks and for compat 32 bit tasks,
> but not for native 64 bit ones.
> * On IA64, it was used for compat tasks (support for which has since
> been removed from the kernel), plus all 32 bit tasks would start with
> PER_LINUX32.
> * On PowerPC, Sparc and s390, it is used for native 64 bit tasks and for
> compat 32 bit tasks, but not for native 32 bit ones.
> * On Tile, it was never used.
> * On x86_64, it used to be defined (copied from ia64) but not used
> throughout the git history.
>
> The semantics of the function are also interesting: The intention seems
> to be that to a compat task, PER_LINUX32 would appear as PER_LINUX.
> The effect is that any process can set PER_LINUX32 but it can never
> be unset except by a 64 bit MIPS or PA-RISC task.
IMHO, it makes sense to keep the compat_sys_personality() as implemented
above. You may want to start a chroot ARMv7 environment using "linux32"
but don't want some 32-bit app calling personality(PER_LINUX) (as that's
the default personality on an ARMv7 system) and unknowingly changing the
personality that you wanted to enforce via "linux32".
I agree with not setting the personality based on the ELF type, but
that's different from the compat_sys_personality().
> Since x86_64 does not implement this behavior at all, I suspect that
> there are now lots of things depending on not having it, while all
> the other architectures might also have some (even predating the
> x86_64 port) use cases that depend on depend on not being able to
> observe PER_LINUX32 in 32 bit compat tasks.
>
> I think we should try to agree on how this is all supposed to work
> and use common code, either put the ppc/sparc/s390 version into
> sys_personality, or remove all of them and just do what x86 and tile
> do, using the regular sys_personality for all tasks.
Late topic for the KS :).
I don't think we can move this behaviour to sys_personality. We may want
to add a generic compat_sys_personality() if we agree on the above
use-case.
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PER_LINUX32, Was: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Thursday 16 August 2012, Will Deacon wrote:
> On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
> > On Tuesday 14 August 2012, Catalin Marinas wrote:
> > > +asmlinkage int compat_sys_personality(compat_ulong_t personality)
> > > +{
> > > + int ret;
> > > +
> > > + if (personality(current->personality) == PER_LINUX32 &&
> > > + personality == PER_LINUX)
> > > + personality = PER_LINUX32;
> > > + ret = sys_personality(personality);
> > > + if (ret == PER_LINUX32)
> > > + ret = PER_LINUX;
> > > + return ret;
> > > +}
> >
> > Where did you get this from?
> >
> > You should not need compat_sys_personality, just call the native function.
>
> Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
> syscall will start seeing the wrong uname.
Coming back at this topic, I noticed another issue. Jiri Kosina
has recently posted patches to fix this function in the other architectures
in order to mask out the other personality bits, which is a correct fix,
but the above function is odd for other reasons.
* On MIPS, it is used only for compat tasks, like you have it above.
* On PA-RISC, it is used for native 32 bit tasks and for compat 32 bit tasks,
but not for native 64 bit ones.
* On IA64, it was used for compat tasks (support for which has since
been removed from the kernel), plus all 32 bit tasks would start with
PER_LINUX32.
* On PowerPC, Sparc and s390, it is used for native 64 bit tasks and for
compat 32 bit tasks, but not for native 32 bit ones.
* On Tile, it was never used.
* On x86_64, it used to be defined (copied from ia64) but not used
throughout the git history.
The semantics of the function are also interesting: The intention seems
to be that to a compat task, PER_LINUX32 would appear as PER_LINUX.
The effect is that any process can set PER_LINUX32 but it can never
be unset except by a 64 bit MIPS or PA-RISC task.
Since x86_64 does not implement this behavior at all, I suspect that
there are now lots of things depending on not having it, while all
the other architectures might also have some (even predating the
x86_64 port) use cases that depend on depend on not being able to
observe PER_LINUX32 in 32 bit compat tasks.
I think we should try to agree on how this is all supposed to work
and use common code, either put the ppc/sparc/s390 version into
sys_personality, or remove all of them and just do what x86 and tile
do, using the regular sys_personality for all tasks.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PER_LINUX32, Was: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Thursday 16 August 2012, Will Deacon wrote:
On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
On Tuesday 14 August 2012, Catalin Marinas wrote:
+asmlinkage int compat_sys_personality(compat_ulong_t personality)
+{
+ int ret;
+
+ if (personality(current-personality) == PER_LINUX32
+ personality == PER_LINUX)
+ personality = PER_LINUX32;
+ ret = sys_personality(personality);
+ if (ret == PER_LINUX32)
+ ret = PER_LINUX;
+ return ret;
+}
Where did you get this from?
You should not need compat_sys_personality, just call the native function.
Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
syscall will start seeing the wrong uname.
Coming back at this topic, I noticed another issue. Jiri Kosina
has recently posted patches to fix this function in the other architectures
in order to mask out the other personality bits, which is a correct fix,
but the above function is odd for other reasons.
* On MIPS, it is used only for compat tasks, like you have it above.
* On PA-RISC, it is used for native 32 bit tasks and for compat 32 bit tasks,
but not for native 64 bit ones.
* On IA64, it was used for compat tasks (support for which has since
been removed from the kernel), plus all 32 bit tasks would start with
PER_LINUX32.
* On PowerPC, Sparc and s390, it is used for native 64 bit tasks and for
compat 32 bit tasks, but not for native 32 bit ones.
* On Tile, it was never used.
* On x86_64, it used to be defined (copied from ia64) but not used
throughout the git history.
The semantics of the function are also interesting: The intention seems
to be that to a compat task, PER_LINUX32 would appear as PER_LINUX.
The effect is that any process can set PER_LINUX32 but it can never
be unset except by a 64 bit MIPS or PA-RISC task.
Since x86_64 does not implement this behavior at all, I suspect that
there are now lots of things depending on not having it, while all
the other architectures might also have some (even predating the
x86_64 port) use cases that depend on depend on not being able to
observe PER_LINUX32 in 32 bit compat tasks.
I think we should try to agree on how this is all supposed to work
and use common code, either put the ppc/sparc/s390 version into
sys_personality, or remove all of them and just do what x86 and tile
do, using the regular sys_personality for all tasks.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PER_LINUX32, Was: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Thu, Aug 23, 2012 at 07:46:30AM +0100, Arnd Bergmann wrote:
On Thursday 16 August 2012, Will Deacon wrote:
On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
On Tuesday 14 August 2012, Catalin Marinas wrote:
+asmlinkage int compat_sys_personality(compat_ulong_t personality)
+{
+ int ret;
+
+ if (personality(current-personality) == PER_LINUX32
+ personality == PER_LINUX)
+ personality = PER_LINUX32;
+ ret = sys_personality(personality);
+ if (ret == PER_LINUX32)
+ ret = PER_LINUX;
+ return ret;
+}
Where did you get this from?
You should not need compat_sys_personality, just call the native function.
Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
syscall will start seeing the wrong uname.
Coming back at this topic, I noticed another issue. Jiri Kosina
has recently posted patches to fix this function in the other architectures
in order to mask out the other personality bits, which is a correct fix,
but the above function is odd for other reasons.
* On MIPS, it is used only for compat tasks, like you have it above.
* On PA-RISC, it is used for native 32 bit tasks and for compat 32 bit tasks,
but not for native 64 bit ones.
* On IA64, it was used for compat tasks (support for which has since
been removed from the kernel), plus all 32 bit tasks would start with
PER_LINUX32.
* On PowerPC, Sparc and s390, it is used for native 64 bit tasks and for
compat 32 bit tasks, but not for native 32 bit ones.
* On Tile, it was never used.
* On x86_64, it used to be defined (copied from ia64) but not used
throughout the git history.
The semantics of the function are also interesting: The intention seems
to be that to a compat task, PER_LINUX32 would appear as PER_LINUX.
The effect is that any process can set PER_LINUX32 but it can never
be unset except by a 64 bit MIPS or PA-RISC task.
IMHO, it makes sense to keep the compat_sys_personality() as implemented
above. You may want to start a chroot ARMv7 environment using linux32
but don't want some 32-bit app calling personality(PER_LINUX) (as that's
the default personality on an ARMv7 system) and unknowingly changing the
personality that you wanted to enforce via linux32.
I agree with not setting the personality based on the ELF type, but
that's different from the compat_sys_personality().
Since x86_64 does not implement this behavior at all, I suspect that
there are now lots of things depending on not having it, while all
the other architectures might also have some (even predating the
x86_64 port) use cases that depend on depend on not being able to
observe PER_LINUX32 in 32 bit compat tasks.
I think we should try to agree on how this is all supposed to work
and use common code, either put the ppc/sparc/s390 version into
sys_personality, or remove all of them and just do what x86 and tile
do, using the regular sys_personality for all tasks.
Late topic for the KS :).
I don't think we can move this behaviour to sys_personality. We may want
to add a generic compat_sys_personality() if we agree on the above
use-case.
--
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Mon 2012-08-20 20:34:54, Arnd Bergmann wrote:
> On Monday 20 August 2012, Pavel Machek wrote:
> > > This patch adds support for 32-bit applications. The vectors page is a
> > > binary blob mapped into the application user space at 0x (the
> > > AArch64 toolchain does not support compilation of AArch32 code). Full
> > > compatibility with ARMv7 user space is supported. The use of deprecated
> > > ARMv7 functionality (SWP, CP15 barriers) has been disabled by default on
> > > AArch64 kernels and unaligned LDM/STM is not supported.
> > >
> > > Please note that only the ARM 32-bit EABI is supported, so no OABI
> > > compatibility.
> >
> > > +struct compat_statfs {
> > > + int f_type;
> > > + int f_bsize;
> > > + int f_blocks;
> > > + int f_bfree;
> > > + int f_bavail;
> > > + int f_files;
> > > + int f_ffree;
> > > + compat_fsid_t f_fsid;
> > > + int f_namelen; /* SunOS ignores this field. */
> >
> > I'm sure it does. But is it good comment?
>
> Good catch. It seems that some of the other compat platforms (x86,
> sparc, powerpc) have the same thing. I guess the real solution would
> be to introduce an asm-generic/compat.h file that contains a bunch
> of those definitions, like
>
> #ifndef compat_timespec
> struct compat_timespec {
> compat_time_t tv_sec;
> s32 tv_nsec;
> };
> #endif
>
> #ifndef compat_timeval
> struct compat_timeval {
> compat_time_t tv_sec;
> s32 tv_usec;
> };
> #endif
Yes, I guess that would be very good.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Mon 2012-08-20 20:34:54, Arnd Bergmann wrote:
On Monday 20 August 2012, Pavel Machek wrote:
This patch adds support for 32-bit applications. The vectors page is a
binary blob mapped into the application user space at 0x (the
AArch64 toolchain does not support compilation of AArch32 code). Full
compatibility with ARMv7 user space is supported. The use of deprecated
ARMv7 functionality (SWP, CP15 barriers) has been disabled by default on
AArch64 kernels and unaligned LDM/STM is not supported.
Please note that only the ARM 32-bit EABI is supported, so no OABI
compatibility.
+struct compat_statfs {
+ int f_type;
+ int f_bsize;
+ int f_blocks;
+ int f_bfree;
+ int f_bavail;
+ int f_files;
+ int f_ffree;
+ compat_fsid_t f_fsid;
+ int f_namelen; /* SunOS ignores this field. */
I'm sure it does. But is it good comment?
Good catch. It seems that some of the other compat platforms (x86,
sparc, powerpc) have the same thing. I guess the real solution would
be to introduce an asm-generic/compat.h file that contains a bunch
of those definitions, like
#ifndef compat_timespec
struct compat_timespec {
compat_time_t tv_sec;
s32 tv_nsec;
};
#endif
#ifndef compat_timeval
struct compat_timeval {
compat_time_t tv_sec;
s32 tv_usec;
};
#endif
Yes, I guess that would be very good.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Monday 20 August 2012, Pavel Machek wrote:
> > This patch adds support for 32-bit applications. The vectors page is a
> > binary blob mapped into the application user space at 0x (the
> > AArch64 toolchain does not support compilation of AArch32 code). Full
> > compatibility with ARMv7 user space is supported. The use of deprecated
> > ARMv7 functionality (SWP, CP15 barriers) has been disabled by default on
> > AArch64 kernels and unaligned LDM/STM is not supported.
> >
> > Please note that only the ARM 32-bit EABI is supported, so no OABI
> > compatibility.
>
> > +struct compat_statfs {
> > + int f_type;
> > + int f_bsize;
> > + int f_blocks;
> > + int f_bfree;
> > + int f_bavail;
> > + int f_files;
> > + int f_ffree;
> > + compat_fsid_t f_fsid;
> > + int f_namelen; /* SunOS ignores this field. */
>
> I'm sure it does. But is it good comment?
Good catch. It seems that some of the other compat platforms (x86,
sparc, powerpc) have the same thing. I guess the real solution would
be to introduce an asm-generic/compat.h file that contains a bunch
of those definitions, like
#ifndef compat_timespec
struct compat_timespec {
compat_time_t tv_sec;
s32 tv_nsec;
};
#endif
#ifndef compat_timeval
struct compat_timeval {
compat_time_t tv_sec;
s32 tv_usec;
};
#endif
#ifndef compat_sysctl
struct compat_sysctl {
unsigned intname;
int nlen;
unsigned intoldval;
unsigned intoldlenp;
unsigned intnewval;
unsigned intnewlen;
unsigned int__unused[4];
};
#endif
For the most part, arch/tile should have useful defaults, though not in the
case of struct statfs, because its 32 bit version does not have a statfs syscall
(it only has statfs64).
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
Hi!
> This patch adds support for 32-bit applications. The vectors page is a
> binary blob mapped into the application user space at 0x (the
> AArch64 toolchain does not support compilation of AArch32 code). Full
> compatibility with ARMv7 user space is supported. The use of deprecated
> ARMv7 functionality (SWP, CP15 barriers) has been disabled by default on
> AArch64 kernels and unaligned LDM/STM is not supported.
>
> Please note that only the ARM 32-bit EABI is supported, so no OABI
> compatibility.
> +struct compat_statfs {
> + int f_type;
> + int f_bsize;
> + int f_blocks;
> + int f_bfree;
> + int f_bavail;
> + int f_files;
> + int f_ffree;
> + compat_fsid_t f_fsid;
> + int f_namelen; /* SunOS ignores this field. */
I'm sure it does. But is it good comment?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
Hi!
This patch adds support for 32-bit applications. The vectors page is a
binary blob mapped into the application user space at 0x (the
AArch64 toolchain does not support compilation of AArch32 code). Full
compatibility with ARMv7 user space is supported. The use of deprecated
ARMv7 functionality (SWP, CP15 barriers) has been disabled by default on
AArch64 kernels and unaligned LDM/STM is not supported.
Please note that only the ARM 32-bit EABI is supported, so no OABI
compatibility.
+struct compat_statfs {
+ int f_type;
+ int f_bsize;
+ int f_blocks;
+ int f_bfree;
+ int f_bavail;
+ int f_files;
+ int f_ffree;
+ compat_fsid_t f_fsid;
+ int f_namelen; /* SunOS ignores this field. */
I'm sure it does. But is it good comment?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Monday 20 August 2012, Pavel Machek wrote:
This patch adds support for 32-bit applications. The vectors page is a
binary blob mapped into the application user space at 0x (the
AArch64 toolchain does not support compilation of AArch32 code). Full
compatibility with ARMv7 user space is supported. The use of deprecated
ARMv7 functionality (SWP, CP15 barriers) has been disabled by default on
AArch64 kernels and unaligned LDM/STM is not supported.
Please note that only the ARM 32-bit EABI is supported, so no OABI
compatibility.
+struct compat_statfs {
+ int f_type;
+ int f_bsize;
+ int f_blocks;
+ int f_bfree;
+ int f_bavail;
+ int f_files;
+ int f_ffree;
+ compat_fsid_t f_fsid;
+ int f_namelen; /* SunOS ignores this field. */
I'm sure it does. But is it good comment?
Good catch. It seems that some of the other compat platforms (x86,
sparc, powerpc) have the same thing. I guess the real solution would
be to introduce an asm-generic/compat.h file that contains a bunch
of those definitions, like
#ifndef compat_timespec
struct compat_timespec {
compat_time_t tv_sec;
s32 tv_nsec;
};
#endif
#ifndef compat_timeval
struct compat_timeval {
compat_time_t tv_sec;
s32 tv_usec;
};
#endif
#ifndef compat_sysctl
struct compat_sysctl {
unsigned intname;
int nlen;
unsigned intoldval;
unsigned intoldlenp;
unsigned intnewval;
unsigned intnewlen;
unsigned int__unused[4];
};
#endif
For the most part, arch/tile should have useful defaults, though not in the
case of struct statfs, because its 32 bit version does not have a statfs syscall
(it only has statfs64).
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Thursday 16 August 2012, Will Deacon wrote:
>
> On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
> > On Tuesday 14 August 2012, Catalin Marinas wrote:
> > > +asmlinkage int compat_sys_personality(compat_ulong_t personality)
> > > +{
> > > + int ret;
> > > +
> > > + if (personality(current->personality) == PER_LINUX32 &&
> > > + personality == PER_LINUX)
> > > + personality = PER_LINUX32;
> > > + ret = sys_personality(personality);
> > > + if (ret == PER_LINUX32)
> > > + ret = PER_LINUX;
> > > + return ret;
> > > +}
> >
> > Where did you get this from?
> >
> > You should not need compat_sys_personality, just call the native function.
>
> Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
> syscall will start seeing the wrong uname.
Not the wrong uname, just the default one, which is correct.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
> On Tuesday 14 August 2012, Catalin Marinas wrote:
> > +asmlinkage int compat_sys_personality(compat_ulong_t personality)
> > +{
> > + int ret;
> > +
> > + if (personality(current->personality) == PER_LINUX32 &&
> > + personality == PER_LINUX)
> > + personality = PER_LINUX32;
> > + ret = sys_personality(personality);
> > + if (ret == PER_LINUX32)
> > + ret = PER_LINUX;
> > + return ret;
> > +}
>
> Where did you get this from?
>
> You should not need compat_sys_personality, just call the native function.
Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
syscall will start seeing the wrong uname.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
On Tuesday 14 August 2012, Catalin Marinas wrote:
+asmlinkage int compat_sys_personality(compat_ulong_t personality)
+{
+ int ret;
+
+ if (personality(current-personality) == PER_LINUX32
+ personality == PER_LINUX)
+ personality = PER_LINUX32;
+ ret = sys_personality(personality);
+ if (ret == PER_LINUX32)
+ ret = PER_LINUX;
+ return ret;
+}
Where did you get this from?
You should not need compat_sys_personality, just call the native function.
Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
syscall will start seeing the wrong uname.
Will
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Thursday 16 August 2012, Will Deacon wrote:
On Wed, Aug 15, 2012 at 03:34:04PM +0100, Arnd Bergmann wrote:
On Tuesday 14 August 2012, Catalin Marinas wrote:
+asmlinkage int compat_sys_personality(compat_ulong_t personality)
+{
+ int ret;
+
+ if (personality(current-personality) == PER_LINUX32
+ personality == PER_LINUX)
+ personality = PER_LINUX32;
+ ret = sys_personality(personality);
+ if (ret == PER_LINUX32)
+ ret = PER_LINUX;
+ return ret;
+}
Where did you get this from?
You should not need compat_sys_personality, just call the native function.
Hmm, but in that case an aarch32 application doing a personality(PER_LINUX)
syscall will start seeing the wrong uname.
Not the wrong uname, just the default one, which is correct.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Tuesday 14 August 2012, Catalin Marinas wrote:
> +#ifdef CONFIG_AARCH32_EMULATION
> +#include
> +
> +#define AARCH32_KERN_SIGRET_CODE_OFFSET 0x500
> +
> +extern const compat_ulong_t aarch32_sigret_code[6];
> +
> +int compat_setup_frame(int usig, struct k_sigaction *ka, sigset_t *set,
> +struct pt_regs *regs);
> +int compat_setup_rt_frame(int usig, struct k_sigaction *ka, siginfo_t *info,
> + sigset_t *set, struct pt_regs *regs);
> +
> +void compat_setup_restart_syscall(struct pt_regs *regs);
> +#else
> +
> +static inline int compat_setup_frame(int usid, struct k_sigaction *ka,
> + sigset_t *set, struct pt_regs *regs)
> +{
> + BUG();
> +}
What good is the run-time BUG() here? Nothing should be calling these
when CONFIG_COMPAT is disabled, so I think you should just remove
the #ifdef around the declarations, and the entire #else case.
> +asmlinkage int compat_sys_sched_rr_get_interval(compat_pid_t pid,
> + struct compat_timespec __user
> *interval)
> +{
> + struct timespec t;
> + int ret;
> + mm_segment_t old_fs = get_fs();
> +
> + set_fs(KERNEL_DS);
> + ret = sys_sched_rr_get_interval(pid, (struct timespec __user *));
> + set_fs(old_fs);
> + if (put_compat_timespec(, interval))
> + return -EFAULT;
> + return ret;
> +}
> +
> +asmlinkage int compat_sys_sendfile(int out_fd, int in_fd,
> +compat_off_t __user *offset, s32 count)
> +{
> + mm_segment_t old_fs = get_fs();
> + int ret;
> + off_t of;
> +
> + if (offset && get_user(of, offset))
> + return -EFAULT;
> +
> + set_fs(KERNEL_DS);
> + ret = sys_sendfile(out_fd, in_fd, offset ? (off_t __user *) : NULL,
> +count);
> + set_fs(old_fs);
> +
> + if (offset && put_user(of, offset))
> + return -EFAULT;
> + return ret;
> +}
I guess it's time to move these two into common code. They look like they should
be shared across most architectures that have compat support.
> +asmlinkage int compat_sys_personality(compat_ulong_t personality)
> +{
> + int ret;
> +
> + if (personality(current->personality) == PER_LINUX32 &&
> + personality == PER_LINUX)
> + personality = PER_LINUX32;
> + ret = sys_personality(personality);
> + if (ret == PER_LINUX32)
> + ret = PER_LINUX;
> + return ret;
> +}
Where did you get this from?
You should not need compat_sys_personality, just call the native function.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 21/31] arm64: 32-bit (compat) applications support
On Tuesday 14 August 2012, Catalin Marinas wrote:
+#ifdef CONFIG_AARCH32_EMULATION
+#include linux/compat.h
+
+#define AARCH32_KERN_SIGRET_CODE_OFFSET 0x500
+
+extern const compat_ulong_t aarch32_sigret_code[6];
+
+int compat_setup_frame(int usig, struct k_sigaction *ka, sigset_t *set,
+struct pt_regs *regs);
+int compat_setup_rt_frame(int usig, struct k_sigaction *ka, siginfo_t *info,
+ sigset_t *set, struct pt_regs *regs);
+
+void compat_setup_restart_syscall(struct pt_regs *regs);
+#else
+
+static inline int compat_setup_frame(int usid, struct k_sigaction *ka,
+ sigset_t *set, struct pt_regs *regs)
+{
+ BUG();
+}
What good is the run-time BUG() here? Nothing should be calling these
when CONFIG_COMPAT is disabled, so I think you should just remove
the #ifdef around the declarations, and the entire #else case.
+asmlinkage int compat_sys_sched_rr_get_interval(compat_pid_t pid,
+ struct compat_timespec __user
*interval)
+{
+ struct timespec t;
+ int ret;
+ mm_segment_t old_fs = get_fs();
+
+ set_fs(KERNEL_DS);
+ ret = sys_sched_rr_get_interval(pid, (struct timespec __user *)t);
+ set_fs(old_fs);
+ if (put_compat_timespec(t, interval))
+ return -EFAULT;
+ return ret;
+}
+
+asmlinkage int compat_sys_sendfile(int out_fd, int in_fd,
+compat_off_t __user *offset, s32 count)
+{
+ mm_segment_t old_fs = get_fs();
+ int ret;
+ off_t of;
+
+ if (offset get_user(of, offset))
+ return -EFAULT;
+
+ set_fs(KERNEL_DS);
+ ret = sys_sendfile(out_fd, in_fd, offset ? (off_t __user *)of : NULL,
+count);
+ set_fs(old_fs);
+
+ if (offset put_user(of, offset))
+ return -EFAULT;
+ return ret;
+}
I guess it's time to move these two into common code. They look like they should
be shared across most architectures that have compat support.
+asmlinkage int compat_sys_personality(compat_ulong_t personality)
+{
+ int ret;
+
+ if (personality(current-personality) == PER_LINUX32
+ personality == PER_LINUX)
+ personality = PER_LINUX32;
+ ret = sys_personality(personality);
+ if (ret == PER_LINUX32)
+ ret = PER_LINUX;
+ return ret;
+}
Where did you get this from?
You should not need compat_sys_personality, just call the native function.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
