From: Ingo Molnar <mingo@kernel.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, linux-kernel@vger.kernel.org, x86@kernel.org,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] x86_64: uninline TASK_SIZE
Date: Mon, 22 Apr 2019 12:34:49 +0200 [thread overview]
Message-ID: <20190422103449.GA75723@gmail.com> (raw)
In-Reply-To: <20190421211007.GA30444@avx2>
* Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > >> +++ b/arch/x86/kernel/task_size_64.c
> > >> @@ -0,0 +1,9 @@
> > >> +#include <linux/export.h>
> > >> +#include <linux/sched.h>
> > >> +#include <linux/thread_info.h>
> > >> +
> > >> +unsigned long _task_size(void)
> > >> +{
> > >> + return test_thread_flag(TIF_ADDR32) ? IA32_PAGE_OFFSET :
> > >TASK_SIZE_MAX;
> > >> +}
> > >> +EXPORT_SYMBOL(_task_size);
> > >
> > >Good idea - but instead of adding yet another compilation unit, why not
> > >
> > >stick _task_size() into arch/x86/kernel/process_64.c, which is the
> > >canonical place for process management related arch functions?
> > >
> > >Thanks,
> > >
> > > Ingo
> >
> > Better yet... since TIF_ADDR32 isn't something that changes randomly,
> > perhaps this should be a separate variable?
>
> Maybe. I only thought about putting every 32-bit related flag under
> CONFIG_COMPAT to further eradicate bloat (and force everyone else to
> keep an eye on it, ha-ha).
Basically TIF_ADDR32 is only set for a task if set_personality_ia32() is
called, which function is called in the following circumstances:
- arch/x86/ia32/ia32_aout.c:load_aout_binary()
This is in exec(), when a new binary is loaded for the current task,
via search_binary_handler() and exec_binprm(). Ordering is
synchronous, AFAICS there can be no race between TASK_SIZE users and
the set_personality_ia32() call which is always for the current task.
- in COMPAT_SET_PERSONALITY(), which through macro detours ends up being
in SET_PERSONALITY2(), which is used in fs/compat_binfmt_elf.c's
load_elf_binary(), used in a similar fashion in exec() as the AOUT
case above. One particular macro detour of note is that
fs/compat_binfmt_elf.c #includes fs/binfmt_elf.c and re-defines the
personality setting method to map to set_personality_ia32().
When set_personality_ia32() is called then TIF_ADDR32 is set
unconditionally, without any Kconfig variations.
TIF_ADDR32 is cleared:
- In set_personality_64bit(), when a 64-bit binary is loaded via
fs/binfmt_elf.c.
- It also defaults to clear in the init task, which is inherited by the
initial kernel threads and any user-space task they might end up
executing.
So the conclusion is that IMO we can safely put TASK_SIZE into a new
thread_info()->task_size field, and:
- change ->task_size to the 32-bit address space in
set_personality_ia32()
- change ->task_size to teh 64-bit address space in the init task and in
set_personality_64bit().
This should cover it I think, unless I missed something.
Thanks,
Ingo
next prev parent reply other threads:[~2019-04-22 10:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-21 16:06 [PATCH] x86_64: uninline TASK_SIZE Alexey Dobriyan
2019-04-21 18:28 ` Ingo Molnar
2019-04-21 20:07 ` hpa
2019-04-21 21:10 ` Alexey Dobriyan
2019-04-22 10:34 ` Ingo Molnar [this message]
2019-04-22 14:30 ` Andy Lutomirski
2019-04-22 22:09 ` Alexey Dobriyan
2019-04-23 0:54 ` Andy Lutomirski
2019-04-23 11:12 ` Ingo Molnar
2019-04-23 17:21 ` Andy Lutomirski
2019-04-24 10:38 ` Ingo Molnar
2019-04-22 22:04 ` Alexey Dobriyan
2019-04-21 22:07 ` [PATCH v2] " Alexey Dobriyan
2019-04-22 22:40 ` [PATCH] " Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190422103449.GA75723@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=adobriyan@gmail.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.