using vn_fullpath_global(). This fixes f_mntonname if mounting
inside chroot, jail or with relative path as argument.
For unmount in jail, use vn_fullpath_global() to discover
global path from supplied path argument. This fixes unmount in jail.
Reviewed by: pjd, kib
Approved by: re (kib)
MFC after: 2 weeks
In particular:
- fix format specifiers in the DPRINTFs;
- do not use kernel_map for temporal mapping backed by the vnode, this
cannot work since kernel map is a system map. Use exec_map instead.
- ignore error code from an attempt to insert the hole. If supposed hole
is located at the region already populated by .bss, it is not an error.
- correctly translate vm error codes to errno, when appropriate.
Reported and tested by: Rich Naill <rich enterprisesystems net>
Approved by: re (kensmith)
MFC after: 1 week
It seems that "info as" is not much precise on what expect by pseudo-op
.word, by the way.
No MFC is previewed for this patch.
Tested by: andreast, pluknet
Approved by: re (kib)
Juniper's loader is that Juniper's loader maps all of the kernel and
preloaded modules at the right virtual address before jumping into the
kernel. FreeBSD's loader simply maps 16MB using the physical address
and expects the kernel to jump through hoops to relocate itself to
it's virtual address. The problem with the FreeBSD loader's approach is
that it typically maps too much or too little. There's no harm if it's
too much (other than wasting space), but if it's too little then the
kernel will simply not boot, because the first thing the kernel needs
is the bootinfo structure, which is never mapped in that case. The page
fault that early is fatal.
The changes constitute:
1. Do not remap the kernel in locore.S. We're mapped where we need to
be so we can pretty much call into C code after setting up the
stack.
2. With kernload and kernload_ap not set in locore.S, we need to set
them in pmap.c: kernload gets defined when we preserve the TLB1.
Here we also determine the size of the kernel mapped. kernload_ap
is set first thing in the pmap_bootstrap() method.
3. Fix tlb1_map_region() and its use to properly externd the mapped
kernel size to include low-level data structures.
Approved by: re (blanket)
Obtained from: Juniper Networks, Inc
This was reported to the mailing list freebsd-net@freebsd.org
on July 21, 2011 under the subject "LOR with nfsclient sillyrename".
The LOR occurred when nfs_inactive() called vrele(sp->s_dvp)
while holding the vnode lock on the file in s_dvp. This patch
modifies the client so that it performs the vrele(sp->s_dvp)
as a separate task to avoid the LOR. This fix was discussed
with jhb@ and kib@, who both proposed variations of it.
Tested by: pho, jlott at averesystems.com
Submitted by: jhb (earlier version)
Reviewed by: kib
Approved by: re (kib)
MFC after: 2 weeks
zfsvfs->z_log before calling zil_commit(). [1]
Do not call zfs_read() from zfs_getextattr() with the IO_SYNC flag.
Submitted by: Alexander Zagrebin <alex@zagrebin.ru> [1]
Reviewed by: pjd@
Approved by: re (kib)
MFC after: 3 days
This was reported to the mailing list freebsd-net@freebsd.org
on July 21, 2011 under the subject "LOR with nfsclient sillyrename".
The LOR occurred when nfs_inactive() called vrele(sp->s_dvp)
while holding the vnode lock on the file in s_dvp. This patch
modifies the client so that it performs the vrele(sp->s_dvp)
as a separate task to avoid the LOR. This fix was discussed
with jhb@ and kib@, who both proposed variations of it.
Tested by: pho, jlott at averesystems.com
Submitted by: jhb (earlier version)
Reviewed by: kib
Approved by: re (kib)
MFC after: 2 weeks
Mac with this chipset does not initialize AHCI mode unless it is started
from EFI loader. However, legacy ATA mode works.
Submitted by: jkim@ (original version)
Approved by: re (kib)
MFC after: 1 week
truly.
Before 802.11n, the RX descriptor list would employ the "self-linked tail
descriptor" trick which linked the last descriptor back to itself.
This way, the RX engine would never hit the "end" of the list and stop
processing RX (and assert RXEOL) as it never hit a descriptor whose next
pointer was 0. It would just keep overwriting the last descriptor until
the software freed up some more RX descriptors and chained them onto the
end.
For 802.11n, this needs to stop as a self-linked RX descriptor tickles the
block-ack logic into ACK'ing whatever frames are received into that
self-linked descriptor - so in very busy periods, you could end up with
A-MPDU traffic that is ACKed but never received by the 802.11 stack.
This would cause some confusion as the ADDBA windows would suddenly
be out of sync.
So when that occured here, the last descriptor would be hit and the PCU
logic would stop. It would only start again when the RX descriptor list
was updated and the PCU RX engine was re-tickled. That wasn't being done,
so RXEOL would be continuously asserted and no RX would continue.
This patch introduces a new flag - sc->sc_kickpcu - which when set,
signals the RX task to kick the PCU after its processed whatever packets
it can. This way completed packets aren't discarded.
In case some other task gets called which resets the hardware, don't
update sc->sc_imask - instead, just update the hardware interrupt mask
directly and let either ath_rx_proc() or ath_reset() restore the imask
to its former setting.
Note: this bug was only triggered when doing a whole lot of frame snooping
with serial console IO in the RX task. This would defer interrupt processing
enough to cause an RX descriptor overflow. It doesn't happen in normal
conditions.
Approved by: re (kib, blanket)
configured swap devices in the Linux-compatible format.
Based on the submission by: Robert Millan <rmh debian org>
PR: kern/159281
Reviewed by: bde
Approved by: re (kensmith)
MFC after: 2 weeks
dynamic memory allocation to hold per-CPU memory types data (sized to
mp_maxid for UMA, and to mp_maxcpus for malloc to match the kernel).
That fixes libmemstat with arbitrary large MAXCPU values and therefore
eliminates MEMSTAT_ERROR_TOOMANYCPUS error type.
Reviewed by: jhb
Approved by: re (kib)
recursive vnode lock on the directory for the case where the
new file name is in the same directory as the old one. The patch
handles this as a special case, recognized by the new directory
having the same file handle as the old one and just VREF()s the old
dir vnode for this case, instead of doing a second VFS_FHTOVP() to get it.
This is required so that the server will work for file systems like
msdosfs, that do not support recursive vnode locking.
This problem was discovered during recent testing by pho@
when exporting an msdosfs file system via the new NFS server.
Tested by: pho
Reviewed by: zkirsch
Approved by: re (kib)
MFC after: 2 weeks
interrupt storm.
This is easily triggered by flipping on and off tcpdump -y IEEE802_11_RADIO
w/ witness enabled. This causes a whole lot of console IO and when you're
attached to a serial console (eg on my AR7161 embedded board), the RX
interrupt doesn't get called quickly enough and the RX queue fills up.
This wasn't a problem in the past because of the self-linked RX descriptor
trick - the RX would never hit the "end" of the RX descriptor list.
However this isn't possible for 802.11n (see previous commit history for
why.)
Both Linux ath9k and the Atheros reference driver code do this; I'm just
looking now for where they then restart the PCU receive. Right now the RX
will just stop until the interface is reset.
Obtained from: Linux, Atheros
Approved by: re (kib)
The AR9280 apparently has an issue with descriptors which straddle a page
boundary (4k). I'm not yet sure whether I should use PAGE_SIZE in the
calculations or whether I should use 4096; the reference code uses 4096.
This patch fiddles with descriptor allocation so a descriptor entry
doesn't straddle a 4kb address boundary. The descriptor memory allocation
is made larger to contain extra descriptors and then the descriptor
address is advanced to the next 4kb boundary where needed.
I've tested this both on Merlin (AR9280) and non-Merlin (in this case,
AR9160.)
Obtained from: Linux, Atheros
Approved by: re (kib)
from NetBSD, with some slight changes:
=========================================================================================
http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/tftpd/tftpd.8?only_with_tag=MAIN#rev1.22
Revision 1.22 or diffs], Fri Jan 8 21:05:14 2010 UTC (18 months, 2 weeks ago) by christos
Patrick Welche <prlw1@cam.ac.uk>
- add -p pathsep option
- make wrap to zero work, but produce a warning
While here:
- fix gcc warnings, in particular variable clobbered warnings
(compiling with fewer warnings does not really fix the problem)
=========================================================================================
These wording changes clarify the default rollover behavior
as a "kludge". Also, the block numbers and octet counts for 65535 blocks
and 32767 blocks are more accurate than the existing documented numbers.
Requested by: Pawan Gupta <pawang at juniper dot net>
Obtained from: Juniper Networks
Approved by: re (kib)
the block counter would rollover to 0 if a file larger
than 65535 blocks was transferred. With the default block size
of 512 octets per block, this is a file size of approximately 32 megabytes.
The new TFTP server code would report an error and stop transferring
the file if a file was larger than 65535 blocks.
This patch restores the old TFTP server's behavior to the new
TFTP server code. If a TFTP client transfers a file larger
than 65535 blocks, and does *not* specify the "rollover" option,
then automatically rollover the block counter to 0 every time
we reach 65535 blocks.
This restores interoperability with the FreeBSD 6 TFTP client.
Without this change, if a FreeBSD 6 TFTP client tried to
retrieve a file larger than 65535 blocks from a FreeBSD 9 TFTP server
, the transfer would fail.
The same file could be retrieved successfully if the same FreeBSD 6
TFTP client was used against a FreeBSD 6 TFTP server.
Approved by: re (kib)
Tested by: Pawan Gupta <pawang at juniper dot net>,
Obtained from: Juniper Networks
historic behavior (create the default base directory in pw.conf) before
I came up with a better fix for this.
Requested by: nwhitehorn
Approved by: re (kib)
failed after the file was created in nfs_create(). This would
probably only happen during a forced dismount. The old NFS client
does have a vput() for this case. Detected by pho during recent
testing, where an open syscall returned with a vnode still locked.
Tested by: pho
Approved by: re (kib)
MFC after: 2 weeks
This is a followup to r222032 and a reimplementation of it.
While that revision fixed the race for the smp_rv_waiters[2] exit
sentinel, it still left a possibility for a target CPU to access
stale or wrong smp_rv_func_arg in smp_rv_teardown_func.
To fix this race the slave CPUs signal when they are really fully
done with the rendezvous and the master CPU waits until all slaves
are done.
Diagnosed by: kib
Reviewed by: jhb, mlaier, neel
Approved by: re (kib)
MFC after: 2 weeks
in the case of a held dataset during remount.
Detailed description is available at:
https://www.illumos.org/issues/883
illumos-gate revision: 13380:161b964a0e10
Reviewed by: pjd
Approved by: re (kib)
Obtained from: Illumos (Bug #883)
MFC after: 3 days
as anonymous namespaces are local to the current translation.
GCC PR: c++/33094
Reviewed by: uqs
Approved by: re (kib)
Obtained from: gcc (branches/redhat/gcc-4_1-branch, rev. 129554, GPLv2)
MFC after: 1 week
allocated the device pager for the given handle, then the object
fictitious pages list and the object membership in the global object
list still need to be initialized. Otherwise, dev_pager_dealloc() will
traverse uninitialized pointers.
Reported and tested by: pho
Reviewed by: jhb
Approved by: re (kensmith)
MFC after: 1 week
