[lkml]   [2003]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] prevent "dd if=/dev/mem" crash
    On Friday 17 October 2003 6:21 pm, David Mosberger wrote:
    > What about memory-mapped device registers? Isn't all memory
    > physically contiguous on x86 and that's why the "p >=
    > __pa(high_memory)" test saves you from that?

    As others have mentioned, using read/write on /dev/mem to get at
    memory-mapped registers is unlikely to work on ia64 anyway, because
    read/write use cacheable mappings. Using mmap does work (using
    uncacheable mappings), and my patch doesn't change that path.

    > >> On ia64, a read to non-existent physical memory causes the processor
    > >> to time out and take a machine check. I'm not sure it's even possible
    > >> to recover from that.
    > Andrew> ick. That would be very poor form.
    > Reasonable people can disagree on that. 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.

    It occurred to me over the weekend that part of this confusion is
    related to the fact that ia64 doesn't have page tables for the
    kernel identity-mapped segments. (We're talking about reading
    physical memory, but read/write_mem() actually convert the address
    using __va() before doing the copy.)

    I bet that ia32 does have page tables for this case, and that
    an attempt to read non-existent physical memory will cause a TLB
    miss from which copy_*_user() can easily recover.

    On ia64, the same TLB miss would occur, but since there are no page
    tables, the miss handler assumes the kernel knows what it is doing
    and happily synthesizes a mapping that points nowhere.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:58    [W:0.022 / U:44.976 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site