public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Andrey Nekrasov <andy@spylog.ru>, linux-kernel@vger.kernel.org
Subject: Re: BUG: 2.4.19-pre6aa1
Date: Tue, 09 Apr 2002 11:50:55 -0700	[thread overview]
Message-ID: <3CB3380F.FA9456D8@zip.com.au> (raw)
In-Reply-To: <20020409084335.GA10890@spylog.ru> <3CB2B09C.DF1A0AC2@zip.com.au> <20020409182200.E15656@dualathlon.random>

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


-

  reply	other threads:[~2002-04-09 19:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-09  8:43 BUG: 2.4.19-pre6aa1 Andrey Nekrasov
2002-04-09  9:13 ` Andrew Morton
2002-04-09 16:22   ` Andrea Arcangeli
2002-04-09 18:50     ` Andrew Morton [this message]
2002-04-09 20:50       ` Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3CB3380F.FA9456D8@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=andrea@suse.de \
    --cc=andy@spylog.ru \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox