On Mon, Apr 20, 2020 at 01:08:52PM +1000, Dave Chinner wrote: > On Fri, Apr 17, 2020 at 11:08:50AM -0400, Brian Foster wrote: > > The inode flush code has several layers of error handling between > > the inode and cluster flushing code. If the inode flush fails before > > acquiring the backing buffer, the inode flush is aborted. If the > > cluster flush fails, the current inode flush is aborted and the > > cluster buffer is failed to handle the initial inode and any others > > that might have been attached before the error. > > > > Since xfs_iflush() is the only caller of xfs_iflush_cluser(), the > > xfs_iflush_cluster() > Fixed. > > error handling between the two can be condensed in the top-level > > function. If we update xfs_iflush_int() to attach the item > > completion handler to the buffer first, any errors that occur after > > the first call to xfs_iflush_int() can be handled with a buffer > > I/O failure. > > > > Lift the error handling from xfs_iflush_cluster() into xfs_iflush() > > and consolidate with the existing error handling. This also replaces > > the need to release the buffer because failing the buffer with > > XBF_ASYNC drops the current reference. > > Yeah, that makes sense. I've lifted the cluster flush error handling > into the callers, even though xfs_iflush() has gone away. > > However... > > > @@ -3798,6 +3765,13 @@ xfs_iflush_int( > > ip->i_d.di_nextents > XFS_IFORK_MAXEXT(ip, XFS_DATA_FORK)); > > ASSERT(iip != NULL && iip->ili_fields != 0); > > > > + /* > > + * Attach the inode item callback to the buffer. Whether the flush > > + * succeeds or not, buffer I/O completion processing is now required to > > + * remove the inode from the AIL and release the flush lock. > > + */ > > + xfs_buf_attach_iodone(bp, xfs_iflush_done, &iip->ili_item); > > + > > /* set *dip = inode's place in the buffer */ > > dip = xfs_buf_offset(bp, ip->i_imap.im_boffset); > > ...I'm not convinced this is a valid thing to do at this point. The > inode item has not been set up yet with the correct state that is > associated with the flushing of the inode (e.g. lsn, last_flags, > etc) and so this kinda leaves a landmine in the item IO completion > processing in that failure cannot rely on any of the inode log item > state to make condition decisions. > It is a bit ugly. I moved it just because it seemed like it could facilitate enough simplification to be worthwhile. It's debatable whether what ultimately fell out of that is worthwhile, of course. TBH, I find the whole I/O approach to the error sequence rather rickety, even though it's currently necessary, so I'm sympathetic to the argument of not risking the common code path in service to the uncommon error path. We could consider other tweaks like making flush imminent and leaving the error checks at the end of the function (with documentation to explain that we're shutting down, etc.), but I'd have to think about that some more. It could be best just to leave this code as is if you anticipate it going away relatively soon. This whole series was just intended to be quick hit cleanups anyways... Brian > While it's technically not wrong, it just makes me uneasy, as in > future the flush abort code will have to be careful about using > inode state in making decisions, and there's not comments in the > abort code to indicate that the state may be invalid... > > /me has chased several subtle issues through this code recently... > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx >
