[Intel-gfx] [PATCH 02/23] perf/core: Only copy-to-user after completely unlocking all locks.

[Nick Desaulniers]

On Tue, Mar 31, 2020 at 11:50 PM kbuild test robot <lkp at intel.com> wrote:
>
> Hi Maarten,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on drm-tip/drm-tip]
> [also build test WARNING on next-20200331]
> [cannot apply to drm-intel/for-linux-next tip/perf/core v5.6]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>
> url:    https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/Revert-drm-i915-gem-Drop-relocation-slowpath/20200401-005710
> base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
> config: x86_64-randconfig-d003-20200331 (attached as .config)
> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 5227fa0c72ce55927cf4849160acb00442489937)
> 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
>         COMPILER=clang make.cross ARCH=x86_64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp at intel.com>
>
> All warnings (new ones prefixed by >>):
>
> >> kernel/events/core.o: warning: objtool: perf_read()+0x306: stack state mismatch: reg1[3]=-2-56 reg2[3]=-1+0

Apologies Maarten, this objtool warning looks like maybe a compiler
bug for us to fix.

Philip, I tried to reproduce by cloning
git://anongit.freedesktop.org/drm/drm-tip, but I don't understand the
URL in the report.  Were Maarten's patches on top of drm-tip?  Is
there a tree you found them from (rather than me fetching the 0day
branch on github)? (Or maybe this is what a report looks like for a
series posted to the list?)  Apologies for the naivete, but I plan to
triage as many of these reports on the Clang side as I can in my free
time, so I want to make sure I understand precisely what failure is
occurring where and how.
-- 
Thanks,
~Nick Desaulniers