# ls -ld /mnt/{foo,bar}
drwxr-xr-x 3 root wheel 512 Mar 16 06:56 /mnt/bar
lrwxr-xr-x 1 root wheel 3 Mar 16 12:10 /mnt/foo -> bar
# grep /mnt/foo /etc/fstab
/dev/da1 /mnt/foo ufs rw 0 0
Which means, we give symbolic link as a mount point to mount(8), but mount(8)
use realpath(3) before mounting the file systems, so we get:
# mount | grep /dev/da1
/dev/da1 on /mnt/bar (ufs, local)
Before the commit:
# snapinfo /mnt/foo
usage: snapinfo [-v] -a
snapinfo [-v] mountpoint
# snapinfo /mnt/bar
/mnt/bar/snap
This commit makes snapinfo(8) to first realpath(3) the given mount point and
now we have:
# snapinfo /mnt/foo
/mnt/bar/snap
# snapinfo /mnt/bar
/mnt/bar/snap
point path. This way we properly handle the case when file system listed
in /etc/fstab was unmounted and another file system was mounted on the
same mount point.
prefix) as an argument and mount point path. At the end it has to find
device name file system is stored on, which means when mount point path is
given, it tries to look into /etc/fstab and find special device
corresponding to the given mount point. This is not perfect, because it
doesn't handle the case when file system is mounted by hand and mount point
is given as an argument.
I found this problem while trying to use snapinfo(8), which passes mount
points to the ufs_disk_fillout(3) function, but I had file system mounted
manually, so snapinfo(8) was exiting with the error below:
ufs_disk_fillout: No such file or directory
I modified libufs(3) to handle those arguments (the order is important):
1. special device with /dev/ prefix
2. special device without /dev/ prefix
3. mount point listed in /etc/fstab, directory exists
4. mount point listed in /etc/fstab, directory doesn't exist
5. mount point of a file system mounted by hand
- We need at least two OCBs with indirect pointers allocated in a 4KB page.
- SBP_MAXPHYS can increase to 1MB once we separate management OCB/ORB
which usually does not need indirect pointers.
- We have to increase SBP_DMA_SIZE for MAXPHYS larger than 1MB.
MFC after: 3 days
EVP_CIPHER_CTX_key_length() should return the set key length
in the EVP_CIPHER_CTX structure which may not be the same as
the underlying cipher key length for variable length ciphers.
This fixes problems in OpenSSH using some ciphers, and possibly other
applications.
See also: http://bugzilla.mindrot.org/show_bug.cgi?id=1291
cache coherency, besides of causing train wreck in other places
(especially on amd64, possibly on i386).
Discussed with: kib@, rafan@
Tested by: rafan@
confusions and panic provided that the following conditions are met:
1) WITNESS is enabled (watch/trace).
2) Using modules, instead of statically linked (Not a strict
requirement, but easier to reproduce this way).
3) 2 or more modules share the same mtx type ("sound softc").
- They might share the same name (strcmp() == 0), but it always
point to different address.
4) Repetitive kldunload/load on any module that shares the same mtx
type (Not a strict requirement, but easier to reproduce this way).
Consider module A and module B:
- From enroll() - subr_witness.c:
* Load module A. Everything seems fine right now.
wA-w_refcount == 1 ; wA-w_name = "sound softc"
* Load module B.
* w->w_name == description will always fail.
("sound softc" from A and B point to different address).
* wA->w_refcount > 0 && strcmp(description, wA->w_name) == 0
* enroll() will return wA instead of returning (possibly unique)
wB.
wA->w_refcount++ , == 2.
* Unload module A, mtx_destroy(), wA->w_name become invalid,
but wA->w_refcount-- become 1 instead of 0. wA will not be
removed from witness list.
* Some other places call mtx_init(), iterating witness list,
found wA, failed on wA->w_name == description
* wA->w_refcount > 0 && strcmp(description, wA->w_name)
* Panic on strcmp() since wA->w_name no longer point to valid
address.
Note that this could happened in other places as well, not just sound
(eg. consider lots of drivers that share simmilar MTX_NETWORK_LOCK).
Solutions (for sound case):
1) Provide unique mtx type string for each mutex creation (chosen)
or
2) Put "sound softc" global variable somewhere and use it.
and syncache_respond() into its own generic function tcp_addoptions().
tcp_addoptions() is alignment agnostic and does optimal packing in all cases.
In struct tcpopt rename to_requested_s_scale to just to_wscale.
Add a comment with quote from RFC1323: "The Window field in a SYN (i.e.,
a <SYN> or <SYN,ACK>) segment itself is never scaled."
Reviewed by: silby, mohans, julian
Sponsored by: TCP/IP Optimization Fundraise 2005
- moved away from ifn/ifa access to sctp_ifa/sctp_ifn
built and managed by the add-ip code.
- cleaned up add-ip code to use the iterator
- made iterator be a thread, which enables auto-asconf now.
- rewrote and cleaned up source address selection (also
made it use new structures).
- Fixed a couple of memory leaks.
- DACK now settable as to how many packets to delay as
well as time.
- connectx() to latest socket API, new associd arg.
- Fixed issue with revoking and loosing potential to
send when we inflate the flight size. We now inflate
the cwnd too and deflate it later when the revoked
chunk is sent or acked.
- Got rid of some temp debug code
- src addr selection moved to a common file (sctp_output.c)
- Support for simple VRF's (we have support for multi-vfr
via compile switch that is scrubbed from BSD but we won't
need multi-vrf until we first get VRF :-D)
- Rest of mib work for address information now done
- Limit number of addresses in INIT/INIT-ACK to
a #def (30).
Reviewed by: gnn
affecting the return value from bsdtar), since (a) it usually occurs
due to a perfectly innocent (and unavoidable) race condition where a
user deletes a file in the window between bsdtar reading a directory
and attempting to read the file; and (b) aside from printing a warning
message, bsdtar behaves exactly as if the file had been deleted prior
to bsdtar reading its parent directory.
Reviewed by: kientzle
MFC after: 6 days
boot. Then, just switch to the kernel pmap when suspending instead of
allocating/freeing our own mapping every time. This should solve a panic
of pmap_remove() being called with interrupts disabled. Thanks to Alan
Cox for developing this patch.
Note: this means that ACPI requires super page (PG_PS) support in the CPU.
This has been present since the Pentium and first documented in the
Pentium Pro. However, it may need to be revisited later.
Submitted by: alc
MFC after: 1 month
