From: David Daney <ddaney@caviumnetworks.com>
To: Oleg Nesterov <oleg@redhat.com>, akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, arnd@arndb.de,
benh@kernel.crashing.org, cmetcalf@tilera.com,
davem@davemloft.net, deller@gmx.de, heiko.carstens@de.ibm.com,
hpa@zytor.com, jejb@parisc-linux.org, kyle@mcmartin.ca,
mingo@elte.hu, roland@redhat.com, schwidefsky@de.ibm.com,
tglx@linutronix.de, tony.luck@intel.com
Subject: Re: + exec_domain-establish-a-linux32-domain-on-config_compat-systems.patc h added to -mm tree
Date: Mon, 15 Nov 2010 10:57:38 -0800 [thread overview]
Message-ID: <4CE182A2.1020606@caviumnetworks.com> (raw)
In-Reply-To: <20101113171722.GA2956@redhat.com>
On 11/13/2010 09:17 AM, Oleg Nesterov wrote:
> On 11/12, Andrew Morton wrote:
>>
>> From: David Daney<ddaney@caviumnetworks.com>
>>
>> If PER_LINUX32 is set calling sys_personality, we will try to find the
>> corresponding exec_domain. This causes us to try to load a module for
>> personality-8. After running the userspace module loader and failing to
>> find the module, we fall back to the default.
>
> Cough. It is not easy to me comment this patch ;)
>
> Personally, I think this change is fine. But, despite the fact
> the code in exec_domain.c is very trivial, I was never able to really
> understand its rationality. And the usage of ->personality has some
> oddities.
>
> In particular, I can't parse default_exec_domain() at all. And,
> what exec_domain->handler() actually does? I do not see anything
> in arch/ which uses EXEC_DOMAIN offsets.
>
> Perhaps someone from CC can explain this?
>
>
>> We can avoid the failed module loading overhead by building-in the
>> linux32_exec_domain for systems that have CONFIG_COMPAT.
>
> Indeed. But at the same time this means it is not possible to use
> personality-8.ko if the system has it.
Well in the same way it is not possible to use personality-0.ko
(PER_LINUX) because it is just as built-in.
>
> Don't get me wrong, I have no idea why anyone could want this module,
> just I am a bit worried.
If the personality is built-in, then I don't see how it makes any sense
to attempt to override it with an externally supplied version. If you
want set a domain for PER_LINUX32, don't configure you system to supply
a default version.
>
>> +#ifdef CONFIG_COMPAT
>> +static struct exec_domain linux32_exec_domain = {
>> + .name = "Linux32", /* name */
>> + .handler = default_handler, /* lcall7 causes a seg fault. */
>> + .pers_low = PER_LINUX32,
>> + .pers_high = PER_LINUX32,
>> + .signal_map = ident_map, /* Identity map signals. */
>> + .signal_invmap = ident_map, /* - both ways. */
>> +};
>> +#endif
>> +
>> struct exec_domain default_exec_domain = {
>> .name = "Linux", /* name */
>> .handler = default_handler, /* lcall7 causes a seg fault. */
>> @@ -41,6 +52,9 @@ struct exec_domain default_exec_domain =
>> .pers_high = 0, /* PER_LINUX personality. */
>> .signal_map = ident_map, /* Identity map signals. */
>> .signal_invmap = ident_map, /* - both ways. */
>> +#ifdef CONFIG_COMPAT
>> + .next =&linux32_exec_domain,
>> +#endif
>> };
>
> OK, but please look at arch/s390/kernel/compat_exec_domain.c and
> arch/ia64/mm/init.c, they also register PER_LINUX32 domain, not
> good. And note that register_exec_domain() doesn't check
> pers_low/high, this means linux32_exec_domain can silently supress
> s390_exec_domain/ia32_exec_domain.
>
Ah, I had not known about this. The comments in arch/ia64/mm/init.c
mirror my reason for creating the patch.
I think the s390 and ia64 definitions will conflict with the #ifdef
CONFIG_COMPAT in my patch. I will attempt to correct this in a new
version of the patch.
Thanks for looking at this,
David Daney
next prev parent reply other threads:[~2010-11-15 18:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-12 20:22 + exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch added to -mm tree akpm
2010-11-13 17:17 ` + exec_domain-establish-a-linux32-domain-on-config_compat-systems.patc h " Oleg Nesterov
2010-11-15 18:57 ` David Daney [this message]
2010-11-15 19:19 ` Oleg Nesterov
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=4CE182A2.1020606@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=cmetcalf@tilera.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=jejb@parisc-linux.org \
--cc=kyle@mcmartin.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
/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.