From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24B1BC433EF for ; Tue, 17 May 2022 11:42:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244822AbiEQLmt (ORCPT ); Tue, 17 May 2022 07:42:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238852AbiEQLmp (ORCPT ); Tue, 17 May 2022 07:42:45 -0400 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 519BF27FFE for ; Tue, 17 May 2022 04:42:44 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id 16so21421766lju.13 for ; Tue, 17 May 2022 04:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=uj5rCEgrEME0641i65F/SbR6hoTPj4hzhlWTwqHQqWk=; b=RcFydaN3PbLyev6mS4qntlxs4M51b7yJgGfZ8ex/bJuWNY0MSRmcIhwi52CSHHNZdN ptBAimz8cIO2HJN9H/Ig0xRPIxLfJCNPWQ4+PPpm1u4UiJ/7LDS8rR/9UqByvZlpXKKd PMrrZUBBzxyVPDbd6F8cBquq4HN7wkJ+jAm+nTco1smdGWT92QvDiX0L0QsGSXitoGY7 C/SMR6Bc4k4+9+KRvHwCh8OIsbvDO87DGgOvuIxuHz0qBdwCFF71dHc0k9MI41RKFExh NSZ0DnGvT6jTrZMTXXuv6Wk56JTbW7jqg1PhfR6n3Dy2cKXOTTkR1xy69Z5mzIhThqpi B+Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=uj5rCEgrEME0641i65F/SbR6hoTPj4hzhlWTwqHQqWk=; b=JxMTXoddkKet3WGKHeDtsqzAtYMQvcGo+j0BykjtVI7mDeZ4mlFNxGCeomSWSBSuEu ti0ACdthV8mtf8VSUfNWca2Xv1R807R7bBVah+sNYZonTaFSaAqykqGyjvbPipexWr+O JY+/S45vMKpxOxdkkLrrroeSPT3eCrdR5aIOLyn+5y3PgbleHAjC+iRvsAbPDn/NuG9r PO/ZvLUwIHY2wWveiopsHkzvlfNSUFSc59dBlnFM2zReqLYBLgVma/Ceu7tmAPFqij+W LFmI2f8zH5115DdSI+cgsYeF2QKvYSNh9BNytw7otTFO8itwHWHlFMVJ5gZfjsmhL1iy Z3Zg== X-Gm-Message-State: AOAM532E7YD27AiXv3s5+zpyaXcMdCwoRYa6v7DI+Le/Dxa1W936fFAg xSRI94kKJRL3jpOe0k2IuZEzwg== X-Google-Smtp-Source: ABdhPJxNGdUbUsF1H48W0SHvw7YaCknC4xl6XPByeWgTRCruMGoyqvNEwEBWhIoPpVCrhH3vfj0JpQ== X-Received: by 2002:a2e:81a:0:b0:250:a331:d0b1 with SMTP id 26-20020a2e081a000000b00250a331d0b1mr14297265lji.363.1652787762678; Tue, 17 May 2022 04:42:42 -0700 (PDT) Received: from [192.168.0.17] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id j20-20020a2e8014000000b0024f3d1dae96sm1874136ljg.30.2022.05.17.04.42.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 May 2022 04:42:42 -0700 (PDT) Message-ID: <2ce7a871-3e55-ae50-955c-bf04a443aba3@linaro.org> Date: Tue, 17 May 2022 13:42:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH net v2] NFC: hci: fix sleep in atomic context bugs in nfc_hci_hcp_message_tx Content-Language: en-US To: Duoming Zhou , linux-kernel@vger.kernel.org Cc: kuba@kernel.org, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, gregkh@linuxfoundation.org, alexander.deucher@amd.com, broonie@kernel.org, netdev@vger.kernel.org References: <20220517105526.114421-1-duoming@zju.edu.cn> From: Krzysztof Kozlowski In-Reply-To: <20220517105526.114421-1-duoming@zju.edu.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/05/2022 12:55, Duoming Zhou wrote: > There are sleep in atomic context bugs when the request to secure > element of st21nfca is timeout. The root cause is that kzalloc and > alloc_skb with GFP_KERNEL parameter and mutex_lock are called in > st21nfca_se_wt_timeout which is a timer handler. The call tree shows > the execution paths that could lead to bugs: > > (Interrupt context) > st21nfca_se_wt_timeout > nfc_hci_send_event > nfc_hci_hcp_message_tx > kzalloc(..., GFP_KERNEL) //may sleep > alloc_skb(..., GFP_KERNEL) //may sleep > mutex_lock() //may sleep > > This patch changes allocation mode of kzalloc and alloc_skb from > GFP_KERNEL to GFP_ATOMIC and changes mutex_lock to spin_lock in > order to prevent atomic context from sleeping. > > Fixes: 2130fb97fecf ("NFC: st21nfca: Adding support for secure element") > Signed-off-by: Duoming Zhou > --- > Changes in v2: > - Change mutex_lock to spin_lock. > > include/net/nfc/hci.h | 3 ++- > net/nfc/hci/core.c | 18 +++++++++--------- > net/nfc/hci/hcp.c | 10 +++++----- > 3 files changed, 16 insertions(+), 15 deletions(-) > > diff --git a/include/net/nfc/hci.h b/include/net/nfc/hci.h > index 756c11084f6..8f66e6e6b91 100644 > --- a/include/net/nfc/hci.h > +++ b/include/net/nfc/hci.h > @@ -103,7 +103,8 @@ struct nfc_hci_dev { > > bool shutting_down; > > - struct mutex msg_tx_mutex; > + /* The spinlock is used to protect resources related with hci message TX */ > + spinlock_t msg_tx_spin; > > struct list_head msg_tx_queue; > > diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c > index ceb87db57cd..fa22f9fe5fc 100644 > --- a/net/nfc/hci/core.c > +++ b/net/nfc/hci/core.c > @@ -68,7 +68,7 @@ static void nfc_hci_msg_tx_work(struct work_struct *work) > struct sk_buff *skb; > int r = 0; > > - mutex_lock(&hdev->msg_tx_mutex); > + spin_lock(&hdev->msg_tx_spin); > if (hdev->shutting_down) > goto exit; How did you test your patch? Did you check, really check, that this can be an atomic (non-sleeping) section? I have doubts because I found at least one path leading to device_lock (which is a mutex) called within your new code. Before sending a new version, please wait for discussion to reach some consensus. The quality of these fixes is really poor. :( Best regards, Krzysztof