From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751330AbdIMGFB (ORCPT ); Wed, 13 Sep 2017 02:05:01 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:33964 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751019AbdIMGFA (ORCPT ); Wed, 13 Sep 2017 02:05:00 -0400 X-Google-Smtp-Source: ADKCNb70dBz/WJvex3/u7Tp0IdNqxu3XY5h8s0A+3dRqT/obcz6itQUBmEjiK3yrSxdTXBCWno0lKQ== Subject: Re: Re: [PATCH] sysrq : fix Show Regs call trace on ARM To: Jibin Xu , gregkh@linuxfoundation.org Cc: rmk+kernel@armlinux.org.uk, mingo@elte.hu, linux-arm-kernel@lists.infradead.org, riel@redhat.com, linux-kernel@vger.kernel.org References: <20170911031142.254308-1-jibin.xu@windriver.com> <8c09c309-e088-1dd6-8d6f-f8929acf0f5f@suse.cz> <5dd5bb30-15af-ab44-8b56-57c3c1d53bc4@windriver.com> <17da8267-c4aa-dc0f-1150-4fd5efe0073c@windriver.com> From: Jiri Slaby Message-ID: Date: Wed, 13 Sep 2017 08:04:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <17da8267-c4aa-dc0f-1150-4fd5efe0073c@windriver.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/11/2017, 01:22 PM, Jibin Xu wrote: > Hi,Jiri: > > I tested get_irq_regs() behave in the softirq context, > I called get_irq_regs() by a tasklet, It returns NULL.My understanding is get_irq_regs() can return the right result > only in hardware IRQ,otherwise it returns ＮＵＬL. > So I think in_irq() would be better. Hi, tasklets are run in the process context (in a kthread). But what about timers? HARDIRQ is decremented, SOFTIRQ remains set and sysrq handlers are called in such conditions (in_interrupt() is true, in_irq() is false). At that moment, irq_regs are still set and valid IMO. But I would believe for now that sysrq handlers are not invoked from softirq context. AFAIK they are called only from hardirq (serial port or keyboard IRQ handler) or process context (write to /proc/sysrq-trigger). So this change *should* be safe unless someone else objects there are some kgdb special cases or something. > thanks, > Jibin Xu > > On 2017年09月11日 17:55, Jibin Xu wrote: > >> Hi,Jiri: >> get_irq_regs() in the softirq context return NULL. >> thanks, >> Jibin Xu >> On 2017年09月11日 13:24, Jiri Slaby wrote: >>> On 09/11/2017, 05:11 AM, Jibin Xu wrote: >>> ... >>>> --- a/drivers/tty/sysrq.c >>>> +++ b/drivers/tty/sysrq.c >>>> @@ -245,8 +245,10 @@ static void sysrq_handle_showallcpus(int key) >>>>        * architecture has no support for it: >>>>        */ >>>>       if (!trigger_all_cpu_backtrace()) { >>>> -        struct pt_regs *regs = get_irq_regs(); >>>> +        struct pt_regs *regs = NULL; >>>>   >>>> +        if (in_irq()) >>>> +            regs = get_irq_regs(); >>> Maybe a stupid question: how does get_irq_regs() behave in the softirq >>> context? I.e. what about s/in_irq/in_interrupt/? >>> thanks, >> > -- js suse labs