Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 17 Oct 2003 19:01:04 -0700 | From | Andrew Morton <> | Subject | Re: [RFC] prevent "dd if=/dev/mem" crash |
| |
David Mosberger <davidm@napali.hpl.hp.com> wrote: > > >>>>> On Fri, 17 Oct 2003 17:49:55 -0700, Andrew Morton <akpm@osdl.org> said: > > Andrew> We _want_ to be able to read mmio ranges via /dev/mem, don't > Andrew> we? I guess it has never come up because everyone uses > Andrew> kmem. > > I just don't see how making a "dd if=/dev/mem" safe and allowing > access to arbitrary physical memory can go to together. Given that > /dev/mem _is_ being used for accessing mmio space, is it really worth > bothering trying to make such a "dd" safe?
Possibly not. I thought that simply oopsing the kernel was a bit rude, and fixing ia32 to not do that was relatively simple.
We should, within reason, handle it as gracefully as possible, yes?
> Andrew> If the hardware doesn't give the system programmer a choice > Andrew> then the hardware is poorly designed, surely? > > Emh, we're talking about _physical_ memory accesses here. AFAIK, > failures on physical memory accesses are never signaled with > synchronous faults (not on any reasonably modern high performance > architecture, at least). Loads probably _could_ be signalled > synchronously, but consider stores: would you really want to wait with > retiring a store until it has made it all the way to some slow ISA > device? I think not (IN/OUT do that). No, modern CPUs check the > TLB/page-table and if that check passes, they'll _assume_ the memory > access will complete without errors. If it doesn't, they signal an > asynchronous failure (e.g., via an MCA).
If the not-present memory is marked cacheable and/or writeback then yes, but that would be an odd thing to do, wouldn't it?
It the memory is mapped noncacheable then a synchronous error on a read sounds reasonable. A synchronous error on a write would assume that the noncacheability affects the write buffers and IIRC that usually doesn't happen(?).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |