OpenVZ Forum

Home » Mailing lists » Devel » Question: remap_pfn_range changes in 2.6.2x
Question: remap_pfn_range changes in 2.6.2x [message #28916] Tue, 01 April 2008 08:46
arusev is currently offline  arusev
Messages: 1
Registered: April 2008
Location: The planet Earth, Solar s...
Junior Member
The current kernel code for remap_pfn_range now includes the check of
vm_area size vs. mapped physical page area.

In earlier versions when vm_area size was more than
pfn-s to map to, the rest of vm_area was attached to on-demand page
allocation/COW so the userspace which mapped more just obtained a piece
of "shared memory" anonymous pages.

What is the reason behind that strict check now included in

How to implement the feature again?

I need to map a few pages to physical PFN-s and the rest of
to ZERO_PAGE where userland may do what it whishes.

Which functions should I use in my filesystem driver to achieve the same

This is an issue for mmaping shared library objects by
at XIP-ed FLASH filesystems.

When shared library marked with "chmod +t" is loaded, the LD-linker
tries to mmap more than it's size due to get some extra place for
dynamic relocations and other housekeeping.

(I'm looking into 2.6.24 mainstream tree)

int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t prot)
 if (is_cow_mapping(vma->vm_flags)) {
        if (addr != vma->vm_start || end != vma->vm_end){
            return -EINVAL;
        vma->vm_pgoff = pfn;


Could anybody give me a hint how this problem should to be dealt?
Previous Topic: [PATCH net-2.6.26 6/6][IPV6][NETNS]: Display per-net info in sockstat6 file.
Next Topic: [PATCH -mm 0/3] cgroup: use hash table for css_set
Goto Forum:

Current Time: Mon Jun 17 21:25:50 GMT 2024

Total time taken to generate the page: 0.03709 seconds