Received: by 10.223.176.46 with SMTP id f43csp279520wra; Thu, 18 Jan 2018 17:20:50 -0800 (PST) X-Google-Smtp-Source: ACJfBosP2YhcfjesGw30mAlo2HgqOz8wt6QUIPQCbH8oxfh/iFNu3CDrHxGEyn2tgXb88tdsswkh X-Received: by 10.98.234.4 with SMTP id t4mr44938653pfh.74.1516324849980; Thu, 18 Jan 2018 17:20:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516324849; cv=none; d=google.com; s=arc-20160816; b=NQPvbQaXtlJKRDOp4p0sQPb0vwOAl/6cz8an1dgkwxym+wjCflrDq4EjvBisqNS6sp SBaLD4MfTtdAXK2eNibfKarMs2Hko1i+QNPG+dhDL3Chtf4sInXvWQqNjvWcpa/VBGPs XPN0dTzv3OmBsEEEtUvKsVzbi3BC25+1x+3LceDDnONnYCzgO6lFCV4Mosv/iisqMQUS pgU2MKHjdQjyXm/rWfosHhRQg35o7avGnH9nO4TFxB6jcvDD26IkKwDMbPCHAOYf955e MorcJ+n7jq4HJs1DDM+khRZcXx2LjH8/3L0LcZwapC9V8k7Ua0MYiLzgyHypvu05RB9s Uc1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=leDI1TP+LXvhDo8luWjU5yBPN8zA5AwGgsuZglMepXA=; b=GB+yZSJMd7aHCSrMapNw2zoJmufXB5ckXtSJpMVv6QTmRLy80r4W6w3DTf70jTrzBC w8I0ACduoqUGz9RXu6gcOcxz47yAiqm90m0JFWP2csoEQpEw4BzodzdV3Kk4uByN6tSa NTME/Sv54nADYTnWfUr7gbnZxVWtu5DEAxy0yCi8iMSSbZPyHZhF+gLdLNi8cvJ8T2jz Eo0/qjeTRZj4o2OiWtAXSuVadQwvH/O8qDZcFbIzN7+kJ+cuzhH83Sw5Z5FUsd7ZTLwW ZMz9rWGhTZral+fJOUhRluZ2S6OXdwbMGsceXBPbs7vE++PGLIn1G7Y5f30Bl9fGifV+ 3e+g== 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 97-v6si376233plb.789.2018.01.18.17.20.36; Thu, 18 Jan 2018 17:20:49 -0800 (PST) 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 S1755456AbeASBS7 (ORCPT + 99 others); Thu, 18 Jan 2018 20:18:59 -0500 Received: from violet.fr.zoreil.com ([92.243.8.30]:51723 "EHLO violet.fr.zoreil.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755268AbeASBSi (ORCPT ); Thu, 18 Jan 2018 20:18:38 -0500 X-Greylist: delayed 404 seconds by postgrey-1.27 at vger.kernel.org; Thu, 18 Jan 2018 20:18:33 EST Received: from violet.fr.zoreil.com (localhost [127.0.0.1]) by violet.fr.zoreil.com (8.14.9/8.14.9) with ESMTP id w0J1B27A015924; Fri, 19 Jan 2018 02:11:02 +0100 Received: (from romieu@localhost) by violet.fr.zoreil.com (8.14.9/8.14.5/Submit) id w0J1B1et015923; Fri, 19 Jan 2018 02:11:01 +0100 Date: Fri, 19 Jan 2018 02:11:01 +0100 From: Francois Romieu To: Jia-Ju Bai Cc: nic_swsd@realtek.com, alexander.h.duyck@redhat.com, David Miller , dhowells@redhat.com, paulmck@linux.vnet.ibm.com, will.deacon@arm.com, peterz@infradead.org, netdev@vger.kernel.org, Linux Kernel Mailing List Subject: Re: net: r8169: a question of memory barrier in the r8169 driver Message-ID: <20180119011101.GA15920@electric-eye.fr.zoreil.com> References: <9a373156-41e5-a78b-cd31-c4b9bdba2696@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9a373156-41e5-a78b-cd31-c4b9bdba2696@gmail.com> X-Organisation: Land of Sunshine Inc. User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jia-Ju Bai : [...] > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { > netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n"); > goto err_stop_0; > } > But there is no memory barrier around this code. > > Is there a possible data race here? This code would not even be needed if rtl8169_start_xmit was only your usual ndo_start_xmit handler: Realtek {ab / re}used it for GSO handling (see r8169_csum_workaround). If the test is not a no-op in this GSO context, it's racy. -- Ueimor