Skip site navigation (1)Skip section navigation (2)
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>