Messages in this thread | | | Date | Wed, 27 Jul 2016 21:58:25 -0400 | From | Steven Rostedt <> | Subject | Re: warning: calling ‘ builtin return addr ess’ with a nonzero argument is unsafe |
| |
On Wed, 27 Jul 2016 16:00:54 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: > > I can just add a > > KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
I like this solution.
> > in the main Makefile, and that is indeed what I have in my tree right > now and will likely commit soon. The warning isn't actually helpful > for us, and there doesn't seem to be any other way to turn it off. At > the same time, there is a somewhat valid reason for that warning > existing, so I'm wondering if the tracing code could perhaps try to > change. > > I detest having lots of warnings when doing my test builds, because > the uninteresting warnings often hide real ones that might actually > matter. > > Comments?
We are well aware of the danger of using __builtin_return_address() of > 0. In fact that's part of the reason for having the "thunk" code in x86 (See arch/x86/entry/thunk_{64,32}.S). Because it adds extra frames when tracking irqs off sections, to prevent the __builtin_return_address() from accessing bad areas. In fact the thunk_32.S states: "Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)".
Now if we can get a better fast arch generic way of getting the same information, we could switch to that. Perhaps the wakeup tracing could use part of stacktrace, as that's not as high volume as the irq tracing is. But the irq tracing does this at every instance interrupts are disabled and enabled. A bit too much impact on the system to be calling into the stack trace code every time interrupts are disable or enabled.
I can still look to see if that information is even useful, as we do a stack dump when we find a new max latency.
-- Steve
| |