<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 17, 2020 at 10:12 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Aug 17, 2020 at 10:30 AM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Aug 17, 2020 at 9:24 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>><br>
>> On Mon, Aug 17, 2020 at 5:53 AM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Mon, Aug 17, 2020 at 11:32 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>> >><br>
>> >> On 16/08/2020 18:09, Utkarsh Rai wrote:<br>
>> >><br>
>> >> ><br>
>> >> ><br>
>> >> > On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a><br>
>> >> > <mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>> wrote:<br>
>> >> ><br>
>> >> > On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai<br>
>> >> > <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
>> >> > ><br>
>> >> > ><br>
>> >> > ><br>
>> >> > > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai<br>
>> >> > <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
>> >> > >><br>
>> >> > >><br>
>> >> > >><br>
>> >> > >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a><br>
>> >> > <mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>> wrote:<br>
>> >> > >>><br>
>> >> > >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai<br>
>> >> > <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
>> >> > >>> ><br>
>> >> > >>> ><br>
>> >> > >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai<br>
>> >> > <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
>> >> > >>> >><br>
>> >> > >>> >> Thanks, I'll check them out.<br>
>> >> > >>> >><br>
>> >> > >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom<br>
>> >> > <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a> <mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>> wrote:<br>
>> >> > >>> >>><br>
>> >> > >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai<br>
>> >> > <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
>> >> > >>> >>> ><br>
>> >> > >>> >>> > Hello,<br>
>> >> > >>> >>> > I have been testing my code for thread stack isolation<br>
>> >> > against various tests( Some written by me, and remaining already<br>
>> >> > present). One of the limitations that I have found is that I<br>
>> >> > encounter fatal errors whenever a context switch takes place<br>
>> >> > through an ISR. Can you please explain how the context switching<br>
>> >> > procedure works when an interrupt occurs. When I use gdb for<br>
>> >> > stepping through the code it asynchronously moves to context<br>
>> >> > switching code from the executing thread( for example psx16 test).<br>
>> >> > >>> >>> > For thread stack protection, the part that deals with<br>
>> >> > context switching simply 'sets 'the memory entries of the heir<br>
>> >> > stack and 'unsets' that of the executing stack.<br>
>> >> > >>> >>><br>
>> >> > >>> >>> There are two issues to start: interrupt stacks and<br>
>> >> > dispatching from an ISR.<br>
>> >> > >>> >>><br>
>> >> > >>> >>> I think you can start by reading some of the documentation:<br>
>> >> > >>> >>><br>
>> >> > <a href="https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt</a><br>
>> >> > >>> >>><br>
>> >> > >>> >>><br>
>> >> > <a href="https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks</a><br>
>> >> > >>> >>><br>
>> >> > >>> >>><br>
>> >> > <a href="https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size</a><br>
>> >> > >>> >>><br>
>> >> > >>> >>><br>
>> >> > <a href="https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing</a><br>
>> >> > >>> >>><br>
>> >> > >>> >>> You can also find some material in rtems-docs.git/porting<br>
>> >> > -- I don't<br>
>> >> > >>> >>> know where that gets generated.<br>
>> >> > >>> >>><br>
>> >> > >>> >>> Continue to ask questions, and writing blog posts.<br>
>> >> > >>> ><br>
>> >> > >>> ><br>
>> >> > >>> > So after going through the materials, I was able to<br>
>> >> > understand how an ISR is registered, ISR stack initialization.<br>
>> >> > What is still not clear to me is what are the differences between<br>
>> >> > dispatching a task in ISR different and a normal context-switch?<br>
>> >> > >>> ><br>
>> >> > >>> > For example the psxsignal06 test, we wait for a signal<br>
>> >> > here, on setting the breakpoint at the context switch code<br>
>> >> > (cpu_asm.S), after this line, I find that the heir context stack<br>
>> >> > is the ISR stack. The next thread is dispatched from this ISR but<br>
>> >> > as soon as I unset the memory attributes of the ISR stack I get a<br>
>> >> > fatal error. One possible reason is that the ISR stack is not page<br>
>> >> > aligned and unsettling its attributes unsets nearby memory<br>
>> >> > regions. Is there something else that I am missing?<br>
>> >> > >>> ><br>
>> >> > >>> what else is on the same page as the ISR stack?<br>
>> >> > >>><br>
>> >> > >><br>
>> >> > >> The idle thread stack is between 0x202e40 to 0x203e40 and the<br>
>> >> > ISR stack is between 0x203e40 to 0x204e40. So when we unset the<br>
>> >> > memory for the ISR it unsets between 0x203000 to 0x205000, I think<br>
>> >> > this may be the problem.<br>
>> >> > >><br>
>> >> > >><br>
>> >> > >>><br>
>> >> > >>> Not quite related, you'll need to also make sure to map the<br>
>> >> > ISR stack<br>
>> >> > >>> back in during ISR Handling, before using it.<br>
>> >> > >><br>
>> >> > >><br>
>> >> > >> When the ISR gets called for the first time, it already has R/W<br>
>> >> > permission and for subsequent context switches it's memory entry<br>
>> >> > is accordingly set/unset.<br>
>> >> > ><br>
>> >> > ><br>
>> >> > > The idle thread stack and the ISR stack are placed at these<br>
>> >> > addresses with the BSP specific linker script as "rtemsstack.idle"<br>
>> >> > and "rtemsstack.interrupt". So to make them page-aligned we may<br>
>> >> > have to make changes in the lnker script.<br>
>> >> ><br>
>> >> > Give it a try. It should be relatively easy to hack in a couple of<br>
>> >> > alignments.<br>
>> >> ><br>
>> >> > We can discuss later the correctness of that.<br>
>> >> ><br>
>> >> > Ok, I will report how it goes.<br>
>> >><br>
>> >> Please use the CPU port option<br>
>> >><br>
>> >> #define CPU_INTERRUPT_STACK_ALIGNMENT CPU_CACHE_LINE_BYTES<br>
>> >><br>
>> >> to define the interrupt and idle stack alignment. There is no need to<br>
>> >> change the linker command file.<br>
>> ><br>
>> ><br>
>> > Thank you, this solves the issue.<br>
>> ><br>
>> > I have used,<br>
>> > #define CPU_INTERRUPT_STACK_ALIGNMENT 4096, in the application code as well as cpu.h, to align for 4K pages.<br>
>><br>
>> Great. Now, a question: can the Idle Task and Interrupt Stack share<br>
>> the same 4K page?<br>
><br>
><br>
> I am not sure whether you mean if they should have the same address or if they have overlapping addresses ( For example if the idle thread stack is at 0x202e40 and interrupt stack is at 0x204e40 then they should have the 0x20300-0x20400 address as common)?<br>
<br>
All this page-alignment stuff might be wasting a lot of space for<br>
stacks that are smaller than 4K size. So, could you allocate them both<br>
in the same 4K region?<br></blockquote><div><br></div><div>The stacks are placed at different addresses using the linker script by " *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.rtemsstack*))) " and each of them have 4k sizes by default. This means that we have to have the same addresses for both the ISR and the idle stacks if we want them in the same 4K region. </div><div>Also, we have a minimum stack size as 4K by default, so at max, we would be wasting a single page.</div></div></div>