xfs: handle inode extent count mismatch
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 patches 13 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | xfs: transactionless xfs_bunmapi shouldn't do format conversionfs/ | +13 | 9 replies | |
| 2/2 | xfs: More robust inode extent count validationfs/ fs/ | +48 | 4 replies |
Reviews trailers per patch
1 of 2 patches has a Reviewed-by or Acked-by.
| Patch | Darrick J. Wong |
|---|---|
| 1/2 | |
| 2/2 | R-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/2] xfs: handle inode extent count mismatch
Hi folks,
Wen Xu provided an image that caused a crash allocating an extent. The AGFL was corrupt, as was the inode data fork extent count. The combination of the two corruptions could lead to a delalloc extent being allocated on write, and then when allocation fails because the AGFL was corrupt, it would try to punch out the delalloc extent which would then try to convert the format of the extent list in the inode data fork without a transaction. This would crash.
The following two patches address this - the first makes xfs_bunmapi() return EFSCORRUPTED if it tries to change the inode fork format without a transaction context and avoids the crash. THe second makes the inode verifier detect this specific inode fork corruption and prevents any attempt to access it with EFSCORRUPTED.
Comments?
Cheers,
Dave.