Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 2 Aug 2022 21:31:31 -0700
From:   "Darrick J. Wong" <djwong@kernel.org>
To:     Dave Chinner <david@fromorbit.com>
Cc:     Sherry Yang <sherry.yang@oracle.com>, dchinner@redhat.com,
        allison.henderson@oracle.com, chandanrlinux@gmail.com,
        bfoster@redhat.com, linux-xfs@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] xfs: initialize error in xfs_defer_finish_one
Message-ID: <Yun6I/drpxG4L4RO@magnolia>
References: <20220801190311.65703-1-sherry.yang@oracle.com>
 <20220801204902.GA3600936@dread.disaster.area>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220801204902.GA3600936@dread.disaster.area>
Precedence: bulk

On Tue, Aug 02, 2022 at 06:49:02AM +1000, Dave Chinner wrote:
> On Mon, Aug 01, 2022 at 12:03:11PM -0700, Sherry Yang wrote:
> > Path through non-void function 'xfs_defer_finish_one' may return error
> > uninitialized if no iteration of 'list_for_each_safe' occurs. Fix this
> > by initializing error.
> 
> I didn't think this situation was possible - how do we get deferred
> work queued with no work items on it?
> 
> If we can return an uninitialised error from xfs_defer_finish_one()
> because of an empty queued work, then something else has gone wrong
> earlier in the work deferral process. If this can actually happen,
> then we need to fix whatever is creating the empty work rather than
> paper over it by initialising the error being returned for empty
> works...

/me bets this is a response to a static checker that doesn't know that
list_empty(&dfp->dfp_work) == false in all circumstances.  It's not
possible for tp->t_dfops to contain an xfs_defer_pending with no work
items.

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com