From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:16:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F4991065674 for ; Tue, 17 Aug 2010 16:16:36 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 20F878FC1F for ; Tue, 17 Aug 2010 16:16:35 +0000 (UTC) Received: by pvg4 with SMTP id 4so2968644pvg.13 for ; Tue, 17 Aug 2010 09:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9OfaXfjcPQYQRQc+Qjlzh+/4+b7jCLk13xSI6L+AZtQ=; b=jgWlDeztHmjdW/8/UEVpekT6qvr6lL+3VyscPPJRSnbdB4fs/zhbj9vDNlTs/idyCg RH57MWmho47Sf45NyfAUK6Twa4zDfpgZOcgzL3NtjqD5J17Adz+H0I+EhISZrcxoIS83 P4sQOIrvK/ROqtuZZpuJxlzDaBGvC3+uxmxyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BEAEqY9ObzvMm3yjHHMwFTEmirXkwI/e89ba3MYPkdv/tx5D+7I4IBL3O9v/WQ0bsc Ijv1pcO+juXhIExHvq3xYCOsZ/9a1wOOEFDOKASvzXHsxY2l6dmHtrp1QLzPvIqtWu8q bqUch6RFvTinRRbNXq3msFD1FRxx3InfWxyxs= MIME-Version: 1.0 Received: by 10.115.47.13 with SMTP id z13mr8127063waj.30.1282061795351; Tue, 17 Aug 2010 09:16:35 -0700 (PDT) Received: by 10.220.72.4 with HTTP; Tue, 17 Aug 2010 09:16:34 -0700 (PDT) In-Reply-To: <20100817160445.GO2396@deviant.kiev.zoral.com.ua> References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> <20100817160445.GO2396@deviant.kiev.zoral.com.ua> Date: Tue, 17 Aug 2010 16:16:34 +0000 Message-ID: From: Matthew Fleming To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: pluknet , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 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: Tue, 17 Aug 2010 16:16:36 -0000 On Tue, Aug 17, 2010 at 4:04 PM, Kostik Belousov wrote: > On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote: >> 2010/8/16 Kostik Belousov : >> > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote: >> >> On 16 August 2010 21:05, pluknet wrote: >> >> > Hi. >> >> > >> >> > Seeing on mostly idle, recently updated current, while closing a file. >> >> > Presumably never reported on ML. >> [...] >> >> >> > Both LORs are valid. The fork performed deep inside the VFS call stack >> > is obviously problematic. As a workaround, you may fix the number of >> > nfsiods. >> > >> > Proper fix might consist of creating a shepherd thread which only task >> > is to act on the requests on creating new nfsiods. >> > >> > Would you try to implement this ? I will provide the assistance, if needed. >> >> Hmm.. I tried to move kproc_create() under shepherd thread and now stuck >> with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b. >> Did I screw up something? >> See weird draft patch attached (weird, as I have no idea how to nicely >> exchange data between nfs_nfsiodnew() and shep_thread() thread). > Most likely, you loose the requests to create nfsiods since the > existing request in the global variable shep_chan can be overwritten > by new request. You should either sleep till existing request is serviced, > or form a queue. If you sleep for the request to be serviced, this presumably has the same LOR/deadlock possibility (unless locks are released before sleep), except now WITNESS can't see the LOR. Thanks, matthew