Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sat, 25 Mar 2017 11:45:29 +0200
On Fri, Mar 24, 2017 at 08:31:42PM -0700, Gleb Smirnoff wrote:
>   Darren,
> 
> On Sat, Mar 25, 2017 at 03:03:14AM +0200, Konstantin Belousov wrote:
> K> On Fri, Mar 24, 2017 at 05:40:15PM +0000, Darren wrote:
> K> > I am getting this panic every hour to every couple of hours.
> K> > 
> K> > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23 14:56:45 EDT 2017šššš darren_at_asrock:/usr/obj/usr/src/sys/GENERICš amd64
> K> > I manually typed out the following, apologize for any typos. 
> K> > 
> K> > 
> K> > panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited
> K> > cpuid = 0
> K> > time = 1490372797
> K> > KDB: stack backtrace:
> K> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0072e33690
> K> > vpanic() at vpanic+0x19c/frame 0xfffffe0072e33710
> K> > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0072e33780
> K> > sleepq_add() at sleepq_add+0x34f/frame 0xfffffe0072337d0
> K> > _sleep() at _sleep+0x28d/frame 0xfffffe0072e33870
> K> > soclose() at soclose+0xda/frame 0xfffffe0072e338b0
> K> > _fdrop() at _fdrop+0x1a/frame 0xfffffe0072e338d0
> K> > sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfffffe0072e33910
> K> > vnode_pager_generic_getpages_done_async() at vnode_pager_generic_getpages_done_async+037/frame 0xfffffe0072e33930
> K> > bufdone() at bufdone+0x64/frame 0xfffffe0072e33960
> K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e339b0
> K> > g_io_deliver() at g_io_deliver+0x276/frame 0xfffffe0072e33a00
> K> > g_disk_done() at g_disk_done+0x104/frame 0xfffffe0072e33a40
> K> > xpt_done_process() at xpt_done_process+0x35f/frame 0xfffffe0072e33a80
> K> > xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfffffe0072e33af0
> K> > ahci_itr() at ahci_intr+0x102/frame 0xfffffe0072e33b20
> K> > intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 0xfffffe0072e33b60
> K> > ithread_loop() at ithread_loop+0xb6/frame 0xfffffe0072e33bb0
> K> > fork_exit() at fork_exit+0x84/frame 0xfffffe0072e33bf0
> K> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0072e33bf0
> K> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> K> > KDB: enter: panic
> K> > [ thread pid 12 tid 100038 ]
> K> > Stopped atššššš kdb_enter+0x3b: movqššš $0,kdb_why
> K> > db>
> K> 
> K> Indeed, the context where sendfile_iodone() is executed, cannot call fdrop().
> 
> Can you please test the attached patch?
> 
> -- 
> Totus tuus, Glebius.

> Index: sys/kern/kern_sendfile.c
> ===================================================================
> --- sys/kern/kern_sendfile.c	(revision 315926)
> +++ sys/kern/kern_sendfile.c	(working copy)
> _at__at_ -296,8 +296,9 _at__at_ sendfile_iodone(void *arg, vm_page_t *pg, int coun
>  		CURVNET_RESTORE();
>  	}
>  
> -	/* XXXGL: curthread */
> -	fdrop(sfio->sock_fp, curthread);
> +	ACCEPT_LOCK();
> +	SOCK_LOCK(so);
> +	sorele(so);
>  	free(sfio, M_TEMP);
>  }
>  
> _at__at_ -860,7 +861,9 _at__at_ prepend_header:
>  		} else {
>  			sfio->sock_fp = sock_fp;
>  			sfio->npages = npages;
> -			fhold(sock_fp);
> +			SOCK_LOCK(so);
> +			soref(so);
> +			SOCK_UNLOCK(so);
>  			error = (*so->so_proto->pr_usrreqs->pru_send)
>  			    (so, PRUS_NOTREADY, m, NULL, NULL, td);
>  			sendfile_iodone(sfio, NULL, 0, 0);

With this patch, what prevents a close of the sfio->sock_fp file, which is
needed to get the pointer to socket ?
Received on Sat Mar 25 2017 - 08:45:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC