From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nbd.name (unknown [IPv6:2a01:4f8:131:30e2::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id CCFFA21F1C7; Wed, 16 Apr 2014 09:56:07 -0700 (PDT) Message-ID: <534EB61C.1080108@openwrt.org> Date: Wed, 16 Apr 2014 18:55:56 +0200 From: Felix Fietkau User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dave Taht References: <534E8168.50003@openwrt.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: cerowrt@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Fwd: [bug #442] ath9k queue hang X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:56:08 -0000 On 2014-04-16 17:34, Dave Taht wrote: > On Wed, Apr 16, 2014 at 6:11 AM, Felix Fietkau wrote: >> On 2014-04-15 21:00, Dave Taht wrote: >>> Thx felix! >>> >>> Given that there seems to be a potential race in the code >>> review I did at: >>> >>> http://www.bufferbloat.net/issues/442#note-22 >>> >>> another thought is to make the increment and decrement of >>> >>> txq->pending_frame atomic, or to do a flush before the unlock >> I'm not convinced that there's a race that involves txq->pending_frames. >> There is no need to make the increment/decrement atomic, because that >> variable is already protected by the txq lock. > > It and "stopped" are briefly unprotected along that code path. Where? - Felix