Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp3446429ybh; Mon, 5 Aug 2019 19:01:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqz0lzbBdQwHF/+amsglAkEzJTa40atJXzVEqm8ONF5hk8l+NyBPJ0d+wIbTUdv0hL+/HjQu X-Received: by 2002:a17:902:4643:: with SMTP id o61mr679115pld.101.1565056914140; Mon, 05 Aug 2019 19:01:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565056914; cv=none; d=google.com; s=arc-20160816; b=hGzk3CzMBMfaUer34oMJVKE08UHHgiScQdj2NLvy/tjwh7EPIWW0nhiuNQZ5QZogJi Et2QRfNJ9Sgzo9tPiKRR1aOaXumV3AsTxNh2vHtQtMH6zcp2dj+GL457iFsgxVFYsm0D ygSN5FyxTldjY2lLSxO76Ijp7msZhsRjZyYkwaj6L7iddz6fKXivbwTAZzjtIQ31I/r0 L1cg/4ieT+fp1Y7zEl4mNERtBDOnBG/CVT0PFz4O7il2SLR/G+w+bNGRCewVbS1mTACx Aoe9tnh8jCfWI28Cti+aQUQNp49LNRcf+ujPHT8hHt9rB2jiFlpPmZR7AtBaEGTzqYaf v1Dg== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=POElCSd95LqgLJytAXiYpam/t5JbLtEtFYIlbIu5oz4=; b=XBfupNu61fHk68NMo50JDdqiEWga+XrqRYt4uUVwa0b7Kjg6J3C6h+vPlEkUl8Gq1X Jrmg9aavIJT+DPwNMVJjVQOJ9/NjlMzmRLAhHN31Xj6v97ab2ey8PVEEB6WLQNwvZMuJ EAwHp1TwuDuHejRRqlUnT1vbT1xkqbB+ozO5v5gff37uPpl49r4aAYxKXu/EoAG3fneG S1w7udtipJjcikQUOc3gCvK6ZT5en0DunIr1po1gzbYJ9B9ydbuO6GCVKgldSQ3aNP2r eEQaeNjOLGg4s5lDwvGzU7KqmsYyQzWXijHbPzp+Izey4yaUvqbRXBuSJRVo0L2BskPC Lw6g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l28si53173426pgm.311.2019.08.05.19.01.37; Mon, 05 Aug 2019 19:01:54 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731437AbfHFCBB (ORCPT + 99 others); Mon, 5 Aug 2019 22:01:01 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:55610 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731359AbfHFCBA (ORCPT ); Mon, 5 Aug 2019 22:01:00 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id AD00BD92B20D5C7FB7AE; Tue, 6 Aug 2019 10:00:58 +0800 (CST) Received: from [127.0.0.1] (10.65.87.206) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.439.0; Tue, 6 Aug 2019 10:00:52 +0800 Subject: Re: [PATCH v1 1/3] net: hisilicon: make hip04_tx_reclaim non-reentrant To: Jakub Kicinski References: <1564835501-90257-1-git-send-email-xiaojiangfeng@huawei.com> <1564835501-90257-2-git-send-email-xiaojiangfeng@huawei.com> <20190805174618.2b3b551a@cakuba.netronome.com> CC: , , , , , , , From: Jiangfeng Xiao Message-ID: Date: Tue, 6 Aug 2019 10:00:52 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20190805174618.2b3b551a@cakuba.netronome.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.65.87.206] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/8/6 8:46, Jakub Kicinski wrote: > On Sat, 3 Aug 2019 20:31:39 +0800, Jiangfeng Xiao wrote: >> If hip04_tx_reclaim is interrupted while it is running >> and then __napi_schedule continues to execute >> hip04_rx_poll->hip04_tx_reclaim, reentrancy occurs >> and oops is generated. So you need to mask the interrupt >> during the hip04_tx_reclaim run. > > Napi poll method for the same napi instance can't be run concurrently. > Could you explain a little more what happens here? > Because netif_napi_add(ndev, &priv->napi, hip04_rx_poll, NAPI_POLL_WEIGHT); So hip04_rx_poll is a napi instance. I did not say that hip04_rx_poll has reentered. I am talking about the reentrant of hip04_tx_reclaim. Pre-modification code: static int hip04_rx_poll(struct napi_struct *napi, int budget) { [...] /* enable rx interrupt */ writel_relaxed(priv->reg_inten, priv->base + PPE_INTEN); napi_complete_done(napi, rx); done: /* clean up tx descriptors and start a new timer if necessary */ tx_remaining = hip04_tx_reclaim(ndev, false); [...] } hip04_tx_reclaim is executed after "enable rx interrupt" and napi_complete_done. If hip04_tx_reclaim is interrupted while it is running, and then __irq_svc->gic_handle_irq->hip04_mac_interrupt->__napi_schedule->hip04_rx_poll->hip04_tx_reclaim Also looking at hip04_tx_reclaim static int hip04_tx_reclaim(struct net_device *ndev, bool force) { [1] struct hip04_priv *priv = netdev_priv(ndev); [2] unsigned tx_tail = priv->tx_tail; [3] [...] [4] bytes_compl += priv->tx_skb[tx_tail]->len; [5] dev_kfree_skb(priv->tx_skb[tx_tail]); [6] priv->tx_skb[tx_tail] = NULL; [7] tx_tail = TX_NEXT(tx_tail); [8] [...] [9] priv->tx_tail = tx_tail; } An interrupt occurs if hip04_tx_reclaim just executes to the line 6, priv->tx_skb[tx_tail] is NULL, and then __irq_svc->gic_handle_irq->hip04_mac_interrupt->__napi_schedule->hip04_rx_poll->hip04_tx_reclaim Then hip04_tx_reclaim will handle kernel NULL pointer dereference on line 4. A reentrant occurs in hip04_tx_reclaim and oops is generated. My commit is to execute hip04_tx_reclaim before "enable rx interrupt" and napi_complete_done. Then hip04_tx_reclaim can also be protected by the napi poll method so that no reentry occurs. thanks.