From owner-freebsd-current@FreeBSD.ORG Wed Jun 20 13:25:52 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFFF11065670; Wed, 20 Jun 2012 13:25:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 48C6D8FC1F; Wed, 20 Jun 2012 13:25:52 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5KDPhju015269; Wed, 20 Jun 2012 16:25:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5KDPglk073341; Wed, 20 Jun 2012 16:25:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5KDPg5p073340; Wed, 20 Jun 2012 16:25:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Jun 2012 16:25:42 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120620132542.GW2337@deviant.kiev.zoral.com.ua> References: <4FE127D3.8070502@FreeBSD.org> <201206200819.39256.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UaNe/QI5+zQ8JiGR" Content-Disposition: inline In-Reply-To: <201206200819.39256.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Alan Cox , Steve Wills , Konstantin Belousov , current@freebsd.org Subject: Re: panic with out of memory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 13:25:52 -0000 --UaNe/QI5+zQ8JiGR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 20, 2012 at 08:19:39AM -0400, John Baldwin wrote: > On Tuesday, June 19, 2012 9:30:59 pm Steve Wills wrote: > > Hi, > >=20 > > I just got a panic out of my r237195 system. The panic looks like: > >=20 > > Sleeping thread (tid 173153, pid 42034) owns a non-sleepable lock > > KDB: stack backtrace of thread 173153: > > sched_switch() at sched_switch+0x28a > > mi_switch() at mi_switch+0xdf > > sleepq_timedwait() at sleepq_timedwait+0x3a > > _sleep() at _sleep+0x266 > > swp_pager_meta_build() at swp_pager_meta_build+0x259 > > swap_pager_copy() at swap_pager_copy+0x17b > > vm_object_collapse() at vm_object_collapse+0x123 > > vm_object_deallocate() at vm_object_deallocate+0x457 > > vm_map_process_deferred() at vm_map_process_deferred+0x72 > > vm_pageout_oom() at vm_pageout_oom+0x180 > > swp_pager_meta_build() at swp_pager_meta_build+0x248 > > swap_pager_copy() at swap_pager_copy+0x17b > > vm_object_collapse() at vm_object_collapse+0x123 > > vm_object_deallocate() at vm_object_deallocate+0x457 > > vm_map_process_deferred() at vm_map_process_deferred+0x72 > > vm_map_remove() at vm_map_remove+0x116 > > exec_new_vmspace() at exec_new_vmspace+0x1bc > > exec_elf64_imgact() at exec_elf64_imgact+0x5f4 > > kern_execve() at kern_execve+0x6f0 > > sys_execve() at sys_execve+0x37 > > amd64_syscall() at amd64_syscall+0x351 > > Xfast_syscall() at Xfast_syscall+0xfb > > --- syscall (59, FreeBSD ELF64, sys_execve), rip =3D 0x800d2eddc, rsp = =3D > > 0x7fffffffd328, rbp =3D 0x7fffffffd470 --- > > panic: sleeping thread > > cpuid =3D 4 > >=20 > > The system was very busy and using lots of swap, but I didn't expect a > > panic. If any more detail is needed or I should just get more RAM, let > > me know. :) >=20 > Hmm, this is due to a bug I noticed recently as well. I had been talking > with Alan and Konstantin about the proper fix. Hmm, thinking abou this s= ome=20 > more, perhaps a simpler fix would be to have a 'I'm already in=20 > vm_map_process_deferred()' flag. Or even better, just move the entire li= st > off into a static variable so that we don't get caught in recursion. =20 > Something like this: >=20 > Index: vm_map.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- vm_map.c (revision 237227) > +++ vm_map.c (working copy) > @@ -475,12 +475,14 @@ static void > vm_map_process_deferred(void) > { > struct thread *td; > - vm_map_entry_t entry; > + vm_map_entry_t entry, next; > vm_object_t object; > =20 > td =3D curthread; > - while ((entry =3D td->td_map_def_user) !=3D NULL) { > - td->td_map_def_user =3D entry->next; > + entry =3D td->td_map_def_user; > + td->td_map_def_user =3D NULL; > + while (entry !=3D NULL) { > + next =3D entry->next; > if ((entry->eflags & MAP_ENTRY_VN_WRITECNT) !=3D 0) { > /* > * Decrement the object's writemappings and > @@ -494,6 +496,7 @@ vm_map_process_deferred(void) > entry->end); > } > vm_map_entry_deallocate(entry, FALSE); > + entry =3D next; > } > } Yes, looks like it should work. --UaNe/QI5+zQ8JiGR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/hz1YACgkQC3+MBN1Mb4gVygCfb88O82yoKTj+UYr5DAMugtqU 4aAAoL+tqXTrZDWkIYKpDvGEgQYT1BVI =x/PV -----END PGP SIGNATURE----- --UaNe/QI5+zQ8JiGR--