From: Matt Chapman <matthewc@cse.unsw.edu.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC] prevent "dd if=/dev/mem" crash
Date: Sat, 18 Oct 2003 01:31:37 +0000 [thread overview]
Message-ID: <marc-linux-ia64-106644074523554@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106642876514553@msgid-missing>
On Fri, Oct 17, 2003 at 05:49:55PM -0700, Andrew Morton wrote:
> David Mosberger <davidm@napali.hpl.hp.com> wrote:
> >
> > One philosophy states that if
> > your kernel touches random addresses, it's better to signal a visible
> > error (machine-check) than to risk silent data corruption.
>
> An access to an illegal address should generate a fault, period. This puts
> the processing into the hands of software. If software chooses to silently
> ignore the fault (ie: "silent data corruption") then it is poorly designed.
It *does* signal a fault, in the form of a machine check. On other
architectures I'm familiar with this is usually implemented as an
interrupt, but the idea is similar - when the system bus controller
detects a bad address on the bus, it returns all 1s (for a read) and
signals an interrupt. Usually you can turn this interrupt off (and
most likely you can on Itanium chipsets too) but that is not a good
idea.
The problem is that this interrupt is not synchronous with respect to
the instruction stream, and this makes it difficult for software to
recover from, particularly in a monolithic system like Linux where you
can't just terminate the faulting driver. The best you can usually do
is to print the details and hope that it's a once-off. It is not
something that you can sensibly use to abort copy_*_user.
In any case touching random addresses is just plain bad. What if
there's a device mapped there which happens to have read side effects
like clearing the interrupt cause, so e.g. every time you read /dev/mem
you cause a timeout on your SCSI bus :)
Matt
next prev parent reply other threads:[~2003-10-18 1:31 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-17 22:10 [RFC] prevent "dd if=/dev/mem" crash Bjorn Helgaas
2003-10-17 22:19 ` Luck, Tony
2003-10-17 22:23 ` Matt Mackall
2003-10-17 22:40 ` Andreas Schwab
2003-10-17 22:50 ` Andrew Morton
2003-10-17 23:25 ` Bjorn Helgaas
2003-10-17 23:55 ` Andrew Morton
2003-10-18 0:15 ` William Lee Irwin III
2003-10-18 0:21 ` David Mosberger
2003-10-18 0:49 ` Andrew Morton
2003-10-18 1:31 ` Matt Chapman [this message]
2003-10-18 1:41 ` Andrew Morton
2003-10-18 1:48 ` David Mosberger
2003-10-18 2:01 ` Andrew Morton
2003-10-18 2:01 ` Matt Chapman
2003-10-19 11:25 ` Eric W. Biederman
2003-10-19 18:17 ` Pavel Machek
2003-10-19 19:01 ` William Lee Irwin III
2003-10-20 15:17 ` Bjorn Helgaas
2003-10-20 17:42 ` Bjorn Helgaas
2003-10-20 18:48 ` David Mosberger
2003-10-23 8:33 ` Martin Pool
2003-10-23 9:31 ` Zoltan Menyhart
2003-10-23 21:05 ` Bjorn Helgaas
-- strict thread matches above, loose matches on Subject: below --
2003-10-17 22:10 Bjorn Helgaas
2003-10-17 22:23 ` Matt Mackall
2003-10-17 22:50 ` Andrew Morton
2003-10-17 23:25 ` Bjorn Helgaas
2003-10-17 23:55 ` Andrew Morton
2003-10-18 0:15 ` William Lee Irwin III
2003-10-18 0:21 ` David Mosberger
2003-10-18 0:49 ` Andrew Morton
2003-10-18 1:31 ` Matt Chapman
2003-10-18 1:41 ` Andrew Morton
2003-10-18 1:48 ` David Mosberger
2003-10-18 2:01 ` Andrew Morton
2003-10-18 2:01 ` Matt Chapman
2003-10-19 11:25 ` Eric W. Biederman
2003-10-19 19:01 ` William Lee Irwin III
2003-10-20 15:17 ` Bjorn Helgaas
2003-10-20 18:48 ` David Mosberger
2003-10-20 17:42 ` Bjorn Helgaas
2003-10-23 21:05 ` Bjorn Helgaas
2003-10-19 18:17 ` Pavel Machek
2003-10-23 8:33 ` Martin Pool
2003-10-23 9:31 ` Zoltan Menyhart
2003-10-17 22:19 Luck, Tony
2003-10-17 22:40 ` Andreas Schwab
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=marc-linux-ia64-106644074523554@msgid-missing \
--to=matthewc@cse.unsw.edu.au \
--cc=linux-ia64@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 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.