Revert r327828, r327949, r327953, r328016-r328026, r328041:
Uses of mallocarray(9).

The use of mallocarray(9) has rocketed the required swap to build FreeBSD.
This is likely caused by the allocation

Revert r327828, r327949, r327953, r328016-r328026, r328041:
Uses of mallocarray(9).

The use of mallocarray(9) has rocketed the required swap to build FreeBSD.
This is likely caused by the allocation size attributes which put extra pressure
on the compiler.

Given that most of these checks are superfluous we have to choose better
where to use mallocarray(9). We still have more uses of mallocarray(9) but
hopefully this is enough to bring swap usage to a reasonable level.

Reported by: wosch
PR: 225197

show more ...

dev: make some use of mallocarray(9).

Focus on code where we are doing multiplications within malloc(9). None of
these is likely to overflow, however the change is still useful as some
static checke

dev: make some use of mallocarray(9).

Focus on code where we are doing multiplications within malloc(9). None of
these is likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.

This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.

show more ...

MFhead@r320180

Merge ^/head r319973 through 321382.

Merge ^/head r320398 through r320572.

Clean up MD pollution of bus_dma.h:

--Remove special-case handling of sparc64 bus_dmamap* functions.
Replace with a more generic mechanism that allows MD busdma
implementations to generate inlin

Clean up MD pollution of bus_dma.h:

--Remove special-case handling of sparc64 bus_dmamap* functions.
Replace with a more generic mechanism that allows MD busdma
implementations to generate inline mapping functions by
defining WANT_INLINE_DMAMAP in <machine/bus_dma.h>. This
is currently useful for sparc64, x86, and arm64, which all
implement non-load dmamap operations as simple wrappers
around map objects which may be bus- or device-specific.

--Remove NULL-checked bus_dmamap macros. Implement the
equivalent NULL checks in the inlined x86 implementation.
For non-x86 platforms, these checks are a minor pessimization
as those platforms do not currently allow NULL maps. NULL
maps were originally allowed on arm64, which appears to have
been the motivation behind adding arm[64]-specific barriers
to bus_dma.h, but that support was removed in r299463.

--Simplify the internal interface used by the bus_dmamap_load*
variants and move it to bus_dma_internal.h

--Fix some drivers that directly include sys/bus_dma.h
despite the recommendations of bus_dma(9)

Reviewed by: kib (previous revision), marius
Differential Revision: https://reviews.freebsd.org/D10729

show more ...

Merge ^/head r318380 through r318559.

xen/blkfront: correctly detach a disk with active users

Call disk_gone when the backend switches to the "Closing" state and blkfront
still has pending users. This allows the disk to be detached, and

xen/blkfront: correctly detach a disk with active users

Call disk_gone when the backend switches to the "Closing" state and blkfront
still has pending users. This allows the disk to be detached, and will call
into xbd_closing by itself when the geom layout cleanup has finished.

Reported by: bapt
Tested by: manu
Reviewed by: bapt
Sponsored by: Citrix Systems R&D
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D10772

show more ...

xen: add support for canceled suspend

When running on Xen, it's possible that a suspend request to the hypervisor
fails (return from HYPERVISOR_suspend different than 0). This means that the
suspend

xen: add support for canceled suspend

When running on Xen, it's possible that a suspend request to the hypervisor
fails (return from HYPERVISOR_suspend different than 0). This means that the
suspend hasn't succeed, and the resume procedure needs to properly handle this
case.

First of all, when such situation happens there's no need to reset the vector
callback, hypercall page, shared info, event channels or grant table, because
it's state is preserved. Also, the PV drivers don't need to be reset to the
initial state, since the connection with the backed has not been interrupted.

Submitted by: Liuyingdong <liuyingdong@huawei.com>
Reviewed by: royger
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D9635

show more ...

Merge ^/head r309817 through r310168.

In xbd_connect(), use correct scanf conversion specifiers for the
feature_barrier and feature_flush variables. Otherwise, adjacent
variables on the stack, such as sector_size, may be overwritten, wi

In xbd_connect(), use correct scanf conversion specifiers for the
feature_barrier and feature_flush variables. Otherwise, adjacent
variables on the stack, such as sector_size, may be overwritten, with
disastrous results.

Note that I did not see a good reason to revert the addition of zero
checks introduced in r310013. Better safe than sorry.

PR: 215209
Tested by: royger
MFC after: 3 days

show more ...

Check that blkfront devices have a non-zero number of sectors and a
non-zero sector size. Such a device would be a virtual disk of zero
bytes; clearly not useful, and not something we should try to

Check that blkfront devices have a non-zero number of sectors and a
non-zero sector size. Such a device would be a virtual disk of zero
bytes; clearly not useful, and not something we should try to attach.

As a fortuitous side effect, checking that these values are non-zero
here results in them not *becoming* zero later on the function. This
odd behaviour began with r309124 (clang 3.9.0) but is challenging to
debug; making any changes to this function whatsoever seems to affect
the llvm optimizer behaviour enough to make the unexpected zeroing of
the sector_size variable cease.

PR: 215209
Security: The potential for variables to unexpectedly become zero
has worrying consequences for security in general, but
not so much in this particular context.

show more ...

sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

MFH

Sponsored by: The FreeBSD Foundation

Pass through some new block device features.

MFC after: 1 month

Merge ^/head r295601 through r295844.

MFH

Sponsored by: The FreeBSD Foundation

Don't dereference a pointer immediately after determining that it is
equal to NULL. [1]

While I'm here, s/xb/xbd/ (the name changed a long time ago but this
instance wasn't corrected).

Reported by:

Don't dereference a pointer immediately after determining that it is
equal to NULL. [1]

While I'm here, s/xb/xbd/ (the name changed a long time ago but this
instance wasn't corrected).

Reported by: PVS-Studio [1]

show more ...

MFH @r294567

Merge ^/head r293686 through r293849.

MFH

Sponsored by: The FreeBSD Foundation

Add two more assertions to catch busdma problems. Each segment provided
by busdma to the blkfront driver must be an integer number of sectors,
and must be aligned in memory on a "sector" boundary.

Add two more assertions to catch busdma problems. Each segment provided
by busdma to the blkfront driver must be an integer number of sectors,
and must be aligned in memory on a "sector" boundary.

Having these assertions yesterday would have made finding the bug fixed
in r293698 somewhat easier.

show more ...

MFH r289384-r293170

Sponsored by: The FreeBSD Foundation

Catch up with head (r291075).

xen-blkfront: add support for unmapped IO

Using unmapped IO is really beneficial when running inside of a VM,
since it avoids IPIs to other vCPUs in order to invalidate the
mappings.

This patch add

xen-blkfront: add support for unmapped IO

Using unmapped IO is really beneficial when running inside of a VM,
since it avoids IPIs to other vCPUs in order to invalidate the
mappings.

This patch adds unmapped IO support to blkfront. The following tests
results have been obtained when running on a Xen host without HAP:

PVHVM
3165.84 real 6354.17 user 4483.32 sys
PVHVM with unmapped IO
2099.46 real 4624.52 user 2967.38 sys

This is because when running using shadow page tables TLB flushes and
range invalidations are much more expensive, so using unmapped IO
provides a very important performance boost.

Sponsored by: Citrix Systems R&D
MFC after: 2 weeks
X-MFC-with: r290610

dev/xen/blkfront/blkfront.c:
- Add and announce support for unmapped IO.

show more ...