From: Mike Fedyk <mfedyk@matchmail.com>
To: Ed L Cashin <ecashin@uga.edu>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH] do_wp_page: BUG on invalid pfn
Date: Fri, 15 Aug 2003 15:05:19 -0700 [thread overview]
Message-ID: <20030815220519.GS1027@matchmail.com> (raw)
In-Reply-To: <87k79e7fna.fsf@uga.edu>
On Fri, Aug 15, 2003 at 05:52:09PM -0400, Ed L Cashin wrote:
> Mike Fedyk <mfedyk@matchmail.com> writes:
>
> > On Fri, Aug 15, 2003 at 05:15:45PM -0400, Ed L Cashin wrote:
> >> Rusty Russell <rusty@rustcorp.com.au> writes:
> >>
> >> > In message <87d6fixvpm.fsf@uga.edu> you write:
> >> >> This patch just does what the comment says should be done.
> >> >
> >> > Hi Ed!
> >> >
> >> > Not trivial I'm afraid. Send to Linus and lkml.
> >>
> >>
> >> This patch just does what the comment says should be done. I thought
> >> it was a trivial patch, but Rusty Russell has informed me otherwise.
> >> (Thanks, RR).
> >>
> >>
> >> --- linux-2.6.0-test2/mm/memory.c.orig Sun Jul 27 13:01:24 2003
> >> +++ linux-2.6.0-test2/mm/memory.c Wed Aug 6 18:30:55 2003
> >> @@ -990,15 +990,10 @@
> >> int ret;
> >>
> >> if (unlikely(!pfn_valid(pfn))) {
> >> - /*
> >> - * This should really halt the system so it can be debugged or
> >> - * at least the kernel stops what it's doing before it corrupts
> >> - * data, but for the moment just pretend this is OOM.
> >> - */
> >> - pte_unmap(page_table);
> >> printk(KERN_ERR "do_wp_page: bogus page at address %08lx\n",
> >> address);
> >> - goto oom;
> >> + dump_stack();
> >> + BUG();
> >
> > You're not unmapping the pte I guess to not interfere with the dump_stack,
>
> This patch changes the logic from "pretend it's out of memory" to
> "announce something's very wrong and bail out right away." Unmapping
> the pte seems like a precursor to carrying on business as usual, but
> there must be some subtleties here that I am unaware of, or Rusty
> Russell wouldn't have called this patch non-trivial.
So does show_stack() halt the kernel? If not, then you probably want the
pte_unmap since you'll have a working/semi-working system after the bug()
call.
And if show_stack() does halt the kernel, what's the point of bug() then?
next prev parent reply other threads:[~2003-08-15 22:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030815184720.A4D482CE79@lists.samba.org>
2003-08-15 21:15 ` [PATCH] do_wp_page: BUG on invalid pfn Ed L Cashin
2003-08-15 21:22 ` Mike Fedyk
2003-08-15 21:52 ` Ed L Cashin
2003-08-15 22:05 ` Mike Fedyk [this message]
2003-08-15 22:18 ` Ed L Cashin
2003-08-15 21:39 ` Russell King
2003-08-15 21:50 ` Ed L Cashin
2003-08-15 22:11 ` Russell King
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=20030815220519.GS1027@matchmail.com \
--to=mfedyk@matchmail.com \
--cc=ecashin@uga.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.