History log of /freebsd/sys/fs/unionfs/union_vnops.c (Results 26 – 50 of 399)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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


12345678910>>...16