Mounting a zpool on 32-bit platforms panics
Mounting a zpool on a 32-bit system triggers a panic in spa_history_log_version() due to a type format mismatch for ZPL_VERSION. ZPL_VERSION is a unsigned long long, but the format expects an integer. On 64-bit platforms this may not be an issue due to word size and alignment. On 32-bit platforms a word size is half that of a long long, causing the second word of the long long to be seen as the string pointer for utsname.nodename.
Updated by Justin Hibbits about 3 years ago
Vitaliy, here's the backtrace (pulled from a pastebin I posted when I hit it):
fatal kernel trap: exception = 0x300 (data storage interrupt) virtual address = 0x4 esr = 0x0 srr0 = 0xc054f4f8 srr1 = 0x21000 lr = 0xc04a44e4 curthread = 0xcf4abae0 pid = 737, comm = zpool [ thread pid 737 tid 100104 ] Stopped at strlen+0x20: lwz r11, 0x0(r8) db> bt Tracing pid 737 tid 100104 td 0xcf4abae0 0xfe79f3b0: at kvprintf+0xa74 0xfe79f470: at vsnprintf+0x44 0xfe79f490: at spa_history_create_obj+0x76c 0xfe79f4d0: at spa_history_log_internal+0xf4 0xfe79f520: at spa_history_log_version+0x94 0xfe79f550: at spa_create+0x904 0xfe79f5c0: at zfs_set_prop_nvlist+0x1278 0xfe79f610: at zfs_secpolicy_share+0x954 0xfe79f670: at dev2udev+0x3b0 0xfe79f6b0: at VOP_IOCTL_APV+0x134 0xfe79f6d0: at vn_open+0x1c8 0xfe79f7c0: at devfs_unmount_final+0x5e0 0xfe79f7e0: at kern_ioctl+0x2c4 0xfe79f830: at sys_ioctl+0x128 0xfe79f8f0: at trap+0x49c 0xfe79fa80: user SC trap by 0x41a93ab8: srr1=0x202d000 r1=0x7fffaf60 cr=0x24022048 xer=0 ctr=0x41a93ab0
This is on FreeBSD 12-CURRENT as of last week, on powerpc.powerpcspe arch.
Updated by Electric Monk about 3 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit b11fe8c01471a5bff68e83e1fe5f809ad16b3be8 Author: Justin Hibbits <firstname.lastname@example.org> Date: 2017-07-25T19:16:48.000Z 8508 Mounting a zpool on 32-bit platforms panics Reviewed by: Matt Ahrens <email@example.com> Approved by: Dan McDonald <firstname.lastname@example.org>