Re: Mapping an executable page

[Thomas De Schampheleire <patrickdepinguin+linuxppc@gmail.com>]

On Tue, Jun 14, 2011 at 10:07 PM, Timur Tabi <timur@freescale.com> wrote:
> Timur Tabi wrote:
>> Hmmm.... I find that surprising. =A0Memory allocated via ioremap() is su=
pposed to
>> be available in interrupt handlers, where TLB mappings can't be created
>> on-the-fly. =A0I'm not sure that your observation is correct.
>
> Ok, it turns out I'm wrong. =A0As long as the page is in the page tables =
(i.e.
> physically present in RAM), you can take a TLB miss in an interrupt handl=
er, and
> the TLB miss handler will create a TLB for you.
>
> This means that ...
>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long dummy =3D =
*(volatile unsigned long *)p;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)dummy;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>>
>> * After these changes (make sure all code is mapped + make sure to
>> read all pages so that the TLBs are updated), my scenario works fine.
>
> is not going to work reliably, because it assumes that the TLBs created b=
y your
> multiple ioremap() calls will still be there when your code is called.
>
> If you use just a single ioremap() call, but still touch every page, that=
 should
> work for you just as well.

I am using a single __ioremap call.
You have a point about the reliability of this: if an interrupt occurs
between the mapping or dummy reading, and the point where the actual
code is executing, some TLB entries may have been replaced, right?
I think I can make it more reliable by dummy reading the pages *after*
I disabled interrupts on that processor, immediately before jumping to
the boot code. Is that correct?
(note that I have to disable interrupts anyhow for the boot code to
work properly without interruptions to 'linux land'.

Thanks for your input,
Thomas