RE: pagetables used in interrupt context

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi Subin:
 
     i am not familiar with other architecture, but for ARM, Linux Kernel 2.6.35, i checked the function handle_level_irq()and handle_edge_irq() in chip.c, both of them will call handle_IRQ_event() which is in handle.c. and the function handle_IRQ_event() will call the interrupt handler written by user. Kernel does not open interrupt(ARM CPSR I bit)when calling interrupt handler in handle_IRQ_event() function. this is only for top-half interrupt handling.  for bottom-half, it is no doubt that the interrupt will be opened.
 
     so if you register a interrupt by request_irq(), the interrupt handler will be called with irq disabled. i tested on Cortex-A9 dual core platform, it is right.
 

 
> Date: Thu, 23 Feb 2012 11:12:06 -0600
> Subject: Re: pagetables used in interrupt context
> From: subingangadharan@xxxxxxxxx
> To: buyit@xxxxxxx
> CC: c.a.subramaniam@xxxxxxxxx; dhylands@xxxxxxxxx; kernelnewbies@xxxxxxxxxxxxxxxxx
>
> Hi ,
>
> > can support nest interrupt if it wants(2.6.35 does not support this). and it
> > is very simple to use the interrupted thread's kernel mode stack as the
> > interrupt context. if kernel use a specific stack which is for interrupt
>
> Thanks for the crystal clear explanation of the page table usage in
> interrupt context. I have one more doubt, so in 2.6.35 as you said it
> doesn't support
> nested interrupt, does it mean that all other interrupts are
> completely disabled, (I mean no other can interrupt the processor)
> while executing an interrupt handler.
>
>
>
> 2012/2/23 卜弋天 <buyit@xxxxxxx>:
> > Hi :
> >
> > for ARM architecture, from the point of my view, interrupt can be
> > handled in IRQ, SVC, or SYSTEM modes.
> > 1.if kernel handles interrupt in IRQ mode, it can use separate specific
> > stack of IRQ mode to handle interrupt,but it cannot support nest interupt,
> > suppose you are running interrupt handler in IRQ mode, a new coming
> > interrupt will corrupt the lr_irq which is used for current function.
> > 2. if kernel handles interrupt in SYSTEM mode, the sequences will be :
> > hardware interrupt occurs-->IRQ mode-->SYSTEM mode -->call
> > interrupt handler.
> > kernel can support nest interrupt well by this way, the problem is
> > SYSTEM mode use the same register with USER mode, which means kernel will
> > use the interrupted thread's user mode stack, this will leake information
> > of kernel to user space, so it is not a good ide a, although i did this for
> > many years for OMAP chipset(the OS is not linux, it is mixed by REX and my
> > own design.).
> > 3. Linux kernel choose the last one, handle interrupt in SVC mode, which
> > can support nest interrupt if it wants(2.6.35 does not support this). and it
> > is very simple to use the interrupted thread's kernel mode stack as the
> > interrupt context. if kernel use a specific stack which is for interrupt
> > only, the sequences will be : hardware interrupt occurs-->IRQ mode-->SVC
> > mode-->backup sp register of interrupted thread to it's TCB--->set sp
> > register to be the specific kernel stack address-->call interrupt
> > handler--->restore sp of interrupted thread--->return from interrupt.
> > this is a little complicated compared with the current design. so i
> > agree with the current design.
> >
> >
> > Best Regards
> >
> >> Date: Thu, 23 Feb 2012 08:41:28 -0600
> >
> >> Subject: Re: pagetables used in interrupt context
> >> From: c.a.subramaniam@xxxxxxxxx
> >> To: buyit@xxxxxxx
> >> CC: dhylands@xxxxxxxxx; subingangadharan@xxxxxxxxx;
> >> kernelnewbies@xxxxxxxxxxxxxxxxx
> >
> >>
> >> On Thu, Feb 23, 2012 at 6:52 AM, 卜弋天 <buyit@xxxxxxx> wrote:
> >> > Hi Subin:
> >> >
> >> > for kernel version 2.6.35, ARM architecture, when interrupt occurs,
> >> > kernel will change from USER/SVC mode to IRQ mode,backup some registers
> >> > and
> >> > change to SVC mode immediately, handle the real interrupt handler in SVC
> >> > mode, which people say in interrupt context.
> >> > kernel will use the stack(interrupt context) of interrupted thread to
> >> > handle the interrupt, a nd there is no MMU operation which do page table
> >> > switch.
> >> > so the thread which is interrupted by interrupt, it's kernel mode stack
> >> > will be choosed as the interrupt context of current interrupt.
> >> >
> >> Thanks ! thats a terse explanation! Can you please mention why we do
> >> not have a IRQ stack (in terms of size of the stack) to do the
> >> processing?
> >> >
> >> >> Date: Tue, 21 Feb 2012 19:18:32 -0700
> >> >> Subject: Re: pagetables used in interrupt context
> >> >> From: subingangadharan@xxxxxxxxx
> >> >> To: dhylands@xxxxxxxxx
> >> >> CC: kernelnewbies@xxxxxxxxxxxxxxxxx
> >> >
> >> >>
> >> >> Thank you for clearing my doubt.
> >> >>
> >> >> On Mon, Feb 20, 2012 at 8:39 PM, Dave Hylands <dhylands@xxxxxxxxx>
> >> >> wrote:
> >> >> > Hi Subin,
> >> >> >
> >> >> > On Mon, Feb 20, 2012 at 6:47 PM, subin gangadharan
> >> >> > <subingangadharan@xxxxxxxxx> wrote:
> >> >> >> Hi All,
> >> >> >>
> >> >> >> Please correct me if I am wrong. In linux each process will have its
> >> >> >> own page tables, so when a interrupt happens processor will switch
> >> >> >> to
> >> >> >> interrupt context
> >> >> >> and execute the proper handler. So my doubt, if this is the case,
> >> >> >> interrupt hanlder will be using the pagetables of the interrupted
> >> >> >> process or is there a separate page table for this.
> >> >> >
> >> >> > Yep - that's right. Co nceptually you can imagine that the kernel page
> >> >> > tables are replicated in each process, so when the interrupt occurs,
> >> >> > the kernel mappings will always be in effect regardless of which task
> >> >> > is running. How this is actually achieved may vary from architecture
> >> >> > to architecture.
> >> >> >
> >> >> > --
> >> >> > Dave Hylands
> >> >> > Shuswap, BC, Canada
> >> >> > http://www.davehylands.com
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> With Regards
> >> >> Subin Gangadharan
> >> >>
> >> >> I am not afraid and I am also not afraid of being afraid.
> >> >>
> >> >> _______________________________________________
> >> >> Kernelnewbies mailing list
> >> >> Kernelnewbies@xxxxxxxxxxxxxxxxx
> >> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >> >
> >> > _______________________________________________
> >> > Kernelnewbies mailing list
> >> > Kernelnewbies@xxxxxxxxxxxxxxxxx
> >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >> >
> >>
> >> _______________________________________________
> >> Kernelnewbies mailing list
> >> Kernelnewbies@xxxxxxxxxxxxxxxxx
> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> --
> With Regards
> Subin Gangadharan
>
> I am not afraid and I am also not afraid of being afraid.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Networking]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

Add to Google Powered by Linux