Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

Adrian Bunk
2007-07-24T18:00:41Z

On Mon, Jul 23, 2007 at 02:28:11PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 23 Jul 2007, Andrew Morton wrote:
> >
> > It'd be nice to get a clean trace. Are you able to obtain the full
> > trace with CONFIG_FRAME_POINTER=y?
>
> If you are talking about
>
> http://userweb.kernel.org/~akpm/dsc03659.jpg
>
> then I think that _is_ a full trace. It's certainly not very messy, and it
> seems accurate. It's just that inlining makes it much harder to see the
> call-graphs, but that's what inlining does..
>
> For example, missing from the call graph is
>
> get_page_from_freelist ->
> buffered_rmqueue -> [ missing - inlined ]
> prep_new_page -> [ missing - inlined ]
> prep_zero_page -> [ missing - inlined ]
> clear_highpage -> [ missing - inlined ]
> kmap_atomic -> [ missing - tailcall ]
> kmap_atomic_prot
>
> but I'm pretty sure the call trace is good (and I'm also pretty sure gcc
> is overly aggressive at inlining, and that it causes us pain for
> debugging, but whatever)
>...

For prep_zero_page() and clear_highpage() we can't blame gcc since we
force gcc to always inline them.

buffered_rmqueue() and prep_new_page() are static functions with only
one caller each, and for the normal non-debug case it's a really nice
optimization to have them inlined automatically. But it might make sense
to add -fno-inline-functions-called-once to the CFLAGS depending on some
debug option?

> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed