On Wed, Aug 03, 2022 at 11:42:21PM +0000, Sherry Yang wrote: > > > On Aug 2, 2022, at 9:31 PM, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > 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. > > Hi Darrick, > > You’re correct. This is a false positive bug detected by our static code > analysis tool. Sorry for the noise. Well, thank /you/ for running smatch/sparse/whatever on the XFS code base. Let us know if you find any other oddities, since it does tend to find things every now and then. :) --D > Sherry > > > > --D > > > >> Cheers, > >> > >> Dave. > >> -- > >> Dave Chinner > >> david@xxxxxxxxxxxxx >
