Bug 82837
| Summary: | /dev/mem mlock physical virtual memory program error | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Stefano Righi <stefanor> | ||||||||
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 8.0 | CC: | andrewm, mitr, stefanor | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i686 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2004-09-30 15:40:28 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Stefano Righi
2003-01-27 16:36:22 UTC
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... 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. 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.... 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? 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... 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?
Created attachment 89687 [details]
result of the run on FreeBSD
Created attachment 89688 [details]
Results of the run on Linux
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/ |