[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151213034437.GA2392@altlinux.org>
Date: Sun, 13 Dec 2015 06:44:40 +0300
From: "Dmitry V. Levin" <ldv@...linux.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Elvira Khabirova <lineprinter0@...il.com>
Subject: Re: [PATCH] x86/signal: fix restart_syscall number for x32 tasks
On Mon, Dec 07, 2015 at 03:22:06PM -0800, Andy Lutomirski wrote:
> [not real reply because I'm using a bad internet connection right now
> and I'm not set up with my usual Gmane reply hack right now]
>
> The new code is (whitespace-damaged):
>
> static inline unsigned long get_nr_restart_syscall(const struct pt_regs *regs)
> {
> #if defined(CONFIG_X86_32) || !defined(CONFIG_X86_64)
> return __NR_restart_syscall;
> #else /* !CONFIG_X86_32 && CONFIG_X86_64 */
> return test_thread_flag(TIF_IA32) ? __NR_ia32_restart_syscall :
> __NR_restart_syscall | (regs->orig_ax & __X32_SYSCALL_BIT);
> #endif /* CONFIG_X86_32 || !CONFIG_X86_64 */
> }
>
> This is IMO awful. This use of TIF_IA32 is wrong, and this is
> otherwise gross. Can we do it for real:
>
> if (is_ia32_task())
> return __NR_ia32_restart_syscall;
> else
> return __NR_restart_syscall | (regs->orig_ax & __X32_SYSCALL_BIT);
> /* preserve x32 bit */
>
> I'd send the patch myself, but you apparently have a good test case
> for this, and I don't.
Unfortunately, this won't compile on CONFIG_X86_32 because
__NR_ia32_restart_syscall is defined for CONFIG_X86_64 only.
Something like this should work:
static inline unsigned long get_nr_restart_syscall(const struct pt_regs *regs)
{
#ifdef CONFIG_X86_64
if (is_ia32_task())
return __NR_ia32_restart_syscall;
# ifdef CONFIG_X86_X32_ABI
if (regs->orig_ax & __X32_SYSCALL_BIT)
return __NR_restart_syscall | __X32_SYSCALL_BIT;
# endif
#endif
return __NR_restart_syscall;
}
I don't see any way to avoid ifdefs here, sorry.
--
ldv
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists