We use extended attribute mount mutex before testing if it had been
initialized, and as reported by Christos, this caused panic with
LOCKDEBUG. Fix it by testing before using.
As Masao Uebayashi pointed to me, UFS_EXTATTR_AUTOSTART, LFS_EXTATTR_AUTOSTART
and UFS_EXTATTR_AUTOCREATE are not used anywhere in the code. Remove them
as they have been obsolete for a long time:
UFS_EXTATTR_AUTOSTART was replaced by mount -o extattr
LFS_EXTATTR_AUTOSTART was created to match obsolete UFS_EXTATTR_AUTOSTART
UFS_EXTATTR_AUTOCREATE was replaced by sysctl vfs.ffs.extattr_autocreate
UFS1 extended attribute backend autocration goes through a vn_open()
to create the backend file, and this forces us to release the lock
on the target node, in case the target is within the parents of the
backend file. That created a window within which another thread could
acquire a lock on the target vnode and deadlock awaiting for the
mount extended attribute lock.
We fix the problem by also releasing the mount extended attribute lock
when calling vn_open(), but that lets another thread race us for backend
creation. We just detect this using O_EXCL for vn_open() and by checking
for EEXIST return code. If we are raced, we fail backend creation but
this is not a problem since another thread succeeded on it: we just have
to use the result.
When unmount failed, for instance because the mount is still busy,
UFS1 extended attributes structures were left freed while the kernel
assumes extended attributes were still enabled. This led to using
UFS1 extended attributes structures after free. With LOCKDEBUG, with
quickly triggers a panic.
The problem is fixed by:
1) clear MNT_EXTATTR flag after extended attributes structures are freed
2) attempt to restart extended attributes after failed unmount
2) set MNT_EXTATTR correctly after extended attributes restart
As a side effect, extended attribute structures are now only initialized
when extended attributes are started for the filesystem.
find.
The filesystem ones all call genfs_eopnotsupp - right now I am only
implementing the plumbing and we can implement fallocate and/or
fdiscard for files later.
The device ones call spec_fallocate (which is also genfs_eopnotsupp)
and spec_fdiscard, which dispatches to the device-level op.
The fifo ones all call vn_fifo_bypass, which also ends up being
EOPNOTSUPP.
src/sys/sys/quotactl.h 1.37
src/sys/compat/netbsd32/netbsd32.h 1.101
src/sys/compat/netbsd32/netbsd32_netbsd.c 1.188, 1.189
src/sys/kern/vfs_quotactl.c 1.39
src/sys/kern/vfs_syscalls.c 1.483
src/sys/ufs/lfs/ulfs_quota.c 1.11
src/sys/ufs/ufs/ufs_quota.c 1.116
src/lib/libquota/quota_kernel.c 1.5
and do them correctly.
If you're going to change the name of something, you need to change
the name of *all* the things with the same name, not just a handful,
and you should change it to something similar so it still matches the
rest of the system rather than just picking an arbitrarily different
name.
Hi, Joerg.
To wit, rename the quotactl "delete" operation to "del", because
"delete" is a reserved word in C++ and for some reason Joerg wants to
run internal interfaces used only by C code through his C++ compiler.
Do not rename it to "remove" instead, because this doesn't match
libquota or the rest of the usage throughout the system; and rename
all the related identifiers, not just the ones that blew the mind of
Joerg's C++ compiler.
Because this is not a user-facing API (the only userland consumer
sys/quotactl.h is libquota) it is sort of ok to make arbitrary
source-incompatible changes; however, by the same token it's completely
unnecessary. If it *were* a user-facing API that someone might have a
semi-rational reason to want to run a C++ compiler on, it would be
incorrect to change it at this point.
need to vget() vnodes that we are not interested at, and optimize locking
a bit. Iterator changes reviewed by Hannken (thanks), the rest of the bugs
are mine.
manu