From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Dmitriy Monakhov <dmonakhov@sw.ru>
Cc: Andrew Morton <akpm@osdl.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-kernel@vger.kernel.org, dmonakhov@openvz.org
Subject: Re: + mm-search_binary_handler-mem-limit-fix.patch added to -mm tree
Date: Tue, 30 Jan 2007 13:23:49 +0100 [thread overview]
Message-ID: <1170159829.22550.2.camel@localhost> (raw)
In-Reply-To: <87veipxeac.fsf@sw.ru>
On Tue, 2007-01-30 at 08:40 +0300, Dmitriy Monakhov wrote:
> > > > The function changes mem limit to USER_DS before possible modprobe, but
> > > > never restored it again.
> Truly. The road to hell is paved with good intentions.
:-)
> > For architectures with a split address space there has to be a call
> > set_fs(USER_DS) that switches from KERNEL_DS to USER_DS for the init
> > process. So far this has been done in search_binary_handler and
> > traditionally the kernel starts with KERNEL_DS to make the early
> > copy_from_user calls work.
> > So, what is wrong with always setting USER_DS? We are starting a user
> > space process after all.
> May be add some comment to prevent future attempts to make this place
> more "correct"?
The use of set_fs(USER_DS) in search_binary_handler is certainly
different compared to the rest. It probably is the only one that is not
paired with a set_fs(KERNEL_DS) or set_fs(old_fs). A comment won't hurt.
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
prev parent reply other threads:[~2007-01-30 12:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-24 9:09 + mm-search_binary_handler-mem-limit-fix.patch added to -mm tree akpm
2007-01-29 11:33 ` Heiko Carstens
2007-01-29 13:59 ` Heiko Carstens
2007-01-29 17:37 ` Andrew Morton
2007-01-29 18:18 ` Martin Schwidefsky
2007-01-30 5:40 ` Dmitriy Monakhov
2007-01-30 12:23 ` Martin Schwidefsky [this message]
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=1170159829.22550.2.camel@localhost \
--to=schwidefsky@de.ibm.com \
--cc=akpm@osdl.org \
--cc=dmonakhov@openvz.org \
--cc=dmonakhov@sw.ru \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.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.