fuse_vnop_copy_file_range(): add safety v_mount for unlocked vnode could be NULL, check for it. Explain why it is safe to access fs-specific data for mp if it is read as non-NULL.
fuse_vnop_copy_file_range(): use vn_lock_pair()
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
LGTM. But under what circumstances can mp be NULL? We should probably add a regression test for that.
Comment Actions
The vnodes passed to VOP_COPY_FILE_RANGE() are not locked, so they can be reclaimed any moment. Then v_data and v_mount become NULL.
| sys/fs/fuse/fuse_vnops.c | ||
|---|---|---|
| 884 | Would VN_IS_DOOMED() be better here (since it would make the intention of the check clearer)? | |
| sys/fs/fuse/fuse_vnops.c | ||
|---|---|---|
| 884 | Then doomed but not yet reclaimed vnode cannot be handled. In principle there it is not very important, but other VOPs are more critical WRT this (subtle) difference. It is important for instance for fsync() or inactivate(). This is just my preference to be more permissive in such situations, after I realized this problem during some UFS work. | |