Hi Raphael, Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master] [cannot apply to v5.3-rc4 next-20190816] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Raphael-Gault/perf-arm64-Add-test-to-check-userspace-access-to-hardware-counters/20190818-182238 config: arm-omap2plus_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=arm If you fix the issue, kindly add following tag Reported-by: kbuild test robot <l...@intel.com> All errors (new ones prefixed by >>): drivers/perf/arm_pmu.c: In function 'refresh_pmuserenr': >> drivers/perf/arm_pmu.c:784:2: error: implicit declaration of function >> 'perf_switch_user_access'; did you mean 'perf_fetch_caller_regs'? >> [-Werror=implicit-function-declaration] perf_switch_user_access(mm); ^~~~~~~~~~~~~~~~~~~~~~~ perf_fetch_caller_regs drivers/perf/arm_pmu.c: In function 'armpmu_event_mapped': >> drivers/perf/arm_pmu.c:804:36: error: 'mm_context_t {aka struct >> <anonymous>}' has no member named 'pmu_direct_access' if (atomic_inc_return(&mm->context.pmu_direct_access) == 1) ^ drivers/perf/arm_pmu.c: In function 'armpmu_event_unmapped': drivers/perf/arm_pmu.c:813:38: error: 'mm_context_t {aka struct <anonymous>}' has no member named 'pmu_direct_access' if (atomic_dec_and_test(&mm->context.pmu_direct_access)) ^ cc1: some warnings being treated as errors vim +784 drivers/perf/arm_pmu.c 781 782 static void refresh_pmuserenr(void *mm) 783 { > 784 perf_switch_user_access(mm); 785 } 786 787 static void armpmu_event_mapped(struct perf_event *event, struct mm_struct *mm) 788 { 789 if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR)) 790 return; 791 792 /* 793 * This function relies on not being called concurrently in two 794 * tasks in the same mm. Otherwise one task could observe 795 * pmu_direct_access > 1 and return all the way back to 796 * userspace with user access disabled while another task is still 797 * doing on_each_cpu_mask() to enable user access. 798 * 799 * For now, this can't happen because all callers hold mmap_sem 800 * for write. If this changes, we'll need a different solution. 801 */ 802 lockdep_assert_held_write(&mm->mmap_sem); 803 > 804 if (atomic_inc_return(&mm->context.pmu_direct_access) == 1) 805 on_each_cpu(refresh_pmuserenr, mm, 1); 806 } 807 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
