Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC PATCH 0/3] Enable kprobe to monitor sdei event handler
To:     Xiongfeng Wang <wangxiongfeng2@huawei.com>
Cc:     huawei.libin@huawei.com, catalin.marinas@arm.com,
        will.deacon@arm.com, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org
References: <1555070699-3685-1-git-send-email-wangxiongfeng2@huawei.com>
From:   James Morse <james.morse@arm.com>
Message-ID: <d197785a-9e3b-2c88-d882-b59075a38264@arm.com>
Date:   Wed, 24 Apr 2019 17:20:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <1555070699-3685-1-git-send-email-wangxiongfeng2@huawei.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Xiongfeng Wang,

On 12/04/2019 13:04, Xiongfeng Wang wrote:
> When I use kprobe to monitor a sdei event handler,

Don't do this! SDEI is like an NMI, it isn't safe to kprobe it as it can interrupt the
kprobe code, causing it become re-entrant.


> the CPU will hang. It's
> because when I probe the event handler, the instruction will be replaced with 
> brk instruction and brk exception is unmaskable. But 'vbar_el1' contains 
> 'tramp_vectors' in '_sdei_handler' when SDEI events interrupt userspace, so
> we will go to the wrong place if brk exception happens.

This was lucky! Its even more fun if the SDEI event interrupted a guest: the kvm vectors
will give you a hyp-panic.

The __kprobes and NOKPROBE_SYMBOL() litter should stop you doing this.


> I notice that 'ghes_sdei_normal_callback' call several funtions that are not
> marked as 'nokprobe'.

Bother. We should probably blacklist those too, its not safe.


> So I was wondering if we can enable kprobe in '_sdei_handler'.

I don't think this can be done safely.


If you need to monitor your SDEI event handler you can just use printk(). Once nmi_enter()
has been called these are safe as they stash data in a per-cpu buffer. The SDEI handler
will exit via the IRQ vector if it can, which will cause this buffer to be flushed to the
console in a timely manner.


Why do you need to kprobe an NMI handler?


Thanks!

James