Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753881AbbHXSGS (ORCPT ); Mon, 24 Aug 2015 14:06:18 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:48705 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751561AbbHXSGR (ORCPT ); Mon, 24 Aug 2015 14:06:17 -0400 Date: Mon, 24 Aug 2015 14:06:15 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: David Miller cc: eugene.shatokhin@rosalab.ru, , , , , Subject: Re: [PATCH] usbnet: Fix two races between usbnet_stop() and the BH In-Reply-To: <20150824.104328.554582952440857559.davem@davemloft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1330 Lines: 41 On Mon, 24 Aug 2015, David Miller wrote: > From: Eugene Shatokhin > Date: Wed, 19 Aug 2015 14:59:01 +0300 > > > So the following might be possible, although unlikely: > > > > CPU0 CPU1 > > clear_bit: read dev->flags > > clear_bit: clear EVENT_RX_KILL in the read value > > > > dev->flags=0; > > > > clear_bit: write updated dev->flags > > > > As a result, dev->flags may become non-zero again. > > Is this really possible? > > Stores really are "atomic" in the sense that the do their update > in one indivisible operation. Provided you use ACCESS_ONCE or WRITE_ONCE or whatever people like to call it now. > Atomic operations like clear_bit also will behave that way. Are you certain about that? I couldn't find any mention of it in Documentation/atomic_ops.txt. In theory, an architecture could implement atomic bit operations using a spinlock to insure atomicity. I don't know if any architectures do this, but if they do then the scenario above could arise. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/