Re: panic: mutex Giant owned at ../../../kern/kern_thread.c:1341

Dan Nelson wrote:
> In the last episode (Mar 28), Dan Nelson said:
> 
>>Got this running an ibcs2_coff binary on today's kernel:
>>
>>(kgdb) where
>>#6  0xc7c1dd5b in ibcs2_wait (td=0xc7ef5540, uap=0x0)
>>    at /usr/src/sys/i386/ibcs2/ibcs2_misc.c:164
> 
> 
> I think this is due to ibcs2_wait being left out when wait4() was
> converted to giant-free (giant-allergic actually).  The following seems
> to fix it:
> 
> Index: syscalls.master
> ===================================================================
> RCS file: /mnt/emssrv5/home/ncvs/src/sys/i386/ibcs2/syscalls.master,v
> retrieving revision 1.17
> diff -u -r1.17 syscalls.master
> --- syscalls.master	6 Feb 2004 20:20:07 -0000	1.17
> +++ syscalls.master	28 Mar 2004 22:00:40 -0000
> _at__at_ -37,7 +37,7 _at__at_
>  4	MNOPROTO { int write(int fd, char *buf, u_int nbytes); }
>  5	STD	{ int ibcs2_open(char *path, int flags, int mode); }
>  6	MNOPROTO { int close(int fd); }
> -7	STD	{ int ibcs2_wait(int a1, int a2, int a3); }
> +7	MSTD	{ int ibcs2_wait(int a1, int a2, int a3); }
>  8	STD	{ int ibcs2_creat(char *path, int mode); }
>  9	NOPROTO	{ int link(char *path, char *link); }
>  10	STD	{ int ibcs2_unlink(char *path); }
> 
> 

I agree that this is appropriate.  However, ibcs2_wait() might need to
have some proc locks sprinkled into it.  It would be good to have
someone like John Baldwin comment on it.

Scott