Created attachment 294451 [details] emerge --info ati-drivers >=x11-drivers/ati-drivers-11.10 fail to compile in very similar ways; version 11.9 emerges flawlessly. [...] In file included from /var/tmp/portage/x11-drivers/ati-drivers-11.11/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.c :33:0: /var/tmp/portage/x11-drivers/ati-drivers-11.11/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_debug.h:202:5: warning: "_DE BUG" is not defined [-Wundef]In file included from /var/tmp/portage/x11-drivers/ati-drivers-11.11/work/common/lib/modules/fgl rx/build_mod/2.6.x/kcl_agp.c:47:0: /var/tmp/portage/x11-drivers/ati-drivers-11.11/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_debug.h:202:5: warning: "_DE BUG" is not defined [-Wundef] /var/tmp/portage/x11-drivers/ati-drivers-11.11/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_debug.h:162:16: warning: ‘mo dule_log_map’ defined but not used [-Wunused-variable] /var/tmp/portage/x11-drivers/ati-drivers-11.11/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_debug.h:175:19: warning: ‘mo dule_type_map’ defined but not used [-Wunused-variable] /var/tmp/portage/x11-drivers/ati-drivers-11.11/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.c: In function ‘KCL_ACP I_EvalObject’: /var/tmp/portage/x11-drivers/ati-drivers-11.11/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.c:246:55: error: called object ‘2’ is not a function [...]
Created attachment 294453 [details] build.log for ati-drivers-11.10
Created attachment 294455 [details] build.log for ati-drivers-11.11
Just a quick note. I have the exact same problem on a new ~amd64 install with gcc-4.5.3-r1. Denis.
Please also attach your kernel .config
I promised Luca I would try with kernel 3.1.2 and also with a much cleaner .config than the one I had quickly hacked up for this fresh install. The cleaner .config did it, even with kernel 3.1.4. I thought I had backed up the original one for comparison but I apparently forgot. Sorry about that. Denis.
Created attachment 294683 [details] .config for kernel 3.1.3
(In reply to comment #5) > I promised Luca I would try with kernel 3.1.2 and also with a much cleaner > .config than the one I had quickly hacked up for this fresh install. The > cleaner .config did it, even with kernel 3.1.4. I thought I had backed up the > original one for comparison but I apparently forgot. Sorry about that. > > Denis. I tried this with a newly created .config (after "make clean" in the kernel source tree) and got the exact same error again. Denis, can you post your kernel .config, so I can compare it with mine?
I suggest that you back up your current config, and then run "make defconfig" If the defconfig build allows ati-drivers to emerge successfully, you can investigate which particular option breaks the package.
(In reply to comment #8) > I suggest that you back up your current config, and then run "make defconfig" > > If the defconfig build allows ati-drivers to emerge successfully, you can > investigate which particular option breaks the package. It does not work with "make defconfig", I'm getting the same error here.
Created attachment 295353 [details, diff] Diff between 11-9 and 11.11 source code A nasty issue nothing to say. I've tried to diff the entire source code of the kernel module (<3 git) to see what changed...... to be honest this does tell me nothing, but I share this so you can take a look too. My feeling is something in the mainline kernel is changed and fglrx is not on par with all possibile kernel configs. Where to look? Well i would start from acpi stack. The next step might be running the CPP and see what gets out from those macros hell, but this is a desperate attempt
Works with: gentoo-sources-3.1.4 + 3.1.5 vanilla-sources-3.1.5. But not with (same error as above): hardened-sources-2.6.39-r8 + 3.1.4 + 3.1.4-r1. So this looks like it has to do with the hardened kernel patches.
Same here, 11.11 and 11.12 work with gentoo-sources, but fail with hardened-sources. Shall we CC hardened team?
Created attachment 296837 [details] Kernel config causing an error Confirming bug on 3.0.4-hardened-r1. However I disagree that it is incompatibility between ATI module and kernel, because proprietary installer works just fine. It seems to be problem in ebuild, maybe?
Might be an ebuild problem if the installer works..... but what is missing? The only difference i can see between the ebuild and the installer is the PAGE_ATTR_FIX definition (and i have no idea what it does or what it is). Does your system need it? To check just run fgrep " change_page_attr\$" /proc/k*syms If it return something the ati installer would change a definition at compile time. Other then this i can't really point to something. Other ideas?
> fgrep " change_page_attr\$" /proc/k*syms returns nothing. No other ideas from my side, as I have totally no clue how the proprietary installer works :(
I'm CCing the hardened team, hoping they might be able to help. I've just tried myself to compile against hardened-sources on my default profile. It very fails the same way. But the issue is not strictly related to PAX or Grsec i think since i just used the same .config i use for my gentoo-sources kernel (so PAX and Grsec are disabled).
> But the issue is not strictly related to PAX or Grsec i think Agree, although I use hardened profile I don't have PaX or GrSecurity enabled. Compiler profile does not matter - compilation fails for all of those: [2] x86_64-pc-linux-gnu-4.5.3 * [3] x86_64-pc-linux-gnu-4.5.3-hardenednopie [4] x86_64-pc-linux-gnu-4.5.3-hardenednopiessp
Created attachment 297347 [details] build.log for ati-drivers-11.11 with gcc-4.4.5 Also ran into this bug, tried to downgrade to gcc-4.4.5 but it still failed with the same error.
(In reply to comment #13) > Confirming bug on 3.0.4-hardened-r1. However I disagree that it is > incompatibility between ATI module and kernel, because proprietary installer > works just fine. It seems to be problem in ebuild, maybe? I just tried to compile the module with the installer and it doesn't work for me. It fails with the exact same error as the ebuild. Can you explain how did you managed to build it with the installer? Be aware the graphical AMD installer gives success even if something fails sometimes, so check carefully the log! This is what i've done: first i extracted the archive with # sh /usr/portage/distfiles/ati-driver-installer-11-11-x86.x86_64.run --extract /tmp/ati # cd /tmp/ati/common/lib/modules/fglrx/build_mod/ then call make.sh as the installer should do, but with some tweak (you can also edit it around line 499 and exit before the install). I call it as user so nothing gets installed. # ./make.sh --norootcheck --uname_r=3.1.5-hardened Of course use the version of the kernel you have installed. If you are already running the hardened kernel you want to run on just omit the --uname_r entry.
(In reply to comment #16) > I'm CCing the hardened team, hoping they might be able to help. I've just tried > myself to compile against hardened-sources on my default profile. It very fails > the same way. But the issue is not strictly related to PAX or Grsec i think > since i just used the same .config i use for my gentoo-sources kernel (so PAX > and Grsec are disabled). The errors point at kmalloc. GrSecurity patches the linux/slab.h, adding a macro called kmalloc there. However, in which way is the kmalloc call replaced with "2"? I am not sure whether this is the right place to check. Since 11.10, kcl_debug.h got a lot of new macros. And it seems kcl_acpi.c and firegl_public.c included kcl_debug.h. However, I am not familiar with C programming and kernel sources. What is the tool to check how macros is preprocessed?
Correct me if I am wrong. Is WARN macro the problem? include/linux/slab.h from hardened-sources: @@ -353,4 +365,59 @@ static inline void *kzalloc_node(size_t size, gfp_t flags, int node) void __init kmem_cache_init_late(void); +#define kmalloc(x, y) \ +({ \ + void *___retval; \ + intoverflow_t ___x = (intoverflow_t)x; \ + if (WARN(___x > ULONG_MAX, "kmalloc size overflow\n")) \ + ___retval = NULL; \ + else \ + ___retval = kmalloc((size_t)___x, (y)); \ + ___retval; \ +}) + build_mod/kcl_debug.h from ati-drivers: 88 #ifdef WARN 89 #undef WARN 90 #endif 121typedef enum _LOG_LEVEL_ { SPECIAL = 0, ERROR , WARN , INFO , INFOEX, TRACE, PERFORMANCE, DUMP, LOG_L_MAX }LOG_LEVEL; 162 static log_map module_log_map[LOG_L_MAX] = 163 { 164 {SPECIAL , 'S'}, 165 {ERROR , 'E'}, 166 {WARN , 'W'}, 167 {INFO , 'I'}, 168 {INFOEX , 'X'}, 169 {TRACE , 'T'}, 170 {PERFORMANCE , 'P'}, 171 {DUMP , 'D'}, 172 };
> Can you explain how did you managed to build it with the installer? Be aware > the graphical AMD installer gives success even if something fails sometimes, so > check carefully the log! Sorry, you are right, I didn't notice the errors in log :(
Created attachment 297377 [details, diff] Patch to fix compilation error I have tested compiling and it works, but am not sure whether it brings any side-effects. While it is only about log verbosity, I guess it does not matter. Ebuild modification is here: --- /var/pkg/portage/x11-drivers/ati-drivers/ati-drivers-11.12.ebuild 2011-12-16 01:07:33.000000000 +0800 +++ /var/pkg/usr/x11-drivers/ati-drivers/ati-drivers-11.12.ebuild 2011-12-30 19:57:23.524033756 +0800 @@ -17,7 +17,7 @@ SRC_URI="https://launchpad.net/ubuntu/natty/+source/fglrx-installer/2:${PV}-0ubuntu1/+files/fglrx-installer_${PV}.orig.tar.gz" FOLDER_PREFIX="" fi -IUSE="debug +modules multilib opencl qt4" +IUSE="debug +modules multilib opencl pax_kernel qt4" LICENSE="AMD GPL-2 QPL-1.0 as-is" KEYWORDS="~amd64 ~x86" @@ -287,6 +287,8 @@ } src_prepare() { + use pax_kernel && epatch ${FILESDIR}/ati-drivers-11.10-pax.patch + # All kernel options for prepare are ment to be in here if use modules; then # version patches
I have checked that no other source file in common/lib/modules/fglrx/build_mod uses WARN. I have not found the sources of other utilities. While the driver works for me now and I am too tired, I am not going to check other sources. Forgive me, please.
(In reply to comment #21) > Correct me if I am wrong. Is WARN macro the problem? I think you just hitten the gold :). I was so near and i missed it... AMD this is bad you are redefining kernel macros and someone actually uses them ;) I opened a bug in the Unofficial catalyst linux bugzilla. I also have a very very bad workaround for braves. Will attach it in a moment.
(In reply to comment #23) > Created attachment 297377 [details, diff] [details, diff] > Patch to fix compilation error You beat me again :). Thank you very much really. I'm trying to reach someone from the hardened and X11 team to have an opinion if we can apply this patch for every kernel or only for hardened kernels, and if so how to check. Then i will upload a new ebuild. So X11 and hardened team if you have some suggestion please share. Also do you think using a prefixed (or suffixed) WARN in the enum inside the fglrx kernel source code is dangerous for some reason? Couse if we can assume it is not then i will apply the patch for every kernel. Thank you. You can also find me in IRC, nick [Enrico]
I'm happy to say ati-drivers-11.12-r2 has been uploaded to X11 overlay. Try it and report any problems :) Many thanks to all, and in particular to Zhang Hongjiu for the solution, Michał "mgorny" Górny and Anthony "blueness" G. Basile for helping me packaging this.
I suggest that you don't apply this patch unconditionally nor conditionally when you detect hardened kernels. Instead add a pax_kernel USE flag and maybe display a warning when you think that the kernel is hardened and the flag is disabled. Also if the patch is strictly a compile fix, usually no revbump is needed.
Updated to apply the patch only when pax_kernel is enabled. Note to X11 overlay users: don't worry if you see a downgrade from -r2 to -r1, just enable the pax_kernel use flag if your profile doesn't and let it recompile :)
ati-drivers-11.12-r1 was added to portage with the patch.
*** Bug 399835 has been marked as a duplicate of this bug. ***
