Mouse-freezes in X.org with CONFIG_PAX_KERNEXEC

[specs]

I read I'm not the only one with problems using X.org with Pax/Grsecurity.
The problem is sometimes the mouse moves to the upper left corner and does not respond anymore.

See also:
http://bugs.freedesktop.org/show_bug.cgi?id=13010
http://home.coming.dk/index.php/2008/06 ... 5#comments

According to the last mentioned page:

Code: Select all

Comment from: Gordon Malm [Visitor]
I've been doing some research/testing on this issue. It seems to be an interaction between forced-preemption and KERNEXEC. You should be able to re-enable KERNEXEC as long as you disable preemption or use voluntary preemption.
PermalinkPermalink 2008-08-09 @ 03:50


I found no other comments on the page or on the page from Hardened Gentoo regarding the problem.

I used to think the problem was hardware dependent, but now it seems to be conformed on a C3 (Epia M10000, 32-bit) and a Intel Core Duo L2400 (the blog mentions a Lenovo X60s).
I have never seen the problem on my laptop (running the same programms which trigger the problem on my desktop).
Perhaps my laptop has a lower system load (it has a more powerful CPU).
Lately I have run in these problems less (I exchanged the mainboard for one with a faster CPU), but I'd like to check if there were bugs solved in the preemption code with the pax-patch.
When using certain programms (java) I ran into the problem more often, perhaps a heavier system load than usual.

According to the comment these settings should be necessary to trigger the bug (my normal settings):

Code: Select all

# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_PAX_KERNEXEC=y


Think I'll have to try to trigger the bug again. Any ideas assuming the problem is caused by the forced pre-emption?

[PaX Team]

Think I'll have to try to trigger the bug again. Any ideas assuming the problem is caused by the forced pre-emption?

i never recommended PREEMPT because i haven't made any big effort to ensure that everything in PaX is compatible with it, so something could have easily fallen through the cracks, so to speak. on the other hand i can't think of anything in KERNEXEC right now that could somehow be disturbed by PREEMPT and hasn't been taken care of already (it's pretty much the open/close kernel stuff which disables preempt). so it may very well be a genuine kernel bug (some kind of race) that manifests more likely under KERNEXEC due to changed timings. unfortunately these kinds of bugs are hard to figure out, especially when i can't reproduce them let alone have any time/desire left to deal with PREEMPT itself. so for now just don't use PREEMPT with KERNEXEC.

[specs]

I think your point is clear.
I'll take the hint to disable the PREEMPT-feature.

Unfortunately there are more parts of the kernel, which don't work correctly even in the vanilla kernel.
(Like longhaul, needed for cpufreqd for a C3).