until after the jail is found or created. This requires unlocking the
jail for the call and re-locking it afterward, but that works because
nothing in the jail has been changed yet, and other processes won't
change the important fields as long as allprison_lock remains held.
Keep better track of name vs namelc in kern_jail_set. Name should
always be the hierarchical name (relative to the caller), and namelc
the last component.
PR: 48471
MFC after: 5 days
removed from the user perspective, i.e. when the last pr_uref goes away,
even though the jail mail still exist in the dying state. It will also
be called if either PR_METHOD_CREATE or PR_METHOD_SET fail.
PR: 48471
MFC after: 5 days
a jail that might be seen mid-removal. It hasn't been doing the right
thing since at least the ability to resurrect dying jails, and such
resurrection also makes it unnecessary.
When ORing in a register_t to a wider integer (vm_paddr_t), it gets sign
extended, so high addresses overwrite the upper word with all 0xf. Cast to the
unsigned form (u_register_t), to avoid this problem, and get correct addresses
printed.
With this, a static environment can be compiled in via config(5). This allows,
among other things, the use of a compiled-in debug console (hw.uart.dbgport) for
kgdb.
Use own protosw structures for both address families.
Check proto in encapcheck function and use -1 as proto argument in
encap_attach_func(), both address families can have IPPROTO_IPV4
and IPPROTO_IPV6 protocols.
Reported by: bz
RFC3173 says that the IP datagram MUST be sent in the original
non-compressed form, when the total size of a compressed payload
and the IPComp header is not smaller than the size of the original
payload. In tunnel mode for small packets IPComp will send
encapsulated IP datagrams without IPComp header.
Add ip_encap handler for IPPROTO_IPV4 and IPPROTO_IPV6 to handle
these datagrams. The handler does lookup for SA related to IPComp
protocol and given from mbuf source and destination addresses as
tunnel endpoints. It decapsulates packets only when corresponding SA
is found.
Reported by: gnn
Reviewed by: gnn
Differential Revision: https://reviews.freebsd.org/D6062
It was reported via email that a Linux client couldn't do a Kerberized
NFS mount when only "sec=krb5" was specified for the exports. The Linux
client attempted a mount via krb5i and the server replied NFSERR_SERVERFAULT.
Although NFSERR_WRONGSEC isn't listed as an error for SetClientID, I
think it is the correct reply, so this patch enables that.
I do not know if this fixes the mount attempt, but adding "krb5i" to the
list of allowed security flavours does allow the mount to work.
Reported by: joef@spectralogic.com
MFC after: 2 weeks
undefined symbol svr4_delete_socket which was moved from streams to the svr4 module
in r160558 that created a two-way dependency between them.
PR: 208464
Submitted by: Kristoffer Eriksson
Reported by: Kristoffer Eriksson
MFC after: 2 week
h_levels_num, as most data structs in ext2fs, is unsigned so
the index that addresses it has to be unsigned as well.
To get to overflow here we would probably be considering a
degenerate case though.
MFC after: 5 days
The purpose of this file was to simply detect the UART speed before
attaching the actual ns8250 driver so that we don't have to specify the
UART speed in DTS files.
However, OpenWRT DTS files specify ns16550a as a compatible string in
their DTS files and this makes the original ns8250 driver attach to
the device. So we would have to edit the DTS files anyway and since this
is only the case for MT7621 and MT7628/MT7688 for now, it's better to
just add the clock-frequency property to those (UART is always clocked
by the same clock in both these SoCs, so that's fine) instead of having
a separate driver and still having to change the DTS files.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6044
The introduction of palmbus and previous work allows us to cut the
differences between FreeBSD and OpenWRT DTS files a bit further.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6043
This allows us to come closer to OpenWRT vanilla DTS files.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6045
This allows us to get closer to OpenWRT DTS files and minimize the diffs
a little more.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6042
The ordering of acquisition of the state and session mutexes was
reversed in two cases executed when an NFSv4.1 client created/freed
a session. Since clients will typically do this only when mounting
and dismounting, the likelyhood of causing a deadlock was low but possible.
This can only occur for NFSv4.1 mounts, since the others do not
use sessions.
This was detected while testing the pNFS server/client where the
client crashed during dismounting.
The patch also reorders the unlocks, although that isn't necessary
for correct operation.
MFC after: 2 weeks
- Added check that the SCOPE ID is only restored for IPv6 linklocal
addresses.
- Changes made by r237263 in the "cma_bind_addr()" function did not
check if the socket address was of type IPv6 and used the IPv4
socket address for IPv6 addresses. This caused the function to
fail. Fixed this.
- In the "rdma_gid2ip()" function and some other places the "sin6_len"
and "sin6_scope_id" fields were not set for IPv6 socket
addresses. Fixed this.
- The scope ID is not stored as part of the GID entries and must be
passed as an argument to "rdma_gid2ip()".
- Added new method to "struct ib_device" which returns a pointer to
the network interface which belongs to the given infiniband
device. This is needed to be able to get the scope ID for IPv6
addresses via the associated ethernet interface.
- Added convenience function, "rdma_get_ipv6_scope_id()", to get the
scope ID for IPv6 addresses.
- Implemented new "get_netdev" method for mlx4ib. Other IB controller
drivers which want to support IPv6 addresses needs to implement this
aswell.
- Bumped the FreeBSD version due to changing "struct ib_device".
Sponsored by: Mellanox Technologies
MFC after: 1 week
Both of the callers were expecting the input cap_set to be modified.
This fixes them to request cap_set to be updated with the returned buffer.
Reviewed by: jkim
Differential Revision: https://reviews.freebsd.org/D6040
Does what it says on the tin; this unbreaks 32-bit builds.
Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D5764
This extracts common code from bhndb_pci, bhnd_pcib, and bhnd_pci_hostb into a
simpler shared bhnd_pci base driver, and should enable SoC-side implementation
of bhnd_pcib root complex support.
Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D5763
While the instructions were not included into the original instruction
set, their support can be indicated by a special feature bit.
For example:
CPU: AMD Phenom(tm) II X4 955 Processor (3214.71-MHz K8-class CPU)
...
AMD Features2=0x37ff<LAHF, ...>
Clang 3.8 uses lahf/sahf as a faster alternative to pushf/popf where
possible.
MFC after: 2 weeks
illumos/illumos-gate@26455f9efc26455f9efchttps://www.illumos.org/issues/6052
At the moment type parameter of lzc_create() is of dmu_objset_type_t type.
That exposes an implementation detail and requires sys/fs/zfs.h to be included
in libzfs_core.h creating unnecessary coupling between libzfs_core interface
and ZFS internals.
I think that dmu_objset_type_t should be replaced with a libzfs_core
enumeration of supported dataset types.
For ABI reasons the new enumeration could be bit-compatible with
dmu_objset_type_t.
For example:
typedef enum {
LZC_DST_ZFS = 2,
LZC_DST_ZVOL
} lzc_dataset_type_t;
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Richard Lowe <richlowe@richlowe.net>
Author: Andriy Gapon <andriy.gapon@clusterhq.com>
MFC after: 2 weeks
Sponsored by: ClusterHQ
Such situation is defined as UNPREDICTABLE by arm arm manual.
This patch fixes all explicit TLB fetches which could cause this issue
and speculative TLB fetches for sections mapped in user address space.
Speculative TLB fetches for sections mapped in kernel address space are
not fixed yet as the break-before-make approach must be implemented for
kernel mappings too. This means that promoted/demoted section will be
unmapped for a while. Either kernel stack the promotion/demotion is
being done on or L1 page table(s) which must be modified may be mapped
by this section. Thus the fix will not be so simple like for userland
mappings.
The issue was detectable only on Cortex-A8 platforms and only very
rarely. It was reported few times. First, it was by Mikael Urankar
in June 2015. He helped to identify the mechanism of this issue, but
we were not sure how to fix it correctly until now.
PR: 208381
Reported by: Mikael Urankar (mikael.urankar at gmail.com)
Reviewed by: kib
This fixes a kernel panic when using IPoIB with VIMAGE and infiniband.
PR: 208957
Sponsored by: Mellanox Technologies
Tested by: Justin Clift <justin@postgresql.org>
MFC after: 1 week
and R/W emulation aborts under pmap lock.
There were two reasons for using of atomic operations:
(1) the pmap code is based on i386 one where they are used,
(2) there was an idea that access and R/W emulation aborts should be
handled as quick as possible, without pmap locking.
However, the atomic operations in i386 pmap code are used only because
page table entries may be modified by hardware. At the beginning, we
were not sure that it's the only reason. So even if arm hardware does
not modify them, we did not risk to not use them at that time. Further,
it turns out after some testing that using of pmap lock for access and
R/W emulation aborts does not bring any extra cost and there was no
measurable difference. Thus, we have decided finally to use pmap lock
for all operations on page table entries and so, there is no reason for
atomic operations on them. This makes the code cleaner and safer.
This decision introduce a question if it's safe to use pmap lock for
access and R/W emulation aborts. Anyhow, there may happen two cases in
general:
(A) Aborts while the pmap lock is locked already - this should not
happen as pmap lock is not recursive. However, under pmap lock only
internal kernel data should be accessed and such data should be mapped
with A bit set and NM bit cleared. If double abort happens, then
a mapping of data which has caused it must be fixed.
(B) Aborts while another lock(s) is/are locked - this already can
happen. There is no difference here if it's either access or R/W
emulation abort, or if it's some other abort.
Reviewed by: kib
(PL1) and unprivileged (PL0) read/write access. As cp15 virtual to
physical address translation operations are used, interrupts must be
disabled to get consistent result when they are called.
These functions should be used only in very specific occasions like
during abort handling or kernel debugging. One of them is going to be
used in pmap_fault(). However, complete function set is added. It cost
nothing, as they are inlined.
While here, fix comment of #endif.
Reviewed by: kib
Submitted by: Jun Su <junsu microsoft com>
Reviewed by: sephe, Dexuan Cui <decui microsoft com>
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D5957
