mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.



  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®