From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751049AbdHAESr (ORCPT ); Tue, 1 Aug 2017 00:18:47 -0400 Received: from mail-pf0-f174.google.com ([209.85.192.174]:36089 "EHLO mail-pf0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750752AbdHAESp (ORCPT ); Tue, 1 Aug 2017 00:18:45 -0400 Subject: Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception To: James Morse Cc: mark.rutland@arm.com, Alexander Shishkin , will.deacon@arm.com, linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , takahiro.akashi@linaro.org, Peter Zijlstra , Ingo Molnar , huawei.libin@huawei.com, linux-arm-kernel@lists.infradead.org References: <597F65BD.3070200@arm.com> From: Pratyush Anand Message-ID: Date: Tue, 1 Aug 2017 09:48:40 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <597F65BD.3070200@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi James, On Monday 31 July 2017 10:45 PM, James Morse wrote: > Hi Pratyush, > > On 31/07/17 11:40, Pratyush Anand wrote: >> samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with >> ARM64. Even though it has been NAKed previously on upstream [1, 2], I have >> tried to come up with patches which can resolve it for ARM64 as well. >> >> I noticed that even perf step exception can go into an infinite loop if CPU >> receives an interrupt while executing breakpoint/watchpoint handler. So, >> event though we are not concerned about above test, we will have to find a >> solution for the perf issue. > > This caught my eye as I've been reworking the order the DAIF flags get > set/cleared[0]. Thanks for pointing to your series. > > What causes your infinite loop? Is it single-stepping kernel_exit? If so patch 4 > "arm64: entry.S mask all exceptions during kernel_exit" [1] may help. Flow is like this: - A SW or HW breakpoint exception is being generated on a cpu lets say CPU5 - Breakpoint handler does something which causes an interrupt to be active on the same CPU. In fact there might be many other reasons for an interrupt to be active on a CPU while breakpoint handler was being executed. - So, as soon as we return from breakpoint exception, we go to the IRQ exception handler, while we were expecting a single step exception. I do not think that your patch 4 will help here. That patch disables interrupt while kernel_exit will execute.So,until we enable PSR I bit, we can not stop an interrupt to be generated before step exception. You can easily reproduce the issue with following: # insmod data_breakpoint.ko ksym=__sysrq_enabled # cat /proc/sys/kernel/sysrq Where data_breakpoint.ko is module from samples/hw_breakpoint/data_breakpoint.c. > > If its more like "single stepping something we didn't expect" you will get the > same problem if we take an SError. (which with that series is unmasked ~all the > time). > Either way this looks like a new and exciting way of hitting the 'known issue' > described in patch 12 [3]. > > > Would disabling MDSCR_EL1.SS if we took an exception solve your problem? > > If so, I think we should add a new flag, 'TIF_KSINGLESTEP', causing us to > save/restore MDSCR_EL1.SS into pt_regs on el1 exceptions. This would let us > single-step without modifying the DAIF flags for the location we are stepping, > and allow taking any kind of exception from that location. > > We should disable nested users of single-step, we can do that by testing the > flag, print a warning then pretend we missed the breakpoint. (hence it needs to > be separate from the user single-step flag). > > > Thanks, > > James > > [0] https://www.spinics.net/lists/arm-kernel/msg596684.html > [1] https://www.spinics.net/lists/arm-kernel/msg596686.html > [2] https://www.spinics.net/lists/arm-kernel/msg596689.html > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Regards Pratyush