How Kernel stack is used in case of different processor mode in ARM architecture?
Arun KS
getarunks at gmail.com
Tue Mar 25 07:15:45 EDT 2014
On Tue, Mar 25, 2014 at 4:40 PM, Arun KS <getarunks at gmail.com> wrote:
> Hello Rahul,
>
> On Tue, Mar 25, 2014 at 4:10 PM, Rahul Garg <rahul.lnmiit at gmail.com> wrote:
>> Hi Arun,
>>
>> Lines from Robert Love :
>>
>> Early in the 2.6 kernel process, an option was added to reduce the
>> stack size from two
>> pages down to one, providing only a 4KB stack on 32-bit systems.This
>> reduced memory
>> pressure because every process on the system previously needed two
>> pages of contiguous,
>> nonswappable kernel memory.To cope with the reduced stack size,
>> interrupt handlers
>> were given their own stack, one stack per processor, one page in
>> size.This stack is referred
>> to as the interrupt stack.Although the total size of the interrupt
>> stack is half that of the
>> original shared stack, the average stack space available is greater
>> because interrupt handlers
>> get the full page of memory to themselves.
>
> Kernel stack size is architecture dependent. Some architecture uses
> CONFIG_4KSTACKS to choose 4K stacks.
>
> Where as in arm, it is always 8KB.
>
> File:arch/arm/include/asm/thread_info.h
> #define THREAD_SIZE_ORDER 1
> #define THREAD_SIZE 8192
> #define THREAD_START_SP (THREAD_SIZE - 8)
>
>>
>>
>> So with these lines, it is clear that interrupt stack is used by
>> interrupt handlers. So can you please re-confirm your answer ?
> On ARM when there is an irq, the processor switches to irq mode. But
> the kernel switches to svc mode immediately and uses SVC stack, ie the
> stack of the current process.
>
> Why do you believe my be? :-)
> If you want re-confirmation, go through arch/arm/kernel/entry-armv.S
>
> Thanks,
> Arun
>>
>> And one more thing, as you mentioned only interrupt, undefined and
>> abort have stack, So how nested interrupt is handled because for that
>> we need System mode stack ?
Interrupts are no more nested in linux kernel,
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/irq/handle.c?id=e58aa3d2d0cc01ad8d6f7f640a0670433f794922
But nested exceptions(data, prefetch aborts etc) can still happen.
And, what made you believe we need system mode to support nesting?
What difference does it make if it is svc mode?
Thanks,
Arun
> ARM linux never use system mode for anything.
>
>>
>> Regards
>> Rahul
>>
>> On Tue, Mar 25, 2014 at 3:06 PM, Arun KS <getarunks at gmail.com> wrote:
>>> On Tue, Mar 25, 2014 at 2:58 PM, Arun KS <getarunks at gmail.com> wrote:
>>>> Hello Rahul,
>>>>
>>>> On Tue, Mar 25, 2014 at 6:29 AM, Rahul Garg <rahul.lnmiit at gmail.com> wrote:
>>>>> As I understand every process have a user stack and kernel stack.
>>>> True.
>>>>
>>>>> Apart from that there is a stack for every mode in ARM achitecture. So
>>>> This is wrong.
>>>> Only irq, abort and undefined modes have stacks in linux. That too is
>>>> very limited, 3 bytes per mode per cpu.
>>>> Have a look at arch/arm/kernel/irq.c
>>> Sorry. Wrong file, its at arch/arm/kernel/setup.c
>>>
>>> Thanks,
>>> Arun
>>>> struct stack {
>>>> u32 irq[3];
>>>> u32 abt[3];
>>>> u32 und[3];
>>>> } ____cacheline_aligned;
>>>>
>>>> kernel runs in SVC mode and the stack used belong to the kernel stack
>>>> of the current task.
>>>> Even irq, abort and undefined exception handlers use kernel stack of
>>>> current task. All the exception
>>>> handlers switch to SVC mode at a very early stage and use kernel
>>>> stack. Those 3 bytes are used
>>>> as stack just during the transition phase(for example transition from
>>>> irq to svc mode during and interrupt).
>>>>
>>>> Thanks,
>>>> Arun
>>>>> I want to know How different stack and stack pointer works in ARM
>>>>> modes? Also when this kernel stack associated with the process will be
>>>>> used ?
>>>>>
>>>>> _______________________________________________
>>>>> Kernelnewbies mailing list
>>>>> Kernelnewbies at kernelnewbies.org
>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
More information about the Kernelnewbies
mailing list