Date: Sun, 18 Dec 2005 15:40:16 -0600 From: Alan Cox <alc@cs.rice.edu> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Alan Cox <alc@FreeBSD.org>, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern imgact_elf.c src/sys/vm vm_extern.h vm_glue.c Message-ID: <20051218214016.GA10163@cs.rice.edu> In-Reply-To: <20051218032053.GD80713@garage.freebsd.pl> References: <200512161834.jBGIYEnv092676@repoman.freebsd.org> <20051218032053.GD80713@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 18, 2005 at 04:20:53AM +0100, Pawel Jakub Dawidek wrote: > On Fri, Dec 16, 2005 at 06:34:14PM +0000, Alan Cox wrote: > +> alc 2005-12-16 18:34:14 UTC > +> > +> FreeBSD src repository > +> > +> Modified files: > +> sys/kern imgact_elf.c > +> sys/vm vm_extern.h vm_glue.c > +> Log: > +> Use sf_buf_alloc() instead of vm_map_find() on exec_map to create the > +> ephemeral mappings that are used as the source for three copy > +> operations from kernel space to user space. There are two reasons for > +> making this change: (1) Under heavy load exec_map can fill up causing > +> vm_map_find() to fail. When it fails, the nascent process is aborted > +> (SIGABRT). Whereas, this reimplementation using sf_buf_alloc() > +> sleeps. (2) Although it is possible to sleep on vm_map_find()'s > +> failure until address space becomes available (see kmem_alloc_wait()), > +> using sf_buf_alloc() is faster. Furthermore, the reimplementation > +> uses a CPU private mapping, avoiding a TLB shootdown on > +> multiprocessors. > > I got panic on boot with this change (maybe because I've DEBUG_VFS_LOCKS > compiled into the kernel): > > Trying to mount root from ufs:/dev/ad0s1a > KDB: stack backtrace: > vfs_badlock() at vfs_badlock+0x95 > assert_vop_locked() at assert_vop_locked+0x77 > VOP_GETPAGES_APV() at VOP_GETPAGES_APV+0x8a > vnode_pager_getpages() at vnode_pager_getpages+0x92 > vm_imgact_map_page() at vm_imgact_map_page+0x84 > elf64_load_section() at elf64_load_section+0xe9 > exec_elf64_imgact() at exec_elf64_imgact+0x336 > kern_execve() at kern_execve+0x457 > execve() at execve+0x5d > start_init() at start_init+0x249 > fork_exit() at fork_exit+0xbb > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffffb280dd40, rbp = 0 --- > VOP_GETPAGES: 0xffffff0009848200 is not locked but should be > KDB: enter: lock violation > [thread pid 1 tid 100004 ] > Stopped at kdb_enter+0x2f: nop > Yes, DEBUG_VFS_LOCKS is showing that I need to update the VOP locking. Thanks. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051218214016.GA10163>