tests/xfs: filestream allocator inode use-after-free test
PATCH v2 1/1 tests/xfs: filestream allocator inode use-after-free test
The XFS filestreams allocator caches dir inode -> agno mappings in an MRU mechanism that holds elements in memory for an amount of time and then cleans up expired elements in the background. The elements typically held inode pointers without holding a reference to the associated inode. This means that if the inode is reclaimed before an expired entry is cleaned up, the MRU reaper can access freed memory and cause a panic.
Test for this problem by performing continuous filestreams allocations under short-lived parent directory inodes. This will produce KASAN use-after-free splats if enabled during the test.
---
v2:
- Drop unnecessary _scratch_mount error check.
- Create and use helper for min. scratch dev size.
v1: https://marc.info/?l=fstests&m=152302430125453&w=2
common/rc | 10 +++++ tests/xfs/445 | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/xfs/445.out | 2 + tests/xfs/group | 1 + 4 files changed, 122 insertions(+) create mode 100755 tests/xfs/445 create mode 100644 tests/xfs/445.out
common/rc +10 -0
@@ -1600,6 +1600,16 @@ _require_scratch() touch ${RESULT_DIR}/require_scratch } +# require a scratch dev of a minimum size (in kb) +_require_scratch_size() +{ + [ $# -eq 1 ] || _fail "_require_scratch_size: expected size param" + + _require_scratch + devsize=`_get_device_size $SCRATCH_DEV` + [ $devsize -lt $1 ] && _notrun "scratch dev too small" +} + # this test needs a test partition - check we're ok & mount it #
tests/xfs/445 new file +109 -0
109 lines not on this page · raw message
tests/xfs/445.out new file +2 -0
@@ -0,0 +1,2 @@ +QA output created by 445 +Silence is golden
tests/xfs/group +1 -0
@@ -442,3 +442,4 @@ 442 auto stress clone quota 443 auto quick ioctl fsr 444 auto quick +445 auto filestreams
Signature · 1 line
2.13.6
Quoted 33 lines · Brian Foster
The XFS filestreams allocator caches dir inode -> agno mappings in an MRU mechanism that holds elements in memory for an amount of time and then cleans up expired elements in the background. The elements typically held inode pointers without holding a reference to the associated inode. This means that if the inode is reclaimed before an expired entry is cleaned up, the MRU reaper can access freed memory and cause a panic.
Test for this problem by performing continuous filestreams allocations under short-lived parent directory inodes. This will produce KASAN use-after-free splats if enabled during the test.
Signed-off-by Brian Foster <[email protected]>---
v2:
- Drop unnecessary_scratch_mounterror check.
- Create and use helper for min. scratch dev size.
v1: https://marc.info/?l=fstests&m=152302430125453&w=2common/rc | 10 +++++ tests/xfs/445 | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/xfs/445.out | 2 + tests/xfs/group | 1 + 4 files changed, 122 insertions(+) create mode 100755 tests/xfs/445 create mode 100644 tests/xfs/445.outcommon/rc +0
-0
common/rc _require_scratch() · line 1609
Quoted 10 lines
common/rc +7
-0@@ -1600,6 +1600,16 @@ _require_scratch() touch ${RESULT_DIR}/require_scratch } +# require a scratch dev of a minimum size (in kb) +_require_scratch_size() +{ + [ $# -eq 1 ] || _fail "_require_scratch_size: expected size param" + + _require_scratch + devsize=`_get_device_size $SCRATCH_DEV`
I made it a 'local' variable.
[snip]
tests/xfs/group line 445
Quoted 9 lines
tests/xfs/group +1
-0@@ -442,3 +442,4 @@ 442 auto stress clone quota 443 auto quick ioctl fsr 444 auto quick +445 auto filestreams
It looks like a 'quick' test too, it runs for around 15s on my test vm. Will add 'quick' group on commit.
Thanks,
Eryu
Quoted 7 lines
Signature · 6 lines
2.13.6 -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 37 lines · Eryu Guan
Quoted 36 lines · Brian Foster
The XFS filestreams allocator caches dir inode -> agno mappings in an MRU mechanism that holds elements in memory for an amount of time and then cleans up expired elements in the background. The elements typically held inode pointers without holding a reference to the associated inode. This means that if the inode is reclaimed before an expired entry is cleaned up, the MRU reaper can access freed memory and cause a panic.
Test for this problem by performing continuous filestreams allocations under short-lived parent directory inodes. This will produce KASAN use-after-free splats if enabled during the test.
Signed-off-by Brian Foster <[email protected]>---
v2:
- Drop unnecessary_scratch_mounterror check.
- Create and use helper for min. scratch dev size.
v1: https://marc.info/?l=fstests&m=152302430125453&w=2common/rc | 10 +++++ tests/xfs/445 | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/xfs/445.out | 2 + tests/xfs/group | 1 + 4 files changed, 122 insertions(+) create mode 100755 tests/xfs/445 create mode 100644 tests/xfs/445.outcommon/rc +0
-0@@ -1600,6 +1600,16 @@ _require_scratch() touch ${RESULT_DIR}/require_scratch }
Quoted 10 lines
common/rc _require_scratch() · line 1609
Quoted 7 lines
common/rc +7
-0+# require a scratch dev of a minimum size (in kb) +_require_scratch_size() +{ + [ $# -eq 1 ] || _fail "_require_scratch_size: expected size param" + + _require_scratch + devsize=`_get_device_size $SCRATCH_DEV`I made it a 'local' variable.
Ok.
Quoted 15 lines
[snip]
tests/xfs/group line 445
Quoted 9 lines
tests/xfs/group +1
-0@@ -442,3 +442,4 @@ 442 auto stress clone quota 443 auto quick ioctl fsr 444 auto quick +445 auto filestreamsIt looks like a 'quick' test too, it runs for around 15s on my test vm. Will add 'quick' group on commit.
Sounds good to me, thanks!
Brian
Quoted 14 lines
Thanks,
EryuQuoted 7 lines
Signature · 6 lines
2.13.6 -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html