Date: Wed, 20 Jun 2012 16:25:42 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Alan Cox <alc@freebsd.org>, Steve Wills <swills@freebsd.org>, Konstantin Belousov <kib@freebsd.org>, current@freebsd.org Subject: Re: panic with out of memory Message-ID: <20120620132542.GW2337@deviant.kiev.zoral.com.ua> In-Reply-To: <201206200819.39256.jhb@freebsd.org> References: <4FE127D3.8070502@FreeBSD.org> <201206200819.39256.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120620132542.GW2337>