| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
| |
Found by: clang static analyzer
Reviewed by: ed
Differential Revision: https://reviews.freebsd.org/D4722
|
|
|
|
|
|
|
|
|
| |
NLM (rpc.lockd) is running can crash the system.
Unfortunately this is not easy to fix, but I have left
PR#200585 open.
PR: 200585
MFC after: 3 days
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
|
| | |
|
| |\
| |/
|/| |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | | |
Requested by: Simon Gerraty <sjg@juniper.net>
|
| |_|/
|/| |
| | |
| | |
| | | |
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
|
| |/
|/|
| |
| |
| |
| | |
mount_nfs effectively uses mount protocol v3 by default already.
v1 mount protocol is being removed along with nfsv2 by a high profile NFS
appliance vendor and our legacy v1 mount protocol usage causes rpc errors.
|
|/
|
|
|
|
|
| |
PR: bin/172553
Submitted by: Erik Cederstrand <erik@cederstrand.dk>
Approved by: cperciva
MFC after: 3 days
|
|
|
|
|
|
| |
These tools declare global variables without using the static keyword,
even though their use is limited to a single C-file, or without placing
an extern declaration of them in the proper header file.
|
|
|
|
| |
to unmount /dev as it will always fail.
|
|
|
|
|
|
|
|
| |
for forced dismount when used on an NFS mount point. Requested by
Jeremy Chadwick.
This is a content change.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a sync(2) syscall before unmount(2) for the "-f" case.
This avoids a forced dismount from getting stuck for
an NFS mountpoint in sync() when the server is not
responsive. With this commit, forced dismounts should
normally work for the NFS clients, but can take up to
about 1minute to complete.
PR: kern/157365
Reviewed by: kib
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since the existing implementation searches ':' backward, a path which
includes ':' could not be mounted. You can now mount such path by
enclosing an IP address by '[]'.
Though we should change to search ':' forward, it will break
'ipv6addr:path' which is currently working. So, it still searches ':'
backward, at least for now.
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Cast delimiter width to integer [1]
- Solve name conflicts against system header
- Constify parameters to avoid qualifier conflict
PR: bin/140017 [1]
Submitted by: Ulrich Spörlein <uqs spoerlein net> [1]
MFC after: 1 month
Sponsored by: iXsystems, Inc
|
|
|
|
|
|
| |
by root.
Approved by: re (kib)
|
|
|
|
| |
and will be removed.
|
| |
|
|
|
|
|
|
| |
per letter dated July 22, 1999.
Approved by: core, imp
|
| |
|
|
|
|
| |
Use WARNS?= instead of WARNS=.
|
|
|
|
|
|
|
|
|
| |
is all zeros. The kernel now consistently zeroes FSIDs for non-root
users, so there's no point in printing these. Also fix a misspelling
in a comment.
Submitted by: Rudolf Cejka <cejkar@fit.vutbr.cz>
Approved by: re (scottl)
|
|
|
|
|
|
|
| |
a non-fsid unmount if the file system ID is all zeros. This is a
temporary workaround for warnings that occur in the vfs.usermount=1
case because non-root users get a zeroed filesystem ID. I have a
more complete fix in the works, but I won't get it done for 5.2.
|
|
|
|
|
| |
of the name if it is '/'. Also fix a comparison between signed and
unsigned quantities (pointed out by trhodes).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and make it work more reliably in a number of cases that have
traditionally been troublesome. The new behaviour is:
1) If the filesystem can be determined by the fsid or device,
or uniquely identified by the mountpoint, then just go ahead
and call unmount(2) using the file system ID.
2) Otherwise use fstatfs(2) to resolve the path into a file system
ID (checking with stat(2) that it is a filesystem root directory).
Case 2 can potentially block if an NFS server is down, but it can
always be avoided by using an unambiguous specification. It handles
all the hard cases such as symlinks and mismatches between the mount
list and reality. For example, if a filesystem was mounted as /mnt
inside a chroot, it will show up in the mount list as /mnt, but now
you can unmount it from outside the chroot with "umount /chroot_path/mnt".
|
|
|
|
|
|
|
|
|
|
|
|
| |
ID for each file system in addition to the normal information.
In umount(8), accept filesystem IDs as well as the usual device and
path names. This makes it possible to unambiguously specify which
file system is to be unmounted even when two or more file systems
share the same device and mountpoint names (e.g. NFS mounts from
the same export into different chroots).
Suggested by: Dan Nelson <dnelson@allantgroup.com>
|
|
|
|
| |
includes the filesystem type name, remove the "type" output parameter.
|
|
|
|
|
|
|
|
| |
of by mount point, umount had to take care not to unmount the wrong
file system if another file system was covering the requested one.
Now that the file system to unmount is specified to the kernel using
the filesystem ID, this confusion cannot occur, so remove the code
that checked for it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
system by specifying the file system ID instead of a path. Use this
by default in umount(8). This avoids the need to perform any vnode
operations to look up the mount point, so it makes it possible to
unmount a file system whose root vnode cannot be looked up (e.g.
due to a dead NFS server, or a file system that has become detached
from the hierarchy because an underlying file system was unmounted).
It also provides an unambiguous way to specify which file system is
to be unmunted.
Since the ability to unmount using a path name is retained only for
compatibility, that case now just uses a simple string comparison
of the supplied path against f_mntonname of each mounted file system.
Discussed on: freebsd-arch
mdoc help from: ru
|
| |
|
| |
|
|
|
|
| |
Requested by: ru
|
|
|
|
| |
specify an alternate fstab file.
|
| |
|
| |
|
|
|
|
| |
especially in troff files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make getvfsbyname() take a struct xvfsconf *.
- Convert several consumers of getvfsbyname() to use struct xvfsconf.
- Correct the getvfsbyname.3 manpage.
- Create a new vfs.conflist sysctl to dump all the struct xvfsconf in the
kernel, and rewrite getvfsbyname() to use this instead of the weird
existing API.
- Convert some {set,get,end}vfsent() consumers to use the new vfs.conflist
sysctl.
- Convert a vfsload() call in nfsiod.c to kldload() and remove the useless
vfsisloadable() and endvfsent() calls.
- Add a warning printf() in vfs_sysctl() to tell people they are using
an old userland.
After these changes, it's possible to modify struct vfsconf without
breaking the binary compatibility. Please note that these changes don't
break this compatibility either.
When bp will have updated mount_smbfs(8) with the patch I sent him, there
will be no more consumers of the {set,get,end}vfsent(), vfsisloadable()
and vfsload() API, and I will promptly delete it.
|
| |
|
| |
|
|
|
|
|
|
| |
Binary builds that cannot handle this must explicitly set WARNS=0.
Reviewed by: mike
|