[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whNAEuNPU3Oy_-EpjOojpysWcCh4uqDgOt2RjBNx2xBSg@mail.gmail.com>
Date: Wed, 13 Nov 2019 13:10:13 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Stephen Hemminger <stephen@...workplumber.org>,
Willy Tarreau <w@....eu>, Juergen Gross <jgross@...e.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [patch V3 02/20] x86/process: Unify copy_thread_tls()
On Wed, Nov 13, 2019 at 1:02 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> +int copy_thread_tls(unsigned long clone_flags, unsigned long sp,
> + unsigned long arg, struct task_struct *p, unsigned long tls)
...
> +#ifdef CONFIG_X86_64
..
> +#else
> + /* Clear all status flags including IF and set fixed bit. */
> + frame->flags = X86_EFLAGS_FIXED;
> +#endif
Hmm. The unification I like, but it also shows these differences that
I don't remember the reason for.
Remind me why __switch_to_asm() on 32-bit safes eflags, but we don't
do it on x86-64?
The comment just talks about callee-saved registers, but flags isn't
callee-saved, so there's something else going on.
This patch clearly doesn't change anything, I'm not complaining about
the patch at all. I'm just wondering about the odd difference that the
patch exposes.
Linus
Powered by blists - more mailing lists