Re: [PATCH] Fix mmap kmem (was: [question] What's the difference between /dev/kmem and /dev/mem)

[Nicolas George <nicolas.george@ens.fr>]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

Le quintidi 25 thermidor, an CCXIII, Linus Torvalds a écrit :
> We do need to support /dev/mem for X, but even that might go away some 
> day. 

If I may interfere, I would like to point another use of /dev/mem:
long-running memory tests that do not alter the service much. I have written
a small package which does such tests. The principle is to write
pseudo-random data in a page, and later read it back and compare it to what
it should be. For such a test, /dev/mem can be used two ways:

- to access memory pages that have been disabled by mem=/memmap= command
  lines arguments;

- to look for the physical address of an userland-allocated and mlock()ed
  page (by writing a known pattern in it).

(Well, I am not even sure that the physical address of a mlock()ed page can
not change.)

With the increasing cheapness but lack of reliability of noname RAM, such
tests become very useful for home and even professional usage. I could
easyly imagine a fully automated distribution that would enable such a test
tool for a month after the first installation, for example.

It can be noted that those tests do not require the full features of
/dev/mem, and especially not the security threatening ones. It would be
sufficient to have some sort of API to:

- map a particular physical page of memory in a process' address space,
  optionnally reallocating a previous usage of that page, and failing if it
  can not be done;

- ask the physical address of a maped page.

The second can be done with /proc/kcore, but it depends on internal
structures of the kernel. I believe it could easily be done with a
/proc/$PID/maps-like file.

The first could be implemented as a flag to mmap (maybe MAP_PHYSICAL) which
would cause the addr argument to be the physical address of the requested
page.

It may seem a lot of trouble for some very specific need, but I have
remarked that bad memory bits are an increasing problem, and ECC memory and
motherboards supporting it are not easy to find for non high-grade
professional hardware. A well-integrated software workaround would be really
useful I believe.

Regads,

-- 
  Nicolas George

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 185 bytes --]