| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Porters should refer to __FreeBSD_version 1000021 for this change as
it may have happened at the same timeframe.
|
| |
|
|
|
|
| |
Reviewed by: kib
|
|
|
|
| |
Reviewed by: kib
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a mount point. Active vnodes are those with a non-zero use or hold
count, e.g., those vnodes that are not on the free list. Note that
this list is in addition to the list of all the vnodes associated
with a mount point.
To avoid adding another set of linkage pointers to the vnode
structure, the active list uses the existing linkage pointers
used by the free list (previously named v_freelist, now renamed
v_actfreelist).
This update adds the MNT_VNODE_FOREACH_ACTIVE interface that loops
over just the active vnodes associated with a mount point (typically
less than 1% of the vnodes associated with the mount point).
Reviewed by: kib
Tested by: Peter Holm
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The primary changes are that the user of the interface no longer
needs to manage the mount-mutex locking and that the vnode that
is returned has its mutex locked (thus avoiding the need to check
to see if its is DOOMED or other possible end of life senarios).
To minimize compatibility issues for third-party developers, the
old MNT_VNODE_FOREACH interface will remain available so that this
change can be MFC'ed to 9. Following the MFC to 9, MNT_VNODE_FOREACH
will be removed in head.
The reason for this update is to prepare for the addition of the
MNT_VNODE_FOREACH_ACTIVE interface that will loop over just the
active vnodes associated with a mount point (typically less than
1% of the vnodes associated with the mount point).
Reviewed by: kib
Tested by: Peter Holm
MFC after: 2 weeks
|
|
|
|
| |
Suggested and reviewed by: kib
|
| |
|
|
|
|
|
| |
Noted by: bde
MFC after: 1 week
|
|
|
|
|
|
|
|
|
| |
Add the sysctl debug.iosize_max_clamp, enabled by default. Setting the
sysctl to zero allows to perform the SSIZE_MAX-sized i/o requests from
the usermode.
Discussed with: bde, das (previous versions)
MFC after: 1 month
|
|
|
|
|
|
|
| |
and that all internal kernel calls passing mount flags are declared
as uint64_t so that flags in the top 32-bits are not lost.
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
| |
They are confusing to user, and not informative for general consumption.
MFC after: 1 week
|
|
|
|
|
|
| |
bug fixes by Kuan-Chung Chiu <buganini at gmail dot com>.
Tested by me in production for several days at work.
|
|
|
|
|
|
|
|
|
|
| |
32 bits to 64 bits and eliminates the unused mnt_xflag field. The
existing mnt_flag field is completely out of bits, so this update
gives us room to expand. Note that the f_flags field in the statfs
structure is already 64 bits, so the expanded mnt_flag field can
be exported without having to make any changes in the statfs structure.
Approved by: re (bz)
|
|
|
|
|
|
|
|
|
|
|
| |
method, so that callers can indicate the minimum vnode
locking requirement. This will allow some file systems to choose
to return a LK_SHARED locked vnode when LK_SHARED is specified
for the flags argument. This patch only adds the flag. It
does not change any file system to use it and all callers
specify LK_EXCLUSIVE, so file system semantics are not changed.
Reviewed by: kib
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
root directory of msdosfs mount. The VFS code would handle deletion
case itself too, assuming VV_ROOT flag is not lost. The msdosfs_rename()
should also note attempt to rename root via doscheckpath() or different
mount point check leading to EXDEV. Nonetheless, keep the checks for now.
The change is inspired by NetBSD change referenced in PR, but return
EBUSY like kern_unlinkat() does.
PR: kern/152079
MFC after: 1 week
|
|
|
|
|
|
| |
PR: bin/154928
Submitted by: Eitan Adler <lists at eitanadler.com>
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
and vop_reclaim() methods. They seems to be unused, and the reported
situation is normal for the forced unmount.
MFC after: 1 week
X-MFC-note: keep prtactive symbol in vfs_subr.c
|
|
|
|
|
|
|
|
|
| |
that was used by ".." entry.
This change seems fixed panic during attempt to access msdosfs data
over nfs.
Reviewed by: kib
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
|
| |
breakage for old mount(2) syscall, since most struct <filesystem>_args
embed export_args. The mount(2) is supposed to provide ABI
compatibility for pre-nmount mount(8) binaries, so restore ABI to
pre-r184588.
Requested and reviewed by: bde
MFC after: 2 weeks
|
|
|
|
|
| |
Requested by: danfe
MFC after: 6 days
|
|
|
|
|
|
|
|
|
|
|
| |
a single directory entry. As a consequnce, name cache purge done by lookup
for fvp when DELETE op for namei is specified, might be not enough to
expunge all namecache entries that were installed for this direntry.
Explicitely call cache_purge(fvp) when msdosfs_rename() succeeded.
PR: kern/93634
MFC after: 1 week
|
|
|
|
| |
Submitted by: bde@
|
|
|
|
| |
Reviewed by: kib
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bytes per cluster are calcuated as bytes per sector times sectors per
cluster. Too high value can overflow an internal variable with type
that can hold only values in valid range. Trying to use a wider type
results in an attempt to read more than MAXBSIZE at once, a panic.
Unfortunately, it is FreeBSD newfs_msdos that produces filesystems
with invalid parameters for certain types of media.
Reported by: Fabian Keil <freebsd-listen@fabiankeil.de>,
Paul B. Mahol <onemda@gmail.com>
Discussed with: bde, kib
MFC after: 1 week
X-ToDo: fix newfs_msdos
|
|
|
|
|
|
|
| |
lookup() KASSERTs this condition.
Reported and tested by: pho
MFC after: 3 weeks
|
|
|
|
|
|
|
|
|
|
| |
device is different from the device used to the original mount.
Note that update_mp does not need devvp locked, and pmp->pm_devvp cannot
be freed meantime.
Reported and tested by: pho
MFC after: 3 weeks
|
|
|
|
| |
MFC after: 3 weeks
|
|
|
|
|
| |
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
|
|
|
|
|
|
| |
msdosfs-specific variant of vn_vget_ino(), msdosfs_deget_dotdot().
As was done for UFS, relookup the dotdot denode after the call to
msdosfs_deget_dotdot(), because vnode lock is dropped and directory
might be moved.
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
|
|
| |
on the large FAT volumes. Previously, a single global mutex was used.
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
| |
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
| |
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
|
|
| |
as fat bitmap lock and to replace global mutex protecting fileno rbtree.
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
| |
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
|
|
|
|
|
| |
SLOT_EMPTY deName[0] values. Besides conforming to FAT specification, it
also clears the issue where vfs_hash_insert found the vnode in hash, and
newly allocated vnode is vput()ed. There, deName[0] == 0, and vnode is
not reclaimed, indefinitely kept on mountlist.
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
|
|
| |
causing LOR.
Reported and tested by: pho
MFC after: 3 weeks
|
|
|
|
|
|
|
|
|
|
| |
The plan is to use vnode lock to protect denode and fat cache,
and having separate lock for block use map.
Change the check and return on impossible condition into KASSERT().
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
| |
Tested by: pho
MFC after: 3 weeks
|
|
|
|
|
| |
Pointed out by: bf1783 at gmail
Approved by: np (cxgb), kientzle (tar, etc.), philip (mentor)
|
|
|
|
|
|
| |
Noted by: Pedro F. Giffuni <giffunip tutopia com>
Obtanined from: NetBSD
MFC after: 1 week
|
|
|
|
|
| |
Submitted by: ed
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Update bpb structs with reserved fields.
- In direntry struct join deName with deExtension. Although a
fix was attempted in the past, these fields were being overflowed,
Now this is consistent with the spec, and we can now share the
WinChksum code with NetBSD.
Submitted by: Pedro F. Giffuni <giffunip tutopia com>
Mostly obtained from: NetBSD
Reviewed by: bde
MFC after: 2 weeks
|
|
|
|
|
|
| |
Fix function name in the comment.
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
know better than to commit with a cat in the area.
|
| |
|
|
|
|
|
|
|
| |
It was assumed that r193923 was trivial change that cannot be done
wrong.
MFC after: 2 weeks
|