Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Console View


Tags: Architectures Platforms default
Legend:   Passed Failed Warnings Failed Again Running Exception Offline No data

Architectures Platforms default
George Wilson
zio can deadlock during device removal

When doing a device removal on a pool with gang blocks, the zio pipeline
can deadlock when trying to free blocks from a device which is being
removed with a stack similar to this:

0xffff8ab9a13a1740 UNINTERRUPTIBLE      4
                  __schedule+0x2e5
                  __schedule+0x2e5
                  schedule+0x33
                  schedule_preempt_disabled+0xe
                  __mutex_lock.isra.12+0x2a7
                  __mutex_lock.isra.12+0x2a7
                  __mutex_lock_slowpath+0x13
                  mutex_lock+0x2c
                  free_from_removing_vdev+0x61
                  metaslab_free_impl+0xd6
                  metaslab_free_dva+0x5e
                  metaslab_free+0x196
                  zio_free_sync+0xe4
                  zio_free_gang+0x38
                  zio_gang_tree_issue+0x42
                  zio_gang_tree_issue+0xa2
                  zio_gang_issue+0x6d
                  zio_execute+0x94
                  zio_execute+0x94
                  taskq_thread+0x23b
                  kthread+0x120
                  ret_from_fork+0x1f

Since there are gang blocks we have to read the gang members as part of
the free. This can be seen with a zio dependency tree that looks like
this:

sdb> echo 0xffff900c24f8a700 | zio -rc | zio
ADDRESS                      TYPE  STAGE            WAITER
0xffff900c24f8a700            NULL  CHECKSUM_VERIFY  0xffff900ddfd31740
0xffff900c24f8c920            FREE  GANG_ASSEMBLE    -
0xffff900d93d435a0            READ  DONE

In the illustration above we are processing frees but because of gang
block we have to read the constituents blocks. Once we finish the READ
in the zio pipeline we will execute the parent. In this case the parent
is a FREE but the zio taskq is a READ and we continue to process the
pipeline leading to the stack above. In the stack above, we are blocked
waiting for the svr_lock so as a result a READ interrupt taskq thread
is now consumed. Eventually, all of the READ taskq threads end up
blocked and we're unable to complete any read requests.

In zio_notify_parent there is an optimization to continue to use
the taskq thread to exectue the parent's pipeline. To resolve the
deadlock above, we only allow this optimization if the parent's
zio type matches the child which just completed.

Signed-off-by: George Wilson <gwilson@delphix.com>
External-issue: DLPX-80130

Pull-request: #14236 part 1/1
George Wilson
nopwrites on dmu_sync-ed blocks can result in a panic

After a device has been removed, any nopwrites for blocks on that
indirect vdev should be ignored and a new block should be allocated. The
original code attempted to handle this but used the wrong block pointer
when checking for indirect vdevs and failed to check all DVAs.

This change corrects both of these issues and modifies the test case
to ensure that it properly tests nopwrites with device removal.

Signed-off-by: George Wilson <gwilson@delphix.com>

Pull-request: #14235 part 1/1
George Wilson
nopwrites on dmu_sync-ed blocks can result in a panic

After a device has been removed, any nopwrites for blocks on that
indirect vdev should be ignored and a new block should be allocated. The
original code attempted to handle this but used the wrong block pointer
when checking for indirect vdevs and failed to check all DVAs.

This change corrects both of these issues and modifies the test case
to ensure that it properly tests nopwrites with device removal.

Signed-off-by: George Wilson <gwilson@delphix.com>

Pull-request: #14235 part 1/1
Richard Yao
Rebase on avx512 code

It is now running faster than the Intel written avx2 code in a KVM guest
on Zen 3:

0 0 0x01 -1 0 1544703784 7905022158
implementation  native        byteswap
scalar          9844805719    9474656265
superscalar      14186756773    12659613432
superscalar4    13727489481    12508784940
generic-avx2    49197257633    2958823554
sse2            22567594300    12265074850
ssse3            22566380108    20582510550
avx2            42224833182    38138634892
fastest          generic-avx2  avx2

The problem with GCC 11.3.0's bad code generation for the byteswap case
is still there.

This works because the total theoretical bandwidth is
51.2GB/sec and Zen 3 is capable of performing two 256-bit vpaddq
operations per cycle according to Agner Fog. i.e. superscalar SIMD is
possible.

Presumably, the sse2 and ssse3 code should be re-evaluated based on the
revelation that superscalar SIMD is possible. They might benefit from
additional accumulator streams.

Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>

Pull-request: #14234 part 3/3
Richard Yao
Add generic fletcher4 vector implementation

This is written using GNU C's generic vector extensions to the C
standard. This compiles on all supported architectures. However,
initially, it only generates vector instructions in the kernel on x86,
x86_64 and power64 when either AVX2 is avaliable or VSX is avaliable.
Other architectures should see something equivalent to superscalar64.i

In userspace, we are more likely to see vector instructions
automatically generated for other architectures, but this depends on
what the compiler is willing to use by default, since we make no attempt
to force vector instruction generation on other architectures.
Coincidentally, the compilers do not give us a generic way of doing that
across all architectures.

Supporting vector instructions on an architecture requires using
compiler pragma directives. At present, there are directives for both
GCC and Clang. ICC was tested and was found to need its own directives,
which were not added, so anyone compiling ZFS with ICC will not have
vector instructions emitted inside the kernel.

For x86 and x86_64, AVX2 will be generated. This is mostly a proof of
concept demonstration that shows that modern compilers are capable of
generating optimal vector instructions from generic vector code. This
comes with a caveat. GCC is actually unable to generate good assembly on
its own, so a single handwritten instruction was added to fix the native
case. In the byteswap case, another instruction is needed by GCC, but
this was not implemented. On the other hand, Clang generates the correct
instructions without any need for help.

For POWER, VSX instructions will be generated. This will only occur on
POWER8 or later with Clang or POWER9 or later with GCC. The assembly
generated by Clang for POWER8 appears optimal. GCC's assembly output
appears substantially less optimal, but it becomes less terrible when
built for POWER9 and later. That is why we require POWER9 as a minimum
for GCC, but only require POWER8 as a minimum for Clang.

Support for AARCH64/ARM was considered, but the build system passes
-mgeneral-regs-only and upon seeing this, both GCC and Clang refuse to
emit NEON instructions. This is incompatible with the idea of
selectively enabling them on key functions, so support for ARM was not
implemented.

Support for SPARC was also considered, but its SIMD instructions have a
maximum 64-bit width. We need greater widths to be able to do 64-bit
additions to be done simultaneously, so it was not possible to use its
SIMD instructions. The result is that the best possible on SPARC is the
superscalar code, which this resembles without vector instructions.

Support for MIPS was also considered, but MIPS Release 5 is required for
that, almost no hardware implements MIPS Release 5 and it was not
apparent how to get the compilers to generate SIMD instructions for it.
It would not surprise me if the compilers do not support MIPS Release
5's SIMD instructions at all.

Support for Loongson was also considered, but a lack of documentation
(depsite it being MIPS-based) prevented it from being done.

Support for S390 was also considered, but it required compiling for the
rather new Z13, and the compilers did not appear to emit vector
instructions for it. Like for MIPS, it is quite possible that the
compilers do not know how to emit them.

Support for RISC-V was also considered. While the RISC-V Vector Extension
was ratified in 2021, it does not appear to be supported by compilers at
this time.

Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>

Pull-request: #14234 part 2/3
Richard Yao
Add POWER ISA 3.00 detection

Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>

Pull-request: #14234 part 1/3
Richard Yao
Add generic fletcher4 vector implementation

This is written using GNU C's generic vector extensions to the C
standard. This compiles on all supported architectures. However,
initially, it only generates vector instructions in the kernel on x86,
x86_64 and power64 when either AVX2 is avaliable or VSX is avaliable.
Other architectures should see something equivalent to superscalar64.i

In userspace, we are more likely to see vector instructions
automatically generated for other architectures, but this depends on
what the compiler is willing to use by default, since we make no attempt
to force vector instruction generation on other architectures.
Coincidentally, the compilers do not give us a generic way of doing that
across all architectures.

Supporting vector instructions on an architecture requires using
compiler pragma directives. At present, there are directives for both
GCC and Clang. ICC was tested and was found to need its own directives,
which were not added, so anyone compiling ZFS with ICC will not have
vector instructions emitted inside the kernel.

For x86 and x86_64, AVX2 will be generated. This is mostly a proof of
concept demonstration that shows that modern compilers are capable of
generating optimal vector instructions from generic vector code. This
comes with a caveat. GCC is actually unable to generate good assembly on
its own, so a single handwritten instruction was added to fix the native
case. In the byteswap case, another instruction is needed by GCC, but
this was not implemented. On the other hand, Clang generates the correct
instructions without any need for help.

For POWER, VSX instructions will be generated. This will only occur on
POWER8 or later with Clang or POWER9 or later with GCC. The assembly
generated by Clang for POWER8 appears optimal. GCC's assembly output
appears substantially less optimal, but it becomes less terrible when
built for POWER9 and later. That is why we require POWER9 as a minimum
for GCC, but only require POWER8 as a minimum for Clang.

Support for AARCH64/ARM was considered, but the build system passes
-mgeneral-regs-only and upon seeing this, both GCC and Clang refuse to
emit NEON instructions. This is incompatible with the idea of
selectively enabling them on key functions, so support for ARM was not
implemented.

Support for SPARC was also considered, but its SIMD instructions have a
maximum 64-bit width. We need greater widths to be able to do 64-bit
additions to be done simultaneously, so it was not possible to use its
SIMD instructions. The result is that the best possible on SPARC is the
superscalar code, which this resembles without vector instructions.

Support for MIPS was also considered, but MIPS Release 5 is required for
that, almost no hardware implements MIPS Release 5 and it was not
apparent how to get the compilers to generate SIMD instructions for it.
It would not surprise me if the compilers do not support MIPS Release
5's SIMD instructions at all.

Support for Loongson was also considered, but a lack of documentation
(depsite it being MIPS-based) prevented it from being done.

Support for S390 was also considered, but it required compiling for the
rather new Z13, and the compilers did not appear to emit vector
instructions for it. Like for MIPS, it is quite possible that the
compilers do not know how to emit them.

Support for RISC-V was also considered. While the RISC-V Vector Extension
was ratified in 2021, it does not appear to be supported by compilers at
this time.

Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>

Pull-request: #14234 part 2/2
Richard Yao
Add POWER ISA 3.00 detection

Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>

Pull-request: #14234 part 1/2
Richard Yao
Add generic fletcher4 vector implementation

This is written using GNU C's generic vector extensions to the C
standard. This compiles on all supported architectures. However,
initially, it only generates vector instructions in the kernel on x86,
x86_64 and power64 when either AVX2 is avaliable or VSX is avaliable.
Other architectures should see something equivalent to superscalar64.i

In userspace, we are more likely to see vector instructions
automatically generated for other architectures, but this depends on
what the compiler is willing to use by default, since we make no attempt
to force vector instruction generation on other architectures.
Coincidentally, the compilers do not give us a generic way of doing that
across all architectures.

Supporting vector instructions on an architecture requires using
compiler pragma directives. At present, there are directives for both
GCC and Clang. ICC was tested and was found to need its own directives,
which were not added, so anyone compiling ZFS with ICC will not have
vector instructions emitted inside the kernel.

For x86 and x86_64, AVX2 will be generated. This is mostly a proof of
concept demonstration that shows that modern compilers are capable of
generating optimal vector instructions from generic vector code. This
comes with a caveat. GCC is actually unable to generate good assembly on
its own, so a single handwritten instruction was added to fix the native
case. In the byteswap case, another instruction is needed by GCC, but
this was not implemented. On the other hand, Clang generates the correct
instructions without any need for help.

For POWER, VSX instructions will be generated. This will only occur on
POWER8 or later with Clang or POWER9 or later with GCC. The assembly
generated by Clang for POWER8 appears optimal. GCC's assembly output
appears substantially less optimal, but it becomes less terrible when
built for POWER9 and later. That is why we require POWER9 as a minimum
for GCC, but only require POWER8 as a minimum for Clang.

Support for AARCH64/ARM was considered, but the build system passes
-mgeneral-regs-only and upon seeing this, both GCC and Clang refuse to
emit NEON instructions. This is incompatible with the idea of
selectively enabling them on key functions, so support for ARM was not
implemented.

Support for SPARC was also considered, but its SIMD instructions have a
maximum 64-bit width. We need greater widths to be able to do 64-bit
additions to be done simultaneously, so it was not possible to use its
SIMD instructions. The result is that the best possible on SPARC is the
superscalar code, which this resembles without vector instructions.

Support for MIPS was also considered, but MIPS Release 5 is required for
that, almost no hardware implements MIPS Release 5 and it was not
apparent how to get the compilers to generate SIMD instructions for it.
It would not surprise me if the compilers do not support MIPS Release
5's SIMD instructions at all.

Support for Loongson was also considered, but a lack of documentation
(depsite it being MIPS-based) prevented it from being done.

Support for S390 was also considered, but it required compiling for the
rather new Z13, and the compilers did not appear to emit vector
instructions for it. Like for MIPS, it is quite possible that the
compilers do not know how to emit them.

Support for RISC-V was also considered. While the RISC-V Vector Extension
was ratified in 2021, it does not appear to be supported by compilers at
this time.

Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>

Pull-request: #14234 part 2/2
Richard Yao
Add POWER ISA 3.00 detection

Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>

Pull-request: #14234 part 1/2
Richard Yao
Add generic fletcher4 vector implementation

This is written using GNU C's generic vector extensions to the C
standard. This compiles on all supported architectures. However,
initially, it only generates vector instructions in the kernel on x86,
x86_64 and power64 when either AVX2 is avaliable or VSX is avaliable.
Other architectures should see something equivalent to superscalar64.i

In userspace, we are more likely to see vector instructions
automatically generated for other architectures, but this depends on
what the compiler is willing to use by default, since we make no attempt
to force vector instruction generation on other architectures.
Coincidentally, the compilers do not give us a generic way of doing that
across all architectures.

Supporting vector instructions on an architecture requires using
compiler pragma directives. At present, there are directives for both
GCC and Clang. ICC was tested and was found to need its own directives,
which were not added, so anyone compiling ZFS with ICC will not have
vector instructions emitted inside the kernel.

For x86 and x86_64, AVX2 will be generated. This is mostly a proof of
concept demonstration that shows that modern compilers are capable of
generating optimal vector instructions from generic vector code. This
comes with a caveat. GCC is actually unable to generate good assembly on
its own, so a single handwritten instruction was added to fix the native
case. In the byteswap case, another instruction is needed by GCC, but
this was not implemented. On the other hand, Clang generates the correct
instructions without any need for help.

For POWER, VSX instructions will be generated. This will only occur on
POWER8 or later with Clang or POWER9 or later with GCC. The assembly
generated by Clang for POWER8 appears optimal. GCC's assembly output
appears substantially less optimal, but it becomes less terrible when
built for POWER9 and later. That is why we require POWER9 as a minimum
for GCC, but only require POWER8 as a minimum for Clang.

Support for AARCH64/ARM was considered, but the build system passes
-mgeneral-regs-only and upon seeing this, both GCC and Clang refuse to
emit NEON instructions. This is incompatible with the idea of
selectively enabling them on key functions, so support for ARM was not
implemented.

Support for SPARC was also considered, but its SIMD instructions have a
maximum 64-bit width. We need greater widths to be able to do 64-bit
additions to be done simultaneously, so it was not possible to use its
SIMD instructions. The result is that the best possible on SPARC is the
superscalar code, which this resembles without vector instructions.

Support for MIPS was also considered, but MIPS Release 5 is required for
that, almost no hardware implements MIPS Release 5 and it was not
apparent how to get the compilers to generate SIMD instructions for it.
It would not surprise me if the compilers do not support MIPS Release
5's SIMD instructions at all.

Support for Loongson was also considered, but a lack of documentation
(depsite it being MIPS-based) prevented it from being done.

Support for S390 was also considered, but it required compiling for the
rather new Z13, and the compilers did not appear to emit vector
instructions for it. Like for MIPS, it is quite possible that the
compilers do not know how to emit them.

Support for RISC-V was also considered. While the RISC-V Vector Extension
was ratified in 2021, it does not appear to be supported by compilers at
this time.

Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>

Pull-request: #14234 part 2/2
Jorgen Lundman
maybe we need to add header files to makefile

Pull-request: #14228 part 11/11
Jorgen Lundman
maybe we need to add header files to makefile

Pull-request: #14228 part 11/11
lundman
Merge branch 'UnifyLinux' of github.com:openzfsonwindows/openzfs into UnifyLinux

Pull-request: #14228 part 10/10
lundman
Add header path to libicp

Pull-request: #14228 part 7/7
lundman
FreeBSD needs one as well

Pull-request: #14228 part 6/6
lundman
FreeBSD needs one as well

Pull-request: #14228 part 6/6
lundman
FreeBSD needs one as well

Pull-request: #14228 part 6/6
lundman
Windows header snuck in there

Pull-request: #14228 part 5/5
Jorgen Lundman
Restore ELF ifdef

Pull-request: #14228 part 4/5
lundman
Add includes for Linux

Pull-request: #14228 part 3/5
Jorgen Lundman
Linux assembler changes

Plus missing file

Signed-off-by: Jorgen Lundman <lundman@lundman.net>

Pull-request: #14228 part 2/5
Jorgen Lundman
All the renames and deletes (Linux)

Pull-request: #14228 part 1/5
Jorgen Lundman
Restore ELF ifdef

Pull-request: #14228 part 4/4
lundman
Add includes for Linux

Pull-request: #14228 part 3/4
Jorgen Lundman
Linux assembler changes

Plus missing file

Signed-off-by: Jorgen Lundman <lundman@lundman.net>

Pull-request: #14228 part 2/4
Jorgen Lundman
All the renames and deletes (Linux)

Pull-request: #14228 part 1/4
Ameer Hamza
zfs_zaccess_trivial() causes deadlock for xattr attributes

zfs_zaccess_trivial() calls the generic_permission() to read
xattr attributes. This may cause deadlock if xattr and dent
locks were already held. This commit add support to prevent
deadlock if dent_lock() is held from generic_permission()
context.

Signed-off-by: Ameer Hamza <ahamza@ixsystems.com>

Pull-request: #14220 part 1/1
Alexander Motin
Micro-optimize zrl_remove().

atomic_dec_32() should be a bit lighter than atomic_dec_32_nv().

Signed-off-by:  Alexander Motin <mav@FreeBSD.org>

Pull-request: #14200 part 1/1
Alexander Motin
Remove few pointer dereferences in dbuf_read().

Signed-off-by:  Alexander Motin <mav@FreeBSD.org>

Pull-request: #14199 part 1/1
Alexander Motin
Switch dnode stats to wmsums.

I've noticed that some of those counters are used in hot paths like
dnode_hold_impl(), and results of this change is visible in profiler.

Signed-off-by:  Alexander Motin <mav@FreeBSD.org>

Pull-request: #14198 part 1/1
szubersk
zfs_setup_cmdline_props(): fix access violation

First check if property is not an user property, then if it is not
ineritable.

Without this fix any user property (enum value -1) causes memory
access violation inside zfs_prop_inheritable().

Signed-off-by: szubersk <szuberskidamian@gmail.com>

Pull-request: #14187 part 8/8
szubersk
zfs_setup_cmdline_props(): fix access violation

First check if property is not an user property, then if it is not
ineritable.

Without this fix any user property (enum value -1) causes memory
access violation inside zfs_prop_inheritable().

Pull-request: #14187 part 8/8
Ameer Hamza
zed: unclean disk attachment faults the vdev

If the attached disk already contains a vdev GUID, it
means the disk is not clean. In such a scenario, the
physical path would be a match that makes the disk
faulted when trying to online it. So, we would only
want to proceed if either GUID matches with the last
attached disk or the disk is in a clean state.

Signed-off-by: Ameer Hamza <ahamza@ixsystems.com>

Pull-request: #14181 part 1/1
Ameer Hamza
zed: unclean disk attachment faults the vdev

If the attached disk already contains a vdev GUID, it
means the disk is not clean. In such a scenario, the
physical path would be a match that makes the disk
faulted when trying to online it. So, we would only
want to proceed if either GUID matches with the last
attached disk or the disk is in a clean state.

Signed-off-by: Ameer Hamza <ahamza@ixsystems.com>

Pull-request: #14181 part 1/1
szubersk
Fix Clang 15 compilation errors

- Clang 15 doesn't support `-fno-ipa-sra` anymore. Do a separate
  check for `-fno-ipa-sra` support by $KERNEL_CC.

- Don't enable `-mgeneral-regs-only` for certain module files.
  Fix #13260

- Scope `GCC diagnostic ignored` statements to GCC only. Clang
  doesn't need them to compile the code.

Signed-off-by: szubersk <szuberskidamian@gmail.com>

Pull-request: #14150 part 2/2
szubersk
Fix GCC 12 compilation errors

Squelch false positives reported by GCC 12 with UBSan.

Signed-off-by: szubersk <szuberskidamian@gmail.com>

Pull-request: #14150 part 1/2
Brian Atkinson
Cleaning up dmu_write_direct_done()

Instead of redirtying the dirty record in the event their is an IO error
with a direct IO write, we should just do like we do on success. This
means just waiting for the other dirty records to sync out so we are
never in an inconsistent state for the TXG's and the dirty records. This
change also allows for further cleanup in the function as well.

Signed-off-by: Brian Atkinson <batkinson@lanl.gov>

Pull-request: #10018 part 7/7
  • FreeBSD stable/13 amd64 (TEST): zfstests failed -  stdiosummary
Brian Atkinson
Additional DEBUGGING

Removing the -r (runtime) parameter to manipulate_user_buffer. We
instead will always only write up to numblocks and manipulate the
buffer. The reason for this is we don't want to limit ourselves to only
8 blocks constantly being overwritten.

Also added in that we should never do reexecution of a ZIO that we have
flagged to have a direct write verify checksum error.

Signed-off-by: Brian Atkinson <batkinson@lanl.gov>

Pull-request: #10018 part 6/6
  • FreeBSD stable/13 amd64 (TEST): zfstests failed -  stdiosummary
Brian Atkinson
Additional DEBUGGING

Removing the -r (runtime) parameter to manipulate_user_buffer. We
instead will always only write up to numblocks and manipulate the
buffer. The reason for this is we don't want to limit ourselves to only
8 blocks constantly being overwritten.

Also added in that we should never do reexecution of a ZIO that we have
flagged to have a direct write verify checksum error.

Signed-off-by: Brian Atkinson <batkinson@lanl.gov>

Pull-request: #10018 part 6/6