On Mon, Jul 26, 2021 at 10:57:01AM -0700, Darrick J. Wong wrote:
> On Mon, Jul 26, 2021 at 04:07:15PM +1000, Dave Chinner wrote:
> > IOWs, attr3 leaf buffers fall through the magic number checks
> > unrecognised, so trigger the "recover immediately" behaviour instead
> > of undergoing an LSN check. IOWs, we incorrectly replay ATTR3 leaf
> > buffers and that causes silent on disk corruption of inode attribute
> > forks and potentially other things....
> >
> > Git history shows this is *another* zero day bug, this time
> > introduced in commit 50d5c8d8e938 ("xfs: check LSN ordering for v5
> > superblocks during recovery") which failed to handle the attr3 leaf
> > buffers in recovery. And we've failed to handle them ever since...
>
> I wonder, what happens if we happen to have a rt bitmap block where a
> sparse allocation pattern at the start of the rt device just happens to
> match one of these magic numbers + fs UUID? Does that imply that log
> recovery can be tricked into forgetting to replay rtbitmap blocks?
Possibly. RT bitmap/summary buffers are marked by type in the
xfs_buf_log_format type field so log recovery can recognise these
and do the right thing with them. So it really comes down to whether
log recovery handles XFS_BLFT_RTBITMAP_BUF types differently to any
other buffers. Which, without looking at the code, I doubt it does,
so there's probably fixes needed there, too...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
