Re: 2.6.12-rc1 breaks dosemu

[Arjan van de Ven <arjan@infradead.org>]

> 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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/