Ok, with the help of my colleague Ian Rogers, I think we solved the mystery. Clang actually inlined hrtimer_nanosleep() inside SyS_nanosleep(), so there is no call to that function throughout the path of the nanosleep syscall. I've been looking at the function body of hrtimer_nanosleep for quite some time, but clearly overlooked the caller of hrtimer_nanosleep. hrtimer_nanosleep is pretty short and there are many constants, inlining would not be too surprising. Sigh... Hao On Tue, Jun 30, 2020 at 3:48 PM Hao Luo <haoluo@xxxxxxxxxx> wrote: > > On Tue, Jun 30, 2020 at 1:37 PM Yonghong Song <yhs@xxxxxx> wrote: > > > > On 6/30/20 11:49 AM, Hao Luo wrote: > > > The test_vmlinux test uses hrtimer_nanosleep as hook to test tracing > > > programs. But it seems Clang may have done an aggressive optimization, > > > causing fentry and kprobe to not hook on this function properly on a > > > Clang build kernel. > > > > Could you explain why it does not on clang built kernel? How did you > > build the kernel? Did you use [thin]lto? > > > > hrtimer_nanosleep is a global function who is called in several > > different files. I am curious how clang optimization can make > > function disappear, or make its function signature change, or > > rename the function? > > > > Yonghong, > > We didn't enable LTO. It also puzzled me. But I can confirm those > fentry/kprobe test failures via many different experiments I've done. > After talking to my colleague on kernel compiling tools (Bill, cc'ed), > we suspected this could be because of clang's aggressive inlining. We > also noticed that all the callsites of hrtimer_nanosleep() are tail > calls. > > For a better explanation, I can reach out to the people who are more > familiar to clang in the compiler team to see if they have any > insights. This may not be of high priority for them though. > > Hao
