Received: by 10.192.165.148 with SMTP id m20csp3764264imm; Mon, 7 May 2018 19:17:46 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoWts95NA22yeGiIBAX6LwdV2YFEGyi0GO+jZmYH4ayJJcc1oXLx2zQOOSppGG0WnNuxu7l X-Received: by 2002:a17:902:6505:: with SMTP id b5-v6mr39356667plk.147.1525745866581; Mon, 07 May 2018 19:17:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525745866; cv=none; d=google.com; s=arc-20160816; b=r04qOlEgEIoqJhq8xl2EZErcErrL4WfV8mBg2UJC6gKnmEbkcclREvU+SUJweJFF9K GjnP7EAVZiku1brweGvgsTZlHS9s0tE4oiGk6xaepytkPdbtqm0NTMovbwmi4jvTx5Dh agUxGIDTR4m6nZBU5LPVOagUIZoVvHNTLmXzTPXQAVOJ6HFIsnpYwFdnWZB52h9K0ikK RHKsWRFuAdeLkMYPiPKfyYFS5poxQIhV4HGAObptqQ8ksNrsOMboAMYvAwUBz0sYpgIr dDpg+Kui9cmK4nZWN9aIkxD+O4V08qKjhWCYYjMfFoWPStiB8QUJU6JlDbuWTfnfNnq6 zY0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=/JHlcv+WxyTCsegEr/8vco7ClNkCCTCFlfOXqRj53RQ=; b=W89HTMBerloopjoiU1N7ZESeXBQyq4Y5PQ7ZpasK66ksIUZNQy7RAwP9rkkXuleRix FBDZ6PiV9DEVgpzWU/83Lb2lHyAW0RLD5G3EEZmiA3KCCiBrNxYcU5pioAVeusV7WCfI 93H7+38DhKGygn2V4iH2d7l3G2f/ClEHw/wg8S3yJ6t9gBMDTIZxtuEGiMt+u34cgQJb lLOb8XmShUXPuYrtWcqHZX0DKDj+iHDAAm8aVt4ra/F68hbfjiuO4luNKXlBPtj7ktwb 42Yl4We/aeR4OgiCL+WSedxpTo53Q4/xkzj64/vmIEgjrFtX6opJIm8HyeE1tsvlbFVw QQfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Kw7DOYmH; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 89-v6si23133826plc.444.2018.05.07.19.17.19; Mon, 07 May 2018 19:17:46 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Kw7DOYmH; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753780AbeEHCRA (ORCPT + 99 others); Mon, 7 May 2018 22:17:00 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:40224 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753512AbeEHCQ6 (ORCPT ); Mon, 7 May 2018 22:16:58 -0400 Received: by mail-pg0-f68.google.com with SMTP id l2-v6so20465071pgc.7; Mon, 07 May 2018 19:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/JHlcv+WxyTCsegEr/8vco7ClNkCCTCFlfOXqRj53RQ=; b=Kw7DOYmHkVH7R02afg2JLFsDPOkMCbTMbZz97U2PBZANh0bY39ZGAjyYtcv3xHm86J Nati5D+E7nLhZfYd5LLSFjkRpYKS8Rfkd9jhE4cRNTKWt5k5Cn9DaEBaDs/8mCbMGRln wqukznjI/zMY4lbLckwqmiwo04875RD1QLVJvHmbuKtHugg6HfQ3NKVXJKjOqQOVsLgg mseyo2ME3zL7GgKjOXb0jXOaCyDhgmVjX8bCYMAlFfqBQYznEzGVM1XvF7mfPx1fUByx idS/S6+1Ut/XC9TjXCcGlTVftArr++3MH8fKtFNTbEGNOrCWvZpbVA73U0/ry+OcVfs3 l05A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/JHlcv+WxyTCsegEr/8vco7ClNkCCTCFlfOXqRj53RQ=; b=XgRSQNBl299i5PDuooeYFtp0F5aIFu6afUDHt6hhgm+lcdTQ6IP/bGv9+ejNJ35/yl sClI54X6g6Nf2YZqibfLttlwCQUrtFs/zIQS/QOQq197VxnvWrx9z2zc4dG/aUeeG+lq +BKDEgl57os6quRVPAL7jr1aGcxOhbANF3vBMweXUDbnxchKJtZ0DI3HH335WpyRjDmq bxhid2iqJrpUCU6JaHcF3Kynn24BzaNI0bIxWn2fFHqHMNNLHWRCixL+UKleqFTxajmd yil+ETqeXUPOMlv70WGxv6moh6kTcMFpDlJGXnzjt7/5KvEnAhtEDrXk+Rb00ECeVnxb +7uA== X-Gm-Message-State: ALQs6tDBICQsBt8kDTUzNx3b/ZC4DnNhnHuqrnutnXEjnzEghLXkTSoF zpzYAJLZuG34x/TUdPf287X3xe4N X-Received: by 2002:a63:7207:: with SMTP id n7-v6mr28570386pgc.195.1525745817898; Mon, 07 May 2018 19:16:57 -0700 (PDT) Received: from ?IPv6:2402:f000:1:1501:200:5efe:166.111.70.9? ([2402:f000:1:1501:200:5efe:a66f:4609]) by smtp.gmail.com with ESMTPSA id j193-v6sm40379218pgc.43.2018.05.07.19.16.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 19:16:57 -0700 (PDT) Subject: Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats To: Eric Dumazet , davem@davemloft.net, fthain@telegraphics.com.au, joe@perches.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20180507140809.28847-1-baijiaju1990@gmail.com> From: Jia-Ju Bai Message-ID: <6fe51782-2169-53c8-9bac-1715262e716d@gmail.com> Date: Tue, 8 May 2018 10:16:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/5/8 9:56, Eric Dumazet wrote: > > On 05/07/2018 05:51 PM, Jia-Ju Bai wrote: >> >> On 2018/5/7 22:15, Eric Dumazet wrote: >>> On 05/07/2018 07:08 AM, Jia-Ju Bai wrote: >>>> The write operations to "dev->stats" are protected by >>>> the spinlock on line 862-864, but the read operations to >>>> this data on line 858 and 867 are not protected by the spinlock. >>>> Thus, there may exist data races for "dev->stats". >>>> >>>> To fix the data races, the read operations to "dev->stats" are >>>> protected by the spinlock, and a local variable is used for return. >>>> >>>> Signed-off-by: Jia-Ju Bai >>>> --- >>>> drivers/net/ethernet/8390/lib8390.c | 14 ++++++++++---- >>>> 1 file changed, 10 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/net/ethernet/8390/lib8390.c b/drivers/net/ethernet/8390/lib8390.c >>>> index c9c55c9eab9f..198952247d30 100644 >>>> --- a/drivers/net/ethernet/8390/lib8390.c >>>> +++ b/drivers/net/ethernet/8390/lib8390.c >>>> @@ -852,19 +852,25 @@ static struct net_device_stats *__ei_get_stats(struct net_device *dev) >>>> unsigned long ioaddr = dev->base_addr; >>>> struct ei_device *ei_local = netdev_priv(dev); >>>> unsigned long flags; >>>> + struct net_device_stats *stats; >>>> + >>>> + spin_lock_irqsave(&ei_local->page_lock, flags); >>>> /* If the card is stopped, just return the present stats. */ >>>> - if (!netif_running(dev)) >>>> - return &dev->stats; >>>> + if (!netif_running(dev)) { >>>> + stats = &dev->stats; >>>> + spin_unlock_irqrestore(&ei_local->page_lock, flags); >>>> + return stats; >>>> + } >>>> - spin_lock_irqsave(&ei_local->page_lock, flags); >>>> /* Read the counter registers, assuming we are in page 0. */ >>>> dev->stats.rx_frame_errors += ei_inb_p(ioaddr + EN0_COUNTER0); >>>> dev->stats.rx_crc_errors += ei_inb_p(ioaddr + EN0_COUNTER1); >>>> dev->stats.rx_missed_errors += ei_inb_p(ioaddr + EN0_COUNTER2); >>>> + stats = &dev->stats; >>>> spin_unlock_irqrestore(&ei_local->page_lock, flags); >>>> - return &dev->stats; >>>> + return stats; >>>> } >>>> /* >>>> >>> dev->stats is not a pointer, it is an array embedded in the >>> struct net_device >>> >>> So this patch is not needed, since dev->stats can not change. >> Thanks for your reply :) >> >> I do not understand that why "dev->stats can not change". >> Its data is indeed changed by the code: >> dev->stats.rx_frame_errors += ei_inb_p(ioaddr + EN0_COUNTER0); >> dev->stats.rx_crc_errors += ei_inb_p(ioaddr + EN0_COUNTER1); >> dev->stats.rx_missed_errors += ei_inb_p(ioaddr + EN0_COUNTER2); > So ? > >> So I think a data race may occur when returning "dev->stats" without lock protection. > &dev->stats is a stable value. > > It wont change over the lifetime of net_device object. > > Adding a barrier before or after getting &dev->stats is useless, confusing and really not needed. > Yes, "&dev->stats" will not change, because it is a fixed address. But the field data in "dev->stats" is changed (rx_frame_errors, rx_crc_errors and rx_missed_errors). So if the driver returns "&dev->stats" without lock protection (like on line 858), the field data value of this return value can be the changed field data value or unchanged field data value. Best wishes, Jia-Ju Bai