Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 May 2019 16:37:53 +0000
From:      Alexey Dokuchaev <danfe@freebsd.org>
To:        Ian Lepore <ian@freebsd.org>
Cc:        Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r250609 - head/sys/dev/ath
Message-ID:  <20190522163753.GA5149@FreeBSD.org>
In-Reply-To: <953361717e24b2e3a6911940881f42dcd05736c0.camel@freebsd.org>
References:  <201305131903.r4DJ3DHm045333@svn.freebsd.org> <20190522162005.GA82729@FreeBSD.org> <953361717e24b2e3a6911940881f42dcd05736c0.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 22, 2019 at 10:34:35AM -0600, Ian Lepore wrote:
> On Wed, 2019-05-22 at 16:20 +0000, Alexey Dokuchaev wrote:
> > On Mon, May 13, 2013 at 07:03:13PM +0000, Adrian Chadd wrote:
> > > New Revision: 250609
> > > URL: http://svnweb.freebsd.org/changeset/base/250609
> > > 
> > > Log:
> > >   Since the node state is 100% back under the TX lock, just kill
> > > the use
> > >   of atomics.
> > >   
> > > Modified:
> > >   head/sys/dev/ath/if_ath.c
> > > 
> > > @@ -6140,13 +6133,13 @@ ath_tx_update_tim(struct ath_softc *sc,
> > >  		/*
> > >  		 * Don't bother grabbing the lock unless the queue is
> > > empty.
> > >  		 */
> > > -		if (atomic_load_acq_int(&an->an_swq_depth) != 0)
> > > +		if (&an->an_swq_depth != 0)
> > >  			return;
> > >  
> > >  		if (an->an_is_powersave &&
> > >  		    an->an_stack_psq == 0 &&
> > >  		    an->an_tim_set == 1 &&
> > > -		    atomic_load_acq_int(&an->an_swq_depth) == 0) {
> > > +		    an->an_swq_depth == 0) {
> > 
> > PVS Studio complains here: warning: V560 A part of conditional
> > expression
> > is always true: an->an_swq_depth == 0.  Which probably makes sense
> > since
> > you return earlier if it's != 0.
> 
> You're replying to a six year old commit?

Yeah, anything wrong with it?

> It doesn't check earlier whether that value is 0, it checks whether the
> address of that value is 0.  That's probably a bug.

No, the & is a vestige from the atomic_* conversion, it is not present in
current code.  The check is still there, however.

./danfe



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190522163753.GA5149>