Re: [Xen-devel] [PATCH 2/2] build/clang: fix XSM dummy policy when using clang 4.0
On 03/06/2017 07:31 AM, Roger Pau Monne wrote: There seems to be some weird bug in clang 4.0 that prevents xsm_pmu_op from working as expected, and vpmu.o ends up with a reference to __xsm_action_mismatch_detected which makes the build fail: [...] ld-melf_x86_64_fbsd -T xen.lds -N prelink.o \ xen/common/symbols-dummy.o -o xen/.xen-syms.0 prelink.o: In function `xsm_default_action': xen/include/xsm/dummy.h:80: undefined reference to `__xsm_action_mismatch_detected' xen/xen/include/xsm/dummy.h:80: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__xsm_action_mismatch_detected' ld: xen/xen/.xen-syms.0: hidden symbol `__xsm_action_mismatch_detected' isn't defined Then doing a search in the objects files: # find xen/ -type f -name '*.o' -print0 | xargs -0 bash -c \ 'for filename; do nm "$filename" | \ grep -q __xsm_action_mismatch_detected && echo "$filename"; done' bash xen/arch/x86/prelink.o xen/arch/x86/cpu/vpmu.o xen/arch/x86/cpu/built_in.o xen/arch/x86/built_in.o The current patch is the only way I've found to fix this so far, by simply moving the XSM_PRIV check into the default case in xsm_pmu_op. This also fixes the behavior of do_xenpmu_op, which will now return -EINVAL for unknown XENPMU_* operations, instead of -EPERM when called by a privileged domain. Signed-off-by: Roger Pau Monné Acked-by: Daniel De Graaf This also looks like a good patch for backporting. The best alternative I can think of is to disable the mismatch detection in non-DEBUG builds, but I'd rather not do that unless this problem expands more than it has. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] build/clang: fix XSM dummy policy when using clang 4.0
On Mon, Mar 06, 2017 at 05:52:14AM -0700, Jan Beulich wrote: > >>> On 06.03.17 at 13:31, wrote: > > There seems to be some weird bug in clang 4.0 that prevents xsm_pmu_op from > > working as expected, and vpmu.o ends up with a reference to > > __xsm_action_mismatch_detected which makes the build fail: > > > > [...] > > ld-melf_x86_64_fbsd -T xen.lds -N prelink.o \ > > xen/common/symbols-dummy.o -o xen/.xen-syms.0 > > prelink.o: In function `xsm_default_action': > > xen/include/xsm/dummy.h:80: undefined reference to > > `__xsm_action_mismatch_detected' > > xen/xen/include/xsm/dummy.h:80: relocation truncated to fit: R_X86_64_PC32 > > against undefined symbol `__xsm_action_mismatch_detected' > > ld: xen/xen/.xen-syms.0: hidden symbol `__xsm_action_mismatch_detected' > > isn't defined > > > > Then doing a search in the objects files: > > > > # find xen/ -type f -name '*.o' -print0 | xargs -0 bash -c \ > > 'for filename; do nm "$filename" | \ > > grep -q __xsm_action_mismatch_detected && echo "$filename"; done' bash > > xen/arch/x86/prelink.o > > xen/arch/x86/cpu/vpmu.o > > xen/arch/x86/cpu/built_in.o > > xen/arch/x86/built_in.o > > > > The current patch is the only way I've found to fix this so far, by simply > > moving the XSM_PRIV check into the default case in xsm_pmu_op. This also > > fixes > > the behavior of do_xenpmu_op, which will now return -EINVAL for unknown > > XENPMU_* operations, instead of -EPERM when called by a privileged domain. > > Especially from this perspective I think the patch is fine (but also > Cc-ing Boris), yet I still think the compilation aspect needs to be got > to the bottom of, to have a complete picture in case the problem > shows up in a slightly different way elsewhere. Did you report this > to clang folks? Did they have any explanation of what's going on? I've just reported this upstream, for the record the ticket is at: http://bugs.llvm.org/show_bug.cgi?id=32150 Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] build/clang: fix XSM dummy policy when using clang 4.0
On 03/06/2017 09:54 AM, Jan Beulich wrote: On 06.03.17 at 15:42, wrote: >> On 03/06/2017 07:52 AM, Jan Beulich wrote: >> On 06.03.17 at 13:31, wrote: There seems to be some weird bug in clang 4.0 that prevents xsm_pmu_op from working as expected, and vpmu.o ends up with a reference to __xsm_action_mismatch_detected which makes the build fail: [...] ld-melf_x86_64_fbsd -T xen.lds -N prelink.o \ xen/common/symbols-dummy.o -o xen/.xen-syms.0 prelink.o: In function `xsm_default_action': xen/include/xsm/dummy.h:80: undefined reference to `__xsm_action_mismatch_detected' xen/xen/include/xsm/dummy.h:80: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__xsm_action_mismatch_detected' ld: xen/xen/.xen-syms.0: hidden symbol `__xsm_action_mismatch_detected' isn't defined Then doing a search in the objects files: # find xen/ -type f -name '*.o' -print0 | xargs -0 bash -c \ 'for filename; do nm "$filename" | \ grep -q __xsm_action_mismatch_detected && echo "$filename"; done' bash xen/arch/x86/prelink.o xen/arch/x86/cpu/vpmu.o xen/arch/x86/cpu/built_in.o xen/arch/x86/built_in.o The current patch is the only way I've found to fix this so far, by simply moving the XSM_PRIV check into the default case in xsm_pmu_op. This also fixes the behavior of do_xenpmu_op, which will now return -EINVAL for unknown XENPMU_* operations, instead of -EPERM when called by a privileged domain. >> How will these changes make do_xenpmu_op() return -EINVAL? > Since the XSM check no longer returns -EPERM, the handling inside > do_vpmu_op() will now reach the default case there. Oh, I was staring at xsm_default_action() and trying to see where -EINVAL would be coming from. Sorry for the noise. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] build/clang: fix XSM dummy policy when using clang 4.0
>>> On 06.03.17 at 15:42, wrote: > On 03/06/2017 07:52 AM, Jan Beulich wrote: > On 06.03.17 at 13:31, wrote: >>> There seems to be some weird bug in clang 4.0 that prevents xsm_pmu_op from >>> working as expected, and vpmu.o ends up with a reference to >>> __xsm_action_mismatch_detected which makes the build fail: >>> >>> [...] >>> ld-melf_x86_64_fbsd -T xen.lds -N prelink.o \ >>> xen/common/symbols-dummy.o -o xen/.xen-syms.0 >>> prelink.o: In function `xsm_default_action': >>> xen/include/xsm/dummy.h:80: undefined reference to >>> `__xsm_action_mismatch_detected' >>> xen/xen/include/xsm/dummy.h:80: relocation truncated to fit: R_X86_64_PC32 >>> against undefined symbol `__xsm_action_mismatch_detected' >>> ld: xen/xen/.xen-syms.0: hidden symbol `__xsm_action_mismatch_detected' >>> isn't defined >>> >>> Then doing a search in the objects files: >>> >>> # find xen/ -type f -name '*.o' -print0 | xargs -0 bash -c \ >>> 'for filename; do nm "$filename" | \ >>> grep -q __xsm_action_mismatch_detected && echo "$filename"; done' bash >>> xen/arch/x86/prelink.o >>> xen/arch/x86/cpu/vpmu.o >>> xen/arch/x86/cpu/built_in.o >>> xen/arch/x86/built_in.o >>> >>> The current patch is the only way I've found to fix this so far, by simply >>> moving the XSM_PRIV check into the default case in xsm_pmu_op. This also >>> fixes >>> the behavior of do_xenpmu_op, which will now return -EINVAL for unknown >>> XENPMU_* operations, instead of -EPERM when called by a privileged domain. > > How will these changes make do_xenpmu_op() return -EINVAL? Since the XSM check no longer returns -EPERM, the handling inside do_vpmu_op() will now reach the default case there. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] build/clang: fix XSM dummy policy when using clang 4.0
On 03/06/2017 07:52 AM, Jan Beulich wrote: On 06.03.17 at 13:31, wrote: >> There seems to be some weird bug in clang 4.0 that prevents xsm_pmu_op from >> working as expected, and vpmu.o ends up with a reference to >> __xsm_action_mismatch_detected which makes the build fail: >> >> [...] >> ld-melf_x86_64_fbsd -T xen.lds -N prelink.o \ >> xen/common/symbols-dummy.o -o xen/.xen-syms.0 >> prelink.o: In function `xsm_default_action': >> xen/include/xsm/dummy.h:80: undefined reference to >> `__xsm_action_mismatch_detected' >> xen/xen/include/xsm/dummy.h:80: relocation truncated to fit: R_X86_64_PC32 >> against undefined symbol `__xsm_action_mismatch_detected' >> ld: xen/xen/.xen-syms.0: hidden symbol `__xsm_action_mismatch_detected' >> isn't defined >> >> Then doing a search in the objects files: >> >> # find xen/ -type f -name '*.o' -print0 | xargs -0 bash -c \ >> 'for filename; do nm "$filename" | \ >> grep -q __xsm_action_mismatch_detected && echo "$filename"; done' bash >> xen/arch/x86/prelink.o >> xen/arch/x86/cpu/vpmu.o >> xen/arch/x86/cpu/built_in.o >> xen/arch/x86/built_in.o >> >> The current patch is the only way I've found to fix this so far, by simply >> moving the XSM_PRIV check into the default case in xsm_pmu_op. This also >> fixes >> the behavior of do_xenpmu_op, which will now return -EINVAL for unknown >> XENPMU_* operations, instead of -EPERM when called by a privileged domain. How will these changes make do_xenpmu_op() return -EINVAL? -boris > Especially from this perspective I think the patch is fine (but also > Cc-ing Boris), yet I still think the compilation aspect needs to be got > to the bottom of, to have a complete picture in case the problem > shows up in a slightly different way elsewhere. Did you report this > to clang folks? Did they have any explanation of what's going on? > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] build/clang: fix XSM dummy policy when using clang 4.0
>>> On 06.03.17 at 13:31, wrote: > There seems to be some weird bug in clang 4.0 that prevents xsm_pmu_op from > working as expected, and vpmu.o ends up with a reference to > __xsm_action_mismatch_detected which makes the build fail: > > [...] > ld-melf_x86_64_fbsd -T xen.lds -N prelink.o \ > xen/common/symbols-dummy.o -o xen/.xen-syms.0 > prelink.o: In function `xsm_default_action': > xen/include/xsm/dummy.h:80: undefined reference to > `__xsm_action_mismatch_detected' > xen/xen/include/xsm/dummy.h:80: relocation truncated to fit: R_X86_64_PC32 > against undefined symbol `__xsm_action_mismatch_detected' > ld: xen/xen/.xen-syms.0: hidden symbol `__xsm_action_mismatch_detected' > isn't defined > > Then doing a search in the objects files: > > # find xen/ -type f -name '*.o' -print0 | xargs -0 bash -c \ > 'for filename; do nm "$filename" | \ > grep -q __xsm_action_mismatch_detected && echo "$filename"; done' bash > xen/arch/x86/prelink.o > xen/arch/x86/cpu/vpmu.o > xen/arch/x86/cpu/built_in.o > xen/arch/x86/built_in.o > > The current patch is the only way I've found to fix this so far, by simply > moving the XSM_PRIV check into the default case in xsm_pmu_op. This also fixes > the behavior of do_xenpmu_op, which will now return -EINVAL for unknown > XENPMU_* operations, instead of -EPERM when called by a privileged domain. Especially from this perspective I think the patch is fine (but also Cc-ing Boris), yet I still think the compilation aspect needs to be got to the bottom of, to have a complete picture in case the problem shows up in a slightly different way elsewhere. Did you report this to clang folks? Did they have any explanation of what's going on? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel