7454d2bb behlendorf1 Jan. 27, 2021, 12:11 a.m.
Explicitly check for NULL to satisfy cppcheck that "val" can never
be NULL when passed to printf().  This looks like a false positive
since is_blank_str() can never take the false conditional branch
when passed a NULL.  But there's no harm in adding the extra check.

Reviewed-by: Ryan Moeller <ryan@ixsystems.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #11508
62d4287f noreply Jan. 27, 2021, 12:05 a.m.
When scrubbing, (non-sequential) resilvering, or correcting a checksum
error using RAIDZ parity, ZFS should heal any incorrect RAIDZ parity by
overwriting it.  For example, if P disks are silently corrupted (P being
the number of failures tolerated; e.g. RAIDZ2 has P=2), `zpool scrub`
should detect and heal all the bad state on these disks, including
parity.  This way if there is a subsequent failure we are fully

With RAIDZ2 or RAIDZ3, a block can have silent damage to a parity
sector, and also damage (silent or known) to a data sector.  In this
case the parity should be healed but it is not.

The problem can be noticed by scrubbing the pool twice.  Assuming there
was no damage concurrent with the scrubs, the first scrub should fix all
silent damage, and the second scrub should be "clean" (`zpool status`
should not report checksum errors on any disks).  If the bug is
encountered, then the second scrub will repair the silently-damaged
parity that the first scrub failed to repair, and these checksum errors
will be reported after the second scrub.  Since the first scrub repaired
all the damaged data, the bug can not be encountered during the second
scrub, so subsequent scrubs (more than two) are not necessary.

The root cause of the problem is some code that was inadvertently added
to `raidz_parity_verify()` by the DRAID changes.  The incorrect code
causes the parity healing to be aborted if there is damaged data
(`rc_error != 0`) or the data disk is not present (`!rc_tried`).  These
checks are not necessary, because we only call `raidz_parity_verify()`
if we have the correct data (which may have been reconstructed using
parity, and which was verified by the checksum).

This commit fixes the problem by removing the incorrect checks in

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #11489 
Closes #11510
6c7a932d tsoome Jan. 26, 2021, 11:07 p.m.
If kernel is built without VT vbefb driver, make sure
we start kernel in text mode.
93ebd630 tsoome Jan. 26, 2021, 11:07 p.m.
Set refcount for loader provided font to 1 to prevent this font
from being released (so we can reset to default).

PR: 252833
7a731da5 marius Jan. 26, 2021, 10:02 p.m.
ndis(4) has been removed in bfc99943b04b46a6c1c885ce7bcc6f235b7422aa
and its build option in 84876bf70222c4e10144d034119f7f455f99813c.
84876bf7 marius Jan. 26, 2021, 9:59 p.m.
ndis(4) has been removed in bfc99943b04b46a6c1c885ce7bcc6f235b7422aa.
173f6ce1 marius Jan. 26, 2021, 9:51 p.m.
ndis(4) has been removed in bfc99943b04b46a6c1c885ce7bcc6f235b7422aa.
f39b4996 marius Jan. 26, 2021, 9:46 p.m.
The latter has been removed in bfc99943b04b46a6c1c885ce7bcc6f235b7422aa.
c1655b0f marius Jan. 26, 2021, 9:28 p.m.
It's rather confusing when adapter->hw and hw are mixed and matched
within a particular function.
Some of this was missed in cd1cf2fc1d49c509ded05dcd41b7600a5957fb9a
and r353778 respectively.
f1c010d9 olivier Jan. 26, 2021, 9:19 p.m.
Approved by:    oshogbo
Sponsored by:   Netflix
Differential Revision: https://reviews.freebsd.org/D2834
d7265b33 noreply Jan. 26, 2021, 9:14 p.m.
- refactor cleanup routines into common kshlib zpool_export_cleanup func
- don't require physical disks to test, just use files

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by:	Will Andrews <will@firepipe.net>
Closes #11518
a098a831 mjg Jan. 26, 2021, 8:42 p.m.
The code was performing an avoidable check for doomed state to account
for foo being a VDIR but turning VBAD. Now that dooming puts a vnode
in a permanent "modify" state this is no longer necessary as the final
status check will catch it.
a51eca79 mjg Jan. 26, 2021, 8:42 p.m.
Said use is a remnant from the old code and clashes with the NCF_INVALID
caedada6 noreply Jan. 26, 2021, 8:14 p.m.
zfs-load-key.sh is called by the dracut-pre-mount.service unit which has
no explicit 'After' dependency on zfs-import.target. That way it can be
that the pool has not yet been imported and the zfs-load-key.sh finishes
without ever seeing the relevant pool.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Lorenz Hüdepohl <dev@stellardeath.org>
Closes #11500
8c22cf9b mckusick Jan. 26, 2021, 7:46 p.m.
A long-standing bug in Pass 1 of fsck_ffs in which it is reading in
blocks of inodes to check their block pointers. It failed to round
up the size of the read to a disk block size. When disks would
accept 512-byte aligned reads, the bug rarely manifested itself.
But many recent disks will no longer accept 512-byte aligned reads
but require 4096-byte aligned reads, so the failure to properly
round-up read sizes to multiples of 4096 bytes makes the error
much more likely to occur.

Reported by:  Peter Holm and others
Tested by:    Peter Holm and Rozhuk Ivan
MFC after:    3 days
Sponsored by: Netflix