so it's the latterQuote:
Originally Posted by cat /usr/src/linux/.config | grep COMPAT
Actually, I was wrong with my assumption that compat_alloc_user_space is rennamed to arch_compat_alloc_user_space. compat_alloc_user_space get's some extra checking and calls the "new" arch_compat_alloc_user_space (which is the old compat_alloc_user_space)
The new compat_alloc_user_space is declared in linux/compat.h which should be included by kcl_ioctl.c.
--- fglrx/build_mod/kcl_ioctl.c 2010-09-01 10:05:31.000000000 -0400
+++ kcl_ioctl.c 2010-09-16 23:11:12.066336002 -0400
@@ -193,7 +193,7 @@
void* ATI_API_CALL KCL_IOCTL_AllocUserSpace32(long size)
- return compat_alloc_user_space(size);
+ return arch_compat_alloc_user_space(size);
#endif // __x86_64__
I have had the same problem as descriped in the first post.
The patch later on worked for me an 2.6.36-rc3.
But now I have the following issu.
My system looks like this
- one installation on internel hdd - as working system
- and the same at an externel hdd (copied via cp -a) - as experimental system
The above things worked well on the external system and I could start X, so I wanted to get the same one the internal installation.
Build and install with dkms worked well but when starting X I get the following error
"fglrx incompatible kernel module detected"
(as mentioned both systems run the same kernel-image 2.6.36-rc3)
I found another forum where this issue is discriped but the final answer is missing and I can't get behind it.(http://www.linux-club.de/viewtopic.p...107085&start=0)
Would be great if anyone could give me a hint :-)
New compat_alloc_user_space() GPLness and fglrx
could you please tell the devs for the proprietary driver / fglrx to fix it that it won't leave a security-hole open in the kernel with versions newer than 2.6.36-rc4-git2+ ?
I don't think there is a good way to do that (at least nothing yet). The patch that caused problems wrapped the arch-specific compat_alloc_user_space calls with a new, common call which included a security fix (yay !), but that new call was then marked GPL-only so we can't use it from fglrx (boo !).
If the routine that "everyone thinks we should be using" has been marked GPL-only there may not be a better solution than what Evan implemented, which is continuing to use the arch_ call but implementing a similar security fix. A number of other options have been discussed but right now all of them seem worse.
IMO it's pretty user-unfriendly to do this kind of stuff: this also effectively prevents using lock tracking:
[ ] Lock debugging: detect incorrect freeing of live locks
[ ] Lock debugging: prove locking correctness
[ ] Lock usage statistics
why is there no problem with nvidia and their binary blob ?
in the past when I had this enabled it nevertheless worked
do they mark parts of their driver GPL or some other kind of black magic ?
anyways: if that's the only (best of all) way(s) to do it - then leave it at that ...
Argh, looks like they did this to 184.108.40.206 too. Why do they do such stuff in stable kernels. It is stupid to keep up with these kind of changes for 3rd party software in general.
Anyway, thanks for all the help here :D.
From your reply it looks like there is no way to get it working 'the right way' at the moment. With the fglrx release cycle of multiple months and the fact that *all* previous releases are also affected, will we really have to wait until next year for acceleration without this gaping security hole? Or is a security release of fglrx a real possibility?