From: Andrew Morton <akpm@linux-foundation.org>
To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Cc: jkosina@suse.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i386 and x86_64: randomize brk()
Date: Sun, 2 Sep 2007 13:28:47 -0700 [thread overview]
Message-ID: <20070902132847.5fc968b1.akpm@linux-foundation.org> (raw)
In-Reply-To: <46D9C935.3000701@gmail.com>
> On Sat, 01 Sep 2007 22:19:01 +0200 Franck Bui-Huu <vagabon.xyz@gmail.com> wrote:
> Hello Andrew,
>
> Andrew Morton wrote:
> > On Thu, 30 Aug 2007 17:10:03 +0200 (CEST) Jiri Kosina <jkosina@suse.cz> wrote:
> >> Andrew, do you still strongly oppose to having ARCH_HAS_RANDOMIZE_BRK
> >> macro instead please?
> >>
> >
> > Not strongly, but the general opinion seems to be that ARCH_HAS_FOO is
> > sucky. It should at least be done in Kconfig rather than in .h, but even
> > better is just to implement the thing for all architectures.
> >
>
> Sorry for asking again but the initial poster haven't taken time to
> answer to my feedbacks...
>
> What about using a weak function in that case ? It actually gives a
> default implementation in _one_ place and can be changed easily from
> a nop to something more complex later.
Yeah, weak functions are by far the cleanest way of doing this - they're
most elegant. But they do add the overhead of an empty call/return, so
some thought needs to go into the tradeoff.
> Another point is that the current prototype of arch_randomize_brk()
> could be slightly improved IMHO.
>
> The proposed prototype is:
>
> void arch_randomize_brk(void)
>
> and I think it could be:
>
> unsigned long randomize_brk(unsigned long brk)
>
> Because the current code of exec syscall is rather.. hmm "tricky",
> _hiding_ "current" global usage inside this function is error prone:
> if this function is moved later, its use of "current->mm" could
> reference the old mm process and it's hard to notice/fix.
Could be..
next prev parent reply other threads:[~2007-09-02 20:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-30 13:47 [PATCH] i386 and x86_64: randomize brk() Jiri Kosina
2007-08-30 14:01 ` Mike Frysinger
2007-08-30 14:21 ` Jiri Kosina
2007-08-30 14:26 ` Mike Frysinger
2007-08-30 15:10 ` Jiri Kosina
2007-08-30 15:33 ` Franck Bui-Huu
2007-08-31 1:05 ` Andrew Morton
2007-08-31 11:56 ` Jiri Kosina
2007-09-01 20:19 ` Franck Bui-Huu
2007-09-02 20:28 ` Andrew Morton [this message]
2007-09-03 9:34 ` Jiri Kosina
2007-09-03 10:03 ` Jiri Kosina
2007-09-03 17:38 ` Franck Bui-Huu
2007-09-03 20:44 ` Jiri Kosina
-- strict thread matches above, loose matches on Subject: below --
2007-08-22 16:05 Jiri Kosina
2007-08-22 22:58 ` Andrew Morton
2007-08-22 23:04 ` Jiri Kosina
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=20070902132847.5fc968b1.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=vagabon.xyz@gmail.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.