[Celinux-dev] Application XIP on Linux 2.6.17

[Alexey, Korolev]

Paulo,
Thanks a lot for giving us a very helpful information about appliication 
XIP.
I'm trying to fix it on Linux 2.6.17. I'll let you know if it will be done.

> On 9/1/06, Alexey, Korolev <alexey.korolev at intel.com> wrote:
> > Hi all,
> >
> > I need application XIP on Linux 2.6.17. But I faced some issues with
> > application XIP on Linux 2.6.17.
> > The problem is related to huge changes in Memory management code 
> between
> > 2.6.17 and 2.6.14.
> > I tried to tune patch for Linux 2.6.14
>
> http://tree.celinuxforum.org/CelfPubWiki/PatchArchive?action=AttachFile&do=get&target=cramfs-linear-xip-2.6.14.patch 
> <http://tree.celinuxforum.org/CelfPubWiki/PatchArchive?action=AttachFile&do=get&target=cramfs-linear-xip-2.6.14.patch> 
>
> >
> > but patch tuning didn't help. Linux still drops to kernel panic.
>
> You need first to understand VM changes by looking at mm/ git changelogs.
>
> > I wonder has somebody else faced the same issues with kernel newer than
> > 2.6.14?
> >
> > I'm a new person in memory managemnt code of Linux kernel. I would be
> > very much appreciate if somebody explain me why we need this code to
> > provide application XIP ?
>
> I've looked for updated patches but found none, and many sites say
> that current XIP support is just for kernel execution, but code says
> differently. My impression is that this change is not needed in the
> new kernel - any range mapped with remap_pfn_range will be
> auto-handled this way (and CRAMFS only maps so XIP pages). However,
> this code does not use the generic XIP code in 2.6.15+ (and maybe even
> before) kernels, and changing this may be a good idea.
>
> Then, what this code does? Suppose that the .data section of an
> executable from cramfs is mapped - it will be mapped
> PROT_READ|PROT_WRITE, MAP_PRIVATE, but the PTE will be read-only.
> Suppose that a variable is written in this page - a protection fault
> is generated and a new copy of the page must be allocated, so that the
> file is not altered (MAP_PRIVATE) and the write succeeds.
>
> However, it is possible that do_wp_page() when seeing that
> vm_normal_page fails will still correctly handle the fault by calling
> cow_user_page() - VM_PFNMAP should be set, but remap_pfn_range does
> it.
>
> Quite frankly, I'm surprised about the fact that EXT2 XIP support does
> not have such code - if application XIP is not supported then that's
> clearer, but comment are clear enough about it being supported
>
> Some pointers about the original implementation are here:
> http://lwn.net/Articles/135472/
> http://search.gmane.org/?query=execute+in+place+support&email=Carsten+Otte&group=gmane.linux.kernel&sort=relevance&DEFAULTOP=and&query= 
> <http://search.gmane.org/?query=execute+in+place+support&email=Carsten+Otte&group=gmane.linux.kernel&sort=relevance&DEFAULTOP=and&query=>
>
> So, this code should go (if needed) in do_wp_page I guess (if it is
> not there or in that code path I'm being mislead - I do not have
> 2.6.14 sources available right now) - currently the pfn_valid check
> after which this patch is inserted is in vm_normal_page which is used
> also elsewhere (IIRC) so the change must not go in vm_normal_page but
> must be done if vm_normal_page fails. As vm_normal_page comment and
> the below comment explain, vm_normal_page will fail because "the
> source memory is not RAM so no struct page is associated with it.
>
> Also note that the spinlocking has changed, the spinlock to use
> possibly depends on the pte (right now this is true on big SMP boxes
> IIRC). See pte_offset_map_lock and other such macros.
>