User Details
- User Since
- Mar 25 2015, 11:24 AM (505 w, 5 d)
Wed, Nov 27
Tue, Nov 26
Oops, I didn't see this until after I wrote and tested my own version: https://reviews.freebsd.org/D47769
Mon, Nov 25
Thu, Nov 7
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()
Mar 10 2024
Mar 4 2024
Feb 29 2024
Incorporate code review feedback from olce@
Feb 24 2024
This basically amounts to a generalized version of the mkdir()-specific fix I made last year in commit 93fe61afde72e6841251ea43551631c30556032d (of course in that commit I also inadvertently added a potential v_usecount ref leak on the new vnode). Or I guess it can be thought of as a tailored version of null_bypass().
Feb 23 2024
Only clear LK_SHARED
Only allow lkflags to be 0 when the corresponding vnode is NULL
This is needed for upcoming work to adopt VOP_UNP_* in unionfs.