Re: BUG: 2.4.19-pre6aa1

[Andrew Morton]

Andrea Arcangeli wrote:
> 
> On Tue, Apr 09, 2002 at 02:13:00AM -0700, Andrew Morton wrote:
> > Andrey Nekrasov wrote:
> > >
> > > ..
> > > >>EIP; e0115c1c <out_of_line_bug+0/14>   <=====
> > > Trace; e012069a <copy_page_range+1da/334>
> > > Trace; e0114caa <copy_mm+222/2bc>
> > > Trace; e01154b6 <do_fork+42e/744>
> > > Trace; e0107270 <sys_fork+14/1c>
> >
> > hmm.  That out-of-line stuff has obfuscated the trace
> > a bit.  It died in kunmap_atomic or kmap_atomic, part
> > of Andrea's pte-highmem additions.
> >
> > I guess the out-of-line bug should be if !CONFIG_DEBUG_KERNEL.
> 
> I didn't complained yet but the whole point of the BUG() was to get such
> a printk in the right place. Now the above report is trivial and the
> debugging check triggered a false positive bugcheck due
> CONFIG_DEBUG_HIGHMEM=y (I always compile with =n and that's why I didn't
> triggered it here), but sometime it isn't that easy to find it out, in
> particular when there are plenty of BUG()s in a row like in
> page_alloc.c, so I disagree with the merger of the out_of_line_bug in
> mainline.

No, you misunderstand.  All the BUG()s in .c files are unchanged.

out_of_line_bug() is used in one place only:  in inline functions
which appear in commonly-included header files.

There are only ten or fifteen out_of_line_bug()s.  We just happened
to hit one here.  They were added by a process of peering at the 
kernel image and asking "why does the same string appear 120 times?".

Yeah, it's all a bit sad.  It's a workaround for a toolchain shortcoming,
and it does save 100 to 200 kbytes.  If I'd been smarter I'd have
passed __LINE__ into out_of_line_bug().  It's only the string which
is a problem.

There is a sneaky new featurette, btw.  We sometimes see BUG
reports where the reporter failed to report the file-and-line.
But it's still available in the oops record:

Code: 0f 0b c2 05 d8 36 92 f0 83 c4 14 5b 5e 5f 5d c3 8d 76 00 8d
            ^^^^^
                 This is the line number

-