Up to [cvs.NetBSD.org] / src / sys / miscfs / genfs
Request diff between arbitrary revisions
Default branch: MAIN
Revision 1.7 / (download) - annotate - [select for diffs], Wed Oct 20 13:29:06 2021 UTC (19 months, 2 weeks ago) by thorpej
Branch: MAIN
CVS Tags: netbsd-10-base,
netbsd-10,
bouyer-sunxi-drm-base,
bouyer-sunxi-drm,
HEAD
Changes since 1.6: +9 -6
lines
Diff to previous 1.6 (colored)
Don't use genfs_rename_knote() in the "rename foo over hard-link to itself" case, which simply results in removing the "from" name; there are assertions in genfs_rename_knote() that are too strong for that case. PR kern/56460
Revision 1.6 / (download) - annotate - [select for diffs], Wed Oct 20 03:08:18 2021 UTC (19 months, 2 weeks ago) by thorpej
Branch: MAIN
Changes since 1.5: +20 -16
lines
Diff to previous 1.5 (colored)
Overhaul of the EVFILT_VNODE kevent(2) filter: - Centralize vnode kevent handling in the VOP_*() wrappers, rather than forcing each individual file system to deal with it (except VOP_RENAME(), because VOP_RENAME() is a mess and we currently have 2 different ways of handling it; at least it's reasonably well-centralized in the "new" way). - Add support for NOTE_OPEN, NOTE_CLOSE, NOTE_CLOSE_WRITE, and NOTE_READ, compatible with the same events in FreeBSD. - Track which kevent notifications clients are interested in receiving to avoid doing work for events no one cares about (avoiding, e.g. taking locks and traversing the klist to send a NOTE_WRITE when someone is merely watching for a file to be deleted, for example). In support of the above: - Add support in vnode_if.sh for specifying PRE- and POST-op handlers, to be invoked before and after vop_pre() and vop_post(), respectively. Basic idea from FreeBSD, but implemented differently. - Add support in vnode_if.sh for specifying CONTEXT fields in the vop_*_args structures. These context fields are used to convey information between the file system VOP function and the VOP wrapper, but do not occupy an argument slot in the VOP_*() call itself. These context fields are initialized and subsequently interpreted by PRE- and POST-op handlers. - Version VOP_REMOVE(), uses the a context field for the file system to report back the resulting link count of the target vnode. Return this in tmpfs, udf, nfs, chfs, ext2fs, lfs, and ufs. NetBSD 9.99.92.
Revision 1.3.18.1 / (download) - annotate - [select for diffs], Sun Sep 13 12:25:29 2020 UTC (2 years, 8 months ago) by martin
Branch: netbsd-9
CVS Tags: netbsd-9-3-RELEASE,
netbsd-9-2-RELEASE,
netbsd-9-1-RELEASE
Changes since 1.3: +88 -25
lines
Diff to previous 1.3 (colored) next main 1.4 (colored)
Pull up following revision(s) (requested by riastradh in ticket #1083): sys/miscfs/genfs/genfs_rename.c: revision 1.5 tests/fs/vfs/t_renamerace.c: revision 1.37 tests/fs/vfs/t_renamerace.c: revision 1.38 tests/fs/vfs/t_renamerace: Test a screw case hannken@ found. genfs_rename: Fix deadlocks in cross-directory cyclic rename. Reproducer: A: for (;;) { mkdir("c", 0600); mkdir("c/d", 0600); mkdir("c/d/e", 0600); rmdir("c/d/e"); rmdir("c/d"); } B: for (;;) { mkdir("c", 0600); mkdir("c/d", 0600); mkdir("c/d/e", 0600); rename("c", "c/d/e"); } C: for (;;) { mkdir("c", 0600); mkdir("c/d", 0600); mkdir("c/d/e", 0600); rename("c/d/e", "c"); } Deadlock: - A holds c and wants to lock d; and either - B holds . and d and wants to lock c, or - C holds . and d and wants to lock c. The problem with these is that genfs_rename_enter_separate in B or C tried lock order .->d->c->e (in A/B, fdvp->tdvp->fvp->tvp; in A/C, tdvp->fdvp->tvp->fvp) which violates the ancestor->descendant order .->c->d->e. The resolution is to change B to do fdvp->fvp->tdvp->tvp and C to do tdvp->tvp->fdvp->fvp. But there's an edge case: tvp and fvp might be the same (hard links), and we can't detect that until after we've looked them both up -- and in some file systems (I'm looking at you, ufs), there is no mere lookup operation, only lookup-and-lock, so we can't even hold the lock on one of tvp or fvp when we look up the other one if there's a chance they might be the same. Fortunately the cases (a) tvp = fvp (b) tvp or fvp is a directory are mutually exclusive as long as directories cannot be hard-linked. In case (a) we can just defer locking {tvp, fvp} until the end, because it can't possibly have {fdvp or fvp, tdvp or tvp} as descendants. In case (b) we can just lock them in the order fdvp->fvp->tdvp->tvp or tdvp->tvp->fdvp->fvp if the first one of {fvp, tvp} is a directory, because it can't possibly coincide with the second one of {fvp, tvp}. With this change, we can now prove that the locking order is consistent with the ancestor->descendant partial ordering. Where two nodes are incommensurate under that partial ordering, they are only ever locked by rename and there is only ever one rename at a time. Proof: - For same-directory renames, genfs_rename_enter_common locks the directory first and then the children. The order directory->child[i] is consistent with ancestor->descendant and child[0]/child[1] are incommensurate. - For cross-directory renames: . While a rename is in progress and the fs-wide rename lock is held, directories can be created or removed but not changed, so the outcome of gro_genealogy -- which, given fdvp and tdvp, returns the node N relating fdvp/N/.../tdvp or null if there is none -- can only transition from finding N to not finding N, if one of the directories is removed while any of the vnodes are unlocked. Merely creating directories cannot change the ancestry of tdvp, and concurrent renames are not possible. Thus, if a gro_genealogy determined the operation to have the form fdvp/N/.../tdvp, then it might cease to have that form, but only because tdvp was removed which will harmlessly cause the rename to fail later on. Similarly, if gro_genealogy determined the operation _not_ to have the form fdvp/N/.../tdvp then it can't begin to have that form until after the rename has completed. The lock order is, => for fdvp/.../tdvp: 1. lock fdvp 2. lookup(/lock/unlock) fvp (consistent with fdvp->fvp) 3. lock fvp if a directory (consistent with fdvp->fvp) 4. lock tdvp (consistent with fdvp->tdvp and possibly fvp->tdvp) 5. lookup(/lock/unlock) tvp (consistent with tdvp->tvp) 6. lock fvp if a nondirectory (fvp->t* or fvp->fdvp is impossible) 7. lock tvp if not fvp (tvp->f* is impossible unless tvp=fvp) => for incommensurate fdvp & tdvp, or for tdvp/.../fdvp: 1. lock tdvp 2. lookup(/lock/unlock) tvp (consistent with tdvp->tvp) 3. lock tvp if a directory (consistent with tdvp->tvp) 4. lock fdvp (either incommensurate with tdvp and/or tvp, or consistent with tdvp(->tvp)->fdvp) 5. lookup(/lock/unlock) fvp (consistent with fdvp->fvp) 6. lock tvp if a nondirectory (tvp->f* or tvp->tdvp is impossible) 7. lock fvp if not tvp (fvp->t* is impossible unless fvp=tvp) Deadlocks found by hannken@; resolution worked out with dholland@. XXX I think we could improve concurrency somewhat -- with a likely big win for applications like tar and rsync that create many files with temporary names and then rename them to the permanent one in the same directory -- by making vfs_renamelock a reader/writer lock: any number of same-directory renames, or exactly one cross-directory rename, at any one time.
Revision 1.5 / (download) - annotate - [select for diffs], Sat Sep 5 02:47:03 2020 UTC (2 years, 9 months ago) by riastradh
Branch: MAIN
CVS Tags: thorpej-i2c-spi-conf2-base,
thorpej-i2c-spi-conf2,
thorpej-i2c-spi-conf-base,
thorpej-i2c-spi-conf,
thorpej-futex2-base,
thorpej-futex2,
thorpej-futex-base,
thorpej-futex,
thorpej-cfargs2-base,
thorpej-cfargs2,
thorpej-cfargs-base,
thorpej-cfargs,
cjep_sun2x-base1,
cjep_sun2x-base,
cjep_sun2x,
cjep_staticlib_x-base1,
cjep_staticlib_x-base,
cjep_staticlib_x
Changes since 1.4: +88 -25
lines
Diff to previous 1.4 (colored)
genfs_rename: Fix deadlocks in cross-directory cyclic rename. Reproducer: A: for (;;) { mkdir("c", 0600); mkdir("c/d", 0600); mkdir("c/d/e", 0600); rmdir("c/d/e"); rmdir("c/d"); } B: for (;;) { mkdir("c", 0600); mkdir("c/d", 0600); mkdir("c/d/e", 0600); rename("c", "c/d/e"); } C: for (;;) { mkdir("c", 0600); mkdir("c/d", 0600); mkdir("c/d/e", 0600); rename("c/d/e", "c"); } Deadlock: - A holds c and wants to lock d; and either - B holds . and d and wants to lock c, or - C holds . and d and wants to lock c. The problem with these is that genfs_rename_enter_separate in B or C tried lock order .->d->c->e (in A/B, fdvp->tdvp->fvp->tvp; in A/C, tdvp->fdvp->tvp->fvp) which violates the ancestor->descendant order .->c->d->e. The resolution is to change B to do fdvp->fvp->tdvp->tvp and C to do tdvp->tvp->fdvp->fvp. But there's an edge case: tvp and fvp might be the same (hard links), and we can't detect that until after we've looked them both up -- and in some file systems (I'm looking at you, ufs), there is no mere lookup operation, only lookup-and-lock, so we can't even hold the lock on one of tvp or fvp when we look up the other one if there's a chance they might be the same. Fortunately the cases (a) tvp = fvp (b) tvp or fvp is a directory are mutually exclusive as long as directories cannot be hard-linked. In case (a) we can just defer locking {tvp, fvp} until the end, because it can't possibly have {fdvp or fvp, tdvp or tvp} as descendants. In case (b) we can just lock them in the order fdvp->fvp->tdvp->tvp or tdvp->tvp->fdvp->fvp if the first one of {fvp, tvp} is a directory, because it can't possibly coincide with the second one of {fvp, tvp}. With this change, we can now prove that the locking order is consistent with the ancestor->descendant partial ordering. Where two nodes are incommensurate under that partial ordering, they are only ever locked by rename and there is only ever one rename at a time. Proof: - For same-directory renames, genfs_rename_enter_common locks the directory first and then the children. The order directory->child[i] is consistent with ancestor->descendant and child[0]/child[1] are incommensurate. - For cross-directory renames: . While a rename is in progress and the fs-wide rename lock is held, directories can be created or removed but not changed, so the outcome of gro_genealogy -- which, given fdvp and tdvp, returns the node N relating fdvp/N/.../tdvp or null if there is none -- can only transition from finding N to not finding N, if one of the directories is removed while any of the vnodes are unlocked. Merely creating directories cannot change the ancestry of tdvp, and concurrent renames are not possible. Thus, if a gro_genealogy determined the operation to have the form fdvp/N/.../tdvp, then it might cease to have that form, but only because tdvp was removed which will harmlessly cause the rename to fail later on. Similarly, if gro_genealogy determined the operation _not_ to have the form fdvp/N/.../tdvp then it can't begin to have that form until after the rename has completed. The lock order is, => for fdvp/.../tdvp: 1. lock fdvp 2. lookup(/lock/unlock) fvp (consistent with fdvp->fvp) 3. lock fvp if a directory (consistent with fdvp->fvp) 4. lock tdvp (consistent with fdvp->tdvp and possibly fvp->tdvp) 5. lookup(/lock/unlock) tvp (consistent with tdvp->tvp) 6. lock fvp if a nondirectory (fvp->t* or fvp->fdvp is impossible) 7. lock tvp if not fvp (tvp->f* is impossible unless tvp=fvp) => for incommensurate fdvp & tdvp, or for tdvp/.../fdvp: 1. lock tdvp 2. lookup(/lock/unlock) tvp (consistent with tdvp->tvp) 3. lock tvp if a directory (consistent with tdvp->tvp) 4. lock fdvp (either incommensurate with tdvp and/or tvp, or consistent with tdvp(->tvp)->fdvp) 5. lookup(/lock/unlock) fvp (consistent with fdvp->fvp) 6. lock tvp if a nondirectory (tvp->f* or tvp->tdvp is impossible) 7. lock fvp if not tvp (fvp->t* is impossible unless fvp=tvp) Deadlocks found by hannken@; resolution worked out with dholland@. XXX I think we could improve concurrency somewhat -- with a likely big win for applications like tar and rsync that create many files with temporary names and then rename them to the permanent one in the same directory -- by making vfs_renamelock a reader/writer lock: any number of same-directory renames, or exactly one cross-directory rename, at any one time.
Revision 1.4 / (download) - annotate - [select for diffs], Sat May 16 18:31:51 2020 UTC (3 years ago) by christos
Branch: MAIN
Changes since 1.3: +3 -3
lines
Diff to previous 1.3 (colored)
Add ACL support for FFS. From FreeBSD.
Revision 1.1.8.2 / (download) - annotate - [select for diffs], Sun Dec 3 11:38:47 2017 UTC (5 years, 6 months ago) by jdolecek
Branch: tls-maxphys
Changes since 1.1.8.1: +0 -6
lines
Diff to previous 1.1.8.1 (colored) to branchpoint 1.1 (colored) next main 1.2 (colored)
update from HEAD
Revision 1.2.6.1 / (download) - annotate - [select for diffs], Mon Aug 28 17:53:08 2017 UTC (5 years, 9 months ago) by skrll
Branch: nick-nhusb
Changes since 1.2: +2 -8
lines
Diff to previous 1.2 (colored) next main 1.3 (colored)
Sync with HEAD
Revision 1.2.10.1 / (download) - annotate - [select for diffs], Wed Apr 26 02:53:27 2017 UTC (6 years, 1 month ago) by pgoyette
Branch: pgoyette-localcount
Changes since 1.2: +2 -8
lines
Diff to previous 1.2 (colored) next main 1.3 (colored)
Sync with HEAD
Revision 1.2.14.1 / (download) - annotate - [select for diffs], Fri Apr 21 16:54:03 2017 UTC (6 years, 1 month ago) by bouyer
Branch: bouyer-socketcan
Changes since 1.2: +2 -8
lines
Diff to previous 1.2 (colored) next main 1.3 (colored)
Sync with HEAD
Revision 1.3 / (download) - annotate - [select for diffs], Thu Mar 30 09:11:12 2017 UTC (6 years, 2 months ago) by hannken
Branch: MAIN
CVS Tags: tls-maxphys-base-20171202,
prg-localcount2-base3,
prg-localcount2-base2,
prg-localcount2-base1,
prg-localcount2-base,
prg-localcount2,
phil-wifi-base,
phil-wifi-20200421,
phil-wifi-20200411,
phil-wifi-20200406,
phil-wifi-20191119,
phil-wifi-20190609,
phil-wifi,
pgoyette-localcount-20170426,
pgoyette-compat-merge-20190127,
pgoyette-compat-base,
pgoyette-compat-20190127,
pgoyette-compat-20190118,
pgoyette-compat-1226,
pgoyette-compat-1126,
pgoyette-compat-1020,
pgoyette-compat-0930,
pgoyette-compat-0906,
pgoyette-compat-0728,
pgoyette-compat-0625,
pgoyette-compat-0521,
pgoyette-compat-0502,
pgoyette-compat-0422,
pgoyette-compat-0415,
pgoyette-compat-0407,
pgoyette-compat-0330,
pgoyette-compat-0322,
pgoyette-compat-0315,
pgoyette-compat,
perseant-stdc-iso10646-base,
perseant-stdc-iso10646,
nick-nhusb-base-20170825,
netbsd-9-base,
netbsd-9-0-RELEASE,
netbsd-9-0-RC2,
netbsd-9-0-RC1,
netbsd-8-base,
netbsd-8-2-RELEASE,
netbsd-8-1-RELEASE,
netbsd-8-1-RC1,
netbsd-8-0-RELEASE,
netbsd-8-0-RC2,
netbsd-8-0-RC1,
netbsd-8,
matt-nb8-mediatek-base,
matt-nb8-mediatek,
jdolecek-ncq-base,
jdolecek-ncq,
isaki-audio2-base,
isaki-audio2,
is-mlppp-base,
is-mlppp,
bouyer-xenpvh-base2,
bouyer-xenpvh-base1,
bouyer-xenpvh-base,
bouyer-xenpvh,
bouyer-socketcan-base1,
ad-namecache-base3,
ad-namecache-base2,
ad-namecache-base1,
ad-namecache-base,
ad-namecache
Branch point for: netbsd-9
Changes since 1.2: +2 -8
lines
Diff to previous 1.2 (colored)
Remove now redundant calls to fstrans_start()/fstrans_done().
Revision 1.1.8.1 / (download) - annotate - [select for diffs], Wed Aug 20 00:04:31 2014 UTC (8 years, 9 months ago) by tls
Branch: tls-maxphys
Changes since 1.1: +6 -0
lines
Diff to previous 1.1 (colored)
Rebase to HEAD as of a few days ago.
Revision 1.1.2.3 / (download) - annotate - [select for diffs], Thu May 22 11:41:05 2014 UTC (9 years ago) by yamt
Branch: yamt-pagecache
Changes since 1.1.2.2: +8 -2
lines
Diff to previous 1.1.2.2 (colored) to branchpoint 1.1 (colored) next main 1.2 (colored)
sync with head. for a reference, the tree before this commit was tagged as yamt-pagecache-tag8. this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments")
Revision 1.1.10.1 / (download) - annotate - [select for diffs], Sun May 18 17:46:09 2014 UTC (9 years ago) by rmind
Branch: rmind-smpnet
Changes since 1.1: +8 -2
lines
Diff to previous 1.1 (colored) next main 1.2 (colored)
sync with head
Revision 1.2 / (download) - annotate - [select for diffs], Thu Feb 6 10:57:12 2014 UTC (9 years, 4 months ago) by hannken
Branch: MAIN
CVS Tags: yamt-pagecache-base9,
tls-maxphys-base,
tls-earlyentropy-base,
tls-earlyentropy,
rmind-smpnet-nbase,
rmind-smpnet-base,
riastradh-xf86-video-intel-2-7-1-pre-2-21-15,
riastradh-drm2-base3,
pgoyette-localcount-base,
pgoyette-localcount-20170320,
pgoyette-localcount-20170107,
pgoyette-localcount-20161104,
pgoyette-localcount-20160806,
pgoyette-localcount-20160726,
nick-nhusb-base-20170204,
nick-nhusb-base-20161204,
nick-nhusb-base-20161004,
nick-nhusb-base-20160907,
nick-nhusb-base-20160529,
nick-nhusb-base-20160422,
nick-nhusb-base-20160319,
nick-nhusb-base-20151226,
nick-nhusb-base-20150921,
nick-nhusb-base-20150606,
nick-nhusb-base-20150406,
nick-nhusb-base,
netbsd-7-nhusb-base-20170116,
netbsd-7-nhusb-base,
netbsd-7-nhusb,
netbsd-7-base,
netbsd-7-2-RELEASE,
netbsd-7-1-RELEASE,
netbsd-7-1-RC2,
netbsd-7-1-RC1,
netbsd-7-1-2-RELEASE,
netbsd-7-1-1-RELEASE,
netbsd-7-1,
netbsd-7-0-RELEASE,
netbsd-7-0-RC3,
netbsd-7-0-RC2,
netbsd-7-0-RC1,
netbsd-7-0-2-RELEASE,
netbsd-7-0-1-RELEASE,
netbsd-7-0,
netbsd-7,
localcount-20160914,
bouyer-socketcan-base
Branch point for: pgoyette-localcount,
nick-nhusb,
bouyer-socketcan
Changes since 1.1: +8 -2
lines
Diff to previous 1.1 (colored)
Move fstrans_start()/fstrans_done() into genfs_insane_rename() to protect the complete rename operation like we do for all other vnode operations.
Revision 1.1.6.2 / (download) - annotate - [select for diffs], Mon Jul 2 18:01:17 2012 UTC (10 years, 11 months ago) by jdc
Branch: netbsd-6
CVS Tags: netbsd-6-1-RELEASE,
netbsd-6-1-RC4,
netbsd-6-1-RC3,
netbsd-6-1-RC2,
netbsd-6-1-RC1,
netbsd-6-1-5-RELEASE,
netbsd-6-1-4-RELEASE,
netbsd-6-1-3-RELEASE,
netbsd-6-1-2-RELEASE,
netbsd-6-1-1-RELEASE,
netbsd-6-1,
netbsd-6-0-RELEASE,
netbsd-6-0-RC2,
netbsd-6-0-RC1,
netbsd-6-0-6-RELEASE,
netbsd-6-0-5-RELEASE,
netbsd-6-0-4-RELEASE,
netbsd-6-0-3-RELEASE,
netbsd-6-0-2-RELEASE,
netbsd-6-0-1-RELEASE,
netbsd-6-0,
matt-nb6-plus-nbase,
matt-nb6-plus-base,
matt-nb6-plus
Changes since 1.1.6.1: +1159 -0
lines
Diff to previous 1.1.6.1 (colored) to branchpoint 1.1 (colored) next main 1.2 (colored)
Pull up revisions: src/sys/conf/files revision 1.1050 src/sys/miscfs/genfs/genfs.h revision 1.30 via patch src/sys/miscfs/genfs/genfs_rename.c revision 1.1 via patch src/sys/rump/librump/rumpvfs/Makefile.rumpvfs revision 1.33 (requested by riastradh in ticket #286). Implement a genfs_rename abstraction. First major step in incrementally adapting all the file systems to a saner rename VOP protocol.
Revision 1.1.4.2 / (download) - annotate - [select for diffs], Sat Jun 2 11:09:36 2012 UTC (11 years ago) by mrg
Branch: jmcneill-usbmp
Changes since 1.1.4.1: +1154 -0
lines
Diff to previous 1.1.4.1 (colored) to branchpoint 1.1 (colored) next main 1.2 (colored)
sync to latest -current.
Revision 1.1.2.2 / (download) - annotate - [select for diffs], Wed May 23 10:08:14 2012 UTC (11 years ago) by yamt
Branch: yamt-pagecache
CVS Tags: yamt-pagecache-tag8
Changes since 1.1.2.1: +1154 -0
lines
Diff to previous 1.1.2.1 (colored) to branchpoint 1.1 (colored)
sync with head.
Revision 1.1.6.1, Tue May 8 23:53:26 2012 UTC (11 years, 1 month ago) by jdc
Branch: netbsd-6
Changes since 1.1: +0 -1154
lines
FILE REMOVED
file genfs_rename.c was added on branch netbsd-6 on 2012-07-02 18:01:17 +0000
Revision 1.1.4.1, Tue May 8 23:53:26 2012 UTC (11 years, 1 month ago) by mrg
Branch: jmcneill-usbmp
Changes since 1.1: +0 -1154
lines
FILE REMOVED
file genfs_rename.c was added on branch jmcneill-usbmp on 2012-06-02 11:09:36 +0000
Revision 1.1.2.1, Tue May 8 23:53:26 2012 UTC (11 years, 1 month ago) by yamt
Branch: yamt-pagecache
Changes since 1.1: +0 -1154
lines
FILE REMOVED
file genfs_rename.c was added on branch yamt-pagecache on 2012-05-23 10:08:14 +0000
Revision 1.1 / (download) - annotate - [select for diffs], Tue May 8 23:53:26 2012 UTC (11 years, 1 month ago) by riastradh
Branch: MAIN
CVS Tags: yamt-pagecache-base8,
yamt-pagecache-base7,
yamt-pagecache-base6,
yamt-pagecache-base5,
riastradh-drm2-base2,
riastradh-drm2-base1,
riastradh-drm2-base,
riastradh-drm2,
khorben-n900,
jmcneill-usbmp-base10,
agc-symver-base,
agc-symver
Branch point for: yamt-pagecache,
tls-maxphys,
rmind-smpnet,
netbsd-6,
jmcneill-usbmp
Implement a genfs_rename abstraction. First major step in incrementally adapting all the file systems to a saner rename VOP protocol.