Messages in this thread | | | Subject | Re: [PATCH] arm64: reenable interrupt when handling ptrace breakpoint | From | "Shi, Yang" <> | Date | Fri, 5 Feb 2016 13:25:47 -0800 |
| |
On 1/13/2016 10:10 AM, Shi, Yang wrote: > On 1/13/2016 9:23 AM, Will Deacon wrote: >> On Wed, Jan 13, 2016 at 09:17:46AM -0800, Shi, Yang wrote: >>> On 1/13/2016 2:26 AM, Will Deacon wrote: >>>> On Tue, Jan 12, 2016 at 11:59:54AM -0800, Shi, Yang wrote: >>>>> This might be buried in email storm during the holiday. Just want >>>>> to double >>>>> check the status. I'm supposed there is no objection for getting it >>>>> merged >>>>> in upstream? >>>> >>>> Sorry, when you replied with: >>>> >>>>> I think we could just extend the "signal delay send" approach from >>>>> x86-64 >>>>> to arm64, which is currently used by x86-64 on -rt kernel only. >>>> >>>> I understood that you were going to fix -rt, so I dropped this pending >>>> anything more from you. >>>> >>>> What's the plan? >>> >>> Sorry for the confusion. The "signal delay send" approach used by >>> x86-64 -rt >>> should be not necessary for arm64 right now. Reenabling interrupt is >>> still >>> the preferred approach. >>> >>> Since x86-64 has per-CPU IST exception stack, so preemption has to be >>> disabled all the time. However, it is not applicable to other >>> architectures >>> for now, including arm64. >> >> Actually, we grew support for a separate IRQ stack in the recent merge >> window. Does that change things here, or are you referring to something >> else? > > Had a quick look at the patches, it looks the irq stack is not nestable > and it switches back to the original stack as long as irq handler is > done before preempt happens. So, it sounds it won't change things here.
Just had a quick test on 4.5-rc1. It survives with kgdbts, ptrace and ltp. So, it sounds safe with the "separate IRQ stack" change.
Thanks, Yang
> > Thanks., > Yang > >> >> Will >> >
| |