| created | 2024-07-16T02:07:56Z |
|---|---|
| begin | 2024-07-12T04:10:46Z |
| end | 2024-07-12T08:15:19Z |
| path | src/sys |
| commits | 1 |
| date | 2024-07-12T08:15:19Z | |||
|---|---|---|---|---|
| author | beck | |||
| files | src/sys/kern/vfs_subr.c | log | diff | annotate |
| src/sys/sys/vnode.h | log | diff | annotate | |
| src/sys/ufs/ext2fs/ext2fs_inode.c | log | diff | annotate | |
| src/sys/ufs/ufs/ufs_inode.c | log | diff | annotate | |
| message |
Add vdoom() to fix ufs/ext2fs re-use of invalid vnode. This was noticed by syzkiller and analyzed in isolaiton by mbuhl@ and visa@ two years ago. As the kernel has become more unlocked it has started to appear more and was being hit regularly by jsing@ on the Go builder. The problem was during reclaim of a inode the corresponding vnode could be picked up by a vget() by another thread while the inode was being cleared out in the ufs_inactive routine and the thread running ufs_inactive slept for i/o. When raced the vnode would then not have zero use count and would not be cleared out on exit from ufs_inactive with a dead/invalid vnode being used. While this could get "fixed" by checking for the race happening and trying again in the inactive routine, or by adding "yet another visible vnode locking flag" we choose to add a vdoom() api for the moment that allows the caller to block future attempts to grab this vnode until it is cleared out fully with vclean. Teste by jsing@ on the Go builder and seems to solve the issue. ok kettenis@, claudio@ |
|||