diff mbox

[v2,02/16] sparc/compat: Provide an accurate in_compat_syscall implementation

Message ID e520030f750b29d14486aa1e99c271a0fa18f19e.1453759363.git.luto@kernel.org
State Not Applicable
Delegated to: David Miller
Headers show

Commit Message

Andy Lutomirski Jan. 25, 2016, 10:24 p.m. UTC
On sparc64 compat-enabled kernels, any task can make 32-bit and
64-bit syscalls.  is_compat_task returns true in 32-bit tasks, which
does not necessarily imply that the current syscall is 32-bit.

Provide an in_compat_syscall implementation that checks whether the
current syscall is compat.

As far as I know, sparc is the only architecture on which
is_compat_task checks the compat status of the task and on which the
compat status of a syscall can differ from the compat status of the
task.  On x86, is_compat_task checks the syscall type, not the task
type.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/sparc/include/asm/compat.h | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

David Miller Jan. 25, 2016, 10:51 p.m. UTC | #1
From: Andy Lutomirski <luto@kernel.org>
Date: Mon, 25 Jan 2016 14:24:16 -0800

> On sparc64 compat-enabled kernels, any task can make 32-bit and
> 64-bit syscalls.  is_compat_task returns true in 32-bit tasks, which
> does not necessarily imply that the current syscall is 32-bit.
> 
> Provide an in_compat_syscall implementation that checks whether the
> current syscall is compat.
> 
> As far as I know, sparc is the only architecture on which
> is_compat_task checks the compat status of the task and on which the
> compat status of a syscall can differ from the compat status of the
> task.  On x86, is_compat_task checks the syscall type, not the task
> type.
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>

Acked-by: David S. Miller <davem@davemloft.net>
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sam Ravnborg Jan. 26, 2016, 6:29 a.m. UTC | #2
On Mon, Jan 25, 2016 at 02:24:16PM -0800, Andy Lutomirski wrote:
> On sparc64 compat-enabled kernels, any task can make 32-bit and
> 64-bit syscalls.  is_compat_task returns true in 32-bit tasks, which
> does not necessarily imply that the current syscall is 32-bit.
> 
> Provide an in_compat_syscall implementation that checks whether the
> current syscall is compat.
> 
> As far as I know, sparc is the only architecture on which
> is_compat_task checks the compat status of the task and on which the
> compat status of a syscall can differ from the compat status of the
> task.  On x86, is_compat_task checks the syscall type, not the task
> type.
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
>  arch/sparc/include/asm/compat.h | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
> index 830502fe62b4..5467404857fc 100644
> --- a/arch/sparc/include/asm/compat.h
> +++ b/arch/sparc/include/asm/compat.h
> @@ -307,4 +307,10 @@ static inline int is_compat_task(void)
>  	return test_thread_flag(TIF_32BIT);
>  }
>  
> +static inline bool in_compat_syscall(void)
> +{
> +	return pt_regs_trap_type(current_pt_regs()) == 0x110;
Could you please add a comment about where 0x110 comes from.
I at least failed to track this down.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Jan. 26, 2016, 6:51 a.m. UTC | #3
From: Sam Ravnborg <sam@ravnborg.org>
Date: Tue, 26 Jan 2016 07:29:51 +0100

> Could you please add a comment about where 0x110 comes from.
> I at least failed to track this down.

Frankly I'm fine with this.  Someone who understands sparc64 can look
at the trap table around entry 0x110 and see:

tl0_resv10e:	BTRAP(0x10e) BTRAP(0x10f)
tl0_linux32:	LINUX_32BIT_SYSCALL_TRAP
tl0_oldlinux64:	LINUX_64BIT_SYSCALL_TRAP
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sam Ravnborg Jan. 26, 2016, 5:44 p.m. UTC | #4
On Mon, Jan 25, 2016 at 10:51:00PM -0800, David Miller wrote:
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Tue, 26 Jan 2016 07:29:51 +0100
> 
> > Could you please add a comment about where 0x110 comes from.
> > I at least failed to track this down.
> 
> Frankly I'm fine with this.  Someone who understands sparc64 can look
> at the trap table around entry 0x110 and see:
> 
> tl0_resv10e:	BTRAP(0x10e) BTRAP(0x10f)
> tl0_linux32:	LINUX_32BIT_SYSCALL_TRAP
> tl0_oldlinux64:	LINUX_64BIT_SYSCALL_TRAP

If one realise to look in the trap table in the first place - yes.

Adding a short:

/* Check if this is LINUX_32BIT_SYSCALL_TRAP */
Would make wonders to readability.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andy Lutomirski Jan. 26, 2016, 5:48 p.m. UTC | #5
On Tue, Jan 26, 2016 at 9:44 AM, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Mon, Jan 25, 2016 at 10:51:00PM -0800, David Miller wrote:
>> From: Sam Ravnborg <sam@ravnborg.org>
>> Date: Tue, 26 Jan 2016 07:29:51 +0100
>>
>> > Could you please add a comment about where 0x110 comes from.
>> > I at least failed to track this down.
>>
>> Frankly I'm fine with this.  Someone who understands sparc64 can look
>> at the trap table around entry 0x110 and see:
>>
>> tl0_resv10e:  BTRAP(0x10e) BTRAP(0x10f)
>> tl0_linux32:  LINUX_32BIT_SYSCALL_TRAP
>> tl0_oldlinux64:       LINUX_64BIT_SYSCALL_TRAP
>
> If one realise to look in the trap table in the first place - yes.
>
> Adding a short:
>
> /* Check if this is LINUX_32BIT_SYSCALL_TRAP */
> Would make wonders to readability.

I'll add a comment in v2.

--Andy
David Miller Jan. 26, 2016, 6:04 p.m. UTC | #6
From: Sam Ravnborg <sam@ravnborg.org>
Date: Tue, 26 Jan 2016 18:44:41 +0100

> On Mon, Jan 25, 2016 at 10:51:00PM -0800, David Miller wrote:
>> From: Sam Ravnborg <sam@ravnborg.org>
>> Date: Tue, 26 Jan 2016 07:29:51 +0100
>> 
>> > Could you please add a comment about where 0x110 comes from.
>> > I at least failed to track this down.
>> 
>> Frankly I'm fine with this.  Someone who understands sparc64 can look
>> at the trap table around entry 0x110 and see:
>> 
>> tl0_resv10e:	BTRAP(0x10e) BTRAP(0x10f)
>> tl0_linux32:	LINUX_32BIT_SYSCALL_TRAP
>> tl0_oldlinux64:	LINUX_64BIT_SYSCALL_TRAP
> 
> If one realise to look in the trap table in the first place - yes.
> 
> Adding a short:
> 
> /* Check if this is LINUX_32BIT_SYSCALL_TRAP */
> Would make wonders to readability.

Fair enough.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
index 830502fe62b4..5467404857fc 100644
--- a/arch/sparc/include/asm/compat.h
+++ b/arch/sparc/include/asm/compat.h
@@ -307,4 +307,10 @@  static inline int is_compat_task(void)
 	return test_thread_flag(TIF_32BIT);
 }
 
+static inline bool in_compat_syscall(void)
+{
+	return pt_regs_trap_type(current_pt_regs()) == 0x110;
+}
+#define in_compat_syscall in_compat_syscall
+
 #endif /* _ASM_SPARC64_COMPAT_H */