Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp636140ybg; Wed, 10 Jun 2020 09:40:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZF3/6sp1Q7ldaGb012JkjLhH/1VOA4azu57kzaU2RlNNgWgy2KoS/tdnsc2SapDZGSCUH X-Received: by 2002:aa7:d98e:: with SMTP id u14mr3287804eds.247.1591807238130; Wed, 10 Jun 2020 09:40:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591807238; cv=none; d=google.com; s=arc-20160816; b=txDh8tX2zacfWikTCxF8TOn1P7SNgxIEmrKcrDJLX+My18pKnnhi53tt/J8kT3QbQP 08MBoYRCqOlzvt/zxi1F/B2zL4tyG0bDfzgdsvOizxqaBwo9YGmfeCIO6AHiOeMAt26T 4JhZ8ykOvUSsYcTHskFpx0JcpcBDnu827BcGE2JGvhROFAgvm/EZ7+XOAWkRCV8rixbe JLD+r+XColWtgHcDgPmiTtoM+CSr1ScVnqJiGjc/8/pZ1qbi3QYIXEHT1MKVKOdAd8gR FhKZjZFMFvAd2GhPBD/TJGvrahtq2PrxQCF68FhGvqolwjbsxECh54ZMsGyktUJ7RuWF J1tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=ViBmYElAtSXDaSxP33X/THXx7ctGZma3wRWQVfEjIgk=; b=MjotRgUuAxLBj47HqpDVPAhgFbrlWrKJjMcha9wk6vM2ax8Z1kvQaiZc9a+cG7Yqra uhYOWV87gfsMCDmPRxUweS6oWEYF4KEVAZWURFLfTaTNA2uBt/sTbp9ke4QUxkQmasq8 OGfd+aJWaTBNThKaDJ0VSy+YSc3PmDicQ4ZRZMrrnAm77fjfRpXYHf4+stDUPAMSDp6d Ru9EK3vL4gtbWHWMiOFfoboiJwBl7FFmzSGRTwmM9Z+9dws5T+H6y3KrEwKAqm4k1eYg JNUjbTtZouE4IhAUVmvMFcheDilULsBrMpGVRqXd32bd8B4nHnbQCQUrAUNflvsg/VKV YbFQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i7si352862ejo.684.2020.06.10.09.40.15; Wed, 10 Jun 2020 09:40:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729630AbgFJN7d (ORCPT + 99 others); Wed, 10 Jun 2020 09:59:33 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:33304 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729613AbgFJN7d (ORCPT ); Wed, 10 Jun 2020 09:59:33 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 95CC8DAAEE057B21A14B; Wed, 10 Jun 2020 21:59:28 +0800 (CST) Received: from [10.173.222.27] (10.173.222.27) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.487.0; Wed, 10 Jun 2020 21:59:20 +0800 Subject: Re: [PATCH] irqchip/gic-v4.1: Use readx_poll_timeout_atomic() to fix sleep in atomic To: CC: , , , , , , References: <20200605052345.1494-1-yuzenghui@huawei.com> From: Zenghui Yu Message-ID: <4a9822bd-0362-7ffe-6e56-3f05a7816d9e@huawei.com> Date: Wed, 10 Jun 2020 21:59:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <20200605052345.1494-1-yuzenghui@huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.222.27] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, Sorry to ping you in the merge window, but ... On 2020/6/5 13:23, Zenghui Yu wrote: > readx_poll_timeout() can sleep if @sleep_us is specified by the caller, > and is therefore unsafe to be used inside the atomic context, which is > this case when we use it to poll the GICR_VPENDBASER.Dirty bit in > irq_set_vcpu_affinity() callback. this seems like an urgent thing to me. Without this patch, CPUs are easily to get stuck on my board with GICv4.1 enabled. So it'd be good if you can have a look and take this as a fix (if it is correct). Thanks, Zenghui > > Let's convert to its atomic version instead which helps to get the v4.1 > board back to life! > > Fixes: 96806229ca03 ("irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling") > Signed-off-by: Zenghui Yu > --- > drivers/irqchip/irq-gic-v3-its.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index cd685f521c77..6a5a87fc4601 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -3797,10 +3797,10 @@ static void its_wait_vpt_parse_complete(void) > if (!gic_rdists->has_vpend_valid_dirty) > return; > > - WARN_ON_ONCE(readq_relaxed_poll_timeout(vlpi_base + GICR_VPENDBASER, > - val, > - !(val & GICR_VPENDBASER_Dirty), > - 10, 500)); > + WARN_ON_ONCE(readq_relaxed_poll_timeout_atomic(vlpi_base + GICR_VPENDBASER, > + val, > + !(val & GICR_VPENDBASER_Dirty), > + 10, 500)); > } > > static void its_vpe_schedule(struct its_vpe *vpe) >