moving from misc@ to bugs@

On Sun, Jun 24, 2018 at 12:37:45PM +0200, Walter Alejandro Iglesias wrote:
> Hello,
> 
> I had a kernel panic while reproducing a video with mpv.
> 
> It's my first kernel panic with OpenBSD, so I didn't know how to use
> ddb(4).  Since I'm running my http and smtp server in this machine I
> cannot entertain myself too much reproducing the panic to get more info.
> That's why I don't include the per cpu trace and other additonal info as
> explained in ddb.html, sorry!  But, if you need it let me knonw and I'll
> try my best.
> 
> 
> Message automatically dumped:
> ===============================================================
> panic: mtx 0xffffffff81c86470: locking against myself
> Stopped at      db_enter+0x12:  popq    %r11
>     TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND                    
>   
>  
>  104021  96401   1000         0x3  0x4000000    2  mpv                        
>   
>   
> *402610  50624   1000        0x32          0    0K Xorg                       
>   
>   
> db_enter() at db_enter+0x12
> panic() at panic+0x138
> __mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5
> _mtx_enter(ffffffff81cf3e60,ffffffff81a5d6a2,0) at _mtx_enter+0x5a
> printf(c9ef1007dec621e0) at printf+0x70
> witness_checkorder(2e4447d1b3cbb9af,ffffffff81c2ac7c,32a,0,ffffffff81da6d00) 
> at 
> witness_checkorder+0x943
> ___mp_lock(ffff8000330cd760,d,7) at ___mp_lock+0x70
> selwakeup(e80faaebded7c1a2) at selwakeup+0x9c
> ptsstart(8ce5939828d5e23) at ptsstart+0x79
> tputchar(174549bf676e909c,ffff800000afa400) at tputchar+0x85
> kputchar(75d50501b895e9e4,0,ffffffff81a5d6a2) at kputchar+0x91
> kprintf() at kprintf+0xe8
> printf(c9ef1007dec621e0) at printf+0x85
> witness_checkorder(2e4447d1b3cba2fe,ffffffff81af9df1,298,ffffffff81c8a678,ffffff
> ff81c8a688) at witness_checkorder+0x943
> end trace frame: 0xffff80003302e978, count: 0
> 

I think I might already see such problem while doing some debug-printf
in kernel. so I should not be related to mpv.

It is a witness issue when a lock ordering problem is found while under
printf(9).

kern/subr_prf.c
   503  int
   504  printf(const char *fmt, ...)
   505  {
   506          va_list ap;
   507          int retval;
   508
   509
   510          va_start(ap, fmt);
   511          mtx_enter(&kprintf_mutex);
   512          retval = kprintf(fmt, TOCONS | TOLOG, NULL, NULL, ap);
   513          mtx_leave(&kprintf_mutex);
   514          va_end(ap);
   515          if (!panicstr)
   516                  logwakeup();
   517
   518
   519          return(retval);
   520  }

printf(9) enter in `kprintf_mutex' to use kprintf().

but as witness_checkorder() might want to use printf(9), it could result
in deadlock situation (calling printf(9) from printf(9)).

I dunno what would be the right solution. Maybe witness should use
kprintf() directly (without taking kprintf_mutex) ? but it could result
in mangled output.

-- 
Sebastien Marie

Reply via email to