A boot parameter has been added: strict-devmem=0 will disable it now.

Chuck: perfect, thanks!
By the way -- anyone knows why doesn't crash use /proc/kcore?

Just curious -- why was the crash driver module dropped?

* Thu Mar 12 2009 Dave Jones <davej>
- Drop no longer needed 'crash' driver.

The strict-devmem parameter is a nice solution, although even with it in place,
/dev/mem will still not allow x86 32-bit memory accesses above highmem.  So
module memory access, user memory access, PTEs, etc., anything that's not
GFP_KERNEL will not be accessible.

> By the way -- anyone knows why doesn't crash use /proc/kcore? 

Couple reasons, one being that /proc/kcore doesn't exist in RHEL.

But even if it did, it's a kernel virtual memory accessor, whereas crash
translates all memory accesses to physical addresses prior to reading them
from whatever the memory-access handler is, i.e., live memory or the plethora
of dumpfile formats it supports.

I was under the mistaken impression that crash would work on /dev/mem
I was unaware of the 32bit limitations. How much work would it be to make /dev/mem use kmaps ?
(Essentially folding bits of /dev/crash into /dev/mem).

I'm not opposed to adding back the crash driver, but I'd like some sort of plan where we can get it upstream, so we don't have to carry it forever.

(In reply to comment #4)
> I was under the mistaken impression that crash would work on /dev/mem
> I was unaware of the 32bit limitations. How much work would it be to make
> /dev/mem use kmaps ?
> (Essentially folding bits of /dev/crash into /dev/mem).

Crash on x86 with /dev/mem will at least come up to its prompt, and as long
as only lowmem addresses are required, most crash commands will work OK.
But if the system has more than 896MB, then in all probability the highmem
memory will have been used for kernel modules, PTE contents, and user-space.
That being the case, kernel module debugging will be unavailable, and
less importantly, user-space access won't be available.  There are other
things that won't work, but I can't remember them off-hand.

Anyway, there's a couple gotcha's upstream.

The first thing /dev/mem's read_mem() function does is:

  static ssize_t read_mem(struct file * file, char __user * buf,
                        size_t count, loff_t *ppos)
  {
          unsigned long p = *ppos;
          ssize_t read, sz;
          char *ptr;

          if (!valid_phys_addr_range(p, count))
                  return -EFAULT;

which has the high_memory restriction:

  #ifndef ARCH_HAS_VALID_PHYS_ADDR_RANGE
  static inline int valid_phys_addr_range(unsigned long addr, size_t count)  
  {
          if (addr + count > __pa(high_memory))
                  return 0;

          return 1;
  }

And that restriction would also be affected by systems with more than
4GB of physical memory -- note that the "p" assignment is an unsigned
long, so it would clip off the upper 32 bits from "loff_t *ppos".

And then the unsigned long "p" is used in a few other places further on in read_mem(), so dealing with that could get ugly...

Secondly, the physical page mapping/copying is done like so:

                ptr = xlate_dev_mem_ptr(p);
                if (!ptr)
                        return -EFAULT;

                if (copy_to_user(buf, ptr, sz)) {
                        unxlate_dev_mem_ptr(p, ptr);
                        return -EFAULT;
                }

                unxlate_dev_mem_ptr(p, ptr);

where xlate_dev_mem_ptr() for x86 only works for lowmem physical addrs:

  #define xlate_dev_mem_ptr(p)    __va(p)

and unxlate_dev_mem_ptr() also has to deal with non-RAM addresses:

  void unxlate_dev_mem_ptr(unsigned long phys, void *addr)
  {
          if (page_is_ram(phys >> PAGE_SHIFT))
                  return;

          iounmap((void __iomem *)((unsigned long)addr & PAGE_MASK));
          return;
  }

> I'm not opposed to adding back the crash driver, but I'd like some sort of
> plan where we can get it upstream, so we don't have to carry it forever.  

So to be honest, for the remainder of the x86 life-form, it's probably
easier to carry forward the crash driver for x86.

Bernhard Walle tried to get a patch similar in nature to the "strict-devmem"
concept upstream a few months ago, but got nowhere.

re-added the crash driver.