#
d877dd57 |
| 22-Dec-2021 |
Jason A. Harmening <jah@FreeBSD.org> |
unionfs: simplify writecount management
Use atomics to track the writecount granted to the underlying FS, and avoid holding the vnode interlock while calling the underling FS' VOP_ADD_WRITECOUNT().
unionfs: simplify writecount management
Use atomics to track the writecount granted to the underlying FS, and avoid holding the vnode interlock while calling the underling FS' VOP_ADD_WRITECOUNT(). This also fixes a WITNESS warning about nesting the same lock type. Also add comments explaining why we need to track the writecount on the unionfs vnode in the first place. Finally, simplify writecount management to only use the upper vnode and assert that we shouldn't have an active writecount on the lower vnode through unionfs.
Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D33611
show more ...
|
#
b214fcce |
| 14-Dec-2021 |
Alan Somers <asomers@FreeBSD.org> |
Change VOP_READDIR's cookies argument to a **uint64_t
The cookies argument is only used by the NFS server. NFSv2 defines the cookie as 32 bits on the wire, but NFSv3 increased it to 64 bits. Our V
Change VOP_READDIR's cookies argument to a **uint64_t
The cookies argument is only used by the NFS server. NFSv2 defines the cookie as 32 bits on the wire, but NFSv3 increased it to 64 bits. Our VOP_READDIR, however, has always defined it as u_long, which is 32 bits on some architectures. Change it to 64 bits on all architectures. This doesn't matter for any in-tree file systems, but it matters for some FUSE file systems that use 64-bit directory cookies.
PR: 260375 Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D33404
show more ...
|
Revision tags: release/12.3.0 |
|
#
cfc2cfec |
| 15-Nov-2021 |
Jason A. Harmening <jah@FreeBSD.org> |
unionfs: implement VOP_VPUT_PAIR
unionfs must pass VOP_VPUT_PAIR directly to the underlying FS so that it can have a chance to manage any special locking considerations that may be necessary. The u
unionfs: implement VOP_VPUT_PAIR
unionfs must pass VOP_VPUT_PAIR directly to the underlying FS so that it can have a chance to manage any special locking considerations that may be necessary. The unionfs implementation is based heavily on the corresponding nullfs implementation.
Also note some outstanding issues with the unionfs locking scheme, as a first step in fixing those issues in a future change.
Discussed with: kib Tested by: pho Differential Revision: https://reviews.freebsd.org/D33008
show more ...
|
#
6d8420d4 |
| 15-Nov-2021 |
Jason A. Harmening <jah@FreeBSD.org> |
Remove unnecessary thread argument from unionfs_nodeget() and _noderem()
Also remove a couple of write-only variables found by the recent clang update. No functional change intended.
Discussed wit
Remove unnecessary thread argument from unionfs_nodeget() and _noderem()
Also remove a couple of write-only variables found by the recent clang update. No functional change intended.
Discussed with: kib Differential Revision: https://reviews.freebsd.org/D33008
show more ...
|
#
87360699 |
| 24-Nov-2021 |
Mateusz Guzik <mjg@FreeBSD.org> |
unionfs: plug a set-but-not-unused var
Sponsored by: Rubicon Communications, LLC ("Netgate")
|
#
06f79675 |
| 14-Nov-2021 |
Jason A. Harmening <jah@FreeBSD.org> |
unionfs: fix potential deadlock in VOP_RMDIR
VOP_RMDIR() is called with both parent and child directory vnodes locked. The relookup operation performed by the unionfs implementation may relock both
unionfs: fix potential deadlock in VOP_RMDIR
VOP_RMDIR() is called with both parent and child directory vnodes locked. The relookup operation performed by the unionfs implementation may relock both vnodes. Accordingly, unionfs_relookup() drops the parent vnode lock, but the child vnode lock is never dropped. Although relookup() will very likely try to relock the child vnode which is already locked, in most cases this doesn't produce a deadlock because unionfs_lock() forces LK_CANRECURSE (!). However, relocking of the parent vnode while the child vnode remains locked effectively reverses the expected parent->child lock order, which can produce a deadlock e.g. in the presence of a concurrent unionfs_lookup() operation. Address the issue by dropping the child lock around the unionfs_relookup() call in unionfs_rmdir().
Reported by: pho Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D32986
show more ...
|
#
152c35ee |
| 26-Sep-2021 |
Jason A. Harmening <jah@FreeBSD.org> |
unionfs: Ensure SAVENAME is set for unionfs vnode operations
"rm-style" system calls such as kern_frmdirat() and kern_funlinkat() don't supply SAVENAME to preserve the pathname buffer for subsequent
unionfs: Ensure SAVENAME is set for unionfs vnode operations
"rm-style" system calls such as kern_frmdirat() and kern_funlinkat() don't supply SAVENAME to preserve the pathname buffer for subsequent vnode ops. For unionfs this poses an issue because the pathname may be needed for a relookup operation in unionfs_remove()/unionfs_rmdir(). Currently unionfs doesn't check for this case, leading to a panic on DIAGNOSTIC kernels and use-after-free of cn_nameptr otherwise.
The unionfs node's stored buffer would suffice as a replacement for cnp->cn_nameptr in some (but not all) cases, but it's cleaner to just ensure that unionfs vnode ops always have a valid cn_nameptr by setting SAVENAME in unionfs_lookup().
While here, do some light cleanup in unionfs_lookup() and assert that HASBUF is always present in the relevant relookup calls.
Reported by: pho Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D32148
show more ...
|
#
312d49ef |
| 31-Aug-2021 |
Jason A. Harmening <jah@FreeBSD.org> |
unionfs: style
Fix the more egregious style(9) violations in unionfs. No functional change intended.
|
#
abe95116 |
| 29-Aug-2021 |
Jason A. Harmening <jah@FreeBSD.org> |
unionfs: rework pathname handling
Running stress2 unionfs tests reliably produces a namei_zone corruption panic due to unionfs_relookup() attempting to NUL-terminate a newly- allocate pathname buffe
unionfs: rework pathname handling
Running stress2 unionfs tests reliably produces a namei_zone corruption panic due to unionfs_relookup() attempting to NUL-terminate a newly- allocate pathname buffer without first validating the buffer length.
Instead, avoid allocating new pathname buffers in unionfs entirely, using already-provided buffers while ensuring the the correct flags are set in struct componentname to prevent freeing or manipulation of those buffers at lower layers.
While here, also compute and store the path length once in the unionfs node instead of constantly invoking strlen() on it.
Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D31728
show more ...
|
Revision tags: release/13.0.0, release/12.2.0 |
|
#
e2515283 |
| 27-Aug-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
8f226f4c |
| 19-Aug-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
vfs: remove the always-curthread td argument from VOP_RECLAIM
|
Revision tags: release/11.4.0 |
|
#
cc3593fb |
| 13-Jan-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
vfs: rework vnode list management
The current notion of an active vnode is eliminated.
Vnodes transition between 0<->1 hold counts all the time and the associated traversal between different lists
vfs: rework vnode list management
The current notion of an active vnode is eliminated.
Vnodes transition between 0<->1 hold counts all the time and the associated traversal between different lists induces significant scalability problems in certain workloads.
Introduce a global list containing all allocated vnodes. They get unlinked only when UMA reclaims memory and are only requeued when hold count reaches 0.
Sample result from an incremental make -s -j 104 bzImage on tmpfs: stock: 118.55s user 3649.73s system 7479% cpu 50.382 total patched: 122.38s user 1780.45s system 6242% cpu 30.480 total
Reviewed by: jeff Tested by: pho (in a larger patch, previous version) Differential Revision: https://reviews.freebsd.org/D22997
show more ...
|
#
b249ce48 |
| 03-Jan-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
vfs: drop the mostly unused flags argument from VOP_UNLOCK
Filesystems which want to use it in limited capacity can employ the VOP_UNLOCK_FLAGS macro.
Reviewed by: kib (previous version) Differenti
vfs: drop the mostly unused flags argument from VOP_UNLOCK
Filesystems which want to use it in limited capacity can employ the VOP_UNLOCK_FLAGS macro.
Reviewed by: kib (previous version) Differential Revision: https://reviews.freebsd.org/D21427
show more ...
|
#
4a20fe31 |
| 03-Jan-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
unionfs: fix up VOP_UNLOCK use after flags stopped being supported
For the most part the code was passing the LK_RELEASE flag. The 2 cases which did not use the VOP_UNLOCK_FLAGS macro.
This fixes a
unionfs: fix up VOP_UNLOCK use after flags stopped being supported
For the most part the code was passing the LK_RELEASE flag. The 2 cases which did not use the VOP_UNLOCK_FLAGS macro.
This fixes a panic when stacking unionfs on top of e.g., tmpfs when debug is enabled.
Note there are latent bugs which prevent unionfs from working with debug regardless of this change.
PR: 243064 Reported by: Mason Loring Bliss
show more ...
|
#
6fa079fc |
| 16-Dec-2019 |
Mateusz Guzik <mjg@FreeBSD.org> |
vfs: flatten vop vectors
This eliminates the following loop from all VOP calls:
while(vop != NULL && \ vop->vop_spare2 == NULL && vop->vop_bypass == NULL) vop = vop->vop_default;
Revie
vfs: flatten vop vectors
This eliminates the following loop from all VOP calls:
while(vop != NULL && \ vop->vop_spare2 == NULL && vop->vop_bypass == NULL) vop = vop->vop_default;
Reviewed by: jeff Tesetd by: pho Differential Revision: https://reviews.freebsd.org/D22738
show more ...
|
Revision tags: release/12.1.0 |
|
#
c5c3ba6b |
| 03-Sep-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r351317 through r351731.
|
#
1e2f0ceb |
| 28-Aug-2019 |
Mateusz Guzik <mjg@FreeBSD.org> |
vfs: add VOP_NEED_INACTIVE
vnode usecount drops to 0 all the time (e.g. for directories during path lookup). When that happens the kernel would always lock the exclusive lock for the vnode in order
vfs: add VOP_NEED_INACTIVE
vnode usecount drops to 0 all the time (e.g. for directories during path lookup). When that happens the kernel would always lock the exclusive lock for the vnode in order to call vinactive(). This blocks other threads who want to use the vnode for looukp.
vinactive is very rarely needed and can be tested for without the vnode lock held.
This patch gives filesytems an opportunity to do it, sample total wait time for tmpfs over 500 minutes of poudriere -j 104:
before: 557563641706 (lockmgr:tmpfs) after: 46309603301 (lockmgr:tmpfs)
Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21371
show more ...
|
#
48407115 |
| 27-Aug-2019 |
Mateusz Guzik <mjg@FreeBSD.org> |
unionfs: stop passing LK_INTERLOCK to VOP_UNLOCK
This is part of the preparation to remove flags argument from VOP_UNLOCK. Also has a side effect of fixing stacking on top of nullfs broken by r35147
unionfs: stop passing LK_INTERLOCK to VOP_UNLOCK
This is part of the preparation to remove flags argument from VOP_UNLOCK. Also has a side effect of fixing stacking on top of nullfs broken by r351472.
Reported by: cy Sponsored by: The FreeBSD Foundation
show more ...
|
#
30d49d53 |
| 01-Aug-2019 |
Konstantin Belousov <kib@FreeBSD.org> |
Try to decrease the number of bugs in unionfs after the VV_TEXT flag removal.
- Provide unionfs_add_writecount() which passes the writecount to the lower or upper vnode as appropriate. - In unionf
Try to decrease the number of bugs in unionfs after the VV_TEXT flag removal.
- Provide unionfs_add_writecount() which passes the writecount to the lower or upper vnode as appropriate. - In unionfs VOP_RECLAIM() implementation, annulate unionfs writecounts from upper or lower vnode. It is not clear that it is always correct to remove the all references from either lower or upper vnode, but we currently do not track which vnode get how many refs anyway.
Reported and tested by: t_uemura@macome.co.jp MFC after: 1 week Sponsored by: The FreeBSD Foundation
show more ...
|
Revision tags: release/11.3.0, release/12.0.0, release/11.2.0 |
|
#
82725ba9 |
| 23-Nov-2017 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Merge ^/head r325999 through r326131.
|
#
51369649 |
| 20-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for
sys: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point.
show more ...
|
Revision tags: release/10.4.0, release/11.1.0 |
|
#
348238db |
| 01-Mar-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r314420 through r314481.
|
#
fbbd9655 |
| 01-Mar-2017 |
Warner Losh <imp@FreeBSD.org> |
Renumber copyright clause 4
Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is
Renumber copyright clause 4
Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu> Pull Request: https://github.com/freebsd/freebsd/pull/96
show more ...
|
Revision tags: release/11.0.1, release/11.0.0 |
|
#
27067774 |
| 16-Aug-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r303250 through r304235.
|
#
569e9018 |
| 13-Aug-2016 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead @ r304038
|