User Details
- User Since
- Mar 25 2015, 11:24 AM (551 w, 3 d)
Fri, Oct 17
Thu, Oct 16
Tue, Oct 14
Further cleanup of unionfs_unlock()
Mon, Oct 13
I did post some related questions to https://reviews.freebsd.org/D52625 about both the policy of passing NULL for the thread to VOP_CLOSE and the possibility of trying to make the passing of file objects to vnode ops more consistent.
But assuming everyone's ok with still passing NULL there, I'll also update VOP_OPENCLOSE.9 to note that possibility.
Mon, Sep 22
Apologies for dropping this on the review after-the-fact, but I was looking over the unionfs version of the bug Alan filed (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289700), and a couple of questions jumped out at me:
Sep 8 2025
Sep 7 2025
I hadn't thought about it very much at all TBH, but the 2 very rough ideas I had were either to factor out the newbus walk into a common (gracefully failing) helper that could be used by both iommu_get_requester() and the sysctl handler, or to do as you suggest and change iommu_get_requester() to return an error.
Would it be better to handle the bug in the PR with a few extra checks in the calling DEVICE_SYSCTL_IOMMU code? That would also allow the sysctl to return some string in the sbuf to clearly indicate that the RID can't be determined or is N/A.
Jan 9 2025
Dec 30 2024
Dec 22 2024
Avoid destructive copy
Nov 27 2024
Nov 26 2024
Oops, I didn't see this until after I wrote and tested my own version: https://reviews.freebsd.org/D47769
Nov 25 2024
Nov 7 2024
These appear to be both KPI and KBI-breaking changes, so shouldn't they have included a __FreeBSD_version bump? Also, it looks like you MFCed these to stable/14, don't we at least frown on that kind of breakage in a -stable branch?
Sep 9 2024
Aug 14 2024
- Clarifying tweaks for the tmpfs implementation
Aug 6 2024
Since whiteout-only directory removal will no longer succeed by default outside the union view, should we also change 'rm -rf' to allow whiteouts to be forcibly removed? As @olce alluded to earlier, it looks as though this might just be a one-line change in bin/rm/rm.c to specify FTS_WHITEOUT in the 'fflag' case.
Add IGNOREWHITEOUT flag and adopt in UFS and tmpfs.
Aug 5 2024
Aug 2 2024
@olce Reading back through the discussion here, I'm not sure we're in as much disagreement as it initially seemed.
Jul 26 2024
Jul 25 2024
Jul 17 2024
- Move clearing of rename target dir to more logical location
- Move tmpfs_dir_clear() calls after error checking and detachment from parent
Jul 13 2024
Jul 6 2024
Jul 5 2024
- Use the common cleanup path upon completion of dot-dot lookup This simplifies the code and avoids attempted creation of a negative dot-dot VFS cache entry for a doomed vnode.
@pho You may want to run unionfs19.sh against this patchset. I believe the "forward VOP" guards added in unionfs_lookup() will address the panic seen there.
- Avoid leaking a locked+referenced vnode in the dot-dot lookup case
- Avoid returning a doomed vnode in the dot-dot lookup case
- Simplify a few locking-related checks in unionfs_lookup()
Jul 2 2024
- Add and clarify some comments
Jun 18 2024
- unionfs: do not create a new status object during vop_close()
- Review feedback from olce@, fix for hung process reported by pho@
Jun 14 2024
Jun 13 2024
Jun 12 2024
May 29 2024
These changes have proven stable in the testing I've done so far, but I still see this as a somewhat rough patch.
I expect there will be plenty of review feedback, but my hope is that what I have here can at least be used as a starting point to fix unionfs locking.
Apr 29 2024
Apr 27 2024
Apr 20 2024
Apr 19 2024
- Fix fdvp lock recursion during file copy-up; use ERELOOKUP to simplify
Apr 17 2024
Apr 16 2024
Apr 15 2024
Apr 14 2024
Apr 13 2024
Apr 9 2024
Apr 7 2024
Apr 3 2024
Apr 2 2024
Mar 24 2024
Mar 16 2024
Code review feedback, also remove a nonsensical check from unionfs_link()