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
-
next prev parent 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