Bug 82837 - /dev/mem mlock physical virtual memory program error
/dev/mem mlock physical virtual memory program error
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
high Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-27 11:36 EST by Stefano Righi
Modified: 2007-03-27 00:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
testcase (1.07 KB, text/plain)
2003-01-28 10:32 EST, Stefano Righi
no flags Details
result of the run on FreeBSD (2.20 KB, text/plain)
2003-01-29 14:00 EST, Stefano Righi
no flags Details
Results of the run on Linux (1.75 KB, text/plain)
2003-01-29 14:01 EST, Stefano Righi
no flags Details

  None (edit)
Description Stefano Righi 2003-01-27 11:36:22 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)

Description of problem:
I have created an utility for updating AMIBIOS. It works on all system tested 
till now except with Red Hat 8.0 2.4.18-14smp with 1GB of memory or more.
The root cause is the folowing:
The program allocate memory using calloc and call mlock to avoid swapping (I 
want to be sure that what the program has written stay in physical memory).
Then I read through /dev/mem scanning all memory location to search for the 
pattern written in the calloc'ed and mlock'ed. (I use read because with mmap I 
cannot access memory above 256MB).
In all other test cases I find the pattern, in the above test case I do not 
find the pattern.
This cause my application to NOT work.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. have 1GB of memory installed in the system or more
2. use kernel 2.4.18.14-smp
3. run my test application with debug printf on the screen

Actual Results:  My program do not read the right information through /dev/mem

Expected Results:  My program should read expected information from /dev/mem

Additional info:
Comment 1 Arjan van de Ven 2003-01-27 11:42:39 EST
What is the purpose of the /dev/mem sweep?
Please be aware that mlock() is no guarantee that the physical address of a page
doesn't change, just that it doesn't get swapped out
Also memory can be in the > 4Gb area if a machine has > 4Gb ram... 
Comment 2 Stefano Righi 2003-01-27 11:56:35 EST
The reason of the sweep is to find the physical address where the buffer is 
allocated.
It is weird that with less memory I can find it and not with more memory: it is 
stated that it is not guaranteed to stay in same location but I would expect 
the location to change more easily in case of less memory, instead it is 
happening with more memory...
What is the "best practice" way to obtain a buffer in a locked physical 
location? I cannot use a driver because I cannot rebuild the utility for every 
different distribution...
Now documentation mention that the reason of mlock is for "Real-time 
applications require deterministic timing, and, like scheduling, paging is one 
major cause of unexpected program execution delays". Now if the physical 
location changes this requisite for mlock is NOT satisfied: also moving among 
different memory location cause non-deterministic timing...
I really think that the problem is not that the information is moved in memory 
but one of the two:
- the locking does not work and the info is paged out
- through /dev/mem I cannot access the entire physical memory
I think more at the second case because when I read /dev/mem I can read only up 
to 0x38000000 in a 1GB system: this mean I am unable to read the last 128MB.
By the way I have tryed also with shared object without any meaningful change 
and with mmap, but in this case I can access only the first 256MB of memory.
Comment 3 Arjan van de Ven 2003-01-27 12:00:02 EST
you are correct that the moving thing is not the cause of the problem you see:
the fact that /dev/mem only gives back kernel memory and not high memory is. I
just wanted to point out that it was likely that for what you tried to solve
/dev/mem might be the wrong interface.
It sounds like you actually want a kernel driver. If the driver is GPL I'm sure
Red Hat and all other distros would be more than happy to include it by default....
Comment 4 Stefano Righi 2003-01-27 12:06:57 EST
Again,
I do NOT want to write a driver for this. 
You state that /dev/mem is not the right interface but accordign to the 
documentation it is the "physical memory". Does it means that the documentation 
is wrong?
I have tryed also /proc/kcore with same results.
What is the "right" interface according to Red Hat? Please do not answer a 
driver, for the official documentation this is not needed.
Don't you think it is a but of /dev/mem? Which means we need a patch?
Comment 5 Stefano Righi 2003-01-27 14:54:24 EST
Just a quick note. Before I stated something regarding usage of mmap that is 
not correct. Using mmap I do not get any error from mmap on all the 4GB address 
space: a pointer is always returned, but this does not mean I find the 
information I need to find in memory... I am still thinking to some kernel 
problem...
Comment 6 Stefano Righi 2003-01-28 10:32:30 EST
Created attachment 89647 [details]
testcase

OK, here is a quick test. This code in FreeBSD always report the same value
from read and the value obtained using the pointer returned by mmap, while in
Linux the result is very odd.
Do you have an explanation for it?
Comment 7 Stefano Righi 2003-01-29 14:00:30 EST
Created attachment 89687 [details]
result of the run on FreeBSD
Comment 8 Stefano Righi 2003-01-29 14:01:22 EST
Created attachment 89688 [details]
Results of the run on Linux
Comment 9 Bugzilla owner 2004-09-30 11:40:28 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.