Fixes to get bits running on Linux: #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1. Fix type in expression 2. Fix up vdev_name() 3. Add support for properties.vdev in SYSFS
allanjude
pushed a commit
that referenced
this pull request
Jul 30, 2021
`zpool_do_import()` passes `argv[0]`, (optionally) `argv[1]`, and
`pool_specified` to `import_pools()`. If `pool_specified==FALSE`, the
`argv[]` arguments are not used. However, these values may be off the
end of the `argv[]` array, so loading them could dereference unmapped
memory. This error is reported by the asan build:
```
=================================================================
==6003==ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 8 at 0x6030000004a8 thread T0
#0 0x562a078b50eb in zpool_do_import zpool_main.c:3796
#1 0x562a078858c5 in main zpool_main.c:10709
#2 0x7f5115231bf6 in __libc_start_main
#3 0x562a07885eb9 in _start
0x6030000004a8 is located 0 bytes to the right of 24-byte region
allocated by thread T0 here:
#0 0x7f5116ac6b40 in __interceptor_malloc
#1 0x562a07885770 in main zpool_main.c:10699
#2 0x7f5115231bf6 in __libc_start_main
```
This commit passes NULL for these arguments if they are off the end
of the `argv[]` array.
Reviewed-by: George Wilson <gwilson@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes openzfs#12339
oshogbo
pushed a commit
that referenced
this pull request
Oct 15, 2022
Before this patch, in zfs_domount, if zfs_root or d_make_root fails, we leave zfsvfs != NULL. This will lead to execution of the error handling `if` statement at the `out` label, and hence to a call to dmu_objset_disown and zfsvfs_free. However, zfs_umount, which we call upon failure of zfs_root and d_make_root already does dmu_objset_disown and zfsvfs_free. I suppose this patch rather adds to the brittleness of this part of the code base, but I don't want to invest more time in this right now. To add a regression test, we'd need some kind of fault injection facility for zfs_root or d_make_root, which doesn't exist right now. And even then, I think that regression test would be too closely tied to the implementation. To repro the double-disown / double-free, do the following: 1. patch zfs_root to always return an error 2. mount a ZFS filesystem Here's the stack trace you would see then: VERIFY3(ds->ds_owner == tag) failed (0000000000000000 == ffff9142361e8000) PANIC at dsl_dataset.c:1003:dsl_dataset_disown() Showing stack for process 28332 CPU: 2 PID: 28332 Comm: zpool Tainted: G O 5.10.103-1.nutanix.el7.x86_64 #1 Call Trace: dump_stack+0x74/0x92 spl_dumpstack+0x29/0x2b [spl] spl_panic+0xd4/0xfc [spl] dsl_dataset_disown+0xe9/0x150 [zfs] dmu_objset_disown+0xd6/0x150 [zfs] zfs_domount+0x17b/0x4b0 [zfs] zpl_mount+0x174/0x220 [zfs] legacy_get_tree+0x2b/0x50 vfs_get_tree+0x2a/0xc0 path_mount+0x2fa/0xa70 do_mount+0x7c/0xa0 __x64_sys_mount+0x8b/0xe0 do_syscall_64+0x38/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reviewed-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Co-authored-by: Christian Schwarz <christian.schwarz@nutanix.com> Signed-off-by: Christian Schwarz <christian.schwarz@nutanix.com> Closes openzfs#14025
allanjude
pushed a commit
that referenced
this pull request
Oct 17, 2022
`zpool_do_import()` passes `argv[0]`, (optionally) `argv[1]`, and
`pool_specified` to `import_pools()`. If `pool_specified==FALSE`, the
`argv[]` arguments are not used. However, these values may be off the
end of the `argv[]` array, so loading them could dereference unmapped
memory. This error is reported by the asan build:
```
=================================================================
==6003==ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 8 at 0x6030000004a8 thread T0
#0 0x562a078b50eb in zpool_do_import zpool_main.c:3796
#1 0x562a078858c5 in main zpool_main.c:10709
#2 0x7f5115231bf6 in __libc_start_main
#3 0x562a07885eb9 in _start
0x6030000004a8 is located 0 bytes to the right of 24-byte region
allocated by thread T0 here:
#0 0x7f5116ac6b40 in __interceptor_malloc
#1 0x562a07885770 in main zpool_main.c:10699
#2 0x7f5115231bf6 in __libc_start_main
```
This commit passes NULL for these arguments if they are off the end
of the `argv[]` array.
Reviewed-by: George Wilson <gwilson@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes openzfs#12339
rob-wing
pushed a commit
that referenced
this pull request
Feb 17, 2023
Under certain loads, the following panic is hit:
panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1)
cpuid = 17
KDB: stack backtrace:
#0 0xffffffff805e29c5 at kdb_backtrace+0x65
#1 0xffffffff8059620f at vpanic+0x17f
#2 0xffffffff81a27f4a at spl_panic+0x3a
#3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40
openzfs#4 0xffffffff8066fdee at vinactivef+0xde
openzfs#5 0xffffffff80670b8a at vgonel+0x1ea
openzfs#6 0xffffffff806711e1 at vgone+0x31
openzfs#7 0xffffffff8065fa0d at vfs_hash_insert+0x26d
openzfs#8 0xffffffff81a39069 at sfs_vgetx+0x149
openzfs#9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4
openzfs#10 0xffffffff80661c2c at lookup+0x45c
openzfs#11 0xffffffff80660e59 at namei+0x259
openzfs#12 0xffffffff8067e3d3 at kern_statat+0xf3
openzfs#13 0xffffffff8067eacf at sys_fstatat+0x2f
openzfs#14 0xffffffff808b5ecc at amd64_syscall+0x10c
openzfs#15 0xffffffff8088f07b at fast_syscall_common+0xf8
A race condition can occur when allocating a new vnode and adding that
vnode to the vfs hash. If the newly created vnode loses the race when
being inserted into the vfs hash, it will not be recycled as its
usecount is greater than zero, hitting the above assertion.
Fix this by dropping the assertion.
FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700
Signed-off-by: Rob Wing <rob.wing@klarasystems.com>
Sponsored-by: rsync.net
Sponsored-by: Klara, Inc.
rob-wing
pushed a commit
that referenced
this pull request
Feb 17, 2023
Under certain loads, the following panic is hit:
panic: page fault
KDB: stack backtrace:
#0 0xffffffff805db025 at kdb_backtrace+0x65
#1 0xffffffff8058e86f at vpanic+0x17f
#2 0xffffffff8058e6e3 at panic+0x43
#3 0xffffffff808adc15 at trap_fatal+0x385
openzfs#4 0xffffffff808adc6f at trap_pfault+0x4f
openzfs#5 0xffffffff80886da8 at calltrap+0x8
openzfs#6 0xffffffff80669186 at vgonel+0x186
openzfs#7 0xffffffff80669841 at vgone+0x31
openzfs#8 0xffffffff8065806d at vfs_hash_insert+0x26d
openzfs#9 0xffffffff81a39069 at sfs_vgetx+0x149
openzfs#10 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4
openzfs#11 0xffffffff8065a28c at lookup+0x45c
openzfs#12 0xffffffff806594b9 at namei+0x259
openzfs#13 0xffffffff80676a33 at kern_statat+0xf3
openzfs#14 0xffffffff8067712f at sys_fstatat+0x2f
openzfs#15 0xffffffff808ae50c at amd64_syscall+0x10c
openzfs#16 0xffffffff808876bb at fast_syscall_common+0xf8
The page fault occurs because vgonel() will call VOP_CLOSE() for active
vnodes. For this reason, define vop_close for zfsctl_ops_snapshot. While
here, define vop_open for consistency.
After adding the necessary vop, the bug progresses to the following
panic:
panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1)
cpuid = 17
KDB: stack backtrace:
#0 0xffffffff805e29c5 at kdb_backtrace+0x65
#1 0xffffffff8059620f at vpanic+0x17f
#2 0xffffffff81a27f4a at spl_panic+0x3a
#3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40
openzfs#4 0xffffffff8066fdee at vinactivef+0xde
openzfs#5 0xffffffff80670b8a at vgonel+0x1ea
openzfs#6 0xffffffff806711e1 at vgone+0x31
openzfs#7 0xffffffff8065fa0d at vfs_hash_insert+0x26d
openzfs#8 0xffffffff81a39069 at sfs_vgetx+0x149
openzfs#9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4
openzfs#10 0xffffffff80661c2c at lookup+0x45c
openzfs#11 0xffffffff80660e59 at namei+0x259
openzfs#12 0xffffffff8067e3d3 at kern_statat+0xf3
openzfs#13 0xffffffff8067eacf at sys_fstatat+0x2f
openzfs#14 0xffffffff808b5ecc at amd64_syscall+0x10c
openzfs#15 0xffffffff8088f07b at fast_syscall_common+0xf8
This is caused by a race condition that can occur when allocating a new
vnode and adding that vnode to the vfs hash. If the newly created vnode
loses the race when being inserted into the vfs hash, it will not be
recycled as its usecount is greater than zero, hitting the above
assertion.
Fix this by dropping the assertion.
FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700
Signed-off-by: Rob Wing <rob.wing@klarasystems.com>
Submitted-by: Klara, Inc.
Sponsored-by: rsync.net
allanjude
pushed a commit
that referenced
this pull request
Feb 24, 2023
Under certain loads, the following panic is hit:
panic: page fault
KDB: stack backtrace:
#0 0xffffffff805db025 at kdb_backtrace+0x65
#1 0xffffffff8058e86f at vpanic+0x17f
#2 0xffffffff8058e6e3 at panic+0x43
#3 0xffffffff808adc15 at trap_fatal+0x385
openzfs#4 0xffffffff808adc6f at trap_pfault+0x4f
openzfs#5 0xffffffff80886da8 at calltrap+0x8
openzfs#6 0xffffffff80669186 at vgonel+0x186
openzfs#7 0xffffffff80669841 at vgone+0x31
openzfs#8 0xffffffff8065806d at vfs_hash_insert+0x26d
openzfs#9 0xffffffff81a39069 at sfs_vgetx+0x149
openzfs#10 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4
openzfs#11 0xffffffff8065a28c at lookup+0x45c
openzfs#12 0xffffffff806594b9 at namei+0x259
openzfs#13 0xffffffff80676a33 at kern_statat+0xf3
openzfs#14 0xffffffff8067712f at sys_fstatat+0x2f
openzfs#15 0xffffffff808ae50c at amd64_syscall+0x10c
openzfs#16 0xffffffff808876bb at fast_syscall_common+0xf8
The page fault occurs because vgonel() will call VOP_CLOSE() for active
vnodes. For this reason, define vop_close for zfsctl_ops_snapshot. While
here, define vop_open for consistency.
After adding the necessary vop, the bug progresses to the following
panic:
panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1)
cpuid = 17
KDB: stack backtrace:
#0 0xffffffff805e29c5 at kdb_backtrace+0x65
#1 0xffffffff8059620f at vpanic+0x17f
#2 0xffffffff81a27f4a at spl_panic+0x3a
#3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40
openzfs#4 0xffffffff8066fdee at vinactivef+0xde
openzfs#5 0xffffffff80670b8a at vgonel+0x1ea
openzfs#6 0xffffffff806711e1 at vgone+0x31
openzfs#7 0xffffffff8065fa0d at vfs_hash_insert+0x26d
openzfs#8 0xffffffff81a39069 at sfs_vgetx+0x149
openzfs#9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4
openzfs#10 0xffffffff80661c2c at lookup+0x45c
openzfs#11 0xffffffff80660e59 at namei+0x259
openzfs#12 0xffffffff8067e3d3 at kern_statat+0xf3
openzfs#13 0xffffffff8067eacf at sys_fstatat+0x2f
openzfs#14 0xffffffff808b5ecc at amd64_syscall+0x10c
openzfs#15 0xffffffff8088f07b at fast_syscall_common+0xf8
This is caused by a race condition that can occur when allocating a new
vnode and adding that vnode to the vfs hash. If the newly created vnode
loses the race when being inserted into the vfs hash, it will not be
recycled as its usecount is greater than zero, hitting the above
assertion.
Fix this by dropping the assertion.
FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700
Reviewed-by: Andriy Gapon <avg@FreeBSD.org>
Reviewed-by: Mateusz Guzik <mjguzik@gmail.com>
Reviewed-by: Alek Pinchuk <apinchuk@axcient.com>
Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Signed-off-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Submitted-by: Klara, Inc.
Sponsored-by: rsync.net
Closes openzfs#14501
oshogbo
pushed a commit
that referenced
this pull request
Mar 24, 2023
Before this patch, in zfs_domount, if zfs_root or d_make_root fails, we leave zfsvfs != NULL. This will lead to execution of the error handling `if` statement at the `out` label, and hence to a call to dmu_objset_disown and zfsvfs_free. However, zfs_umount, which we call upon failure of zfs_root and d_make_root already does dmu_objset_disown and zfsvfs_free. I suppose this patch rather adds to the brittleness of this part of the code base, but I don't want to invest more time in this right now. To add a regression test, we'd need some kind of fault injection facility for zfs_root or d_make_root, which doesn't exist right now. And even then, I think that regression test would be too closely tied to the implementation. To repro the double-disown / double-free, do the following: 1. patch zfs_root to always return an error 2. mount a ZFS filesystem Here's the stack trace you would see then: VERIFY3(ds->ds_owner == tag) failed (0000000000000000 == ffff9142361e8000) PANIC at dsl_dataset.c:1003:dsl_dataset_disown() Showing stack for process 28332 CPU: 2 PID: 28332 Comm: zpool Tainted: G O 5.10.103-1.nutanix.el7.x86_64 #1 Call Trace: dump_stack+0x74/0x92 spl_dumpstack+0x29/0x2b [spl] spl_panic+0xd4/0xfc [spl] dsl_dataset_disown+0xe9/0x150 [zfs] dmu_objset_disown+0xd6/0x150 [zfs] zfs_domount+0x17b/0x4b0 [zfs] zpl_mount+0x174/0x220 [zfs] legacy_get_tree+0x2b/0x50 vfs_get_tree+0x2a/0xc0 path_mount+0x2fa/0xa70 do_mount+0x7c/0xa0 __x64_sys_mount+0x8b/0xe0 do_syscall_64+0x38/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reviewed-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Co-authored-by: Christian Schwarz <christian.schwarz@nutanix.com> Signed-off-by: Christian Schwarz <christian.schwarz@nutanix.com> Closes openzfs#14025
allanjude
pushed a commit
that referenced
this pull request
Feb 10, 2025
Wasabi have reported the following shape of crash:
Aug 24 19:44:09 C2-R106-U40 kernel: general protection fault, probably for non-canonical address 0xa0bba1ad27732c24: 0000 [#1] SMP NOPTI
...
Aug 24 19:44:09 C2-R106-U40 kernel: RIP: 0010:__mutex_lock.isra.0+0xc2/0x470
...
Aug 24 19:44:09 C2-R106-U40 kernel: Call Trace:
Aug 24 19:44:09 C2-R106-U40 kernel: <TASK>
Aug 24 19:44:09 C2-R106-U40 kernel: ? __wake_up_common_lock+0x8a/0xc0
Aug 24 19:44:09 C2-R106-U40 kernel: __mutex_lock_slowpath+0x13/0x20
Aug 24 19:44:09 C2-R106-U40 kernel: mutex_lock+0x36/0x40
Aug 24 19:44:09 C2-R106-U40 kernel: zil_lwb_flush_vdevs_done+0x1bc/0x380 [zfs]
Aug 24 19:44:09 C2-R106-U40 kernel: zio_done+0x312/0x15f0 [zfs]
Aug 24 19:44:09 C2-R106-U40 kernel: zio_execute+0x92/0xf0 [zfs]
Aug 24 19:44:09 C2-R106-U40 kernel: taskq_thread+0x2bf/0x4d0 [spl]
Aug 24 19:44:09 C2-R106-U40 kernel: ? wake_up_q+0x90/0x90
Aug 24 19:44:09 C2-R106-U40 kernel: ? zio_taskq_member.isra.0.constprop.0+0xa0/0xa0 [zfs]
Aug 24 19:44:09 C2-R106-U40 kernel: ? task_done+0xb0/0xb0 [spl]
Aug 24 19:44:09 C2-R106-U40 kernel: kthread+0x127/0x150
Aug 24 19:44:09 C2-R106-U40 kernel: ? set_kthread_struct+0x50/0x50
Aug 24 19:44:09 C2-R106-U40 kernel: ret_from_fork+0x1f/0x30
Aug 24 19:44:09 C2-R106-U40 kernel: </TASK>
This is a weird one. Its difficult to correlate exactly, but as best I
can tell, this is trying to take either zl_lock or zl_issuer_lock near
the top of zil_lwb_flush_vdevs_done(). Since they're on the
dataset-global zilog_t, and has the same lifetime as zl_lock, its not
entirely clear how this could be a use-after-free or a corruption, yet
that's what it looks like.
No error or disk failure was reported in both the occurrences we've
seen, so it seems unlikely that this was an error, and so io_error
should be zero and so zl_issuer_lock never taken. But, I don't see any
way that zl_lock could really be involved.
I started thinking about the MUTEX_HELD() check when the ZIL is failed
and we need to release zl_issuer_lock, and how its not entirely
symmetrrical with the error check decision to acquire the lock. I can't
think of any path where we could be trying to release zl_issuer_lock
when we don't hold it, but there is an enormously implausible way if we
were to leak zl_issuer_lock on the same taskq thread that eventually
calls zil_lwb_flush_vdevs_done(), and then and up falsely acquiring or
releasing it. I don't think that's even in play, but I did see that it
was silly to take zl_issuer_lock if we're not actually going to fail the
ZIL, and instead we can just trade locks if we need to.
I still don't see how this solves the actual problem though, sigh.
(cherry picked from commit dda0e91eadc47703f4e3910e2efc1738139ef1a7)
Signed-off-by: Allan Jude <allan@klarasystems.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation and Context
Description
How Has This Been Tested?
Types of changes
Checklist:
Signed-off-by.