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 18E6721F1C3; Wed, 16 Apr 2014 06:11:16 -0700 (PDT) Message-ID: <534E8168.50003@openwrt.org> Date: Wed, 16 Apr 2014 15:11:04 +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: 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 13:11:16 -0000 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. > What tree is this patch against? mac80211 from OpenWrt trunk. - Felix