From: Arjan van de Ven <arjan@infradead.org>
To: Bart Oldeman <bartoldeman@ihug.co.nz>
Cc: Arnd Bergmann <arnd@arndb.de>, Adrian Bunk <bunk@stusta.de>,
linux-kernel@vger.kernel.org, linux-msdos@vger.kernel.org,
Ingo Molnar <mingo@elte.hu>
Subject: Re: 2.6.12-rc1 breaks dosemu
Date: Sat, 26 Mar 2005 10:28:29 +0100 [thread overview]
Message-ID: <1111829310.6293.43.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0503262023250.3166@enm-bo-lt.localnet>
> There is one more improbable thing I can think of: comcom. This is
> dosemu's built-in command.com and uses some very tricky code
> (coopthreads), which certainly does not work any more with address space
> randomization. It's deprecated but was still present in 1.2.2, and Debian
> packages still used it with dosemu 1.2.1. The fix for that one is easy:
> replace your command.com with a real DOS command.com (e.g. FreeDOS
> freecom).
#define STACK_GRAN_SHIFT 17 /* 128K address space granularity */
#define STACK_GRAN (1U << STACK_GRAN_SHIFT)
#define STACK_TOP 0xc0000000U
#define STACK_BOTTOM 0xa0000000U
#define STACK_TOP_PADDING STACK_GRAN
#define STACK_SLOTS ((STACK_TOP-STACK_BOTTOM) >> STACK_GRAN_SHIFT)
#define roundup_stacksize(size) ((size + STACK_GRAN - 1) & (-((int)STACK_GRAN)))
that certainly isn't boding well for things....
ok this thing is evil.
It hardcode assumes that the stack goes from 0xc00000 to 0xa0000000, divides it into slots of 128Kb and uses each such slot
for a thread. With the randomisation there may be "slots" above the actual stack that appear free but are just entirely
unmapped. This thing is broken beyond belief! (and it won't work for any other kind of split than 3:1, eg 2:2 or 4:4 or 0.5:3.5,
as well as the 4Gig address space on x86-64 or ia64 in 32 bit emu mode)
I can't think of any reasonable way to work around this behavior other than suggesting to use the setarch
option to disable randomisation for this process... this is just too much weirdness/brokenness to work around.
next prev parent reply other threads:[~2005-03-26 9:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-20 2:11 Adrian Bunk
2005-03-20 3:04 ` Gene Heskett
2005-03-25 18:52 ` Arnd Bergmann
2005-03-25 19:14 ` Arjan van de Ven
2005-03-25 22:54 ` Arnd Bergmann
2005-03-26 8:10 ` Arjan van de Ven
2005-03-26 8:18 ` Bart Oldeman
2005-03-26 13:49 ` Arnd Bergmann
2005-03-26 14:28 ` Arjan van de Ven
2005-03-26 14:35 ` Arjan van de Ven
2005-03-26 8:25 ` Arjan van de Ven
2005-03-26 8:32 ` Bart Oldeman
2005-03-26 9:28 ` Arjan van de Ven [this message]
2005-03-31 6:43 ` Bart Oldeman
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=1111829310.6293.43.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=arnd@arndb.de \
--cc=bartoldeman@ihug.co.nz \
--cc=bunk@stusta.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-msdos@vger.kernel.org \
--cc=mingo@elte.hu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®