From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755250AbeASBTA (ORCPT ); Thu, 18 Jan 2018 20:19:00 -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 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 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