public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: Memory management bug
Date: 15 Nov 2000 08:45:47 -0800	[thread overview]
Message-ID: <8uuejr$hbq$1@penguin.transmeta.com> (raw)
In-Reply-To: <C1256998.004585F4.00@d12mta07.de.ibm.com>

In article <C1256998.004585F4.00@d12mta07.de.ibm.com>,
>	 After some trickery with some special hardware feature (storage
>keys) I found out that empty_bad_pmd_table and empty_bad_pte_table have
>been put to the page table quicklists multiple(!) times.

This is definitely bad, and means that something else really bad is
going on.

In fact, I have this fairly strong suspicion that we should just get rid
of the "bad" page tables altogether, and make the stuff that now uses
them BUG() instead. 

The whole concept of "bad" page tables comes from very early on in
Linux, when the way the page fault handler worked was that if it ran out
of memory or something else really bad happened, it would insert a dummy
page table entry that was guaranteed to let the CPU continue.  That way
the page fault handler was always "successful" from a hardware
standpoint, even if it ended up trying to kill the process. 

This used to be required simply because a page fault in kernel space
originally needed to let the process unwind sanely and cleanly.

These days, the requirement that page faults always "succeed" is long
long gone. The exception handling mechanism handles the cases where we
validly can take a page fault, and in other cases we will just kill the
process outright. As such, the bad page tables should no longer be
needed, and are apparently just hiding some nasty bugs.

What happens if you just replace all places that would use a bad page
table with a BUG()? (Ie do _not_ add the bug to the place where you
added the test: by that time it's too late.  I'm talking about the
places where the bad page tables are used, like in the error cases of
"get_pte_kernel_slow()" etc.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-11-15 17:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-15 12:39 Memory management bug schwidefsky
2000-11-15 13:19 ` Andi Kleen
2000-11-15 16:45 ` Linus Torvalds [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-11-15 13:24 schwidefsky
2000-11-16 16:12 schwidefsky
2000-11-16 17:01 ` Linus Torvalds
2000-11-16 17:45   ` Andrea Arcangeli
2000-11-16 18:07     ` Linus Torvalds
2000-11-17 10:41 schwidefsky
2000-11-17 15:44 ` Andrea Arcangeli
2000-11-17 19:12   ` Rik van Riel
2000-11-17 16:35 schwidefsky
2000-11-17 16:42 ` Linus Torvalds
2000-11-17 18:11 ` Andrea Arcangeli
2000-11-17 19:15   ` Rik van Riel
2000-11-21 19:55 schwidefsky

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='8uuejr$hbq$1@penguin.transmeta.com' \
    --to=torvalds@transmeta.com \
    --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