Project

General

Profile

Bug #11047

zmod: make sure we use zmemcpy and friends

Added by Igor Kozhukhov 5 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
kernel
Start date:
2019-05-17
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

The problem is that we do not really have memcpy in early kernel, so the zlib build needs to use wrapper (zmod_subr.c) and we did miss that.

The z_inflate() calling zmemcpy() for COPY blocks did result with wrong %rsp and that did start the whole chain of events ending up with trap and failed boot. What exactly is to blow up depends on the registers we restore when returning from z_inflate(). The later consumers never see the issue because once we have genunix linked, we have functional mem* family functions.


Related issues

Related to illumos gate - Bug #10697: zmod: use zlib-1.2.11Closed2019-04-06

Actions

History

#1

Updated by Andy Fiddaman 5 months ago

Igor has confirmed that reverting the change from 10697 fixes this problem.

In OmniOS, I tried:

# beadm create test
# beadm mount test /a
# bootadm update-archive -R /a -F hsfs -f
# beadm umount test
# beadm activate test
# init 6

and got

Loading unix...
Loading /platform/i86pc/amd64/boot_archive...
Loading /platform/i86pc/amd64/boot_archive.hash...
Booting...
/kernel/amd64/genunix bad shndx in symbol 1
genunix error reading symbols
Unexpected trap
error code           0x0
instruction pointer  0xfffffffffb83a7f0
code segment         0x28
flags register       0x10082
return %rsp          0xfffffffffbc90340
return %ss           0x8
%cr2                    0x0
Attempting stack backtrace:
Stack traceback:
  do_splx+30
  panicsys+3e
  vpanic+15c
  param_preset+0
  mutex_exit_critical_size+2617c
  rw_enter_sleep+366
  mutex_exit_critical_size+4fd9e
  kobj_load_module+15f
  mutex_exit_critical_size+4e704
  kobj_init+190
  _kobj_boot+5f
  _start+1b7
Unexpected trap
error code           0x0
instruction pointer  0xfffffffffb83a7f0
code segment         0x28
flags register       0x10086
return %rsp          0xfffffffffbc8fea0
return %ss           0x8
%cr2                    0x0
Attempting stack backtrace:
Stack traceback:
  do_splx+30
  panicsys+3e
  vpanic+15c
  param_preset+0
  mutex_exit_critical_size+201d0
  mutex_vector_enter+347
  kobj_getsymname+7b
  bop_traceback+84
  bop_trap+102
  _cmntrap_size+114
  panicsys+3e
  vpanic+15c
  param_preset+0
  mutex_exit_critical_size+2617c
  rw_enter_sleep+366
  mutex_exit_critical_size+4fd9e
  kobj_load_module+15f
  mutex_exit_critical_size+4e704
  kobj_init+190
  _kobj_boot+5f
  _start+1b7
Nested trap
Press any key to reboot.
#2

Updated by Andy Fiddaman 5 months ago

  • Related to Bug #10697: zmod: use zlib-1.2.11 added
#3

Updated by x v 5 months ago

Seeing the same, likely when the system being updated doesn't have the fix for #9721.

# file /platform/i86pc/amd64/boot_archive
/platform/i86pc/amd64/boot_archive: ISO 9660 filesystem image

#4

Updated by Toomas Soome 5 months ago

x void wrote:

Seeing the same, likely when the system being updated doesn't have the fix for #9721.
[...]

The problem is indeed related to hsfs (also likely to ufs as both hsfs and ufs BA can have compressed files), specifically the implementation about reading compressed files from BA at the time of early boot. (usr/src/common/fs/decompress.c). Still investigating what is really happening there because uncompressing and reading unix is ok, the error does manifest while reading the last bytes of genunix.

#5

Updated by Toomas Soome 4 months ago

  • Subject changed from #10697 break hsfs boot_archive type to zmod: make sure we use zmemcpy and friends
  • Description updated (diff)
  • Category set to kernel
  • Status changed from New to In Progress
  • Assignee set to Toomas Soome
  • % Done changed from 0 to 90
  • Tags deleted (needs-triage)
#6

Updated by Toomas Soome 4 months ago

Testing done: confirmed the hsfs with compressed files is usable for boot_archive

#7

Updated by Toomas Soome 4 months ago

  • Description updated (diff)
#8

Updated by Electric Monk 4 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

git commit 535ff4fc926c4df67c4665a72c71724810962d4f

commit  535ff4fc926c4df67c4665a72c71724810962d4f
Author: Toomas Soome <tsoome@me.com>
Date:   2019-06-18T17:26:24.000Z

    11047 zmod: make sure we use zmemcpy and friends
    Reviewed by: Andy Fiddaman <andy@omniosce.org>
    Reviewed by: Gergő Doma <domag02@gmail.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Also available in: Atom PDF